AWS日本账号 AWS亚马逊云IAM用户权限设置
你有没有在AWS控制台点到一半，突然弹出一个红字警告："AccessDenied"？
那一刻，你盯着屏幕，手悬在键盘上，心里默念三遍："我不是root，我不是root，我不是root……"
别慌——这不是你的错，是IAM在温柔地（但坚定地）给你上安全课。
一、IAM不是“用户管理”，是“权限导演”
先破个幻觉：IAM（Identity and Access Management）根本不负责管人，它只管谁能在什么条件下干啥事。它不管你是张三李四，也不关心你工号几号，只认一句话：“这个凭证（Access Key或密码），此刻想调用哪个API，带了哪些参数，是否满足所有预设条件？”
所以别急着建用户，先问自己三个灵魂问题：
- 这个人真正需要做什么？（不是“他以后可能要用”，是“今天下午三点他必须重启这台EC2”）
- 他必须在哪做？（公司办公网？家里Wi-Fi？还是非得用手机热点？）
- 他必须什么时候做？（9:00–18:00？还是只允许周五17:00批量删日志？）
答案越具体，你的策略就越干净；越模糊，后期越容易半夜被电话叫醒查权限漏洞。
二、建用户？先忍住！策略才是主角
很多人一上来就猛点“Create user”，填完名字点下一步，再勾选“Programmatic access”和“AWS Management Console access”，然后——卡住了。因为接下来要选权限组，而列表里赫然躺着一个诱人的选项：AdministratorAccess。
停！深呼吸三次。
这个策略就像一把万能钥匙，能开AWS全部170+项服务的全部门。但它不叫“管理员权限”，它叫“我愿用未来三个月的咖啡因戒断换一次事故追责”。
真实案例：某团队给新入职运维配了AdministratorAccess，结果他误删了S3桶（没开版本控制），又顺手清空了CloudTrail日志——等发现时，连谁删的都查不到。老板没骂他，但整个Q3的合规审计报告，成了一页PPT加三个省略号。
最小权限原则不是KPI，是生存法则。
AWS日本账号 三、动手写策略：不用JSON也能赢
别怕策略文档长得像《民法典》。AWS早就准备好了“可视化策略生成器”（IAM Policy Generator），但更推荐你用官方在线策略生成器（对，就是那个连HTTPS都没配、但至今活着的古老页面）——它不联网、不传数据，纯前端拼接，安全得像个修自行车的老技师。
举个栗子：你需要一个用户，只能查看北京区（cn-north-1）的EC2实例列表，且仅限工作日9–18点访问。
策略长这样（删掉注释，就是合法JSON）：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*",
"Condition": {
"StringEquals": {"aws:RequestedRegion": "cn-north-1"},
"DayOfWeek": {"aws:CurrentTime": ["Mon", "Tue", "Wed", "Thu", "Fri"]},
"TimeOfDay": {"aws:CurrentTime": ["09:00", "18:00"]}
}
}
]
}注意：aws:CurrentTime是UTC时间！北京是UTC+8，所以如果你真想限制北京时间9–18点，得写成01:00到10:00——没错，就是这么反直觉。这也是为什么建议：要么统一用UTC写策略，要么在文档里用红字标出“此处为UTC时间”。
四、MFA？不是可选项，是入场券
没有MFA的IAM用户，就像没锁门的保险柜——钥匙丢了，钱就没了。AWS早就不止一次强调：所有具备console访问权限的用户，必须强制绑定虚拟MFA设备（如Google Authenticator或Authy）。
怎么强？不是“建议开启”，而是用策略堵死：
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}把它加进用户策略或组策略，用户下次登录就会看到：“请先配置MFA，否则无法进入控制台。”
（小技巧：把这个Deny策略单独建一个叫“Require-MFA”的托管策略，以后所有需MFA的组，一键附加即可。）
五、那些年我们踩过的坑
- “我就改了个Tag，咋没权限？”→ EC2的
ec2:CreateTags和ec2:DeleteTags是独立动作，不包含在ec2:Describe*里； - “我明明给了S3权限，为啥上传失败？”→ S3有两层权限：Bucket策略（资源级） + IAM策略（身份级），缺一不可；
- “策略生效要多久？”→ 答案是：秒级。但控制台缓存可能让你以为延迟，强制刷新（Ctrl+F5）或换隐身窗口验证；
- “能不能限制只读用户看特定标签的资源？”→ 可以！用
ResourceTag/Environment条件键，配合ec2:DescribeInstances的Filter参数，但注意：不是所有API都支持标签过滤。
六、终极心法：权限即文档
每一条策略，都该是一份可读、可审、可追溯的微型说明书。建议你在策略的"Description"字段（或关联的IAM备注）里，写清楚：
- 谁申请的？
- 为什么需要？（附Jira链接或会议纪要编号）
- 有效期到哪天？（别忘了设自动过期！）
- 下次评审时间？（比如“2025-Q2重审”）
这样，半年后你被调去搞Lambda冷启动优化，接盘同事打开策略一看，就知道这串JSON背后是谁、为啥存在、何时该砍。
最后送一句AWS资深架构师常挂嘴边的话：
“你不是在配置权限，你是在给未来的自己写免责说明书。”
所以，下次再看到AccessDenied，别叹气——那是IAM在说：
“嘿，朋友，咱们把规则写清楚，比事后救火，体面多了。”
