AWS企业实名 亚马逊云 AWS 账号权限管理方案

别让AWS账号变成‘裸奔账户’：一份不讲PPT、只掏干货的权限管理指南

你有没有过这种时刻？凌晨三点，监控告警疯狂刷屏，一查发现是某个开发同学误删了生产环境的RDS快照——而他用的账号，居然有ec2:TerminateInstances和rds:DeleteDBSnapshot两个高危权限；又或者，安全团队例行审计时翻出37个长期未轮换的访问密钥，其中5个绑定在根账号上……别急着甩锅给“操作失误”，真正的问题，往往藏在权限设计的毛细血管里。

一、根账号：不是你的‘主号’，而是你的‘保险柜钥匙’

AWS根账号（Root Account）不是起点，是终点。它拥有全服务、全区域、无条件的绝对权限，且无法被策略限制。把它当日常登录账号？等于把银行金库的总钥匙挂在工位墙上还贴张便签写“请勿乱动”。真实建议只有三条：锁死、封存、遗忘。开通后立刻启用MFA（硬件令牌优先），导出并离线加密保存根账号凭证，然后——彻底停用。后续所有操作，必须通过IAM实体完成。我们曾见过某客户因根账号密钥泄露导致S3桶被勒索挖矿，事后复盘发现：他们甚至没开启MFA，密钥就明文存在Git仓库里，还带注释：“老板说这个最保险”。保险？保险柜门开着，还贴了张导航图。

二、IAM用户：别当‘独行侠’，要建‘作战小组’

每个真人对应一个IAM用户？错。IAM用户本质是身份载体，不是人名标签。正确姿势是：按职能分组，按任务授权，按周期轮换。比如“运维组”不直接授予权限，而是作为策略容器；真正执行EC2重启的，是“prod-ops-ec2-restart”这个角色；而开发同学A需要临时调试Lambda，就让他临时扮演“dev-lambda-debug”角色——权限随角色走，不随人走。我们给某电商客户重构权限时，把原先127个散装用户精简为23个标准化用户组+41个角色，权限变更效率提升80%，审计报告从37页压缩到5页。

三、角色（Role）：云原生权限的‘任脉’，别让它堵在胸口

角色才是AWS权限的真正心脏。跨账号访问、EC2实例临时凭证、Lambda执行上下文——全靠角色串场。关键口诀：信任策略定边界，权限策略管动作。常见死穴有二：一是信任策略写成"Principal": {"Service": "ec2.amazonaws.com"}却忘了加Condition限定来源实例配置，结果任何EC2都能代入；二是权限策略用"Resource": "*"图省事，实则埋下越权地雷。记住：角色不是“我允许谁调用我”，而是“我允许谁在什么条件下以什么身份调用我”。我们修复过一个案例：某CI/CD管道角色被赋予iam:PassRole且资源不限，攻击者借此创建恶意角色并注入EC2启动脚本——权限链瞬间断裂。

四、SCP：组织级‘铁栅栏’，不是装饰画

服务控制策略（SCP）常被误认为“高级版IAM策略”，大错特错。SCP不授予权限，只做减法——它是在组织单元（OU）层面设置的天花板。哪怕IAM策略写了"Effect": "Allow"，只要SCP写着"Effect": "Deny"，请求当场毙命。典型用法：在“测试OU”下禁止s3:PutBucketPolicy，防止测试账号意外公开生产桶；在“财务OU”禁用ec2:RunInstances，杜绝非IT部门自建服务器。注意：根组织单位（Root OU）的SCP影响全局，修改前务必用aws organizations simulate-policy预演——我们有客户曾因一条Deny * on *误配，导致整个亚太区API网关全部失联，恢复花了47分钟。

五、权限边界与会话策略：给权限套上‘双保险’

权限边界（Permissions Boundary）是附加在用户/角色上的“隐形天花板”，会话策略（Session Policy）则是临时会话的“速效救心丸”。两者不冲突，而是叠加生效。举个实战场景：某外包团队需访问日志S3桶，但严禁下载原始数据。方案是——给其角色绑定权限边界s3:GetObject仅限logs/*路径，再通过STS AssumeRole传入会话策略，显式拒绝s3:GetObject对*.csv和*.json后缀的请求。双重过滤下，连aws s3 cp s3://my-bucket/logs/app-2024.csv .都会被拦住。这不是过度设计，是把“不能做”刻进系统DNA。

六、踩坑现场直击：那些年我们交过的‘权限税’

• 坑1：策略版本混搭——IAM策略用Version: '2012-10-17'，但SCP沿用老版Version: '2008-10-17'，导致Condition语法失效，Deny规则形同虚设；
• 坑2：通配符陷阱——策略里写"Resource": "arn:aws:s3:::my-bucket/*"看似安全，实则s3:GetBucketLocation等桶级操作仍能穿透，必须显式声明桶级ARN；
• 坑3：跨区域盲区——在us-east-1设置的SCP，对ap-southeast-1的资源毫无约束力，多区域架构必须逐区域部署或使用组织级SCP。

七、权限健康度自查清单（可直接打印贴工位）

1. 根账号是否启用硬件MFA？凭证是否离线加密封存？
2. 是否存在超过90天未登录的IAM用户？是否存在未轮换超180天的访问密钥？
3. 所有EC2实例是否绑定角色而非长期密钥？角色信任策略是否精确限定来源实例配置？
4. 组织内是否至少有一个OU应用了SCP？是否覆盖高风险操作（如S3公开策略、KMS密钥删除）？
5. AWS企业实名 敏感角色（如CI/CD、数据库管理员）是否设置了权限边界？是否启用CloudTrail日志加密并独立存储？

最后说句实在话

权限管理不是安全团队的KPI填表作业，而是业务连续性的底层基建。它不该出现在事故复盘会上，而该默默站在每次API调用的背后，像空气一样存在——你看不见它，但缺了它，系统立刻窒息。下次当你新建一个IAM用户时，不妨停三秒：这个权限，是业务真需要，还是我们懒得想清楚？毕竟，在云上，最大的风险从来不是技术漏洞，而是那句轻飘飘的“先开个权限试试”。