RAM权限策略设计：最小权限原则实践
RAM（访问控制）是阿里云的安全基石。正确的权限设计可以防止误操作和安全事故。很多企业为了方便给所有子账号授予AdministratorAccess，这是极其危险的做法。本文分享如何设计合理的RAM权限策略。
「RAM权限策略设计：最小权限原则实践」提醒我们一个朴素的事实：云上安全纵深防御靠的不是临场发挥，而是平时的体系化建设。告警是否准确、日志是否齐全、权限是否收敛，决定了故障来临时是从容处置还是手忙脚乱。
核心概念
用户（User）：具体的操作人员或应用。每个操作人员应有独立的RAM用户，禁止共用账号。用户组（Group）：将用户分组，统一授权。如"运维组"、"开发组"、"只读组"。角色（Role）：临时身份，用于跨账号授权或服务间调用。ECS绑定RAM角色就是典型场景。策略（Policy）：定义允许或拒绝的操作，是权限的最小单元。
策略设计原则
最小权限原则：只授予完成工作所需的最小权限。开发人员只需要开发环境的ECS和RDS权限，不需要管理RAM、删除资源等高危权限。
职责分离：不同角色有不同的权限。开发人员可以部署代码但不能修改安全组；运维人员可以管理基础设施但不能查看业务数据。
定期review：每季度检查一次权限分配，及时回收不再需要的权限。员工离职立即禁用账号。
自定义策略示例
只允许操作特定Bucket的OSS：{"Effect": "Allow", "Action": ["oss:GetObject", "oss:PutObject"], "Resource": ["acs:oss:*:*:my-bucket/*"]}
只允许重启特定ECS：{"Effect": "Allow", "Action": "ecs:RebootInstance", "Resource": "acs:ecs:cn-hangzhou:*:instance/i-xxxxx", "Condition": {"StringEquals": {"ecs:tag/Environment": "dev"}}}
拒绝删除任何RDS实例（防止误删）：{"Effect": "Deny", "Action": "rds:DeleteDBInstance", "Resource": "*"}。Deny优先级高于Allow，即使有Allow策略也会被Deny覆盖。
STS临时授权
对于需要临时授权的场景（如前端直传OSS），使用STS生成临时凭证（有效期15分钟-1小时），过期自动失效。比将长期AK嵌入前端代码安全得多。
云上安全纵深防御的体系化思路
与其追求单点工具的极致配置，不如先保证覆盖面：关键资产是否都在监控之内、重要操作是否都有审计、对外暴露面是否都经过评估。覆盖面完整之后，再谈深度优化才有意义。
体系化的另一个好处是可传承：不依赖某个人的记忆，而是依赖流程与清单，团队整体水位才会稳定提升。
一份可执行的日常清单
- 暴露面盘点：定期梳理对外端口与服务，关闭不必要的开放。
- 权限最小化：账号与密钥按最小权限分配，定期回收闲置权限。
- 告警治理：清理长期无人响应的告警，保证留下的告警都值得处理。
- 预案演练：对高频故障场景准备处置预案并定期演练。
清单不复杂，难在坚持；而云上安全纵深防御的差距，恰恰体现在坚持上。