多云访问权限评审（IGA）实战：认证活动设计、职责分离 SoD 与审计举证闭环（2026）

访问权限评审（IGA，Identity Governance and Administration）是多云合规里最容易被做成形式主义的一环：企业把"最小权限"写进制度、把 RAM/IAM 策略收得很紧，却在审计时拿不出"这些权限在过去一个周期内仍然必要"的证据。本文给出一套可直接落地的闭环：先用 AWS Access Analyzer 的未使用权限分析（按 IAM 角色与用户数以每主体每月 0.20 美元计费）、IAM 凭据报告，以及阿里云 RAM、腾讯云 CAM 的清单接口把"谁有什么"导成统一快照；再用职责分离（SoD）规则引擎做静态冲突检测；然后按主体类型分配评审人与周期（特权 90 天、生产 180 天、只读 365 天）；最后把"批准撤销"变成 IaC 变更而不是控制台手删。文中含一次 400 人、460 个主体的季度评审成本复算：人工基线 338.8 小时/年、约 20,328 美元，自动化后 174.8 小时/年、合计 12,792 美元，工时降 48.4%、总成本降 37.1%。

Meta Description: 多云访问权限评审（IGA）实战：AWS Access Analyzer 未使用权限分析、阿里云 RAM 与腾讯云 CAM 权限快照归一化、SoD 冲突规则、认证活动设计与 400 人规模成本复算。

关键词：访问权限评审、IGA、访问认证活动、职责分离、SoD、权限蔓延、多云合规、SOC 2、ISO 27001

前言

出海企业的合规审计有一个共同特征：审计师不问"你们的策略写得严不严"，而问"你多久证明一次这些权限还有人用、还有必要"。前者是配置问题，一次性就能答完；后者是流程问题，需要连续多个周期的证据链。

这条链最容易断在三个地方。第一，权限清单不完整——只拉了"直接绑定到用户"的策略，漏掉用户组继承和角色链继承，覆盖率看起来 98%，实际 70%。第二，只有清单没有使用证据——评审人面对一张"张三有 43 项权限"的表，只能全部点"批准"，因为没人知道哪条三个月没被用过。第三，决策不落地——评审会开完、Excel 签了字，线上权限一条没变，下一个周期同样的问题再来一遍。

本文不讲 IGA 的产品概念，只讲工程实现：怎么把三家云的权限导成同一张表、怎么用官方的使用数据减少评审人的判断负担、怎么把 SoD 规则写成代码在 CI 里跑、以及怎么让"撤销"这个动作真的发生并且可以举证。

一、为什么"已经最小权限"的组织仍会被审计打回

最小权限（least privilege）描述的是授予时刻的属性：这条策略是否只包含完成工作所必需的动作和资源。权限蔓延（privilege creep）描述的是时间维度的问题：随着项目迭代、人员轮岗、故障应急，权限只增不减，三年后一个"只负责报表"的账号拥有生产数据库的写权限。

这两件事的治理手段完全不同。前者靠策略评审、Permission Boundary、SCP 和访问分析器；后者只能靠周期性认证——把"这条权限还要不要"这个问题，定期推给一个有权回答它的人，并留下他回答过的记录。

审计标准里的落点很明确：

注意 A.5.18 的措辞是"at regular intervals"——它不要求你实时完美，它要求你有节奏、有记录、有回收。反过来说，一个每季度真跑、证据完整的评审活动，比一个号称"实时最小权限"但拿不出记录的系统更容易过审。

三种最常见的"假最小权限"现场：

1. 角色只增不减。为一次故障开的 prod-emergency-admin 角色，故障结束后没人删，半年后成了值班人员的日常入口。这类角色通常还带 iam:* 或 sts:AssumeRole 的宽授权。
2. 权限靠复制。新人入职时"照着小王的权限配一份"，小王的权限本身是三年前堆出来的。复制不会引入新的越权，但会把历史债务按人数放大。
3. 服务账号无主。CI/CD、监控 Agent、备份任务用的访问密钥，创建人是已离职的工程师，业务方说"不敢删，怕流水线挂"。这类主体在任何"按人评审"的流程里都是盲区。

第三条尤其致命：多数企业的评审活动按"员工名单"组织，而云上真正高权限的主体里，有相当比例是非人类身份（NHI）。如果把服务账号排除在评审范围外，审计师抽样抽到一个三个月未轮转的 CI 密钥，整个控制项就会被判失效。

二、访问评审的四个环节与三类证据

把 IGA 拆成工程环节，只有四步，每步都有明确的输入输出：

对应地，审计师会索要三类证据，缺一类就要解释：

• 清单快照：某个时间点上"谁（主体）对什么（资源/动作）有什么权限"。要求可复现——同一个脚本、同一天重跑，结果一致。
• 使用证据：这条权限在过去 N 天内是否被使用过。这一条决定了评审是"判断"还是"盖章"。
• 决策记录：谁、在什么时间、基于什么理由，批准或撤销了哪一条权限。要求能对应到具体主体和具体权限项，而不是"本季度已完成权限复核"一句话。

这里有一个常见误解需要先破掉：认证（attestation）不是技术审计。技术审计问"配置是否符合基线"，认证问"业务上是否仍然需要"。所以评审人不能是安全团队——安全团队没有立场判断"财务系统分析师是否需要导出全部凭证"，只有该员工的直属经理或该系统 Owner 能回答。安全团队的角色是设计流程、提供证据、抽样复核、跟踪回收，而不是替业务做决定。

三、架构图：一次季度评审活动的数据流

下面是一条可落地的最小链路。左侧是采集，中间是归一化与规则，右侧是决策与执行。整条链路的关键设计是：采集与决策解耦，采集每周跑一次自动落库，决策按周期批量发起；这样评审人看到的永远是最新快照，而不是活动启动那天导出的过期 Excel。

flowchart LR
    subgraph CLOUD["云账号层"]
        A1["AWS 组织<br/>12 个账号"]
        A2["阿里云 RAM<br/>主账号 + 资源目录"]
        A3["腾讯云 CAM<br/>主账号 + 成员账号"]
    end

    subgraph COLLECT["采集层（每周定时）"]
        B1["IAM API<br/>list-users / list-roles"]
        B2["RAM API<br/>ListUsers / ListPoliciesForUser"]
        B3["CAM API<br/>ListUsers / ListAttachedUserPolicies"]
    end

    subgraph NORM["归一化与证据"]
        C1["统一主体-权限表<br/>subject / entitlement / last_used"]
        C2["使用证据<br/>Access Analyzer / 凭据报告 / 审计日志"]
        C3["SoD 规则引擎<br/>冲突对 + 例外台账"]
    end

    subgraph REVIEW["认证活动"]
        D1["按主体类型分配周期<br/>特权90d 生产180d 只读365d"]
        D2["评审任务分发<br/>经理 + 资源 Owner 双轨"]
        D3["决策<br/>批准 / 撤销 / 降级 / 限期例外"]
    end

    subgraph EXEC["回收与举证"]
        E1["IaC 变更<br/>Terraform PR + apply"]
        E2["线上验证<br/>权限探针 + 403 计数"]
        E3["证据包<br/>快照 + 决策 + 执行回执"]
    end

    A1 --> B1
    A2 --> B2
    A3 --> B3
    B1 --> C1
    B2 --> C1
    B3 --> C1
    C1 --> C2
    C2 --> C3
    C3 --> D1
    D1 --> D2
    D2 --> D3
    D3 --> E1
    E1 --> E2
    E2 --> E3
    E3 -.->|下一周期基线| C1

这条链路里有两个容易被省略但决定成败的部件：

其一，last_used 字段必须来自官方数据，不能靠推测。 AWS 提供主体级的服务最后访问时间（generate-service-last-accessed-details）和未使用权限分析器；阿里云 RAM 提供 AccessKey 粒度的最后使用时间（GetAccessKeyLastUsed）；腾讯云 CAM 的 ListAccessKeys 返回里没有最后使用时间字段，只能用 CloudAudit 的事件反查。三家能力不对等，所以归一化表里要允许该字段为 unknown，并把 unknown 单独统计——它不是"没用过"，而是"没有证据"，处置方式不同（前者建议撤销，后者建议先补采集）。

其二，例外必须有到期日。 评审中最常见的产物不是"撤销"，而是"这次先留着"。如果例外没有强制到期，它会变成永久权限，且明年评审时评审人看到"历史上已批准"，更容易继续批准。规则很简单：例外表必须有 expires_at，到期自动回到待评审队列，超过两次续期自动升级到安全负责人。

四、权限清单基线：三家云各能导出什么

做归一化之前，先要接受一个事实：三家云能导出的字段并不对等。如果按能力最全的那家（AWS）设计表结构，另外两家的必填字段就会永远为空；如果按最弱的那家设计，又会丢掉最有价值的未使用证据。正确做法是"宽表 + 证据等级"：字段尽量全，但对每条记录标注证据强度（verified / derived / unknown）。

三家的采集能力对照：

三条实操结论：

1. "直接绑定"永远不等于"实际权限"。 三家的 List*PoliciesForUser 类接口都只返回直接绑定到该主体的策略，不包含经用户组继承的部分。只拉直接绑定，覆盖率会系统性偏低，而且漏掉的恰好是最常见的授权方式（把策略挂到组、人放组里）。必须补一次组展开。
2. 需要"角色链"展开。 如果企业用"人 → 组 → 角色 → 信任链"的模式（AWS 的 sts:AssumeRole、阿里云的 RAM 角色扮演），清单里要记录可传递性：谁能扮演谁。这条边不进表，后面的 SoD 检测就查不出"通过扮演角色绕过职责分离"的路径。
3. 别只取第一页。 三家接口都分页，默认页大小通常 100 条上下。400 人规模的组织，用户列表就要翻 4 到 5 页；漏了第二页，缺口正好出现在按创建时间排序的末尾——通常是最近入职的人，也是审计抽样最爱抽的人。

归一化后的表结构建议如下（字段名保持英文，便于脚本与 BI 直接消费）：

{
  "subject_id": "arn:aws:iam::111122223333:role/AppDeploy",
  "subject_type": "role",
  "provider": "aws",
  "account": "111122223333",
  "display_name": "AppDeploy",
  "owner": "platform-team",
  "entitlement": "s3:PutObject",
  "scope": "arn:aws:s3:::prod-assets/*",
  "grant_type": "attached_policy",
  "granted_at": "2025-11-04T08:12:00Z",
  "last_used_at": "2026-09-18",
  "evidence_level": "verified",
  "risk_flags": ["write_prod", "no_mfa_boundary"]
}

evidence_level 这个字段是整套方案的核心设计。它的取值规则：

• verified：来自云厂商官方接口的使用时间（AWS 服务最后访问、凭据报告、阿里云 AccessKey 最后使用）。
• derived：从审计日志事件反推（腾讯云 CloudAudit、阿里云 ActionTrail），有时间窗偏差，通常只能给到"某天出现过"。
• unknown：没有任何使用证据。这类记录不能按"未使用"直接撤销，要先补采集或人工确认，否则误删会打穿生产。

五、AWS：Access Analyzer 未使用权限分析 + 凭据报告实战

AWS 是三家云里唯一提供主体级未使用权限分析的。它有两个关键参数需要理解清楚，否则会得出错误结论。

第一，跟踪期（tracking period）是 1 到 365 天，不是固定档位。官方文档的措辞是：分析器只评估"在所选跟踪期内始终存在的 IAM 实体"，也就是说跟踪期设 90 天，只有存在满 90 天的权限才会被分析，且在这 90 天内无使用才会产生 finding。这带来一个直接推论：跟踪期必须大于等于你的评审周期，否则每次评审都会有一批"新权限"永远不出结论，而这批恰好是权限蔓延最快的那部分。

第二，未使用分析的 finding 不随区域变化。同一账号在多个区域开分析器不会得到不同结果，所以不需要按区域创建——这是纯浪费。代价结构是按"被分析的 IAM 角色与用户数 × 每月 × 每个分析器"计费，单价 0.20 美元/主体/月，官方算例是 70 个角色与用户 14 美元/月、850 个 170 美元/月。

创建组织级分析器（覆盖组织内全部账号，跟踪期 90 天）：

aws accessanalyzer create-analyzer \
  --analyzer-name unused-access-org \
  --type ORGANIZATION_UNUSED_ACCESS \
  --configuration '{"unusedAccess":{"unusedAccessAge":90}}'

字段名以 aws accessanalyzer create-analyzer help 的当前版本为准；控制台上的同一参数叫 Tracking period，允许 1–365 天的任意整数。创建后 finding 不会立刻出现——需要等分析器积累够数据，官方明确说"创建或更新分析器后，finding 需要一段时间才可用"，所以排期上要把"建分析器"放在活动启动前的两周，而不是活动当天。

拉取 finding（v2 接口，返回结构比 v1 更适合批量处理）：

aws accessanalyzer list-findings-v2 \
  --analyzer-arn arn:aws:access-analyzer:us-east-1:111122223333:analyzer/unused-access-org \
  --filter '{"findingType":{"eq":["UnusedPermission"]}}' \
  --max-results 100 \
  --output json > findings.json

注意 --max-results 有上限且返回带 nextToken，必须循环翻页直到 nextToken 为空。只取第一页是这类脚本最常见的静默缺陷：脚本"跑成功了"，但只处理了 100 条。

第二路证据是 IAM 凭据报告，它给出人这一侧的密钥与密码使用情况，是发现"长期不用的 AccessKey"和"未开 MFA 的高权限账号"最快的手段：

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > creds.csv

报告是 CSV，关键列包括 user、password_enabled、password_last_used、mfa_active、access_key_1_active、access_key_1_last_used_date、access_key_1_last_rotated。注意两个坑：generate 是异步的，刚生成时 get 可能返回 State: STARTED，要轮询到 COMPLETE；以及 password_last_used 对从未登录的用户是 no_information 而不是空值，脚本里要把这个字符串单独处理，否则日期解析会抛异常。

把 CSV 变成"待处理清单"的最小脚本（无第三方依赖）：

import csv, datetime
now = datetime.datetime.now(datetime.timezone.utc)
rows = list(csv.DictReader(open("creds.csv", encoding="utf-8")))
stale = []
for r in rows:
    for n in ("1", "2"):
        if r.get("access_key_%s_active" % n) != "true":
            continue
        last = r.get("access_key_%s_last_used_date" % n) or "N/A"   # 从未使用是 N/A
        if last in ("N/A", "no_information"):
            age = 9999
        else:
            age = (now - datetime.datetime.fromisoformat(last + "T00:00:00+00:00")).days
        if age > 90:
            stale.append((r["user"], n, last, age))
for s in sorted(stale, key=lambda x: -x[3])[:20]:
    print(s)

这段脚本给出的榜单，通常是评审活动的第一份"高置信度撤销清单"——从未使用且创建超过 90 天的密钥，几乎没有保留理由。

六、阿里云 RAM 与腾讯云 CAM：把权限快照固化下来

阿里云和腾讯云没有 AWS 那种主体级未使用分析，但这不影响做 IGA，只是"使用证据"这一列要靠别的方式补。采集侧的重点是把继承关系拉全。

阿里云 RAM 的采集顺序（先人、再组、再策略）：

aliyun ram ListUsers --MaxItems 100
aliyun ram ListGroupsForUser --UserName alice
aliyun ram ListPoliciesForUser --UserName alice
aliyun ram ListPoliciesForGroup --GroupName data-readonly
aliyun ram ListAccessKeys --UserName alice
aliyun ram GetAccessKeyLastUsed --UserAccessKeyId LTAI5tExampleKeyId

GetAccessKeyLastUsed 返回的是该密钥最后一次被调用的时间；参数名以 aliyun ram GetAccessKeyLastUsed --help 为准。这里有个能力边界要写进文档：它只覆盖 AccessKey，不覆盖控制台登录，也不覆盖角色扮演。所以对"只通过控制台操作"的员工，这个字段会显示从未使用，但人其实天天在操作——直接把这类记录判为"未使用"会造成误撤。正确做法是同时拉 ActionTrail 的登录与 API 事件做交叉验证，并把结果标为 derived。

腾讯云 CAM 的坑更具体：ListAccessKeys 返回的字段里没有最后使用时间。要判断一把密钥是否还在用，只能查 CloudAudit（云审计）的事件，用 LookupEvents 按主体和时间窗反查：

tccli cam ListUsers --Limit 100
tccli cam ListGroupsForUser --Uin 100012345678
tccli cam ListAttachedUserPolicies --TargetUin 100012345678
tccli cam ListAttachedGroupPolicies --TargetGroupId 1234
tccli cam ListAccessKeys --TargetUin 100012345678
tccli cloudaudit LookupEvents --StartTime "2026-07-01 00:00:00" \
  --EndTime "2026-09-30 23:59:59" \
  --LookupAttributes '[{"AttributeKey":"Username","AttributeValue":"alice"}]'

CloudAudit 默认只保留一段时间的事件（各账号可能不同，常见为 90 天），这意味着跨度 180 天的评审，前 90 天的证据在日志里已经不存在了。这不是脚本问题，是数据保留期问题。处置有两条：一是把审计日志投递到 COS 并设置生命周期保留 365 天以上（成本很低，一个几百人规模的组织每月事件量通常在几十 GB 以内）；二是在评审报告里明确"使用证据窗口 = 90 天"，并把这一口径写给审计师，而不是假装覆盖了 180 天。

三家云横向对比，值得记住的是这张"证据可得性"表——它决定了你的评审结论有多硬：

最后一行值得强调：审计师不接受"我问过业务方，他说不用了"作为撤销依据。可以接受的是"系统显示该权限 137 天未使用，业务方在活动内确认撤销，决策记录见附件"。人的确认要有，但必须挂在机器证据上。

七、职责分离（SoD）：把"不能同时拥有"写成规则

访问评审解决"这条权限还要不要"，职责分离解决"这两个权限能不能落在同一个人身上"。后者是前者的前置过滤：一个同时拥有"发起付款"和"审批付款"的人，即使两项权限都"在用"，也必须拆开——这类冲突不是靠评审人判断，而是靠规则直接判红。

云上做 SoD 与 ERP 时代最大的区别是粒度。ERP 的 SoD 按事务码（t-code）划分，一个人能不能同时持有 A 事务码和 B 事务码是明确的；云上的权限是"动作 × 资源"的二维集合，同一个策略包里可能混着读写，同一组动作在不同云上叫法不同。所以规则必须定义在语义动作对上，再映射到各云的实际 action。

六条在出海企业里复现率最高的规则：

规则写成代码，进版本库，随清单快照每次采集后执行。用 YAML 描述，便于安全团队自己维护：

version: 1
rules:
  - id: SOD-02
    name: 密钥管理与解密不可同体
    severity: high
    left:
      aws: ["kms:CreateGrant", "kms:PutKeyPolicy"]
      aliyun: ["kms:CreateKey", "kms:ScheduleKeyDeletion"]
      tencent: ["kms:CreateKey", "kms:DisableKey"]
    right:
      aws: ["kms:Decrypt", "kms:GenerateDataKey"]
      aliyun: ["kms:Decrypt"]
      tencent: ["kms:Decrypt"]
    scope: same_account            # 同账号内即判冲突
    exception_max_days: 30         # 例外最长 30 天，到期自动复活为待评审

评估逻辑本身很简单：把每个主体的有效权限展开成 (action, resource) 集合，对每条规则判断左右集合是否同时非空。真正的工作量在动作归一化——同一语义在不同云上的命名差异，以及通配符的展开。

通配符是这里最容易被忽视的漏洞。一条 s3: 或 oss: 在文本层面看不出任何冲突，展开后却同时命中了左集合和右集合。所以评估前必须做动作展开：用各云的动作清单（AWS 的 policies.js 服务授权参考、阿里云的策略语法文档、腾讯云的 CAM 权限列表）把 和 service: 展开成具体动作，再做集合运算。不做这一步，SoD 检测的召回率会低得离谱——而恰恰是那些"图省事写了全通配"的账号风险最高。

跨云语义映射表（示例，实际项目建议维护到 100 条以上）：

一个经验法则：先做语义层，再做厂商层。如果规则直接按各云的 action 名写死，第二年厂商改一次权限命名就要全量返工；把语义作为主键，映射表作为配置，规则库就能活过版本升级。

八、认证活动设计：评审人、周期、决策分类与超时策略

认证活动（campaign）是 IGA 的执行单元：一次活动有明确的范围、期限、评审人集合和决策口径。设计得好不好，看四个参数。

参数一：周期按主体类型分层，不要一刀切。 全组织统一"每年一次"是最省事也最没用的设计——特权账号在 12 个月里可以做很多事，而一个只读报表账号每周评审一次纯属浪费评审人时间。

参数二：评审人按"能回答这个问题的人"分配，双轨而不是单轨。 实践中两种模式各有盲区：

结论是双轨：人对人用经理，权限对权限用 Owner。矩阵型组织里单轨会失效——一个员工同时服务三条业务线，他的经理只知道自己那条线的需求，另外两条线的权限在他眼里全是"可疑"。

参数三：决策必须是四选一，不是"保留/撤销"二选一。 只有两个选项会逼评审人选"保留"，因为撤销看起来像在惩罚人。给出降级选项，评审人就有了中间地带：

如果一次活动里降级率和撤销率都是 0，基本可以判定这次评审是走过场——正常组织的权限只增不减，第一次认真评审一定会撤掉一批。

参数四：超时默认要 fail-closed，但要给缓冲。 到期未决策的记录，默认按"撤销"处理，这是审计上唯一站得住的口径（不能因为评审人没空就默认保留）。但直接撤销会误伤：很多评审人只是漏看了邮件。折中是两次提醒 + 7 天宽限 + 到期自动撤销并抄送其经理，同时把"超时撤销"单列为一项指标，按月看趋势——如果超时率高，问题在流程不在人。

另外一个细节常被忽略：要不要给评审人看"最后使用时间"。两种做法都有依据。显示使用证据能显著提高撤销率，但也诱导评审人只按"有没有用过"做决定，忽略"虽然没用但必须有"的合规权限（比如审计只读、灾备切换权限）。可行的折中是：显示使用时间，同时在界面上强制要求填写一句理由（不少于 10 个字），并对"使用时间为空但被批准"的记录做 100% 复核。

最后是抽样。安全团队对已完成的决策做 10% 随机抽检，抽检对象优先包含三类：批准了从未使用的权限、批准了 SoD 冲突例外、由本人评审本人的记录。第三类如果出现，说明评审人分配逻辑有 bug，属于流程缺陷而不是个案。

九、回收执行：从"批准撤销"到"权限真的消失"

这是整条链路里最容易断的一环，也是最容易在审计时暴露的一环。Excel 上写"撤销"，线上权限还在，审计师抽一个主体一查就知道。

原则：撤销动作必须走 IaC，不走控制台。 理由不是洁癖，是可追溯性。控制台手删有三个问题：没有 PR 记录、没有评审人关联、下次 terraform apply 会把权限"复活"。

第三个问题最致命，也最常发生。典型现场：工程师在控制台删掉了某个角色的 s3:* 绑定，两周后别人跑了一次 terraform apply，Terraform 的 state 里这条绑定还在，于是它被重新创建——权限回来了，而且没人注意到，因为"我们上季度评审过"。正确的顺序是：

1. 改 Terraform 代码（删除 aws_iam_role_policy_attachment 资源或缩小 policy 文档）；
2. 提 PR，PR 描述里带 campaign_id 与决策记录链接；
3. 审批合并，CI 执行 terraform plan；
4. plan 输出必须只包含预期的删除/修改，出现意外新增就阻断；
5. apply 之后跑权限探针验证。

权限探针的做法很朴素但有效：用一个只带该主体权限的临时凭据，对"应当被拒绝"的动作发一次请求，断言返回 AccessDenied。AWS 上可以用 iam simulate-principal-policy 做离线模拟，不必真的发请求：

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/AppDeploy \
  --action-names s3:PutObject s3:DeleteObject \
  --resource-arns arn:aws:s3:::prod-assets/report.csv \
  --output table

阿里云对应 ram SimulatePolicy，返回每个动作的 Allowed / Denied 判定，适合在回收后批量复核。注意模拟接口只判断策略语义，不考虑 SCP、权限边界之外的运行时条件（如源 IP、VPC 端点、MFA 条件），所以它是必要但不充分的验证——最终仍要有一条真实调用失败的证据。

回收的三种形态要区分清楚，因为它们的风险和可逆性不同：

对第三类（换主体）建议单独走变更评审，不要塞进季度活动的批量执行里。批量执行里混入高风险变更，一旦出事会导致整个 IGA 流程被叫停——这是很多项目半途而废的真实原因。

最后是 break-glass。评审活动必须为紧急访问留出通道，否则会出现"为了合规把应急权限删了，真出事时只能改策略提权"的荒唐局面。可行设计：保留 2 个密封的特权账号，凭据分片存放、双人才能解封，任何一次使用都触发实时告警并自动生成一张"事后评审"工单，要求在 5 个工作日内补决策记录。这条通道本身也要进评审范围——评审的是"用了没有、理由是否成立"，而不是"要不要保留"。

十、三类方案对比：自建脚本 / 云原生 / 商业 IGA

做 IGA 有三条路，选错的代价通常不是钱，而是"上线一年还在做权限清单"。三条路的差别不在功能清单，而在谁来维护那 200 条动作映射和 30 条 SoD 规则。

三点经验判断：

1. 人数不是唯一变量，"主体数 / 人数"才是。 一个 200 人的公司如果有 400 个服务账号和 12 个云账号，主体数远超人数，自建脚本的复杂度会接近商业产品；反过来 1000 人的公司如果只有 2 个云账号、权限都挂在 8 个组上，自建完全够用。
2. 商业 IGA 的真正价值在"覆盖 SaaS"，不在云。Salesforce、Workday、GitHub、Jira 这些系统的权限模型千差万别，自建连接器是无底洞。如果企业的审计范围只覆盖云基础设施，商业产品的溢价很难被证明。
3. 开源方案的隐性成本在评审前端。规则引擎好写，"给 200 个经理发任务、收决策、催办、出报告"这一套工作流的工程量和运维量，往往超过规则本身。

十一、成本测算：400 人规模一次季度评审

下面这组数字可以直接拿去改参数复算。假设：400 名员工、60 个 IAM 角色（含服务角色）、3 家云共 12 个账号、每季度一次全量活动、每条决策平均耗时 4.0 分钟、人力综合成本按 60 美元/小时。

先看工具费。Access Analyzer 的未使用权限分析按"被分析的 IAM 角色与用户数 × 每月 × 每个分析器"计费，单价 0.20 美元：

再看人力。这是成本的主体，也是自动化真正能省下来的部分：

换算成年化：

三年口径要把一次性的建设投入算进去（采集器 + 归一化 + 规则库 + 工单对接，按 80 小时计，约 4,800 美元）：

币种与口径说明：Access Analyzer 单价 0.20 美元/主体/月来自 AWS 官方定价页算例（70 主体 $14/月、850 主体 $170/月，2026-10 核验），按 us-east-1 美元计价、不含税；人力成本按 60 美元/小时的综合费率假设，实际应按当地薪资与福利调整；不含商业 IGA 许可费、不含审计服务费；"工时"为管理估算值而非实测，用于相对比较，不应作为预算承诺。

这组数字的意义不在于"省了 37%"，而在于看清结构：评审判断（30.7 小时）是唯一无法自动化的大头，占自动化后总工时的 70%。 所以任何"提升评审效率"的投入，都应该指向减少需要判断的条目数（用使用证据过滤、按组评审、批量决策），而不是优化导出脚本——后者只占 2 小时。

十二、审计举证包：给审计师的那一页纸

证据包的组织方式决定了审计时长。把 460 条决策的原始记录丢给审计师，他会随机抽样 25 条逐条追问；给一页汇总 + 可下钻的明细，他通常看 3 条就够。

一页纸应该包含这七项：

控制项映射（按主流框架）：

三个能显著缩短审计时间的细节：

• 给每个数字一条可复现的命令。 报告里写"共 460 个主体"，旁边放一行采集命令和它输出的行数。审计师自己跑一次能复现，后面就不会再追问。
• 把 unknown 单独列出来。 使用证据缺失的记录占比 8% 是正常的，藏起来被发现才是问题。写明"这 37 条因腾讯云审计日志保留期限制无法取证，已人工确认并标注例外"。
• 保留失败记录。 第一次跑 SoD 一定会有一批误报（通配符展开导致的假冲突）。保留误报清单和修正记录，反而证明规则库被真实校验过。

十三、常见失败模式与处置

下面六种在真实项目里都见过，按出现频率排序：

最后一条值得展开。自评审（self-review）在审计上等于没有评审，但它常常是无意造成的：很多 IGA 工具默认"资源 Owner 评审该资源上的权限"，而平台团队自己既是 Owner 又是被评审主体。修法不是靠人盯，而是在分配逻辑里加断言，跑完后输出一张"自评审清单"，非空就不允许活动进入签核阶段。

总结

多云访问评审的工程难点不在工具选型，而在三个具体动作：把三家云的继承关系拉全、把使用证据挂到每条权限上、把撤销变成 IaC 变更。这三件事做完，剩下的都是流程编排。

本文的几个关键数字可以带回去用：Access Analyzer 未使用权限分析 0.20 美元/主体/月（460 个主体 = 92 美元/月，年 1,104 美元），跟踪期 1–365 天且必须不小于评审周期，finding 不随区域变化因此不必按区域建分析器；腾讯云 ListAccessKeys 不返回最后使用时间、审计日志保留期常为 90 天，这两条决定了 180 天评审的证据只有一半；400 人规模下自动化把工时从 338.8 小时/年降到 174.8 小时/年，总成本降 37.1%，而剩下 70% 的工时集中在"人做判断"这一环，这提示优化的方向是减少需要判断的条目，而不是写更快的导出脚本。

如果只做一件事：先给所有主体打上 Owner 标签，再去做评审。 没有 Owner 的权限，在任何评审会上都只能"暂缓"，而"暂缓"就是永久。

企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。

相关阅读

• 多云统一身份认证实战：阿里云 RAM SSO + AWS IAM Identity Center 联合登录
• 非人类身份（NHI）治理：工作负载身份联邦与机器凭据生命周期
• 多云特权访问管理（PAM）：堡垒机、会话审计与临时提权
• 多云合规审计自动化：SOC 2、ISO 27001 与 GDPR 的证据流水线
• 阿里云 RAM 身份与权限安全实践
• 多云数字取证与事件响应（DFIR）：证据固定顺序与证据链
• 软件资产许可合规与 ITAM 治理

本文由 7.chengzicloud.cloud 提供，点击访问首页了解更多