Amazon SCS-C02: 治理、配置与自动化 — 学习指南
属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.
服务控制策略与组织级护栏
服务控制策略（Service Control Policies）构成了 AWS Organization 中任何主体（principal）所能做的最外层边界。SCP 不是 IAM 策略——它不授予任何权限，只定义了 OU 下或整个组织内账户可用的最大权限。如果 SCP 拒绝了某个操作，那么 IAM 策略、资源策略或权限边界中的 Allow 将完全无效。正是这种不对称性，使得 SCP 成为实施组织级别护栏的正确工具，例如：区域限制、禁用服务、保护集中管理的 IAM 角色以及在资源创建时强制加密。
一个典型的、拒绝创建未加密 DynamoDB 表和 S3 存储桶的 SCP 如下所示：
Version: "2012-10-17"
Statement:
- Sid: DenyUnencryptedS3
Effect: Deny
Action: s3:CreateBucket
Resource: "*"
Condition:
StringNotEquals:
s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
- Sid: DenyUnencryptedDdb
Effect: Deny
Action: dynamodb:CreateTable
Resource: "*"
Condition:
"Null":
dynamodb:SSESpecificationEnabled: "true"
一个常见的陷阱是试图通过附加在每个账户中的 IAM 策略来强制执行“组织内任何人都不能使用 us-east-2”或“任何人都不能禁用 CloudTrail”。即使有权限边界和身份策略的配合，本地管理员也可以为自己创建一个绕过方法。只有应用在根（root）或 OU 上的 SCP 才是可靠的，因为它甚至可以约束成员账户的根用户（除少数不可限制的操作外）。
SCP 也应该用于保护紧急访问（break-glass）和委托管理角色：对任何针对 OrganizationAccountAccessRole 或 SecurityAudit 等角色的操作添加明确的 Deny，除非调用者的 aws:PrincipalArn 匹配一个已批准的列表。
AWS Config、合规包与多账户强制执行
AWS Config 提供了持续评估层，它通过检测（观察和报告偏差）功能，与 SCP（预防）相辅相成。合规包（conformance pack）是一组 Config 规则的集合——包括像 s3-bucket-server-side-encryption-enabled 这样的托管规则，以及由 Lambda 或 Guard 支持的自定义规则——它被打包成一个单一的可部署 YAML 文件，并带有可选的修复操作。
要在整个组织范围内推广一个标准基线，需要结合使用两种机制：
从管理账户部署 CloudFormation StackSets，使用服务托管权限并启用
AutoDeployment: Enabled，这样任何加入组织的新账户都会自动接收一个堆栈，该堆栈会开启 Config 记录器和交付渠道。这解决了引导问题：合规包无法评估未启用 Config 的账户。从委托管理员账户（例如
security-01）部署合规包，使用PutOrganizationConformancePack。这将一套一致的规则集传播到每个当前和未来的账户，无需手动接触每个账户。
委托管理员 + 聚合器模式非常重要：它让安全团队能在一个地方查看所有账户的合规性，同时仍然允许应用团队在本地添加自己的规则。直接从管理账户部署相同的规则虽然可行，但违反了最小权限原则，并会阻碍职责分离的审计。
CloudFormation Guard、StackSets 与 Service Catalog
预防应左移。CloudFormation Guard (cfn-guard) 是一个策略即代码（policy-as-code）引擎，它在部署前解析 CloudFormation 模板（或任何 JSON/YAML），并根据声明性规则对其进行评估。一条 Guard 规则如下所示：
rule s3_encrypted {
Resources.*[ Type == "AWS::S3::Bucket" ] {
Properties.BucketEncryption exists
Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
}
}
}
将其集成到 CI/CD 阶段——通常是作为一个运行 cfn-guard validate -r rules.guard -d template.yaml 的 Docker 容器步骤——可以在任何不合规资源被创建之前使流水线失败。一旦发生违规，流水线会发布到一个 SNS 主题，安全团队订阅该主题，从而在不成为手动审批瓶颈的情况下获得可见性。仅仅依靠 StackSets 或 CloudFormation 变更集审查来通知安全团队是一个陷阱：这两个服务都不会发出针对单个资源的合规性结果，而且当堆栈创建完成时，资源已经存在于账户中了。
Service Catalog 在“最后一公里”对 Guard 进行了补充。平台团队不让开发人员编写任意的 CloudFormation，而是将经过审查的产品（VPC 基线、RDS 模式、EKS 集群）作为 Service Catalog 产品组合发布，并通过 AWS RAM 在账户间共享。开发人员使用受限的参数来启动它们，并通过一个启动约束 IAM 角色来预置资源，该角色拥有开发人员个人所不具备的更高权限。这提供了一个可审计的、自助服务的部署模型，其底层模板已经通过了 Guard 的检查。
StackSets 本身需要正确的配置：从组织管理账户部署时，使用 SERVICE_MANAGED 权限模型；在 Organizations 中为 CloudFormation 启用信任访问；并仔细配置执行角色。AdministrationRoleARN/ExecutionRoleName 对（在自托管模式下）或服务相关角色（在服务管理模式下）必须允许将 iam:PassRole 权限授予实际创建资源的 CloudFormation 服务角色。如果忘记附加 CloudFormation 服务角色，而是依赖于部署用户的凭证，会导致间歇性的 iam:PassRole AccessDenied 错误——这是 StackSet 操作失败的一个常见原因。正确的模式是为每个堆栈配备一个专用的服务角色，该角色仅拥有创建已声明资源类型所需的权限。
自动化修复管道
当 Config 检测到不合规时，对于任何可以安全地自我修复的问题，都必须自动进行修复。事件流如下：
Config 向默认事件总线发布一个
Compliance Change事件。一条 EventBridge 规则 筛选特定规则的
NON_COMPLIANT检测结果，并将其定向到 Systems Manager Automation 文档（用于简单的幂等修复，如启用 S3 加密）、Lambda 函数（用于 API 级别的修复）或 Step Functions 状态机（用于需要审批、重试或跨服务编排的多步骤工作流）。
例如，如果 s3-bucket-public-read-prohibited 规则被触发，一个名为 AWS-DisableS3BucketPublicReadWrite 的 SSM Automation 运行手册会对其进行修复。对于更复杂的流程——比如，一个 KMS 密钥策略发生偏差，必须在通知所属团队的同时进行校准——Step Functions 会协调以下操作：读取当前策略，与黄金版本进行比较，调用 kms:PutKeyPolicy，然后发布到 SNS。将修复逻辑存储在 Step Functions 中而不是单个 Lambda 函数中，可以为每个步骤提供可观察性，并实现清晰的重试语义。
IAM Access Analyzer 与策略验证
IAM Access Analyzer 回答两个截然不同的问题。首先，外部访问分析器可以识别其策略向已定义信任区域（账户或组织）之外的委托人授予访问权限的资源（S3、KMS、IAM 角色、Lambda、SQS、Secrets Manager）。请从委托管理员账户在组织级别启用分析器，以便集中聚合检测结果。
其次，Access Analyzer 的策略验证和策略生成功能在编写策略时运行。aws accessanalyzer validate-policy 会返回安全警告、错误和建议（例如，标记出过于宽泛的 Resource: "*" 与敏感操作的组合）。应将其集成到与 cfn-guard 相同的 CI/CD 阶段，以便在部署前检查嵌入在 CloudFormation 中的 IAM 策略。Access Analyzer 还可以根据 CloudTrail 历史记录生成最小权限策略，用角色实际使用过的确切操作替换通配符策略——这是对“强制实施数据访问的最小权限”这一要求的机械化解答，同时配合使用范围受限的 KMS 密钥策略，该策略通过 kms:ViaService 条件，仅在调用服务是 S3、DynamoDB、Lambda 或 EKS 时才允许 kms:Decrypt 操作。
实践问题：用例场景
场景： Meridian Financial 运行一个多账户的 AWS Organization，其中包括生产、预发布、沙箱和一个集中式安全账户。他们在沙箱中使用 CloudFormation 模板和开发者驱动的模板混合部署工作负载；所有权在团队间是联合的，并且他们必须满足数据加密和最小权限访问的内部治理要求。
挑战： 沙箱中的开发人员意外创建了公共 S3 存储桶和权限过大的 IAM 策略，这些问题传播到了其他账户，并且安全团队在整个 Organization 中缺乏一致的、自动化的强制执行和模板验证机制。
推荐方法：
- 创建组织级别的服务控制策略 (SCP)，在 Organization 根级别拒绝 S3 公共访问、强制实施存储桶加密并限制特权 IAM 操作，以提供预防性护栏。
- 从集中式安全账户出发，使用 CloudFormation StackSets 将 AWS Config 聚合器和合规包部署到每个账户和区域，以持续评估 S3 公共访问、IAM 策略附加模式和加密合规性。
- 将 CloudFormation Guard (cfn-guard) 规则集成到 CI/CD 管道（CodePipeline/CodeBuild）中，并要求对已批准的基础设施使用 Service Catalog 产品，从而确保模板得到验证，只有合规的堆栈才能被预置。
- 对高优先级检测结果（自动阻止 S3 公共访问、修复过于宽泛的 IAM 策略）启用 AWS Config 自动化修复，使用 SSM Automation 文档或 Lambda 运行手册，并通过 EventBridge 触发额外的工作流。
- 集中运行 IAM Access Analyzer 和策略验证，将检测结果摄取到 Security Hub，并针对发现的跨账户或权限过大的策略，自动化创建工单或执行修复手册。
基本原理： 该方法结合了预防性的组织范围护栏 (SCP)、持续检测 (Config/合规包)、模板验证左移 (cfn-guard/Service Catalog) 以及利用 IAM Access Analyzer 进行自动化修复，从而强制实施最小权限，并遵循 AWS 最佳实践实现一致的多账户治理。
AWS Config：组织规则、聚合器和委托管理
AWS Config 是 AWS 上检测性合规的基础。它持续记录资源配置，并根据规则对其进行评估——这些规则可以是 AWS 托管的（例如 restricted-ssh、vpc-flow-logs-enabled、encrypted-volumes），也可以是自定义的（由 Lambda 或 Guard 提供支持）。在企业规模下，有三个架构决策比规则本身更重要：规则如何部署、结果如何聚合以及由谁负责工具。
对于 AWS Organizations 下的多账户、多区域部署，正确的模式是通过 aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com 指定一个委托管理员账户（通常是安全或审计账户，而不是管理账户）。然后从该账户使用 PutOrganizationConfigRule 或 PutOrganizationConformancePack 将规则分发到每个成员账户和区域。如果不使用委托管理，就必须在每个账户中手动启用 Config，或者从管理账户运行所有操作——后者违反了职责分离原则，而前者在账户数量超过少数几个后就无法扩展。
组织规则推送单个规则定义；聚合器则收集由此产生的评估结果。在委托管理员账户中创建一个聚合器，其 OrganizationAggregationSource 覆盖所有账户和区域。聚合器控制面板随后可以回答诸如“200 个账户中有哪些 VPC 缺少 Flow Logs？”之类的问题，而无需进行繁琐的跨账户角色切换。请注意，聚合器是只读的：它们只呈现合规状态，本身不执行修复操作。
使用合规包实施基线
合规包将 Config 规则及其修复操作捆绑到一个 YAML 模板中。AWS 提供了映射到 PCI DSS、HIPAA、NIST 800-53 和 CIS 等框架的合规包。从委托管理员账户部署组织合规包可以针对特定的 OU——例如，对 Prod OU 应用比 Sandbox 更严格的合规包。这是在数百个账户中强制执行一致基线的最有效方法，因为只需一个 API 调用即可将规则集及其修复配置一次性传播到所有地方。
Resources:
EncryptedVolumesRule:
Type: AWS::Config::ConfigRule
Properties:
ConfigRuleName: encrypted-volumes
Source:
Owner: AWS
SourceIdentifier: ENCRYPTED_VOLUMES
EncryptedVolumesRemediation:
Type: AWS::Config::RemediationConfiguration
Properties:
ConfigRuleName: encrypted-volumes
TargetType: SSM_DOCUMENT
TargetId: AWSConfigRemediation-EncryptS3BucketVolume
Automatic: true
MaximumAutomaticAttempts: 3
RetryAttemptSeconds: 60
自动修复模式
有两种典型的修复路径，选择哪一种取决于对延迟和复杂性的要求。
Config 原生修复路径使用 AWS::Config::RemediationConfiguration，在规则报告 NON_COMPLIANT 时调用一个 SSM Automation 运行手册。AWS 提供了预构建的运行手册，例如 AWS-EnableVPCFlowLogs、AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules 和 AWSConfigRemediation-EncryptSNSTopic。这种路径是声明式的，能与合规包干净地集成，并且在可以接受几分钟延迟的情况下是理想选择。
当延迟至关重要或需要自定义编排时，则需要采用EventBridge 驱动的路径。Config 在每次状态转换时都会发出一个 Config Rules Compliance Change 事件。一条 EventBridge 规则根据 detail.newEvaluationResult.complianceType = NON_COMPLIANT 进行筛选，并以 Lambda 函数（或 Step Function，或直接以 SSM 运行手册）为目标。由于 EventBridge 在评估后几秒钟内就会触发，因此亚分钟级的修复窗口成为可能。
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"configRuleName": ["restricted-ssh"],
"newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
}
}
然后，Lambda 处理程序对违规的安全组调用 RevokeSecurityGroupIngress。无论选择哪种路径，自动化操作都必须代入一个拥有修改目标资源所需最低权限的 IAM 角色。一个常见的失败模式是，Config 规则的合规状态在 NON_COMPLIANT 和 COMPLIANT 之间无限翻转，因为修复运行手册因 AccessDenied 错误而失败——Config 会记录调用，但会静默地继续执行。务必检查 SSM Automation 的执行历史，并授予运行手册角色所需的特定修改权限（例如，ec2:CreateFlowLogs、用于流日志交付角色的 iam:PassRole 以及 logs:CreateLogGroup）。
Systems Manager Automation 和 Patch Manager
SSM Automation 运行手册是执行命令式修复的主力工具。它们是版本化的 YAML/JSON 文档，描述了由您指定的 IAM 角色执行的步骤——API 调用、审批、分支等。除了由 Config 触发的修复外，它们还可以运行定期的清理任务：例如轮换访问密钥、为未附加的 EBS 卷添加标签，或终止已停止超过 30 天的实例。
Patch Manager 是 SSM 的一个子系统，它使操作系统与补丁基线（一组已批准的补丁、分类和严重性筛选器）保持合规。实例通过 Patch Group 标签被分组到补丁组中；一个维护时段会针对这些实例调度 AWS-RunPatchBaseline 文档的运行。合规状态会回传到 Config 和 Security Hub，从而形成从操作系统级状态到组织级报告的闭环。
Service Catalog、CloudFormation StackSets 和预防性护栏
检测和修复是被动反应。要防止不合规，应使用预防性控制：
Service Catalog 将经审核、参数化的 CloudFormation 模板作为产品发布。开发人员可以启动获批的模式（例如，一个加固的 VPC、一个加密的 RDS 集群），而无需拥有底层服务的 IAM 权限，这强制实现了平台团队和使用者之间的职责分离。
CloudFormation StackSets 跨账户和区域部署相同的堆栈。通过服务托管权限和 OU 目标设定，单次操作即可将 Config 记录器、IAM 角色或 GuardDuty 检测器部署到组织中的每个账户，包括通过自动部署功能添加到新创建的账户中。
Service Control Policies (SCPs) 是唯一能在组织边界直接拒绝 API 调用的机制。Config 和 SSM 无法阻止一个缺少加密的
RunInstances调用——它们只能在事后进行检测和修复。仅仅使用 Config 规则来尝试强制执行硬性禁令（“永远不允许出现公共 S3 存储桶”）会在资源创建和修复之间留下一个时间窗口。将 Config 检测性规则与诸如s3:PutBucketPublicAccessBlock拒绝策略之类的 SCP 结合使用，可以弥补这一差距。
灾难恢复：备份、模板和源代码控制
要满足 RPO/RTO 目标，需要确保数据和基础设施定义都是可恢复的。AWS Backup 集中管理跨 EBS、RDS、DynamoDB、EFS 和 FSx 的备份策略；组织备份策略在成员账户中强制执行计划，而跨区域、跨账户的副本可以防范区域丢失和账户泄露。RPO 由备份频率设定；RTO 取决于恢复机制（DynamoDB PITR 恢复只需几分钟；跨区域的 RDS 快照恢复可能需要一个小时）。
基础设施恢复依赖于存储在 CodeCommit（或其他 Git 提供商）中作为单一事实来源的 CloudFormation 模板。从版本控制的模板中重新部署 StackSet，可以在几分钟内在恢复区域重建 VPC、IAM 和应用程序堆栈。如果模板只保存在控制台中——没有代码仓库——会使 RTO 变得不可预测，因为没有可复现的工件。
陷阱分析
三个常见的误解总是导致选错答案。第一，将 Config 视为一种预防性控制：它是在 CloudTrail 记录变更之后才进行评估的，因此真正的禁令需要 SCPs。第二，在没有配置足够权限范围的 IAM 角色的情况下设置修复措施——SSM 文档存在，Config 规则也触发了，但运行手册因权限错误而静默失败。第三，从管理账户运行组织范围的服务，而不是注册一个委托管理员，这迫使每个账户都需手动启用，并阻碍了组织范围的聚合器正常工作。
实践问题：用例场景
场景： Meridian Financial 在 AWS Organizations 下运行一个多账户的 AWS 环境，拥有独立的生产、开发和安全账户。安全团队必须向内部控制部门和监管机构证明其持续符合合规要求，同时管理跨多个区域的数百个 EC2 实例、S3 存储桶和 Lambda 函数。
挑战： 最近的一次审计发现存在未打补丁的 EC2 实例、公共的 S3 存储桶，以及跨账户基线执行不一致的问题；修复过程手动且缓慢，预防性控制也未能统一应用。
推荐方法：
- 将安全账户指定为 AWS Config 委托管理员，并通过 CloudFormation StackSets 部署一个 AWS Config 聚合器，以收集来自所有账户和区域的配置与合规数据。
- 从安全账户（使用 StackSets）部署组织级别的 AWS Config 合规包，以将基线控制（S3 公共访问、加密、标签）代码化，从而确保相同的规则得到一致应用。
- 将 AWS Config 自动修复操作附加到高风险规则上，这些规则会调用已注册为修复运行手册的 AWS Systems Manager Automation 文档，这样违规行为就会自动触发 SSM Automation 或 Run Command 进行修复。
- 使用 AWS Systems Manager Patch Manager 及其 SSM 补丁基线和 State Manager 来定义补丁组并自动化跨账户的操作系统补丁工作；将补丁合规性结果反馈给 Config 聚合器。
- 将批准的 CloudFormation 模板发布到 AWS Service Catalog，并使用 CloudFormation StackSets 部署或更新合规的堆栈；通过 AWS Organizations Service Control Policies 强制执行预防性护栏，以阻止不允许的资源创建（例如，禁用公共 S3 存储桶的创建）。
- 配置 Amazon EventBridge (CloudWatch Events) 和 SNS，以便在出现不合规情况时通知安全团队，并为复杂事件触发额外的 SSM Automation 工作流。
理由： 通过 Config 聚合器和合规包集中进行检测，通过 SSM 自动化修复，并通过 Service Catalog/StackSets 和 SCPs 强制执行预防性护栏，这种方法提供了与 AWS 安全、合规和最小权限最佳实践相符的一致、可审计的控制和快速修复能力。
← 边缘与应用安全 · 所有领域 · 漏洞、补丁与主机安全 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →