亚马逊云老号 AWS亚马逊云账户保护策略
你有没有想过——那个注册AWS时随手填的邮箱、设的密码、点点鼠标开通的免费套餐，正默默躺在全球最危险的数字十字路口？
不是危言耸听。2023年，某跨境电商公司被黑，不是因为代码有漏洞，而是运维小哥把根账户密钥硬编码在GitHub公开仓库里；另一家AI初创公司损失超80万美元，只因忘记关闭测试环境的S3桶匿名写入权限，黑客直接塞满勒索信并加密全部训练数据。而这两起事故，根源全在账户本身没设防。
AWS很强大，但再强的云服务，也扛不住一个裸奔的账户。今天咱们不聊高大上的零信任架构，也不堆砌AWS白皮书术语，就坐下来，像两个老运维蹲在机房门口抽烟那样，聊聊怎么给你的AWS账户套上五层防弹衣。
第一层：根账户——请把它当传家宝供起来
根账户（Root User）不是管理员，它是AWS世界的“创世神”。它能删VPC、关IAM、清空账单、甚至把整个账号提交注销申请。但它没有MFA？可以？它还在用注册邮箱密码登录？行吗？
答案是：不行。绝对不行。立刻！马上！停下手头所有活儿，去IAM安全凭证页，把根账户的访问密钥（Access Key）永久删除——对，删掉，不是禁用。然后启用根账户的虚拟MFA（推荐Google Authenticator或Authy），再把MFA设备备份密钥存进防火保险柜（物理的那种）。最后，把根账户邮箱改为你个人实名认证、带邮件归档和异地登录告警的邮箱，别用公司公共邮箱，更别用163、QQ这种没审计日志的“快乐邮箱”。
做完这三步？恭喜，你已甩掉70%的账户级风险。
第二层：IAM——别让权限变成“万能钥匙”
很多团队建好IAM用户就开干，结果发现：开发A能删RDS，测试B能调用Lambda触发生产API，实习生C居然有EC2完全控制权限……这不是授权，这是发烟花——谁点都炸。
记住口诀：权限要像中药方子——君臣佐使，缺一不可；不能像火锅底料——一把倒进去，辣得所有人流泪。
实操建议三条：
- 永远不用AdministratorAccess策略——哪怕临时需要，也用自定义策略精确到具体资源ARN（比如只允许操作
arn:aws:s3:::prod-app-logs-2024/*）； - 按角色分组，而非按人建用户——“DevOps-Pipeline-Role”、“Finance-Billing-Reader”、“Security-Auditor”，人员变动只改组成员，不动策略；
- 开启IAM Access Analyzer——它会自动扫描策略里那些“允许所有区域”“允许所有动作”的危险表达式，每周跑一次，比人工Review快十倍。
顺手送你一行救命CLI命令，检测当前账户是否藏着“通杀型策略”：
aws iam list-policies --scope Local --query 'Policies[?PolicyName==`AdministratorAccess` || contains(PolicyName, `FullAccess`) || contains(DefaultVersion.Document.Statement[0].Resource, `*`)].PolicyName' --output table第三层：MFA——不是可选项，是呼吸权
亚马逊云老号 AWS控制台登录、CLI调用、甚至某些SDK请求，都可以被MFA兜底拦截。但很多人只给根账户配了MFA，却放任几十个IAM用户裸奔。
别偷懒。用IAM策略强制MFA：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireMFAForSensitiveActions",
"Effect": "Deny",
"Action": [
"iam:*",
"ec2:TerminateInstances",
"s3:DeleteBucket"
],
"Resource": "*",
"Condition": {
"Null": {
"aws:MultiFactorAuthAge": "true"
}
}
}
]
}这段策略的意思是：“没MFA？那这些高危操作，一律禁止。”部署后，连资深工程师都得掏出手机点一下才敢删实例——这恰恰是你想要的克制感。
第四层：密钥与凭证——别让Access Key活过90天
AWS密钥不是身份证，是动态口令卡。它该有保质期、有使用记录、有自动报废机制。
三件事必须做：
- 所有Access Key强制开启轮换（90天自动失效），用Credential Report导出密钥年龄清单，每月发邮件提醒；
- 禁止任何硬编码——本地开发用AWS CLI配置文件（
~/.aws/credentials），上线用IAM Role绑定EC2或ECS任务； - 用aws-security-scripts里的
find-unused-keys.py定期扫出三个月零调用的密钥，一键禁用。
第五层：监控与断电——看得见，才管得住
防御不是堵门，是装摄像头+拉电闸。
看：开CloudTrail（所有区域），把日志投递到专用S3桶（桶策略只允许可信IP + 必须启用版本控制 + 启用对象锁定），再接上CloudWatch Alerts——比如“1小时内出现5次FailedAuthentication”，立刻微信告警。
断：部署GuardDuty，它能识别异常API调用模式（比如凌晨3点从尼日利亚IP调用1000次EC2启动）、可疑凭证泄露（密钥出现在GitHub gist里）、甚至挖矿流量特征。一旦触发High级别Findings，用EventBridge自动触发Lambda，立即禁用对应IAM用户，并发邮件+短信通知负责人。
最后，留一手“紧急熔断”预案：准备一个独立的、仅含iam:DeactivateMFADevice和iam:DeleteAccessKey权限的“断电角色”，其凭证绝不存云端，只记在团队组长的纸质笔记本第一页——真出事，5分钟内全员权限清零。
Bonus：三个反直觉但极有效的细节
- 禁用AWS Console的“Remember me”功能——浏览器记住密码=给社工攻击铺红毯；
- 把AWS Organizations用起来——哪怕单账号，也创建一个Org，启用SCP（Service Control Policies），从源头禁止
iam:CreateUser等高危动作； - 定期“红队自查”：用刚入职的实习生账号，只给最低权限，让他尝试提权——他走通的路径，就是你最大的破绽。
账户安全不是一次性项目，是每日晨会要问的三句话：
“上个月有没有新密钥没轮换？”
“GuardDuty有没有未处理的High级告警？”
“我们最不放心的那个人，现在用的是什么权限？”
技术会迭代，工具会升级，但账户安全的本质从未变过：不靠运气，不赌人性，只信流程、日志和定期亲手拧紧的螺丝。
现在，放下手机，打开AWS控制台——就现在。别等明天，别等下次审计。你的账户，值得被认真对待。
