Amazon DVA-C02: 安全、IAM、KMS 与密钥管理 (Cognito, Secrets Manager, SSM) — 学习指南

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

属于 AWS Developer Associate DVA-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

IAM、角色、策略与跨账户访问

身份和访问管理的设计应遵循最小权限、短期凭证以及服务身份与人类身份明确分离的原则。对于在 EC2、ECS 或 Lambda 上运行的应用程序，应优先使用实例/任务/函数角色，而不是嵌入访问密钥；AWS SDK 会自动使用环境提供的凭证提供程序链并刷新临时凭证。跨账户访问应使用 AWS STS AssumeRole (API: sts:AssumeRole)，在目标账户中配置明确的角色信任策略，并在调用方账户中配置 IAM 策略以限制可代入的角色 ARN。当敏感操作需要 MFA 时，应通过在角色或资源策略中使用 aws:MultiFactorAuthPresent 条件来强制执行，或要求人类用户使用 sts:GetSessionToken。对于 Web 或移动客户端，通过 Cognito Identity 或联合身份提供商使用 AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity)，以避免使用长期凭证。注意常见陷阱：过于宽松的通配符操作/资源、依赖基于资源的策略但未匹配相应的主体条件、以及在跨账户访问 S3 或 KMS 时忘记包含 SourceAccount 或 aws:SourceVpc 条件。使用 IAM 策略模拟器和 sts:GetCallerIdentity 进行调试。考虑在组织层面使用服务控制策略 (SCP) 来实施护栏，并在适当情况下对 kms:CreateGrant 或 iam:CreateAccessKey 等高风险操作进行显式拒绝。

KMS、加密模式与密钥访问控制

使用 AWS KMS 进行信封加密：调用 GenerateDataKey/GenerateDataKeyWithoutPlaintext 生成用于客户端或服务器端加密的数据密钥，然后对小负载调用 Encrypt/Decrypt，或使用该数据密钥进行批量加密。选择合适的 CMK：为方便可选用 AWS 自有密钥，为服务集成可选用 AWS 托管密钥 (aws/*)，为完全控制和轮换可选用客户托管密钥。密钥策略是 KMS 的主要控制机制；附加允许 kms:Decrypt、kms:Encrypt 的 IAM 策略，并在需要为 CloudHSM 支持的操作或跨账户 Lambda 调用等服务提供临时的、委托的密钥使用权限时，使用授权 (grant)。包含一个 EncryptionContext 以将密文与使用上下文绑定，并通过 kms:EncryptionContextEquals 条件要求提供该上下文，以获得更高的保障。跨账户使用 KMS 需要在密钥策略中添加明确的条目，授予外部主体或角色权限，在某些情况下还需要授予 CreateGrant/RetireGrant 权限。为了审计和取证，应为 KMS 和 S3 启用 CloudTrail 数据事件，以捕获 GenerateDataKey 和 Decrypt 调用；CloudTrail 日志将包含 arn:aws:kms 以及关于哪个主体使用了密钥的详细信息。常见问题包括：忘记为在后台使用授权 (grant) 的服务授予 kms:CreateGrant 权限、未能轮换客户托管密钥、以及假设仅凭 IAM 策略就能授权 KMS 操作而无需正确的密钥策略条目。

密钥管理：Secrets Manager 与 Parameter Store 对比

Secrets Manager 和 Systems Manager Parameter Store 都提供加密的密钥存储，但在功能和成本模型上有所不同：Secrets Manager 支持自动轮换（使用 Lambda 轮换模板）、内置版本控制和集成复制，并按密钥收费；Parameter Store (SecureString) 对许多参数提供免费套餐，更适合简单的配置管理。访问权限由 IAM 策略控制，授予 secretsmanager:GetSecretValue 或 ssm:GetParameter（带 WithDecryption=true）权限，并且底层的 KMS 密钥必须允许该主体进行解密。对于跨账户密钥，可在 Secrets Manager 上使用基于资源的策略，或使用密钥复制功能。使用 SDK 时，调用 secretsmanager.getSecretValue({ SecretId }) 或 ssm.getParameter({ Name, WithDecryption: true })，并避免记录密钥值；在 CloudFormation 或 SAM 中设置 Lambda 环境变量以引用 Secrets Manager 或 Parameter Store 的值（支持动态解析），或在应用程序启动时通过 SDK 获取。常见的开发人员错误包括：在源代码控制中以明文形式存储密钥、在没有 KMS 保护的情况下依赖 Lambda 环境变量存储高度敏感的数据、以及配置过于宽松的 IAM 策略（例如将 secretsmanager:* 授予宽泛的角色）。对于轮换，确保轮换 Lambda 具有正确的 secretsmanager:RotateSecret 和 kms:GenerateDataKey 权限，并确保应用程序代码在凭证变更时能够无缝地重新初始化连接。

Cognito 身份验证、授权和 API 集成

Amazon Cognito 提供用于身份验证的用户池 (user pools) 和用于获取临时 AWS 凭证的身份池 (identity pools)。使用 Cognito User Pools 管理用户注册、多重身份验证 (MFA) 和 JWT（ID、访问、刷新令牌）的颁发。基于浏览器的单页应用必须使用没有客户端密钥 (client secret) 的应用客户端，并应使用托管 UI 或实现 SRP 流程的 Amazon Cognito SDK (amazon-cognito-identity-js)，以避免暴露密码。在服务器或 API Gateway 上验证 JWT 时，需要从用户池获取 JWKS URI，并验证签名、颁发者 (issuer)、受众 (audience/aud) 和令牌过期时间；API Gateway JWT 授权方 (authorizer) 或 Lambda 自定义授权方可以执行此验证。对于服务器到服务器的身份验证，通过 Cognito Identity Pool 使用 sts:AssumeRoleWithWebIdentity 将用户池令牌交换为临时凭证。常见陷阱包括：回调 (callback) 或登出 URL 配置错误、未验证令牌的范围 (scopes) 或用户组 (groups)，以及期望 ID 令牌能直接用于 AWS API 调用（必须通过身份池交换它们）。为了实现精细化授权，可以使用用户组或自定义声明 (custom claims)，并在将身份映射到 AWS 角色时，将 Cognito 与基于资源的策略和 IAM 条件键（如 aws:userid 或 cognito-identity.amazonaws.com:sub）结合使用。通过 CloudTrail 审计登录和管理员操作，并在 Cognito 中启用高级安全功能以检测泄露的凭证。

实践问题：用例场景

场景：游戏工作室 PixelForge 在单个 AWS 账户中运行一个无服务器后端，使用了 Lambda、API Gateway、S3、DynamoDB 和 Cognito 用户池。敏感的 API 密钥和数据库凭证为多个部署阶段存储，并且第三方审计团队必须在 1-24 小时内访问 S3 中生产环境图像的子集。

挑战：为外部审计员安全地提供对生产图像的短期、可审计的访问权限；确保应用程序密钥由 Lambda 安全地轮换和访问；并为管理员的跨账户访问强制执行 MFA。

推荐方法：

创建一个客户管理的 KMS 密钥，其密钥策略允许 PixelForge 账户解密，并为审计员 IAM 角色授予权限；启用密钥轮换，并在解密操作期间要求提供 EncryptionContext。
将凭证存储在 Secrets Manager 中（每个阶段使用独立的密钥），并为 Lambda 附加一个 IAM 角色，该角色拥有最小化的 secretsmanager:GetSecretValue 权限和针对该 KMS 密钥的 kms:Decrypt 权限；在 Lambda 启动代码中，使用 AWS SDK 调用 secretsmanager.getSecretValue({ SecretId })。
对于审计员访问，创建一个独立的审计员 AWS 账户角色，并在基于资源的 S3 存储桶策略中允许来自审计员账户的 sts:AssumeRole 操作，通过 aws:PrincipalArn 和一个有时间限制、预先配置的角色映射进行限制；通过 sts:AssumeRole 生成短期凭证，并在代入角色时使用 aws:MultiFactorAuthPresent 条件强制执行 MFA。
使用 CloudTrail 记录所有访问（S3 和 KMS 的管理事件和数据事件），并启用 S3 对象级日志记录和 Amazon Macie 或 S3 访问日志以进行额外的取证；要求临时审计员会话使用特定的 EncryptionContext，并为对象/请求打上标签以实现可追溯性。

基本原理：将 Secrets Manager 与 KMS 和短期 STS 凭证结合使用，可以强制执行最小权限原则，实现自动轮换，并避免硬编码密钥。带有 MFA 和 CloudTrail 数据事件、有时间限制的代入角色 (assume-role) 模式，为第三方提供了可审计、可撤销的访问权限，同时保持了职责分离。

← 部署与 CI · 所有领域 · 监控、日志记录与调试 (CloudWatch →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →