1. 云IAM治理全景

在传统数据中心里，权限往往依附于服务器、数据库和网络边界；进入云环境后，身份成为新的安全边界。云IAM（Identity and Access Management，身份与访问管理）治理，指的是围绕“谁、以什么身份、在什么条件下、能对哪些云资源做什么操作”这一核心问题，建立可定义、可授予、可审计、可回收的持续管理机制。它不是一次性配置，而是一套贯穿身份生命周期、权限授予、访问决策与合规审计的治理体系。

理解云IAM治理，需要先区分三个层次。第一层是身份：包括云账号根用户、IAM用户、用户组、角色（Role）、联合身份、服务账号、工作负载身份等。第二层是权限：由策略（Policy）描述，规定允许或拒绝的动作、资源和条件。第三层是治理：在身份与权限之上叠加流程、责任、审计与自动化，确保权限始终与业务需要匹配，而不是随项目扩张不断累积。

从目标看，云IAM治理通常同时服务四个方向。其一是安全：遵循最小权限原则，降低凭证泄露、权限提升和横向移动的风险。其二是合规：满足等保、ISO 27001、SOC 2 等对访问控制、职责分离和审计留痕的要求。其三是效率：让开发、运维和业务团队能够快速获得所需权限，而不是被审批流程拖慢。其四是可运营：权限能够被盘点、被解释、被回收，出现异常时能够定位到具体身份和策略。

然而，云IAM治理在实践中面临几类典型挑战。第一是规模与动态性：云上资源按需创建，身份和权限数量可能从几百迅速增长到数万，人工维护权限矩阵很快失效。第二是权限蔓延：人员转岗、项目结束、临时授权未回收，都会导致权限只增不减。第三是策略复杂性：显式拒绝、权限边界、服务控制策略、资源策略、会话策略可能同时生效，最终决策需要综合判断。第四是多云异构：不同云厂商的IAM模型、策略语法和审计日志格式不同，统一治理难度高。第五是责任边界模糊：安全团队、平台团队、应用团队对权限的归属和审批责任容易重叠或空缺。

上图把云IAM治理拆成三个相互作用的层次：身份层回答“谁在访问”，权限层回答“能做什么”，治理层回答“如何持续管好”。三者之间不是单向流水线，而是持续反馈：治理策略会反过来约束身份创建和权限授予，审计结果又会驱动权限回收和策略调整。图中下半部分列出了本节需要建立认知的核心挑战，以及后续课程从基础概念、模型与策略、治理实践、审计运营到案例复盘的推进路线。

为了把治理从口号落到可执行，可以先建立一个最小可用的权限盘点表。下面是一份示例模板，用于记录一个云账号内关键身份的权限现状。字段和取值均为教学示例，实际使用时需替换为真实数据。

这张表的价值不在于字段本身，而在于它把“权限治理”变成了可判断的动作：看到通配符和长期未使用，就可以优先收敛；看到角色被CI/CD系统正常使用，就保留但增加条件约束。实际落地时，可以先用云厂商的凭证报告或访问分析器导出数据，再按“高危、闲置、合规必需”三类打标，最后进入审批和回收流程。

本课程后续将沿着“概念—模型—策略—治理—审计—案例”的路径展开。你会先理解身份与权限的基本对象和策略评估逻辑，再进入权限边界、最小权限、职责分离等治理机制，随后学习如何用日志、访问分析器和自动化工具持续运营，最后通过真实场景的排障与复盘，把零散知识串成可复用的治理能力。学习时建议始终带着一个问题：当前这个身份，是否真的需要这些权限？如果不需要，应该怎样安全地收回？