账号、角色与权限：让每次工具操作都能追到真实责任人

账号、角色与权限高清原图

一次发布失败后，审计日志只留下 dev-admin 删除了环境变量。团队七个人都知道密码，密码管理器里没有访问记录，浏览器还保存着长期会话。有人认为这是共享账号节省座席的代价，有人准备修改变量补救，但真正的问题是：没人能证明谁做了什么，也无法只撤销可疑操作者。共享账号把身份、权限和责任揉成一个字符串，事故调查、最小授权和离职回收因此同时失效。

研发工具的权限治理不是给每个人套上同一个“开发者”角色。它要把自然人、非人身份、群组、角色、资源、条件和例外拆开，再计算某个主体在某个时刻对某个对象真正能做什么。named account 解决主体可追踪，RBAC 降低逐人授权复杂度，有效权限分析发现继承与叠加后的真实结果，定期复查和事件触发回收则阻止权限随着项目、转组和临时救火不断膨胀。

先冻结共享账号，保留事故证据

发现共享账号时，不能立刻改密码并宣布解决。先确认该账号是否被 CI、Webhook、脚本、浏览器会话、移动端、插件或 API token 使用，保留最近登录、角色、授权对象和关键操作事件。贸然改密可能让自动化全线失败，也可能使尚未导出的审计线索丢失。

处置顺序要区分取证与遏制。先停止共享账号的新登录、新凭据签发和高风险写操作，同时保留不会暴露秘密的登录与管理事件；再枚举应用会话、访问与刷新 token、SSH key、OAuth grant、恢复方式以及资源侧凭据。为真实使用者建立 named account，把自动化迁移到专用非人身份后，逐类撤销旧凭据并做反向访问验证。若产品只能“禁用登录”，不能据此推断已经签发的 token、应用自己的 session cookie、deploy key 或 OAuth grant 同时失效；这些对象必须按目标产品的撤销语义分别处理。非人身份的轮换细节属于独立治理链，但共享账号绝不能因为“脚本依赖”而永久保留。

共享账号事故采证单
- account_id：不可变账号标识，而不是显示名
- account_type：human / shared / service / bot
- direct_roles：直接角色
- group_roles：通过群组继承的角色
- sessions：活动会话数量与最后使用时间
- credentials：凭据类型、创建者、到期状态，不记录秘密值
- integrations：CI、Webhook、插件、API 客户端
- critical_events：时间、动作、资源、结果、来源类别
- recovery_paths：恢复邮箱、外部身份、管理员重置入口

预期证据能把账号作用面画出来，却不会把密码、token 或完整日志复制到工单。若产品无法列出活动会话或 token，先用网络、CI 变量引用和审计事件交叉确认，再安排短窗口撤销。无法证明无人依赖，不等于可以永久保留；它意味着迁移需要更谨慎的观察期。

Named Account 是责任链的起点

named account 表示一个自然人使用唯一、不可转让的账号完成交互操作。显示名可以变化，邮箱可能改名，真正用于审计与关联的应是产品或身份目录的稳定主体标识。团队不能用邮箱字符串作为唯一主键，也不能删除账号后重新创建同名账号并把历史事件误归给新人。

每个自然人账号至少关联主体标识、人员状态、所属团队、管理者、身份来源、认证强度、创建时间、最后活动、直接角色、群组、例外和计划复查时间。正文或示例只使用合成账号，例如 dev02@example.invalid；真实人员目录、邮箱和租户标识不能进入 Git。

subject_id: usr_demo_002
display_name: "Demo Developer 02"
principal: "dev02@example.invalid"
identity_source: "corporate-idp"
employment_state: "active"
team: "payments-demo"
manager_role: "engineering-manager"
authentication:
  sso_required: true
  phishing_resistant_mfa: preferred
direct_assignments: []
groups:
  - repo-payment-readers
exceptions:
  - id: EXC-014
    permission: repository-maintain
    resource: demo-migration-repo
    expires_at: "<short-expiry>"
review_due: "<review-cycle-reference>"

named account 不等于永远授权给个人。日常权限应通过团队或群组分配，直接授权只用于可解释的短期例外。也不要让个人账号承担机器人任务：当员工休假、转组或离职时，个人 token 会把自动化可用性与人员生命周期绑死，审计也无法区分人工点击和定时脚本。

NIST SP 800-53 Rev.5 将账号管理、访问执行、职责分离和最小权限分别作为可检查的控制，而不是一个“启用 SSO”开关。落到研发工具上，就是账号有生命周期、权限在服务端执行、高风险动作不能由同一主体自批，并且授予范围只覆盖岗位所需动作。产品没有某个内置角色名称并不等于这些目标可以省略，只是实现方式要换成群组、保护规则、审批或代理层。

把权限拆成主体、动作、资源与条件

“管理员”“开发者”“只读”是角色标签，不是完整授权。一个权限决策至少包含主体 subject、动作 action、资源 resource 和条件 condition。条件可以是时间、来源网络、认证强度、仓库属性、环境、审批状态或会话风险。没有资源边界的 write 往往意味着对全部项目写入；没有动作边界的 admin 则可能同时包含账单、成员、秘密和删除权限。

RBAC 将常用权限集合封装成角色，再把角色授予主体或群组。它适合稳定岗位，例如 issue 维护者、仓库贡献者、发布审核者和组织审计员。属性和条件用于处理资源分类、临时任务与环境差异。团队不必为了追求理论纯粹而只用一种模型，关键是能解释最终决策。

GitHub 的 组织仓库角色 从 Read、Triage、Write、Maintain 到 Admin 逐级增加能力，并明确 Admin 包含敏感和破坏性操作；Maintain 适合管理仓库而不需要全部敏感权限的人员。GitLab 的 权限与角色 同样按资源层级和角色定义动作。实施时应查目标产品、目标计划和目标资源类型的当前权限表，不能把一个平台的角色名称直接映射成另一个平台的同等能力。

roles:
  issue_triager:
    actions: [issue.read, issue.label, issue.assign]
    excludes: [code.push, settings.write, repository.delete]
  code_contributor:
    actions: [repository.read, branch.push, pull_request.create]
    conditions:
      protected_branch: "pull-request-only"
  release_approver:
    actions: [deployment.review]
    conditions:
      environment: "staging"
      self_approval: false
  repository_owner:
    actions: [settings.manage, access.review]
    excludes: [billing.manage, organization.delete]

角色设计从任务开始，而不是从产品已有的最高角色开始。若一位 issue 维护者只需分类和分派，就不应因为 Write 最方便而获得推送代码能力。产品内置角色过粗时，可以用自定义角色、保护规则、审批、独立资源或代理层收窄；若仍无法收敛，就调整工作流，而不是默许永久管理员。

有效权限不是角色表面名称

用户最终能做什么，往往来自组织基线、直接角色、团队群组、嵌套群组、仓库角色、外部协作者授权、OAuth App、部署密钥和临时例外的叠加。有的系统取最大权限，有的显式拒绝优先，有的子资源继承父资源，还有的角色删除后回落到组织基线。只查看用户详情页上的一个角色，极易漏掉旁路。

可以把有效权限写成可解释计算：先收集直接、群组、继承、组织基线和资源侧授权，再按目标产品真实的优先级应用显式拒绝、条件、保护规则和会话状态，最后生成“主体—动作—资源—来源—到期—决策点”的展开结果。不能假设所有系统都采用“拒绝优先”或简单并集；例如某些角色取最高权限，某些自定义角色还继承组织基础权限。重要的是保留来源链和实际决策点，使复查者知道删除哪个群组、角色、应用授权或例外才会真正回收权限。

function effectivePermissions(subject, resource, now) {
  const grants = collectDirectGrants(subject, resource)
    .concat(collectGroupGrants(subject, resource))
    .concat(collectInheritedGrants(subject, resource))
    .filter((grant) => !grant.expiresAt || grant.expiresAt > now)
    .filter((grant) => conditionsMatch(grant, subject, resource));

  const denies = collectExplicitDenies(subject, resource);
  return explain(removeDeniedActions(grants, denies));
}

这段伪代码强调顺序，不代表所有产品都支持显式拒绝。验证时准备三个合成主体：仅直接只读、通过群组写入、同时拥有过期管理员例外。预期展开结果分别为只读、写入、忽略过期例外后的基础权限。反向结果若仍显示管理员，沿来源链检查嵌套组、组织 owner、外部协作者、应用授权和部署密钥。

GitHub 的组织仓库角色说明特别提醒，拥有部署私钥的人可能在用户被移出组织后继续访问仓库。这个例子说明“删除成员”不等于“资源已回收”；有效权限盘点必须包含非人凭据与资源侧授权，但不要把 deploy key 当作共享人类账号的替代品。

用最小权限实验验证角色，而不是相信名称

角色上线前要在合成组织或测试项目做动作级实验。正向实验确认角色能完成岗位任务；反向实验确认相邻高风险动作被拒绝。只测登录和页面可见性不够，因为真正危险的能力可能藏在 API、CLI、导出、设置或删除入口。

{
  "role": "issue_triager",
  "principal": "triager01@example.invalid",
  "resource": "demo-repository",
  "positive": [
    { "action": "issue.label", "expect": "success" },
    { "action": "issue.assign", "expect": "success" }
  ],
  "negative": [
    { "action": "code.push", "expect": "deny" },
    { "action": "secret.read", "expect": "deny" },
    { "action": "repository.delete", "expect": "deny" }
  ],
  "evidence": ["actor-id", "action", "resource-id", "decision", "policy-source"]
}

执行时用该角色自己的 named account 或测试身份，不用管理员模拟。成功动作创建可清理对象并记录对象 ID；失败动作应在变更发生前拒绝。审计能够记录主体、动作和结果最好；若产品不记录拒绝事件，则必须保留客户端关联 ID、网关或代理日志以及资源未变化的证据，不能虚构一条并不存在的审计记录。若 UI 隐藏按钮但 API 调用仍成功，说明界面不是控制点；必须在服务端授权层拒绝。若管理页面显示角色已移除但旧 token 仍可调用，也只能说明配置改变，不能说明有效访问已终止。

角色变更后重跑同一套实验，并比较有效权限快照。新增一个看似无害的“管理 Webhook”权限可能暴露请求载荷和仓库元数据；新增 Actions secret 管理权限可能允许替换构建凭据。GitHub 的 自定义组织角色权限 会标注部分权限的附带可见性和产品状态，实施前应就近核对，尤其不要把预览能力当成稳定基线。

共享账号拒绝要同时解决座席、值班与自动化借口

共享账号通常以三种理由出现：节省座席、多人值班、脚本只能用账号密码。每种理由都有更可靠替代。座席问题应通过供应商允许的角色、外部协作者、并发或服务身份模式解决，不能违反许可条款；值班使用 named account 加值班角色和短期提权；自动化使用专用服务账号、应用身份或工作负载身份，并将凭据轮换与人员分离。

紧急“破窗”账号是极少数例外，不是日常共享账号。它应保存在受控保险库，使用需要双人批准，取用后立即轮换，登录产生高优先级告警，且不能被浏览器和脚本长期保存。更好的产品若支持紧急角色临时授予，应优先使用 named account 的短期提权，因为审计仍保留真实主体。

破窗入口还必须避开它准备恢复的故障依赖。Microsoft Entra 的紧急访问账号指南要求紧急账号用于正常管理入口不可用的场景，并强调独立认证方式、安全保管、每次使用告警和定期验证。迁移到其他产品时不能机械照搬“全局管理员”角色，但必须保留同一原则：若普通管理员依赖企业 IdP、同一 MFA 服务和同一终端策略，紧急入口就不能把这些依赖原样复制一遍。演练要在不改生产对象的前提下完成登录、读取一个无敏感内容的管理状态、触发告警和退出；任何一次真实取用都要关联事件、复核动作并重新封存凭据。

共享账号迁移步骤
1. 阻止新登录、新 token 和新增集成，保留必要事件证据。
2. 区分人工操作、自动化和值班用途，建立凭据与依赖清单。
3. 为人工使用者创建或启用 named account。
4. 以群组和最小角色重建权限，运行正反实验。
5. 将自动化迁移到专用非人身份并完成凭据轮换。
6. 撤销应用 session、访问与刷新 token、key、OAuth grant 和资源侧授权。
7. 禁用或封存共享账号，分别验证交互登录、API、Git/SSH 与后台任务均被拒绝。
8. 观察一个完整任务周期，确认无成功认证、无人依赖和费用残留。

如果禁用后流水线失败，不要重新启用共享账号“先顶一下”。从失败日志定位具体集成，以限时、最小作用域的临时身份恢复，并继续迁移。否则每次故障都会把共享账号从待清理对象重新变成事实标准。

服务账号是工作负载身份，不是另一个共享用户

服务账号、应用身份和工作负载身份用于没有自然人交互的任务，例如 CI 拉取制品、机器人创建变更或定时任务读取测试数据。它们必须对应一个工作负载和一个责任 owner，不能按部门创建 team-bot 后让所有脚本共用。身份边界过大时，审计只能证明“机器人做了”，仍然无法定位是哪条流水线、哪个版本和哪次批准触发。

优先使用平台签发的短期身份：让 runner、云工作负载或外部 OIDC 主体在满足仓库、分支、环境和 audience 条件后换取短期 token。Google Cloud 的服务账号安全实践把服务账号同时视为 principal 和 resource，并建议在可行时避免服务账号密钥，优先使用附加身份、模拟或工作负载身份联合。这个结论可以推广为治理原则：长期私钥只有在平台无法提供更短链路时才作为限时例外，而且创建、分发、轮换和撤销都要能被 owner 追踪。

workload_identity:
  identity_id: svc_demo_release
  owner_role: release-platform
  backup_owner_role: platform-oncall
  workload:
    repository: demo-release-repo
    workflow: publish-test-artifact
    environment: test
  trust:
    issuer: "<approved-oidc-issuer>"
    subject: "repo:demo/release:ref:refs/heads/main"
    audience: "artifact-service"
  permissions:
    allow:
      - artifact.test.write
    deny:
      - artifact.production.write
      - identity.policy.manage
  credential:
    type: short-lived-federated-token
    maximum_lifetime: "<platform-supported-boundary>"
    static_key_allowed: false
  evidence:
    correlation: workflow-run-id
    token_material_logged: false
  revoke:
    disable_trust: true
    revoke_sessions_if_supported: true
    remove_resource_grants: true

正向实验从批准的仓库、分支和测试环境获取短期 token，只写入带测试前缀的制品，预期审计能关联工作流运行 ID、被模拟身份、动作和资源。反向实验至少做三次：从未批准分支请求 token、把 audience 改成另一个服务、用同一身份写生产命名空间；三次都应在对象创建前失败。若日志只有服务账号名称而没有调用链主体，就补充 runner 事件与云端审计的关联 ID，不能把不可归因的成功调用视为合格。

退出时先把必要任务切换到新身份并跑正向验证，再关闭旧信任关系、撤销可撤销会话、删除资源侧授权和静态 key，最后重跑旧分支、旧 token 与旧 key 的拒绝实验。只删除密钥文件不够，密钥副本可能仍在 runner 缓存、制品、变量库和开发者机器；只禁用账号也不够，目标服务可能缓存授权。无法证明旧身份停止工作的任务，应保持在隔离状态并持续告警。

权限例外必须短期、可撤销、不可自批

开发者偶尔需要超出常规角色的动作，例如迁移仓库设置、处理批量 issue、查看一次审计事件或在测试环境批准部署。例外记录要包含任务、主体、资源、动作、原因、风险、补偿控制、开始与到期、批准人、撤销动作和验证证据。批准的是有限动作，不是把用户临时变成无边界 owner。

exception_id: EXC-014
subject_id: usr_demo_002
task: CHANGE-DEMO-81
resource: demo-migration-repo
actions:
  - repository.settings.read
  - repository.settings.write
denied_actions:
  - repository.delete
  - organization.member.manage
starts_at: "<approved-start>"
expires_at: "<approved-end>"
approver_role: repository-owner
self_approval: false
compensating_controls:
  - change-window
  - second-reviewer
  - audit-alert
revoke:
  assignment: "remove-direct-assignment"
  sessions: "product-specific-session-revocation"
  tokens: "revoke-user-bound-tokens-if-affected"
  verify: "repeat-denied-action-and-check-effective-access"

到期应由系统自动回收；只发提醒让管理员手工处理，必然形成残留。若产品不支持自动到期，就用工单自动化、群组同步或定时脚本调用官方 API，并对失败产生告警。脚本需要幂等：重复执行不会扩大权限，目标不存在时明确记录，API 失败不把本地记录误标为已回收。

反向实验将到期时间设为短窗口，窗口内正向动作成功，到期后分别使用原浏览器会话、原 API token 和新登录重试。预期结果取决于产品鉴权模型：实时鉴权应立即拒绝；承载旧权限声明的短期 token 可能在过期前继续工作；应用自己签发的 session cookie 可能不受上游身份目录直接控制。团队必须为可接受的最长残留窗口设上限，并在高风险例外到期时主动撤销相关 session 或 token。不能只看管理页面的角色已删除就宣布完成。

复查从“谁拥有什么”升级为“为何仍需要”

权限复查若只导出成员清单让经理点“确认”，很容易变成形式。审查包应提供主体状态、团队、角色、有效动作、资源、授权来源、最后使用、例外到期和上次决定。审查人要回答：职责是否仍存在、权限是否实际使用、是否可由更低角色完成、直接授权能否迁入群组、是否存在冲突职责。

复查周期按风险设置，而不是全组织一个日历。组织 owner、账单管理员、秘密管理员、生产发布和审计导出等高权限应更频繁，并在转组、长期休假、重大事故、角色定义变化或资源分类提升时立即触发。普通只读权限可以更长，但外部协作者和无活动账号仍需单独关注。

subject_id,subject_state,resource,role,effective_action,source,last_used,exception_expiry,decision
usr_demo_002,active,demo-repo,contributor,branch.push,group:repo-contributors,<usage-ref>,,keep
usr_demo_003,transferred,demo-repo,maintainer,settings.write,direct,<usage-ref>,,remove
usr_demo_004,active,demo-repo,admin,repository.delete,exception,<usage-ref>,<expired>,remove

复查输出不能包含真实邮箱、token、客户资源名或完整审计内容。系统使用稳定主体 ID 和资源 ID，审查界面再按权限解析显示名。决定执行后，要重新导出有效权限差异，证明 remove 真的消失、reduce 变为目标动作，失败项进入限时修复而不是静默关闭工单。

入职、转组和离职是三种不同事件

入职强调从零授予：人员状态有效、所属团队明确、通过群组获得基础角色，首日不需要管理员手工逐个点选。转组强调先减后增：旧职责权限应先设回收时间，再授予新团队角色，避免“先加上，旧的以后再删”。离职强调阻止新会话、撤销活动凭据、移除群组与直接授权，并检查个人创建的 token、OAuth grant、SSH key 和外部协作者身份。

SSO 与 SCIM 能自动化身份与群组同步，但不能替团队决定某个角色应包含哪些动作，也不能自动发现资源侧 deploy key、共享秘密和手工创建的外部账号。身份自动化属于后续专文；当前权限模型必须为这些事件提供可验证输入和输出。

转组验证
- 输入：usr_demo_003 从 team-a 转到 team-b。
- 预期：team-a 群组移除；team-b 基础角色加入；直接例外单独评估。
- 正向：能读取 team-b 的测试项目并创建普通分支。
- 反向：不能再读取 team-a 的私有测试项目，旧会话也被拒绝。
- 证据：目录事件、产品授权差异、两次访问决策、例外处置。
- 回滚：身份事件误发时恢复原群组，不恢复已确认过期的高权限例外。

离职后仍能访问通常来自四类残留：产品内直接角色、未失效会话或 token、资源侧 key、外部身份或个人 OAuth。排查要逐层验证，不把“目录账号已禁用”当终点。Microsoft Entra 的紧急撤销访问说明明确区分身份提供方 token 与应用自己的 session：目录侧无法直接撤销应用自行签发的 session cookie，实际失效还取决于应用是否重新鉴权、同步停用状态并撤销本地会话。因此离职流程应同时阻止新 token、调用目标产品的会话与 token 撤销能力、移除产品内授权，再观察是否仍有成功认证；不支持即时撤销的产品要把最大残留时间写入风险和隔离措施。

权限失败从决策结果与来源链排查

用户报告“没有权限”时，最差处理是直接授予管理员。先确认主体是否正确、访问的是哪个租户和资源、请求动作是什么、角色从哪里获得、条件是否满足、拒绝发生在哪一层。SSO 登录成功只证明身份认证，不能证明产品角色、仓库权限或环境审批已经就绪。

用户报告“明明删了角色还能访问”时，检查群组继承、组织基线、嵌套组、外部协作者、直接资源授权、缓存会话、token scope、OAuth App 和 deploy key。对每一个来源做单变量撤销和重试，保留差异。不要连续点多个开关后只看最终结果，那会丢失根因。

现象	判断证据	常见原因	修复与再验证
登录成功但资源不可见	主体 ID、租户、群组同步	登录到错误组织或群组未同步	修正映射，重跑只读动作
角色删除后仍可写	有效权限来源、session、token	另一个群组或旧会话仍授权	撤销来源和会话，再做写入反测
UI 无按钮但 API 成功	API 审计与权限表	只做界面隐藏	在授权层拒绝，重跑 API
到期例外仍有效	例外状态、策略缓存	无自动回收或 token 内嵌权限	回收角色并使会话失效
离职用户事件仍出现	actor、auth type、key ID	机器人仍用个人凭据	迁移非人身份并轮换

权限故障恢复要遵循最小变化。若只是读取任务受阻，先授予测试资源只读并验证；不要为了赶进度把用户加入组织 owner。临时扩权必须复用例外模型并自动到期，故障关闭前再次计算有效权限。

审计只记录责任证据，不复制敏感内容

权限事件至少包含稳定主体 ID、认证方式、角色或策略、动作、资源 ID、决定、来源、时间和关联任务。角色创建、修改、分配、撤销、群组变化、共享账号禁用、例外批准与到期都应成为可查询事件。GitHub 的 组织审计事件 列出可出现的角色和组织活动；具体事件、保留和导出能力依目标产品计划而异，应在租户中验证，而不是写死统一期限。

{
  "event": "permission_decision",
  "subject_id": "usr_demo_002",
  "authentication": "sso_mfa",
  "action": "repository.settings.write",
  "resource_id": "repo_demo_081",
  "decision": "deny",
  "sources": ["group:repo-contributors", "policy:protected-settings"],
  "exception_id": null,
  "content_captured": false,
  "correlation_id": "evt_demo_91"
}

日志不应保存密码、token、完整请求正文、客户数据或导出的源码。查询权限也要与管理权限分离：能查看审计不代表能修改角色，能批准例外不代表能编辑自己的权限。对高风险角色变更设置不可由操作者自行抹除的外部日志或告警，避免管理员既执行又控制全部证据。

回收以“再也做不到”为验收标准

权限回收的完成条件不是管理页面显示 Removed，而是旧主体通过交互登录、旧浏览器会话、API token、Git/SSH、OAuth 与资源侧 key 都无法再完成原动作，同时继任者或自动化仍能完成必要任务。顺序按产品依赖设计：先转移必须保留的资源所有权与自动化，再阻止新认证，撤销直接例外、群组与角色，失效 session 和各类 token，清理资源侧 key 与 OAuth grant，最后运行正反验证。上文 GitHub deploy key 的边界说明了资源凭据不能靠成员删除间接回收。若产品文档只保证“阻止新 token”，测试就必须覆盖旧 token 的剩余有效期，不能自行扩大为即时失效承诺。

# 合成审查结果的本地检查示例，不连接真实租户
$before = Import-Csv .\fixtures\effective-before.csv
$after  = Import-Csv .\fixtures\effective-after.csv

$after | Where-Object {
  $_.subject_id -eq 'usr_demo_003' -and
  $_.effective_action -match 'write|admin|delete'
}

# 预期无输出；有输出就继续追踪 source 字段

反向实验用已回收的测试身份尝试读取允许列表、推送分支和调用设置 API，预期全部拒绝并生成 actor 清晰的事件。正向实验用接任者或目标群组完成其岗位任务，避免回收旧权限同时破坏业务。清理合成项目、测试分支和导出文件后，再核对 Git 状态与临时目录。

架构师要控制角色爆炸与管理员单点

角色太少会迫使所有人拿高权限，角色太多又会产生难以解释的组合。判断是否新增角色，可以看它是否对应稳定职责、是否被多名主体复用、是否能通过动作级实验、是否有 owner、是否能清楚区别于已有角色。只为一个人一次任务创建永久角色，通常应该改成限时例外。

管理员也需要分层。组织 owner、账单、审计查看、应用管理、仓库设置和秘密管理不应默认合并。产品支持自定义角色时，优先将日常管理动作从超级管理员拆出；产品不支持时，用双人审批、短期提权、独立审计和受控操作窗口补偿。任何关键操作若只有一个人能完成，都应建立 backup 与接管演练。

长期指标不要只看账号数量。更有价值的是共享账号剩余数、直接授权比例、过期例外数、高权限无活动账号、离职回收时长、角色定义变更后未复测数量、权限复查逾期数和有效权限无法解释的主体数。指标用于找到控制失效，不用于鼓励管理员批量删除而不验证影响。

从最小台账开始建立持续治理

小团队不必先建设庞大 IAM 平台。可以从一个受审查的角色定义文件、一份合成权限测试、一个 named account 规则和一个到期例外脚本开始。每次新工具接入时，先问它能否提供稳定主体 ID、群组或角色、会话与 token 管理、审计事件和回收 API；缺少的能力要么用外围控制补偿，要么降低可承载的数据和任务等级。

团队执行顺序可以稳定为：禁止新增共享账号；列出高风险角色和直接授权；为每个角色写一个正向、两个反向动作；把日常权限迁入群组；为例外增加到期；用转组与离职合成事件验证回收；最后才扩大自动化。这样每一步都能降低真实风险，而不是等待完美平台上线。

账号解决“谁”，角色解决“通常能做什么”，条件和例外解决“何时、对哪个对象”，有效权限解决“实际上还能做什么”，复查与回收解决“为什么现在仍需要”。只有这些环节互相校验，研发工具的操作才能从一个模糊的管理员账号，变成可追踪、可解释、可撤销的工程责任链。