📚 课程目录第3章云数据库身份与访问管理

3. 云数据库身份与访问管理

云数据库的边界防护再严密，只要一个长期有效的数据库口令泄露，攻击者就能以合法身份完成拖库。身份与访问管理（IAM）要解决的核心问题不是“谁能连上网络”，而是“谁在什么条件下、对哪个数据库的哪类资源、能执行什么操作”。在云上，这套判断由 IAM 策略引擎在每次 API 调用或数据库连接时实时求值，而不是靠数据库内部的账号表静态维护。

一、IAM 体系的四个判断要素

一次访问请求能否通过，取决于四个要素的组合：主体（Principal）、操作（Action）、资源（Resource）、条件（Condition）。主体可以是云账号下的子用户、角色会话、联合身份用户；操作是具体的 API 或数据库权限，如 rds:DescribeDBInstances、SELECT；资源用 ARN 或实例 ID 精确指向；条件则约束来源 IP、是否启用 MFA、访问时间、VPC 端点等。策略求值遵循“显式拒绝优先、默认拒绝、允许需显式声明”的规则：只要有一条策略显式 Deny，无论其他策略如何 Allow，请求都会被拒绝。

二、最小权限原则的落地方法

最小权限不是一句口号，而是一条可执行的收敛路径。以“只读查询订单库”为例，初始策略往往写成 "Action": "rds:*", "Resource": "*"，这等于把整个数据库集群的管理权交出去。收敛分四步：

按操作收敛：把 rds:* 改为 rds:DescribeDBInstances、rds:Connect，数据库层只保留 SELECT，去掉 INSERT/UPDATE/DELETE/DROP。
按资源收敛：把 "Resource": "*" 改为具体 ARN，如 arn:aws:rds:cn-north-1:123456789012:db:order-db-prod，并限定到 orders 库的 order_summary 视图。
加条件约束：要求 aws:MultiFactorAuthPresent = true，来源 IP 限定在办公网段 10.20.0.0/16，且必须经 VPC 端点访问。
定期复核：用访问分析器（如 IAM Access Analyzer）找出 90 天内未使用的权限并回收，避免权限只增不减。

一个收敛后的策略片段如下，注意 Deny 用于兜底封堵高危操作：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOrderSummary",
      "Effect": "Allow",
      "Action": ["rds:Connect", "rds:DescribeDBInstances"],
      "Resource": "arn:aws:rds:cn-north-1:123456789012:db:order-db-prod",
      "Condition": {
        "Bool": {"aws:MultiFactorAuthPresent": "true"},
        "IpAddress": {"aws:SourceIp": "10.20.0.0/16"}
      }
    },
    {
      "Sid": "DenyDangerousOps",
      "Effect": "Deny",
      "Action": ["rds:DeleteDBInstance", "rds:ModifyDBInstance"],
      "Resource": "*"
    }
  ]
}

三、角色与策略设计

角色（Role）与用户（User）的关键区别在于：角色没有长期密钥，靠临时凭证被“扮演”。设计时应遵循三条经验：按职责划分角色，如 db-reader、db-writer、db-admin，而不是给每个人一套独立策略；用权限边界限制最大权限，即使角色策略写宽了，边界也会把上限压住；用标签做属性化授权，例如给资源打 env=prod 标签，策略中用 aws:ResourceTag/env 动态匹配，避免为每个实例单独写 ARN。

角色信任策略（Trust Policy）决定“谁能扮演这个角色”，权限策略决定“扮演后能做什么”，两者必须同时正确，缺一不可。

四、多因素认证（MFA）

MFA 在 IAM 中既是登录保护，也是策略条件。对数据库管理面，应强制控制台登录与高危 API 调用启用 MFA；对数据面，可结合数据库自身的 MFA 插件或代理层校验。策略中通过 aws:MultiFactorAuthPresent 与 aws:MultiFactorAuthAge 两个条件键实现：前者要求本次会话已通过 MFA，后者限制 MFA 验证后的有效时长（如 3600 秒），超时需重新验证。这样即使凭证被盗，攻击者没有第二因素也无法调用敏感操作。

五、临时凭证与联合身份

长期 AccessKey 是云上最大的泄露风险源。临时凭证通过 STS（Security Token Service）签发，包含 AccessKeyId、SecretAccessKey 和 SecurityToken 三部分，有效期可设为 15 分钟到 12 小时，到期自动失效。典型用法是 AssumeRole：应用先以自身身份调用 STS，换取目标角色的临时凭证，再访问数据库。联合身份则进一步免除云账号本地用户：企业员工用 OIDC（如企业 IdP）或 SAML 断言登录，STS 校验断言后签发临时凭证，权限由角色策略决定。这样人员离职时只需在 IdP 侧禁用账号，云上权限随之失效，无需逐个回收密钥。

临时凭证同样可能被窃取，务必配合最小权限、条件约束和短有效期使用；不要把临时凭证写入代码仓库或日志，并确保 SecurityToken 与凭证一起传递，否则签名会失败。

六、实践检查要点

检查项	合格标准	常见问题
长期密钥	无长期 AccessKey，全部走角色/联合身份	应用配置里硬编码 AK/SK
权限范围	Action 与 Resource 均精确到最小集	使用 `*` 通配
MFA	高危操作强制 MFA 且限制时效	仅登录启用，API 未校验
凭证有效期	临时凭证 ≤ 所需最短时长	统一设为 12 小时
权限复核	每季度回收未使用权限	权限只增不减

把上述要素串起来看：IAM 体系提供判断框架，最小权限决定授权粒度，角色与策略是承载授权的载体，MFA 与临时凭证/联合身份则分别从“验证强度”和“凭证生命周期”两个维度压缩攻击窗口。四者协同，才能让云数据库的每一次访问都可解释、可追溯、可收敛。