Amazon SCS-C02: 身份与访问管理 — 学习指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

身份、委托人与策略评估

IAM 区分身份（用户、组、角色）和委托人（发出请求的已验证实体）。用户是长期的，拥有静态凭证；角色自身没有凭证，需要被代入（assume）以生成短期的 STS 令牌。组是用于将策略附加到用户的容器——它们绝不是委托人，也不能被代入。

每个 API 调用都会经过一个确定性的评估链：任何位置的显式 Deny 都会胜出，然后组织层面的 SCP 必须允许，然后权限边界必须允许，然后会话策略（如果有）必须允许，最后，至少要有一个基于身份或基于资源的策略包含 Allow。缺少任何一个 Allow 层都会导致隐式拒绝。这就是为什么分层至关重要：如果 SCP 拒绝了 s3:DeleteBucket 或者权限边界完全排除了 S3，那么一个授予 s3:* 的身份策略将毫无意义。

基于资源的策略（S3 存储桶策略、KMS 密钥策略、SNS 主题策略、Lambda 函数策略）可以直接向委托人授予访问权限，而无需调用方拥有任何身份策略——但这仅限于在同一账户内。对于跨账户访问，源账户中的身份策略和目标账户中的资源策略都必须允许该操作。

角色、信任策略与 AssumeRole

一个角色有两个策略文档：信任策略（谁可以代入它）和一个或多个权限策略（代入后可以做什么）。信任策略是应用于角色本身的基于资源的策略，使用 sts:AssumeRole 操作。如果没有匹配的信任策略，即使调用方的身份策略中包含 sts:AssumeRole，AssumeRole 操作也会失败并返回 AccessDenied。

对于跨账户委派，信任策略会指定受信任的账户或该账户中特定的角色/用户 ARN，并且——对于第三方访问至关重要的一点是——强制执行 ExternalId：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

ExternalId 可以防范混淆代理人问题：如果没有它，一个需要代入多个客户账户角色的第三方 SaaS 提供商可能会被诱骗，从而错误地操作了另一个客户的角色。如果在条件中省略 sts:ExternalId，或在执行 sts:AssumeRole 时传递了错误的值，代入操作会返回 AccessDenied——这是在引入监控或 CSPM 等供应商工具时常见的配置错误。

对于 AWS 服务（Lambda、EC2、ECS 任务），信任策略会指定一个服务委托人，例如 "Service": "lambda.amazonaws.com"。一个需要访问 S3 的 Lambda 函数应该代入一个执行角色，该角色的权限策略授予对存储桶的 s3:GetObject 和 s3:PutObject 权限；同样地，S3 存储桶策略也可以将该函数的角色 ARN 指定为委托人。在单个账户内，这两种机制都可以独立生效。

权限边界

权限边界是一种附加到用户或角色上的高级控制，它设定了该身份无论被授予何种身份策略，所能拥有的最大权限上限。有效权限是身份策略和权限边界的交集。如果一个组策略授予了 ec2:*，但权限边界只允许 ec2:Describe*，那么用户将只能执行描述操作。

权限边界通常用于权限委派：允许开发人员为他们的应用程序创建 IAM 角色，但要求他们创建的每个角色都必须附带一个特定的边界。开发人员的 IAM 策略在 iam:CreateRole 和 iam:PutRolePolicy 操作上包含一个类似 "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" 的条件。这在启用自助服务的同时，可以防止权限提升。

一个常见的误解是，组成员身份或其他附加的策略可以“覆盖”权限边界或 SCP。实际上不能——边界和 SCP 是权限的上限，而不是下限。

通过条件强制执行 MFA

两个条件键用于驱动 MFA 策略：aws:MultiFactorAuthPresent（布尔值，如果会话是使用 MFA 获取的，则为 true）和 aws:MultiFactorAuthAge（数字，自 MFA 验证以来经过的秒数）。为敏感 API 强制执行 MFA 并限制会话生命周期的策略如下所示：

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

两小时是 7,200 秒。对于从不携带该键的服务委托人调用，使用 BoolIfExists 而不是 Bool 存在微妙的危险——它会评估为 true，从而对这些调用者有效地绕过了检查。因此，当意图是强制人类用户执行时，应首选 Bool。

由于使用长期访问密钥的 CLI 和 SDK 请求不携带 MFA 上下文，用户必须首先调用 sts:GetSessionToken（使用 --serial-number 和 --token-code）或 sts:AssumeRole（使用 --serial-number/--token-code）来获取包含 MFA 上下文的临时凭证。这些短期凭证随后便能满足 MultiFactorAuthPresent 条件：

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center 与联合身份验证

IAM Identity Center（前身为 AWS SSO）可集中管理整个 AWS Organization 中的员工访问。权限集是一些模板，当分配用户或组时，Identity Center 会在每个目标账户内将这些模板具象化为 IAM 角色。分配操作会绑定三样东西：一个委托人（来自 Identity Center 目录或像 Okta/Entra ID 这样的外部 IdP 的用户或组）、一个权限集以及一个或多个账户。

权限集可以包含 AWS 托管策略、客户托管策略（通过名称引用，因此它们必须存在于每个目标账户中）、内联策略以及权限边界。当您编辑权限集时，Identity Center 会重新配置底层的角色——您永远不会直接编辑那些角色。

对于 Identity Center 之外的 SAML 联合身份验证，AWS 会根据在 IAM SAML 提供商对象上注册的 IdP 元数据来验证断言的签名。当 IdP 轮换其签名证书时，必须上传更新后的元数据 XML；否则 STS 会返回 InvalidIdentityToken / Response Signature Invalid。使用

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

更新元数据是开销最小的修复方法——无需重新创建提供商或重新配置信任关系。

根账户、凭证报告和最小权限

根用户拥有不可移除的完全访问权限，必须被视为紧急访问身份：启用硬件或虚拟 MFA 设备，删除所有根访问密钥，不要将其用于日常工作，并将凭证离线存储。在组织根或 OU 级别使用 SCP，以防止成员账户中的管理员禁用 GuardDuty、删除 CloudTrail 或离开特定区域。SCP 从不授予权限——它们只过滤成员账户中 IAM 可以授予的权限。

最小权限是通过工具而不是直觉来实践的。生成 IAM 凭证报告（

undefined

然后

undefined

）以查找未使用的用户、老化的访问密钥和没有 MFA 的用户。使用 IAM Access Analyzer 来识别跨账户暴露数据的资源策略，并根据 CloudTrail 活动生成适当规模的策略。使用上次访问数据（

undefined

）来修剪角色中未使用的服务权限。

最后一个值得明确指出的陷阱是：假设添加一个身份的 Allow 就足够了。如果 KMS 密钥策略没有指定您的角色，SCP 拒绝了该操作，或者权限边界忽略了它，调用仍然会失败。在排查 AccessDenied 问题时，务必审计整个堆栈——SCP、边界、身份策略、资源策略和会话策略。

实践问题：用例场景

场景： Meridian Financial 运营着一个包含管理、生产和开发工作负载的三账户 AWS Organization，敏感的交易和客户数据位于生产账户中。他们目前混合使用了遗留的长期 IAM 用户、承包商账户和一个 Okta SAML 身份提供商，导致访问控制不一致，角色配置分散在各个账户中。

挑战： 最近发生的一起事件涉及一名承包商被盗用的凭证，该凭证在没有 MFA 的情况下代入了跨账户角色，并执行了过多的操作，因为没有设置权限边界或集中的权限集。Meridian 需要加强联合身份验证、角色信任，并在所有账户中强制执行 MFA 和最小权限。

推荐方法：

部署与 Okta SAML 集成的 AWS IAM Identity Center 作为单一的联合身份平面，并将所有人类用户和承包商从长期 IAM 用户迁移到基于 Identity Center 的账户，禁用遗留 IAM 用户的控制台/密钥访问。
在 IAM Identity Center 中创建集中的权限集，这些权限集映射到成员账户中的 IAM 角色，并为所有角色实施 IAM 权限边界（定义为 IAM 策略）；使用 AWS CloudFormation StackSets 在各账户中部署这些边界和角色模板。
更新跨账户角色信任策略，使其仅允许来自 Identity Center 委托人 ARN 的 sts:AssumeRole，并包含要求 MFA（例如，aws:MultiFactorAuthPresent）和源账户限制的条件；要求会话标签携带身份属性。
在 IdP (Okta) 层面强制执行 MFA，并通过在角色会话上要求 MFA 条件来在 AWS 中反映此强制措施；通过在 AWS Organizations 中应用服务控制策略 (SCP) 来拒绝创建控制台访问或新的 IAM 用户。
启用 AWS CloudTrail、AWS Config 和 IAM Access Analyzer 以进行持续监控和策略验证，并将发现结果发送到 CloudWatch/GuardDuty 以用于告警和自动化修复工作流。

基本原理： 通过 IAM Identity Center 集中联合身份验证，使用权限集和边界强制执行最小权限，在信任策略中要求 MFA，并应用组织级别的 SCP 外加监控，这与 AWS 最佳实践一致，可以减小爆炸半径、防止权限提升并提供可审计性。

IAM 角色与信任策略：PassRole 和 AssumeRole

一个 IAM 角色有两个截然不同的策略层面，混淆这两者是大多数跨账户授权失败的根本原因。信任策略（AssumeRolePolicyDocument）回答的是谁可以代入该角色以及在什么条件下可以代入。权限策略回答的是该角色在被代入后可以做什么。两者都必须允许相应的操作；仅有信任策略永远无法授予对 S3、KMS 或任何其他服务的访问权限。

当一个主体调用 sts:AssumeRole 时，STS 会根据调用方身份加上会话上下文（源 IP、MFA 状态、会话标签、外部 ID）来评估目标角色的信任策略。同时，调用方主体本身也必须有一个基于身份的策略，Allow 对该角色 ARN 执行 sts:AssumeRole 操作。正是这种双重需求使得跨账户边界的角色代入变得安全。

一个典型的、要求 MFA 和外部 ID 的跨账户信任策略如下所示：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

aws:MultiFactorAuthPresent 键只在可代入角色的信任策略中有意义，因为 MFA 上下文是在 STS 调用时建立的，而不是在下游的服务调用中。将 MFA 条件添加到 S3 存储桶策略或角色的权限策略中是一个常见的错误：即使最初的人类用户使用 MFA 进行了身份验证，代入角色后的会话通常也不携带 aws:MultiFactorAuthPresent=true，因此这些条件会静默地拒绝所有操作。应在代入角色时强制执行 MFA；对于长时会话，可使用 aws:MultiFactorAuthAge 来强制重新进行身份验证。

PassRole 是考题场景中第二个容易出错的环节。当你告诉像 CloudFormation、EC2、Lambda 或 CodeBuild 这样的服务要以某个角色的身份运行时，调用方身份必须拥有对该角色的 iam:PassRole 权限。

实践问题：用例场景

场景： Meridian Financial 公司运行着一个多账户的 AWS Organization，为生产、开发和 CI/CD 工具分别设立了独立的账户；他们使用集中的 IAM 角色进行跨账户部署，并让第三方 CI 代理代入角色来执行基础设施变更。身份边界由角色信任策略强制执行，一些团队使用长期的实例配置文件和 Lambda 函数，这些函数被授予 iam:PassRole 权限，以便将角色附加到实例或任务上。

挑战： 最近的一次审计发现，一个过于宽泛的 iam:PassRole 权限允许一个 CI/CD 主体将一个管理员角色传递给了 EC2 实例配置文件，并且攻击者利用了一个 AssumeRole 信任关系，从而获得了跨账户的过高权限。

推荐方法：

使用 AWS CloudTrail 和 Amazon EventBridge 来识别最近的 iam:PassRole 和 sts:AssumeRole API 调用，并在 CloudTrail Lake 或 Athena 中运行查询，列出哪些主体在何时传递了哪些角色 ARN。
跨账户运行 IAM Access Analyzer (for IAM)，以发现基于资源的信任策略暴露问题，并列出可从 Organization 外部或由外部主体代入的角色。
将宽泛的 iam:PassRole 策略替换为最小权限的 IAM 策略，在 Resource 中明确指定角色 ARN，并添加如 aws:PassedToService 或 aws:PrincipalOrgID 等条件键，以限制谁以及什么服务可以接收该角色。
强化角色信任策略，要求设置条件——使用 aws:PrincipalOrgID、为第三方使用 sts:ExternalId、要求 aws:SourceIdentity 并强制执行最大会话时长——以防止未知主体进行宽泛的 AssumeRole。
配置 Amazon EventBridge 规则来检测 iam:PassRole 和 AssumeRole 的异常行为，将警报发送到 Amazon SNS，并创建自动化的 Lambda 执行手册来撤销或修复过于宽泛的策略，同时将发现结果记录在 AWS Security Hub 和 AWS Config 中，以实现持续合规。