AWS老号 亚马逊云 AWS 账号密保设置方案
别让AWS账号变成‘裸奔的ATM机’
\n去年某创业公司CTO在深夜改了个安全组规则，顺手把生产环境RDS的端口全放开——结果三小时后，数据库被扫出17万条用户手机号，勒索邮件发到了他个人邮箱。查日志才发现：他用的是Root账号+未启用MFA+密钥硬编码在GitHub公开仓库里。这不是黑客技术高超，是AWS账号防护比小区门禁还松。
\nAWS不是虚拟游乐场，它是你的数字资产核反应堆。Root账号不是‘管理员小号’，是核按钮；IAM用户不是‘临时工’，是持证上岗的特种兵；MFA不是‘可选项’，是防爆门锁芯。本文不讲PPT式原则，只给能立刻粘贴进控制台的操作清单、血泪教训总结和连实习生都能看懂的避坑指南。
\n\n第一步：给Root账号套上‘钛合金项圈’
\n必须！必须！必须！启用MFA
\nRoot账号MFA不是‘建议开启’，是AWS官方文档第一页就加粗标红的‘否则你将失去所有申诉权’条款。实测：未开MFA的Root账号，一旦密码泄露，攻击者5分钟内可创建新IAM用户、导出所有密钥、删除CloudTrail日志——全程无告警。
\n操作路径（别抄错）：登录Root邮箱→进入IAM安全凭证页→滚动到底部【激活MFA】→选Virtual MFA Device（推荐Google Authenticator或Microsoft Authenticator）→扫描二维码→输入两组6位码→点击【分配MFA】。完成！
\n血泪提醒：别用SMS短信MFA！AWS已明确宣布2024年起逐步弃用，且运营商通道可能被SIM卡劫持。更别把MFA设备和AWS账号存在同一台手机里——手机丢了等于钥匙和锁一起丢。
\n\nRoot密钥？直接物理销毁
\n检查你的Root账号Access Key ID是否还在？打开安全凭证页，如果看到‘Access Key’字段显示‘Active’，请立刻点右侧【删除】。Root密钥=终极权限+无审计日志+无法限制IP，它存在的唯一意义是证明你还没读完这篇文字。
\n替代方案：用IAM用户+策略限制。比如运维人员需要EC2权限，就建专门用户，附加AmazonEC2FullAccess策略，再加一条\"Condition\":{\"StringNotEquals\":{\"aws:SourceIp\":\"203.123.45.67\"}}锁定办公IP。Root只干三件事：开MFA、创建第一个IAM管理员、关掉自己的密钥。
AWS老号 第二步：IAM不是‘人人有份’，是‘按需发枪’
\n权限最小化：从‘上帝视角’到‘单孔窥镜’
\n某客户曾给财务专员赋予AdministratorAccess策略，理由是‘她要查账’。结果她误点S3控制台右上角【Empty bucket】，删光了三年备份。正确姿势：用AWS官方策略生成器（Policy Generator），勾选s3:GetObject、s3:ListBucket，限定资源ARN为arn:aws:s3:::finance-report-2023/*——让她只能看指定前缀的文件，连桶名都看不到。
进阶技巧：用Permissions Boundary给IAM角色戴‘电子镣铐’。比如开发测试角色，边界策略允许ec2:RunInstances，但禁止ec2:TerminateInstances。即使有人偷偷给角色加了删除权限，边界策略会当场拦截。
密码策略：别让‘123456’统治你的云
\n进入IAM → 【账户设置】→ 【密码策略】，勾选全部强制项：最小长度8位、要求大小写字母+数字+符号、90天过期、禁止历史密码复用。特别注意‘允许用户更改密码’必须打钩——否则HR批量重置密码时，员工只能干瞪眼。
\n真实案例：某银行因未启用‘密码重用限制’，员工反复用‘Password2023!’循环修改，导致撞库攻击成功率飙升300%。记住：密码策略不是防君子，是给黑客增加爆破成本。
\n\n第三步：密钥管理——别把API密钥当便利贴
\n访问密钥：用完即焚，定期轮换
\nAWS访问密钥（Access Key ID + Secret Access Key）不是长期饭票。我们要求：应用密钥有效期≤90天，个人CLI密钥≤30天。自动轮换方案：用Lambda函数每月触发iam:createAccessKey和iam:deleteAccessKey，旧密钥失效前3天邮件预警。
手动轮换步骤：1）新建密钥对；2）更新所有应用配置（别漏了Jenkins凭据、Terraform变量文件）；3）验证服务正常；4）删除旧密钥。重点检查：~/.aws/credentials、/etc/boto.cfg、Docker容器环境变量——曾有团队在K8s Secret里藏了3年未轮换的密钥。
Session Token才是真·临时工
\n永远优先使用STS临时凭证（sts:GetSessionToken）。它自带1小时过期、可绑定MFA、能限制源IP。比如CI/CD流水线调用AWS API，用aws sts get-session-token --serial-number arn:aws:iam::123456789012:mfa/user --token-code 123456获取临时Token，比硬编码密钥安全10倍。
第四步：让所有操作‘留痕可查’
\nCloudTrail：你的AWS监控摄像头
\n开通CloudTrail后，默认记录所有区域的管理事件（如创建S3桶、删除EC2实例）。但关键一步常被跳过：**把日志投递到跨账号S3桶+开启S3版本控制+设置生命周期策略**。否则攻击者删掉日志桶，你就真成了‘失忆患者’。
\n实操命令：aws cloudtrail create-trail --name audit-trail --s3-bucket audit-logs-987654321 --is-multi-region-trail。然后立刻在S3桶策略里添加Deny语句，禁止任何人删除aws-cloudtrail-logs-前缀的对象——这是日志的最后防线。
GuardDuty：免费的AI保安
\nGuardDuty是AWS内置的威胁检测服务，免费试用30天，之后每月$0.003/GB分析日志。它能发现：异常API调用频率（如1秒内发起500次iam:ListUsers）、加密货币挖矿流量、SSH暴力破解。某客户靠它提前3小时发现黑客正用被盗密钥横向移动——因为GuardDuty标记了‘从日本IP访问美国区S3’的异常行为。
开启方式：控制台搜索GuardDuty → 【启用】→ 选择分析日志源（CloudTrail+S3 DNS+VPC Flow Logs）。别嫌贵，它省下的应急响应费用够买10年订阅。
\n\n最后补刀：三个反常识但救命的细节
\n- \n
- ‘允许’不等于‘生效’：IAM策略里写
\"Effect\":\"Allow\"，但如果同时存在显式\"Effect\":\"Deny\"，Deny永远赢。检查策略时，用IAM Policy Simulator模拟操作，别靠猜。 \n - 根域名≠所有子域：S3存储桶策略中
\"Principal\":{\"AWS\":\"*\"}放行所有人，但\"Condition\":{\"StringLike\":{\"aws:Referer\":\"https://example.com/*\"}}只匹配example.com，不匹配api.example.com——必须写成\"https://*.example.com/*\"。 \n - 忘记MFA？别慌，但得趁早：Root账号MFA丢失，唯一办法是提交AWS支持工单（需企业支持计划）。普通支持要等72小时，期间账号冻结。所以——现在就用手机拍下MFA恢复代码，存进保险柜，不是微信收藏。 \n
安全不是功能开关，是肌肉记忆。下次登录AWS控制台，先做三件事：看右上角用户名是不是IAM用户、确认MFA图标亮着、快速扫一眼CloudTrail最近24小时有没有红色告警。做完这些，你才真正拿到了云世界的房门钥匙——而不是把钥匙焊死在门把手上，还邀请全世界来参观。” }
