2019年，Capital One遭遇了美国银行业历史上最大规模的数据泄露之一，1.06亿客户的个人信息被窃取。原因是什么？不是复杂的黑客攻击，不是零日漏洞，而是一个配置错误的防火墙，加上一名员工拥有过高权限的IAM角色。

攻击者利用了防火墙的SSRF漏洞，欺骗了这个高权限角色，获取了存储桶的访问凭证。一个权限过高的角色，配上一个配置错误的防火墙——1.06亿条记录就这样流出去了。

这个故事告诉我们一个残酷的真相：云上安全最大的威胁往往不是外部黑客，而是你内部失控的权限。

今天咱们聊聊多云战略下的IAM——身份与访问管理。不是那种"最小权限原则很重要"的正确废话，而是真正能帮你避免"一觉醒来账户被盗"的实战经验。

01 多云IAM为什么容易失控？

如果你的业务只跑在一朵云上，IAM已经够复杂了。AWS有IAM角色、策略、边界、权限边界、服务控制策略（SCP）——光是概念就能把人绕晕。

现在再加一朵Azure，再来一个阿里云。每个平台有自己的术语、自己的模型、自己的配置方式。AWS的Role不等于Azure的Role，阿里云的RAM策略语法和AWS的JSON策略完全不同。

失控是怎么发生的？

• 临时权限变永久：某个开发说"给我开个S3权限，我调试一下"，三个月后权限还在。

• 跨云权限不一致：AWS上严格执行了最小权限，Azure上却给了一堆宽松权限。

• 幽灵权限堆积：人员离职了，权限没回收；项目结束了，服务账号还在。

• 密钥到处乱放：AccessKey硬编码在代码里，提交到GitHub，被爬虫扫到。

某云厂商的内部数据显示：超过60%的云账户中存在超过30天未使用的"僵尸权限"，这些权限就是悬在你头顶的刀。

02 最小权限原则：别把它理解成"越小越好"

最小权限原则（Principle of Least Privilege）被念叨了几十年，但大多数人理解错了。

它不是说"权限越小越好"，而是说"刚好够用就好"。

区别在哪？"越小越好"会让你的业务跑不起来。开发要写代码，运维要配环境，分析师要看数据——每个人都需要权限。你卡得太死，他们就会想方设法绕过——把密钥硬编码、关掉审计、共享账号。

这是权限治理的第一悖论：安全性和效率是跷跷板的两头，你不能只要一头。

真正的落地方式是：

• 分层授权：给开发人员"开发环境的管理权限"，而不是"生产环境的管理权限"。

• 临时授权：需要高权限操作时，走审批流程申请临时提权，用完自动回收。

• 自动化权限管理：不要用手工给权限，用IaC（Terraform等）管理IAM，让权限变更可追溯、可审计。

反常识观点：允许"适度"的权限，比追求"极致"的最小权限更安全。因为前者大家会遵守，后者会被绕过。

03 身份联邦：用一套身份走天下

多云最大的痛苦：每个云一套用户系统，开发得记三个密码，管理员要在三个控制台配权限。

解决方案是身份联邦（Identity Federation）——用企业已有的身份系统（如AD、LDAP、Okta）来登录云平台。

怎么做？

• 企业自建身份源（IdP），员工登录公司系统时完成认证。

• IdP通过SAML断言告诉云平台："这个用户是谁，属于哪个组"。

• 云平台根据断言里的属性，映射到本地角色，授予对应权限。

好处是什么？

• 员工离职，一键封停：不用跑三个云控制台去删账号。

• 权限集中管理：在IdP里就可以控制谁能访问哪个云。

• 多因素认证（MFA）统一配置：不用每个云单独设。

国内不少企业还在用"共享账号"的方式——一个AWS根账号，十个人共用，谁用谁切。这是灾难，一定要改。

04 密钥管理：让AccessKey变成"一次性筷子"

云平台的AccessKey相当于你家的钥匙。丢了，别人就能进屋。

但现实中，AccessKey的管理有多随意？

• 写在配置文件里，跟着代码一起提交到GitHub。

• 存在服务器上的明文文件里。

• 一个Key用三年，从不轮换。

• 开发、测试、生产用同一套Key。

GitHub的爬虫每天都在扫描代码仓库，找AccessKey。一旦发现，几小时内就会被黑产利用，拉起矿机、盗取数据。

最佳实践：

• 用临时凭证代替长期Key：AWS的STS可以颁发有效期为几小时到几天的临时凭证。用完即废，丢了也不怕。

• 必须用长期Key的话，定期轮换：90天换一次，自动化的那种。

• 永远不要写死在代码里：用Secrets Manager、Parameter Store这类服务存密钥。

• 禁用根账号的AccessKey：根账号的权限太大，一辈子都不该有Key。

反常识观点：很多团队纠结"如何保护Key"，其实更好的答案是"让Key消失"——用IAM Role取代Key。EC2、Lambda、EKS这些服务都可以直接绑定角色，不用配置任何Key。

05 权限审计：别等出事了才查

多云环境下，权限是动态变化的。今天开了个桶，明天加了个策略，后天走了个人。三个月下来，权限早就面目全非。

你需要持续审计，不是"一年查一次"。

审计工具该看什么？

• 未使用的权限：某个角色90天没被Assume过，留着干嘛？

• 过高权限：谁能做":"？谁有"AdministratorAccess"？

• 跨账号信任：你信任了哪些外部账号？它们还能访问你的资源吗？

• 密钥使用情况：哪些Key超过90天没轮换？哪些Key最近被使用过？

云厂商提供了工具：AWS IAM Access Analyzer、Azure AD Privileged Identity Management、阿里云RAM访问分析。用起来。

开源方案：CloudMapper、Scout Suite可以帮你扫描云环境，发现配置风险。

突发性数据：某安全厂商的报告显示，95%的云账户存在至少一条"过度权限"的配置，80%的账户有超过一年未使用的"僵尸权限"。这些数据听起来吓人，但我知道你心里在想："我们可能也是。"

是的，大概率是的。

06 落地：三个月内能做的事

别想一口吃成胖子。给你一个三个月路线图：

第一个月：摸清家底

• 列出所有云账号、所有子账号、所有服务账号。

• 导出现有权限配置，整理成清单。

• 找出所有有":"权限的账号，重点关注。

第二个月：削减攻击面

• 给根账号开启MFA，禁用它的AccessKey。

• 轮换所有超过90天的AccessKey。

• 删除所有未使用的IAM用户和角色。

• 开启云厂商的访问分析工具，按提示收紧权限。

第三个月：建立机制

• 配置身份联邦，用企业IdP登录云平台。

• 把IAM管理纳入IaC，禁止手工改权限。

• 设置定期审计任务，每月出一份权限报告。

• 建立权限申请审批流程，高权限操作必须走流程。

三个月后，你可能还没做到完美，但已经比90%的企业强了。

写在最后

回到开头的Capital One案例。事后分析发现，那名员工的高权限角色其实本不该存在。那个角色的权限远远超过工作所需，只是"方便"才给开的。

方便和安全，永远是敌人。

多云战略带来了灵活性，也带来了复杂性。IAM失控不是会不会发生的问题，而是什么时候发生的问题。你今天忽视的"临时权限"，明天可能就是被黑客利用的那个入口。

一位安全老兵跟我说过一句话："权限管理不是技术问题，是组织问题。技术可以帮你发现谁有权限，但只有制度能决定谁该有权限。"

你的云上钥匙，现在在多少人手里？他们真的还需要吗？

今晚回去查查。