亚马逊云32核账号 AWS亚马逊云安全设置必做
你有没有在深夜收到一条 Slack 消息，内容是：“兄弟，咱们的生产 S3 桶被扫出来了，里面全是客户身份证照片，现在被挂到了 Telegram 群里。”
别急着删 Slack 记录——先深呼吸，再打开 AWS 控制台。因为这事，大概率不是黑客多厉害，而是你刚开完一个新账号，顺手点了“创建 IAM 用户”，然后把 Access Key 明文贴进 GitHub；又或者，你在 CloudFormation 里随手写了 "*" 当 Principal，还美其名曰“方便调试”。
AWS 不是保险柜，它是一整套带钥匙孔、密码锁、监控探头、报警铃、甚至还能自己写巡逻日记的安防系统——但前提是你得亲手把门锁上、把摄像头调好、把警报音量调到最大。否则，它就是一扇虚掩的玻璃门，风一吹就晃，猫一撞就开。
下面这 7 件事，不是“建议做”，而是上线前必须做完的底线操作。少一项，你就不是“云原生”，你是“云裸奔”。
亚马逊云32核账号 1. 根用户？锁进保险柜，钥匙熔掉
AWS 账号刚注册时那个邮箱+密码登录的账户，叫根用户（Root User）。它能干啥？删整个账单、关所有服务、导出所有密钥、关闭 MFA——它不是管理员，它是上帝模式。
✅ 正确姿势：
• 立刻为根用户开启 硬件 MFA（推荐 YubiKey 或 Titan Key），软件 MFA（Google Authenticator）次之；
• 永久禁用根用户的访问密钥（IAM → Users → Root user → Security credentials → Deactivate access keys）；
• 把根用户密码写在纸上，锁进物理保险柜，拍照存手机相册？不行，截图？更不行。真要动它，必须三人到场、录像、签字——这不是流程主义，这是防你自己半夜三点手抖点错按钮。
⚠️ 坑点提醒：很多团队用根用户建第一个 IAM 用户，建完就忘了登出。结果某天 CI/CD 流水线报错，运维顺手切回根用户重试……然后误删了 Route53 托管区——域名解析全崩，官网变 404，客服电话被打爆。
2. IAM 用户 ≠ 全员 root，权限必须“抠门到骨子里”
别信“先给 AdminAccess，后面再收权”的鬼话。现实是：93% 的权限收缩计划，会在第 3 天因“这个功能又不能用了”而无限延期，最后变成“祖传 Admin 策略”。
✅ 正确姿势：
• 新员工入职，第一件事不是发密码，而是发一张权限申请单（哪怕只是钉钉审批流）；
• 每个 IAM 用户只附加 自定义策略，且策略必须满足：
- 使用 "Resource": ["arn:aws:s3:::my-app-prod-*"]，而非 "Resource": "*"；
- 用 "Condition": {"StringLike": {"s3:prefix": ["uploads/", "avatars/"]}} 限定操作路径；
- 所有 "Effect": "Allow" 后面，必须配一条 "Effect": "Deny" 来封死危险动作（比如 "iam:CreateUser"）；
• 每季度跑一次 Access Advisor（IAM 控制台 → 用户 → 点进某个用户 → Access Advisor 标签页），把 90 天没用过的权限，直接删掉。
3. MFA？不是“可选项”，是每个能登录控制台的人的呼吸权
没有 MFA 的 AWS 控制台登录，就像用生日当银行卡密码——不是“可能被黑”，是“等被黑”。
✅ 正确姿势：
• 进入 IAM → Policies → Create policy → JSON tab，粘贴这段强制策略（别改，照抄）：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BlockMostAccessUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ListUsers",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}• 把这策略绑定到所有用户组（比如 Developers、Admins）。从此，没 MFA？连 EC2 控制台都打不开。
4. CloudTrail 不开？等于银行金库不装监控
CloudTrail 记录所有 API 调用：谁、什么时候、在哪台机器、删了哪个 RDS 实例、改了哪条安全组规则。它不阻止攻击，但它让你能在 2 分钟内定位肇事者——而不是花三天翻日志猜“是不是 Jenkins 自动化脚本干的？”
✅ 正确姿势：
• 进入 CloudTrail → Create trail；
• 勾选 “Apply trail to all regions”；
• S3 存储桶选全新专用桶（别用项目共用桶！），桶策略必须禁止 public-read、禁止 delete（开启版本控制 + MFA Delete）；
• 开启 CloudTrail Insights（额外收费但值），它会自动告警异常行为，比如“过去一小时某用户调用 ec2:TerminateInstances 高达 87 次”。
5. S3 桶？默认不公开，公开必审批，审批必留痕
全球 90% 的云数据泄露始于 S3。为什么？因为新建桶默认“私有”，但只要点一下“Make public”，或加一行 "Principal": "*"，它就变成互联网公厕。
✅ 正确姿势：
• 创建桶时，取消勾选 “Block all public access” 下的任意一项（四项全勾！）；
• 若真需公开（如静态网站），必须：
- 单独建 www.yourapp.com-static 桶；
- 用 Bucket Policy + CloudFront + OAI 代理访问，绝不用 "Principal": "*"；
- 在该桶上启用 S3 Block Public Access 和 S3 Object Lambda（用于动态脱敏）；
• 每周一运行一次 CLI 扫描：aws s3api list-buckets --query 'Buckets[].Name' --output text | xargs -n1 -I {} aws s3api get-bucket-policy-status --bucket {} --query 'PolicyStatus.IsPublic' --output text 2>/dev/null | grep true，结果非空？立刻查责任人。
6. 安全组？宁可连不上，不可全放开
别再写 0.0.0.0/0 了。你不是在“方便测试”，你是在给全世界的扫描器递名片。
✅ 正确姿势：
• Web 层安全组只放行：
- 443（HTTPS）→ 来源：CloudFront IP 段 或 ALB 安全组 ID；
- 22（SSH）→ 来源：跳板机安全组 ID，且仅限工作时间（用 Security Group Rules with Time-based Conditions，配合 Lambda 自动开关）；
• 数据库层安全组，拒绝所有入站，只允许应用服务器安全组 ID 访问 5432/3306；
• 每季度用 EC2 → Security Groups → Actions → View inbound rules in context 查冗余规则——那些标着“test-2022”却还在生效的规则，删。
7. GuardDuty？不是锦上添花，是你的云上保安队长
GuardDuty 是 AWS 自研的威胁检测服务，它默默分析 VPC Flow Logs、DNS 日志、CloudTrail，发现异常：比如某 EC2 实例突然大量外连矿池 IP、某 IAM 用户从莫斯科登录后立刻创建新 Access Key……
✅ 正确姿势：
• 进入 GuardDuty → Enable GuardDuty（选全部区域）；
• 在 Settings → Findings → Notifications 绑定 SNS 主题，再接企业微信机器人；
• 对中高危告警（如 TrafficDropped, UnauthorizedAccess:IAMUser/MaliciousIPCaller），设置 EventBridge Rule → Lambda 自动隔离实例（stop-instances）+ 发邮件 + @负责人；
• 每月导出 Findings Report，发给 CTO——不是汇报问题，是证明你每天都在盯岗。
最后说句实在话：安全不是 checklist，是肌肉记忆。当你新建资源时，第一反应是“这个要不要加标签？要不要进备份计划？它的日志往哪送？谁有权删它？”，那你才算真正登上了 AWS 的船。
至于那些“等业务稳定后再补安全”的想法？请默念三遍：
没有稳定的业务，只有稳定的漏洞。
没有临时的安全，只有永恒的防线。
没有完美的架构，只有持续的校准。
