跳转到主要内容

​
生产环境二次验证与审批

​
适用对象

本页面向会发起生产环境变更的操作者、CLI/Agent 使用者，以及设计 prod 门禁的实现者。

​
目标与范围

本页回答三件事：
  1. 哪些 prod 操作默认需要 approval
  2. step-up 与 approval 在执行链中的位置
  3. 为什么 Web、CLI、Agent 必须共享同一套门禁语义

​
核心概念

​
step-up

step-up 指在高风险操作前提升身份保证级别，例如：
  • 重新确认会话
  • 二次验证
  • 更强的 token 约束

​
approval

approval 是对高风险生产变更的显式授权记录。其语义不是“顺便确认一下”，而是：
  • 明确谁申请了什么操作
  • 在什么环境和资源上执行
  • 由谁批准
  • 是否已被消费

​
需要 approval 的默认场景

  • prod 环境部署创建 / 更新 / 回滚
  • prod 写数据库操作
  • prod 删除对象存储对象
  • prod 集群安装/高风险运维动作

​
标准流程

AuthN -> AuthZ(require_approval) -> Approval -> ValidateBinding -> Execute -> Audit 绑定校验至少包含：
  • subject_id
  • env
  • resource_hash
  • action
CLI / Agent 场景推荐额外绑定：
  • command_hash

​
CLI 示例

aios approval request \
  --action deploy.app.update \
  --resource app:project/prod/my-api

aios app up --env prod

​
Web UI 路径

  • 应用详情页发起 prod 变更
  • 系统弹出 step-up / approval 流程
  • 审批中心查看票据状态与消费情况

​
常见问题 / 风险提示

  • approval 不是对 AuthZ 的替代，而是 AuthZ 的一个决策分支。
  • approval ticket 成功消费后必须失效，防止重放。
  • 如果某个入口可以绕过这条链直接在 prod 执行变更，这属于严重设计缺陷。

​
相关页面