4. AWS账户安全基线

一个新建的AWS账户，默认状态下几乎没有任何安全防护：根用户用邮箱和密码就能登录，IAM用户密码可以设成“123456”，API调用不留任何审计痕迹。账户安全基线要解决的，就是在业务上线之前，先把这些“默认不安全”的缺口一次性堵住。本节围绕五个相互配合的控制点展开：根用户保护、MFA强制、密码策略、CloudTrail日志和账户别名配置。

根用户：能不用就不用，用就必须加锁

根用户是账户创建时生成的唯一身份，拥有不可限制的完全权限，任何IAM策略都无法对它生效。因此根用户保护的核心思路不是“限制权限”，而是“减少使用 + 强化认证”。

具体做法有三条。第一，为根用户绑定一个专用邮箱（如 aws-root@company.com），而不是某个员工的个人邮箱，避免人员离职导致账户失控。第二，立即启用MFA，且优先选择硬件安全密钥（FIDO2/WebAuthn）或虚拟MFA设备，不要使用短信验证码——短信存在SIM卡劫持风险。第三，删除根用户的访问密钥。根用户访问密钥一旦泄露，攻击者可直接关闭CloudTrail、删除所有资源，且无法通过IAM策略阻止。

此外，AWS提供了“根用户凭证报告”，可在IAM控制台下载CSV，列出账户内所有用户的密码启用状态、MFA状态、访问密钥数量与最近使用时间。建议每月导出一次，作为账户安全巡检的输入。

MFA强制：从“建议开启”变成“不开不能干活”

仅靠密码的账户，在凭证泄露面前毫无抵抗力。MFA强制要做的，是让所有能登录控制台或调用敏感API的身份，都必须通过第二因素验证。AWS中可通过IAM策略实现“无MFA则拒绝”，典型策略片段如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptMFA",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

该策略附加到用户组后，未完成MFA验证的会话将无法执行任何操作，只能先到IAM控制台绑定MFA设备。对于使用AWS CLI或SDK的编程访问，MFA强制需要配合 aws sts get-session-token --serial-number 获取临时凭证，长期访问密钥本身无法携带MFA状态，因此更推荐用IAM Identity Center或角色切换来替代长期密钥。

密码策略：把弱密码挡在创建之前

IAM账户密码策略是账户级设置，作用于所有IAM用户（不影响根用户和联合身份用户）。一条可落地的基线参数如下：

设置路径为 IAM → Account settings → Password policy。需要注意的是，密码策略只约束IAM用户，若企业已使用IAM Identity Center对接外部IdP（如Okta、Azure AD），密码复杂度应由IdP侧统一管理，AWS侧不再重复设置。

CloudTrail：让每一次API调用都留下痕迹

CloudTrail记录账户内几乎所有API调用的“谁、何时、从哪、做了什么”。账户基线要求至少创建一个覆盖所有区域的多区域跟踪（multi-region trail），并将日志投递到专用的S3桶。

关键配置项包括：

• 多区域跟踪：勾选“Apply trail to all regions”，避免攻击者在未启用跟踪的区域操作而不留日志。
• 日志文件验证：启用后CloudTrail会对每个日志文件生成数字签名，可检测日志是否被篡改或删除。
• S3桶保护：日志桶应开启版本控制、阻止公共访问，并使用桶策略拒绝来自CloudTrail服务之外的所有写入和删除操作。
• CloudWatch Logs集成：将日志同时投递到CloudWatch Logs，便于对根用户登录、IAM策略变更、安全组开放0.0.0.0/0等事件设置告警。

一个常见的告警规则是：当CloudTrail中出现 userIdentity.type = Root 且 eventName = ConsoleLogin 时，立即触发SNS通知。根用户登录本身不是错误，但每一次都值得被知晓。

账户别名：让登录入口可识别、可管理

默认情况下，IAM用户的登录地址是一串难以记忆的账户ID，形如 https://123456789012.signin.aws.amazon.com/console。账户别名把它替换为可读名称，例如 https://mycompany-prod.signin.aws.amazon.com/console。

账户别名不只是“好看”。它带来三个实际好处：一是员工能准确识别自己该登录哪个账户，减少钓鱼站点诱导；二是运维文档和脚本中可以用别名代替账户ID，降低硬编码泄露风险；三是多账户环境下，别名与账户用途一一对应，便于审计时快速定位。设置路径为 IAM → Account settings → Account alias，别名在全局唯一，建议采用“公司名-环境”格式，如 acme-prod、acme-dev。

把五项配置串成一次可执行的基线检查

上述五项配置并非孤立存在，它们共同构成账户的“最小安全面”。下面给出一份可直接对照执行的基线检查清单，建议在新账户创建后24小时内完成，并纳入季度巡检。