Amazon DOP-C02: 安全、合规性和治理 — 学习指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

概览

AWS 上的安全性、合规性和治理依赖于确定性的控制措施，这些措施可以跨账户和区域扩展，而不会减慢交付速度。一个稳健的设计需要分层部署身份控制（IAM、权限边界和服务控制策略）、多账户治理（AWS Organizations 和 Control Tower）、持续评估和修复（AWS Config）、威胁检测（Security Hub、GuardDuty、Inspector）、密钥保健、使用 AWS KMS 的加密以及网络隔离（VPC 安全组、NACL、终端节点和 PrivateLink）。其目标是最小化爆炸半径，持续证明合规性，并自动化预防和修复措施，同时保留最小权限和开发者的自主性。

身份、策略和多账户治理

IAM 角色、策略、权限边界和 SCP 协同工作，共同构成有效权限集。IAM 角色的基于身份的策略定义了允许的操作；角色的信任策略定义了谁可以代入它。无论基于身份的策略如何规定，权限边界都会限制主体所能执行的操作。AWS Organizations 中的 SCP 为成员账户中的任何主体（包括根用户）设置了绝对的权限上限。基于资源的策略（用于 S3、KMS、Secrets Manager 等）可能允许跨账户访问，但它们同样不能超越 SCP 或权限边界施加的限制。有效权限是以下各项的交集：基于身份的策略 ∩ 权限边界 ∩ 会话策略（如果存在）∩ 基于资源的策略（如果适用）∩ SCP，其中任何显式的 Deny 语句都具有最高优先权。

使用权限边界在单个账户中实现安全的自助服务。例如，一个开发者交付管道只有在附加了特定边界的情况下才能创建角色，该边界拒绝除特定模式外的

undefined

权限，拒绝在敏感密钥上执行

undefined

，并限制 EC2 实例类型。权限边界只能由已拥有

undefined

权限的主体附加；请严格保护这一权限。

SCP 是组织范围的护栏。常见的护栏包括禁止禁用 AWS Config 或 CloudTrail、阻止来自组织外部的邀请、拒绝更改 IAM Identity Center 的委托管理员以及限制区域。优先使用带有条件的“例外允许”模式（例如，允许由中央管理员角色进行更改）以减少摩擦。务必允许创建和使用所需的服务相关角色（例如，用于 GuardDuty、Inspector、Config 的角色），否则您的 SCP 会无意中阻止服务的设置。

AWS Organizations 提供分层的 OU（组织单元）来分离环境（例如，沙盒、开发、生产）、工作负载类型和例外通道。从父 OU 继承 SCP 以避免策略漂移。使用账户自动发放来标准化账户设置：可以通过 AWS Control Tower 的 Account Factory（控制台）或用于 Terraform 的 Account Factory (AFT) 来集成到 CI/CD 中。AFT 增加了 GitOps 风格的工作流、漂移检测和功能标志（例如，配置企业级支持），并能以一致的基线护栏扩展到数百个账户。

AWS Control Tower 使用规范性护栏自动化部署一个登陆区。预防性护栏是 Control Tower 管理的 SCP；检测性护栏是它部署的 AWS Config 规则。Control Tower 集成了 IAM Identity Center 以实现 SSO 和权限集。使用基于 ABAC 的权限集，通过

undefined

或身份属性进行访问控制，以限定操作范围。通过 Customizations for AWS Control Tower (CfCT) 扩展基线，为每个 OU/账户自动部署 CloudFormation、SCP 和 Config 包。保留例外 OU，用于托管需要定制策略但又不能削弱全局护栏的工作负载。

持续合规和自动化修复

从一个委托管理员账户在整个组织范围内启用 AWS Config。在所有区域为所有资源开启记录，并使用组织聚合器在整个组织中聚合配置。对通用控制使用托管规则（例如，

undefined

、

undefined

、

undefined

），并为定制逻辑编写自定义的由 Lambda 支持的规则（例如，根据 90 天策略验证 KMS 轮换周期，或强制执行默认标签和值）。合规包将规则、参数和修复措施分组到按版本管理的、可部署的捆绑包中，供每个 OU 使用；在版本控制系统中维护它们，并通过 StackSets 或 CfCT 进行推广，以确保一致性和可审计性。

自动化修复形成闭环。将每个规则的不合规评估映射到一个强制执行基线的 SSM Automation 运行手册：附加一个默认实例配置文件、应用一个带默认值的标签、切换 S3 阻止公有访问设置，或重启一个 EC2 实例进行维护。使用参数化文档和动态输入（例如，来自 Config 的发现结果）来保持运行手册的通用性。对于高风险资源，配置修复措施为自动执行；对于敏感操作，则要求通过 EventBridge 和 ChatOps 进行变更审批或手动调用。使用 SCP 保护 Config 本身，拒绝除中央管理员外的任何人停止记录器或删除交付通道。

Firewall Manager 利用 Organizations 为跨账户的“策略即服务”提供了补充。委托一个中央管理员并编写策略，用于在面向互联网的 ALB/API Gateway 上关联 WAF Web ACL、审计和清理 VPC 安全组，或传播 DNS Firewall 规则。这将未来的强制执行从检测/修复转向了预防。

威胁检测、密钥卫生与漏洞管理

Security Hub 充当跨账户和区域的安全发现结果的“单一管理平台”（central pane of glass）。使用委托管理员启用它，聚合发现结果，并激活相关标准（AWS 基础安全最佳实践、CIS、PCI DSS 等适用标准）。发现结果会流入 AWS 安全发现格式（ASFF），从而对来自 GuardDuty、Inspector、IAM Access Analyzer、Config、Macie 和合作伙伴工具的输入进行标准化。配置 EventBridge 模式，将关键发现结果路由到修复自动化流程（SSM Automation、Lambda）和通知（SNS、聊天工具）。

GuardDuty 提供托管式威胁检测，无需您管理数据平面的日志管道。它分析 CloudTrail 管理事件和数据事件、VPC Flow Logs、Route 53 Resolver DNS 查询日志以及 EKS 审计日志，以检测异常行为、凭证泄露、加密货币挖矿、DNS 渗漏等。启用恶意软件防护（Malware Protection），以便在检测到可疑活动时扫描 S3 和 EC2/EBS。使用组织范围的自动启用功能，并通过抑制规则系统地归档低信号的发现结果，以专注于可操作的告警。

Amazon Inspector 持续评估 EC2（通过 SSM agent）的软件包 CVE、ECR 容器镜像在部署前的漏洞，以及 Lambda 函数的代码包 CVE。Inspector 要求 EC2 实例已安装 SSM Agent，实例配置文件允许 SSM 权限，并具有到 SSM/KMS 端点的出口流量（如果限制了互联网访问，则通过 VPC 端点）。配置 Inspector 将发现结果发送到 Security Hub，并使用 Systems Manager Patch Manager 触发补丁工作流或基于运行手册（runbook）的修复。使用标签来界定哪些资源在扫描范围内，并将沙箱工作负载与受监管的工作负载分开。

Secrets Manager 集中管理密钥的存储、轮换和跨账户访问，并提供强大的可审计性。对于需要轮换的凭证，优先选择 Secrets Manager 而不是参数存储（parameter stores），利用其为 RDS/Aurora 提供的内置轮换功能或为外部系统提供的基于 Lambda 的轮换功能。暂存标签（AWSCURRENT、AWSPREVIOUS）可实现零停机轮换。在 VPC 中运行轮换 Lambda，确保 VPC 具有必要的端点（Secrets Manager、RDS、KMS）并限制出口流量。对于跨账户使用场景，附加一个资源策略，授予其他账户中的主体 GetSecretValue 权限；确保密钥的 CMK 的 KMS 密钥策略允许消费者主体进行解密，并在需要时创建授权（grant）。为了灾难恢复或区域性控制，跨区域复制密钥并对齐轮换窗口。

数据保护与网络安全

使用 KMS 和显式密钥策略来设计加密。最终授权主体对 CMK 执行加密操作的是密钥策略，而不仅仅是 IAM 策略。采用最小权限、基于角色的密钥策略模型：将管理权限委派给一个中心的 KMS 管理员角色；将使用权限精确授予工作负载角色；禁止使用通配符 kms:* 以避免意外的权限提升。使用条件键（kms:EncryptionContext:*）将解密操作绑定到预期的上下文。多区域密钥可实现双活（active-active）加密，支持数据跨区域复制。

授权（Grant）是在不编辑密钥策略的情况下委派临时或范围严格的密钥使用权限的正确工具，并且某些服务流程（例如，EC2 Auto Scaling 使用加密的启动模板、跨账户使用 AMI）必须使用它。要允许另一个账户创建授权，密钥策略必须允许该账户的主体执行 kms:CreateGrant；被授权者必须在同一调用路径中提供一个授权令牌（grant token）以立即使用。对于跨账户的加密 AMI，首先复制并使用 CMK 加密 AMI，共享该 AMI，允许目标账户对该 CMK 创建授权，然后让目标的服务相关角色接收该授权。

信封加密是默认模式：使用 KMS 生成一个数据密钥，在本地用明文数据密钥加密数据，然后只存储密文和加密后的数据密钥。读取时，调用 KMS Decrypt 将明文数据密钥恢复到内存中。这种方式最大限度地减少了对大型负载的 KMS 调用，并限制了明文密钥的暴露。在支持的情况下，使用服务托管的 SSE-KMS（S3、EBS、RDS）以简化操作，但仍需调整密钥策略以适应跨账户的生产者/消费者。

VPC 安全始于最小权限安全组。安全组是状态化的，返回流量被隐式允许。优先使用安全组引用，而不是基于 CIDR 的规则，以避免脆弱的 IP 允许列表，并保持基础设施即代码的意图一致性。默认的出站允许规则存在风险；应明确限制出口流量到所需的目的地，并使用 VPC 端点访问 AWS 服务。NACL 是无状态的，且最先被评估；仅在必须实施额外边界或满足监管要求时，才将其用作粗粒度的子网级别控制，并为临时端口明确设置返回规则；否则，为了可管理性，应优先使用安全组。

通过使用 VPC 端点来消除对互联网的依赖。网关端点（S3、DynamoDB）通过 AWS 网络进行私密路由；关联一个端点策略以限制可访问的存储桶或表。接口端点（AWS PrivateLink）通过私有 IP 暴露 AWS 服务（Secrets Manager、KMS、SSM、ECR、CloudWatch）；将它们部署在具有正确安全组的子网中，并启用私有 DNS，以便标准服务名称能解析为私有地址。对于跨账户/VPC 的生产者-消费者微服务，发布一个由 NLB 支持的端点服务，并让消费者通过 PrivateLink 创建指向它的接口端点，从而避免使用对等连接或中转网关，并使流量远离公共互联网。将这些控制措施与无 NAT、无 IGW 的子网以及在需要互联网访问时进行集中式出口流量检测相结合。

实践问题场景

Expedia Group 正在扩展到多个区域的数百个 AWS 账户，必须强制执行严格的安全基线：工作负载无互联网出口、自动修复配置错误、集中式威胁检测、密钥轮换，以及对用于标准化黄金镜像的加密 AMI 进行受控的跨账户共享。

1. 使用 AWS Organizations 和 AWS Control Tower 建立多账户治理

• 操作：为沙箱（Sandbox）、开发（Dev）、生产（Prod）和安全（Security）创建 OU。部署 Control Tower 以建立落地专区（landing zone），启用强制性护栏，并集成 IAM Identity Center。使用 Account Factory for Terraform (AFT) 通过 GitOps 来分发账户。
• 原因：Control Tower 提供了一站式、持续强制执行的护栏（SCP 和 Config 规则）。AFT 在大规模下标准化了账户配置过程，并将基线在版本控制中代码化。

2. 编写 SCP 以强制执行带有例外的全局护栏

• 操作：附加 SCP，禁止禁用 CloudTrail 和 AWS Config，限制区域，并防止公共 S3 ACL。为安全 OU 中的安全管理员角色添加基于条件的例外。允许创建/使用所需的服务相关角色。
• 原因：SCP 限制了包括根用户在内的所有主体的权限上限，防止配置漂移，同时允许为中心化运营提供受控的例外。

3. 部署带自动修复功能的 Config 合规包

• 操作：从安全委托管理员账户中，在整个组织范围内启用 AWS Config 并创建一个聚合器。推出一个合规包，强制执行默认 EBS 加密、受限的 SSH、带默认值的强制标签，以及在公共入口点上必须使用 WAF。将每个规则映射到 SSM Automation 文档以进行自动修复（例如，附加默认实例配置文件，将缺失的标签设置为“weekly”）。
• 原因：合规包提供了带自动修复功能的一致、可审计的策略即代码，使环境保持在合规状态，无需处理大量工单。

4. 使用 Security Hub、GuardDuty 和 Inspector 集中进行检测

• 操作：在整个组织范围内启用 GuardDuty 和 Inspector，并指定一个委托管理员。启用 Security Hub 标准（AWS FSBP 和 CIS）并聚合检测结果。创建 EventBridge 规则，将高严重性的检测结果路由到 SSM Automation 运行手册和一个用于通知待命人员的 SNS 主题。
• 原因：托管式检测和漏洞评估提供了持续的覆盖，运营开销极小，而 Security Hub 则整合了各种信号，以加快分类和响应速度。

5. 使用权限边界和 ABAC 实现 IAM 最小权限

• 操作：在 AFT 配置的账户中，要求开发人员创建的角色附加一个权限边界，该边界禁止 iam:PassRole（除非传递给经过筛选的角色）并限制高影响力的 API。使用 IAM Identity Center 的权限集和 ABAC，根据团队标签来限定操作范围。
• 原因：权限边界在防止权限提升的同时实现了安全的自助服务；ABAC 减少了策略蔓延，并与身份属性保持一致。

6. 使用 VPC 端点和 PrivateLink 强化网络路径

• 操作：从应用程序子网中移除 IGW/NAT。为 KMS、Secrets Manager、SSM、ECR、CloudWatch 创建接口端点，为 S3/DynamoDB 创建带有限制性端点策略的网关端点。通过由 PrivateLink 支持的 NLB 发布内部平台服务，以供跨账户消费。
• 原因：私有连接消除了互联网暴露，并确保服务在被锁定的环境中仍然可以访问。

7. 实施 KMS 密钥策略，并使用授权（Grant）处理跨账户 AMI

• 操作：为每个环境创建带有角色范围密钥策略的 CMK。在镜像构建账户中，加密黄金 AMI 并共享它们。更新 CMK 策略，允许目标账户创建授权，然后为这些目标账户中的服务相关角色创建授权。
• 原因：授权提供了范围明确、可审计的委派，无需为每个消费者编辑密钥策略，从而使 Auto Scaling 能够跨账户从加密 AMI 启动实例。

8. 标准化密钥轮换和跨账户访问

• 操作：将数据库和 API 凭证存储在 Secrets Manager 中。为非 RDS 目标实施 Lambda 轮换，并为 RDS 启用内置轮换。对于共享的平台密钥，附加基于资源的策略，向其他账户中的消费者角色授予 GetSecretValue 权限，并确保 CMK 策略允许解密。将轮换 Lambda 放置在具有必要端点的 VPC 中。
• 原因：自动轮换降低了凭证风险；基于资源的策略与 KMS 的配合使用，实现了安全的跨账户消费，同时保留了最小权限和审计跟踪。

该架构为 Expedia Group 提供了可强制执行的护栏、可证明的合规性、自动修复以及严格控制的数据访问路径，同时通过安全的自助服务和私有连接保持了开发人员的效率。

← 监控、日志记录和可观测性 · 所有领域 · 容器和 Serverless 运维 →

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

浏览 Amazon →