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 角色的身分型政策定義了允許的操作；角色的信任政策則定義了誰可以擔任它。無論身分政策如何規定，許可邊界都會限制一個主體 (principal) 可執行的操作上限。AWS Organizations 中的 SCP 則為成員帳戶中的任何主體（包括根使用者）設定了絕對的權限上限。資源型政策（用於 S3、KMS、Secrets Manager 等）可以允許跨帳戶存取，但它們同樣不能超越 SCP 或許可邊界所施加的限制。有效權限是以下各項的交集：身分政策 ∩ 許可邊界 ∩ 工作階段政策 (若存在) ∩ 資源政策 (若適用) ∩ SCP，其中任何明確的 Deny (拒絕) 均具備優先權。

在單一帳戶中，使用許可邊界來實現安全的自助服務。例如，一個開發人員自動配置管線只能在附加特定邊界的情況下建立角色，該邊界拒絕 iam:PassRole (除非符合特定模式)、拒絕在敏感金鑰上執行 kms:Decrypt，並限制 EC2 執行個體類型。許可邊界只能由已擁有 iam:PutRolePermissionsBoundary 權限的主體附加；請嚴密地保護這項權利。

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 風格的工作流程、漂移偵測和功能旗標（例如，佈建 Enterprise Support），並能以一致的基準護欄擴展至數百個帳戶。

AWS Control Tower 會自動化一個具有規範性護欄的登陸區。預防性護欄是 Control Tower 管理的 SCP；偵測性護欄則是它部署的 AWS Config 規則。Control Tower 整合了 IAM Identity Center 以提供 SSO 和許可集。使用基於 ABAC 的許可集，並搭配屬性進行存取控制，以根據 aws:PrincipalTag 或身分識別屬性來限定操作範圍。透過 AWS Control Tower 的自訂項目 (CfCT) 來擴展基準，以自動為每個 OU/帳戶部署 CloudFormation、SCP 和 Config 套件。保留例外 OU，以託管需要客製化政策的工作負載，而不會削弱全域護欄。

持續合規與自動化修復

從一個委派管理員帳戶中，為整個組織啟用 AWS Config。開啟所有區域中所有資源的記錄功能，並使用組織彙總器來彙總整個組織的組態。使用受管規則來實施常見的控制（例如，ebs-encryption-by-default、restricted-ssh、s3-bucket-level-public-access-prohibited），並撰寫由 Lambda 支援的自訂規則以實現客製化邏輯（例如，根據 90 天政策驗證 KMS 輪替頻率，或強制執行預設標籤和值）。合規包將規則、參數和修復措施分組為可版本化、可部署的套件組合，並按 OU 分配；將它們保存在版本控制中，並透過 StackSets 或 CfCT 推出，以確保一致性與可稽核性。

自動化修復形成了閉環。將每個規則的不合規評估結果對應到一個 SSM Automation runbook，以強制執行基準：附加預設的執行個體描述檔、套用具有預設值的標籤、切換 S3 封鎖公開存取，或重新啟動 EC2 執行個體進行維護。使用參數化文件和動態輸入（例如，來自 Config 的發現項目）來讓 runbook 保持通用性。對於高風險資源，將修復設定為自動執行；對於敏感操作，則要求變更核准或透過 EventBridge 和 ChatOps 進行手動調用。使用 SCP 保護 Config 本身，拒絕任何人停止記錄器或刪除交付通道，除非是中央管理員。

Firewall Manager 為此層提供補充，透過 Organizations 實現「政策即服務」。委派一個中央管理員，並撰寫政策，用於在面向網際網路的 ALB/API Gateway 上關聯 WAF Web ACL、進行 VPC 安全群組的稽核與清理，或傳播 DNS Firewall 規則。這將未來的強制執行從偵測/修復轉變為預防。

威脅偵測、機密資訊衛生與弱點管理

Security Hub 作為跨帳戶與跨區域的調查發現的單一管理平台。透過委派管理員啟用它、彙總調查發現，並啟用相關標準 (AWS Foundational Security Best Practices、CIS，以及適用的 PCI DSS)。調查發現會流入 AWS Security Finding Format (ASFF)，將來自 GuardDuty、Inspector、IAM Access Analyzer、Config、Macie 及合作夥伴工具的輸入標準化。設定 EventBridge 模式，將關鍵的調查發現路由到修復自動化流程 (SSM Automation、Lambda) 和通知 (SNS、聊天室)。

GuardDuty 提供託管式威脅偵測服務，無需您自行管理資料層的日誌管道。它會分析 CloudTrail 管理與資料事件、VPC Flow Logs、Route 53 Resolver DNS 查詢日誌以及 EKS 稽核日誌，以偵測異常行為、憑證外洩、加密貨幣挖礦、DNS 隧道攻擊等。啟用惡意軟體防護，以便在偵測到可疑活動時掃描 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 而非參數存放區，並利用其內建的 RDS/Aurora 輪換功能，或針對外部系統使用基於 Lambda 的輪換。暫存標籤 (AWSCURRENT、AWSPREVIOUS) 可實現零停機時間的輪換。在 VPC 中執行輪換用的 Lambda，並確保 VPC 具備必要的端點 (Secrets Manager、RDS、KMS) 且限制其出口流量。若要跨帳戶使用，請附加一個資源型政策，授予其他帳戶中的 principals 執行 GetSecretValue 的權限；並確保該機密資訊的 CMK 的 KMS 金鑰政策允許消費端的 principals 進行解密，並在需要時建立授權 (grant)。為了災難復原或地理位置控制，請將機密資訊複寫到不同區域，並對齊輪換時間窗。

資料保護與網路安全

設計使用 KMS 的加密機制時，需搭配明確的金鑰政策。最終授權主體對 CMK 執行加密操作的是金鑰政策，而不僅僅是 IAM 政策。採用最低權限、基於角色的金鑰政策模型：將管理權限委派給一個中央的 KMS 管理員角色；將使用權限精確地授予工作負載角色；不允許使用萬用字元 kms:* 以避免意外的權限提升。使用條件金鑰 (kms:EncryptionContext:*) 將解密操作與預期的情境綁定。多區域金鑰 (Multi-Region keys) 讓資料能跨區域複寫，實現 active-active 的加密架構。

授權 (Grants) 是在不編輯金鑰政策的情況下，委派臨時或範圍嚴格的金鑰使用權的正確工具，且在某些服務流程中是必要的（例如，EC2 Auto Scaling 使用加密的啟動範本、跨帳戶使用 AMI）。若要允許另一個帳戶建立授權，金鑰政策必須允許該帳戶的主體執行 kms:CreateGrant；被授權者必須在同一個呼叫路徑中提供一個授權權杖 (grant token) 以便立即使用。對於跨帳戶的加密 AMI，需複製並用 CMK 加密該 AMI，分享該 AMI，允許目標帳戶在該 CMK 上建立授權，並讓目標的服務連結角色 (service-linked role) 接收一個授權。

信封加密 (Envelope encryption) 是預設的模式：用 KMS 產生一個資料金鑰，在本地用純文字資料金鑰加密資料，然後只儲存密文和加密後的資料金鑰。讀取時，呼叫 KMS Decrypt 將純文字資料金鑰還原到記憶體中。這能將處理大型負載時對 KMS 的呼叫次數降到最低，並限制純文字金鑰的曝險。在支援的情況下，使用服務管理的 SSE-KMS (S3, EBS, RDS) 以簡化操作，但仍需調整金鑰政策以配合跨帳戶的生產者/消費者。

VPC 的安全始於最低權限的安全群組 (security groups)。安全群組是具狀態的 (stateful)；回程流量是隱含允許的。優先使用安全群組參考 (security group references) 而非基於 CIDR 的規則，以避免脆弱的 IP 允許清單，並讓基礎設施即程式碼 (infrastructure as code) 更能表達意圖。預設的出站允許規則有風險；應明確限制出口流量至必要的目的地，並使用 VPC 端點來存取 AWS 服務。NACL 是無狀態的 (stateless) 且最先被評估；只有在您必須實作額外的邊界或滿足法規要求時，才將它們當作粗略的、子網路層級的控制，並為臨時埠 (ephemeral ports) 明確設定回程規則；否則，為了可管理性，應優先使用安全群組。

使用 VPC 端點來消除對網際網路的依賴。閘道端點 (Gateway endpoints) (S3, DynamoDB) 透過 AWS 網路進行私有路由；可關聯一個端點政策來限制可存取的儲存貯體或資料表。介面端點 (Interface endpoints) (AWS PrivateLink) 透過私有 IP 暴露 AWS 服務 (Secrets Manager, KMS, SSM, ECR, CloudWatch)；將它們部署在具有正確安全群組的子網路中，並啟用私有 DNS (Private DNS)，讓標準的服務名稱能解析到私有地址。對於跨帳戶/VPC 的生產者-消費者微服務，可發布一個由 NLB 支援的端點服務，並讓消費者透過 PrivateLink 建立介面端點來連接它，這樣可以避免 VPC 對等連接 (peering) 或 Transit Gateway，並讓流量保持在公用網際網路之外。將這些控制措施與無 NAT、無 IGW 的子網路，以及在需要網際網路存取時的集中式出口檢測結合起來。

實際問題情境

Expedia Group 正在擴展到數百個跨多個區域的 AWS 帳戶，並且必須強制執行嚴格的安全基準：工作負載無網際網路出口、自動修復錯誤配置、集中式威脅偵測、秘密輪換，以及對加密 AMI 進行受控的跨帳戶共享，以實現標準化的黃金映像檔 (golden images)。

透過 AWS Organizations 和 AWS Control Tower 建立多帳戶治理

行動：建立 Sandbox、Dev、Prod 和 Security 的 OU。部署 Control Tower 以建立登陸區 (landing zone)，啟用強制性的護欄 (guardrails)，並整合 IAM Identity Center。使用 Account Factory for Terraform (AFT) 透過 GitOps 來發放帳戶。
理由：Control Tower 提供立即可用、持續強制的護欄 (SCPs 和 Config 規則)。AFT 將大規模的帳戶發放標準化，並將基準線以版本控制的方式程式碼化。

撰寫 SCPs 以強制執行全域護欄並設定例外

行動：附加 SCPs 來拒絕停用 CloudTrail 和 AWS Config、限制區域，並防止公開的 S3 ACL。為 Security OU 中的一個安全管理員角色加入基於條件的例外。允許建立/使用必要的服務連結角色。
理由：SCPs 限制了所有主體（包括 root）的權限上限，防止配置漂移，同時允許為中央操作進行受控的例外。

部署具備自動修復功能的 Config 合規套件

行動：從 Security 委派的管理員帳戶，為整個組織啟用 AWS Config 並建立一個彙總器 (aggregator)。推出一個合規套件，強制執行預設 EBS 加密、受限的 SSH、帶有預設值的強制性標籤，以及在公開入口點上必須有 WAF。將每個規則對應到 SSM Automation 文件以進行自動修復（例如，附加預設的執行個體設定檔、將遺失的標籤設定為 weekly）。
理由：合規套件提供了一致、可稽核的政策即程式碼 (policy-as-code)，其自動修復功能可讓環境保持在合規狀態，而無需處理大量的工單。

使用 Security Hub、GuardDuty 和 Inspector 集中化偵測

行動：為整個組織啟用 GuardDuty 和 Inspector，並指定一個委派的管理員。啟用 Security Hub 標準 (AWS FSBP 和 CIS) 並彙總調查結果。建立 EventBridge 規則，將高嚴重性的調查結果路由到 SSM Automation runbooks 和一個用於 on-call 通知的 SNS 主題。
理由：受控的偵測和弱點評估提供了持續的覆蓋範圍，且操作開銷極小，而 Security Hub 則整合了各種信號，以加快分類和應對速度。

透過權限邊界和 ABAC 強制執行 IAM 最低權限

行動：在由 AFT 發放的帳戶中，要求開發人員建立的角色必須附加一個權限邊界 (permission boundary)，該邊界拒絕 iam:PassRole（除非是傳遞給經審核的角色），並限制高影響力的 API。使用 IAM Identity Center 的許可集 (permission sets) 搭配 ABAC，根據團隊標籤來界定操作範圍。
理由：權限邊界讓安全的自助服務成為可能，同時防止權限提升；ABAC 減少了政策的過度擴散，並與身份屬性保持一致。

使用 VPC 端點和 PrivateLink 來強化網路路徑

行動：從應用程式子網路中移除 IGW/NAT。為 KMS、Secrets Manager、SSM、ECR、CloudWatch 建立介面端點，並為 S3/DynamoDB 建立帶有限制性端點政策的閘道端點。透過 PrivateLink 支援的 NLB 發布內部平台服務，以供跨帳戶使用。
理由：私有連線消除了網際網路曝險，並確保服務在被鎖定的環境中仍然可以連線。

實作 KMS 金鑰策略，並使用授權 (grants) 處理跨帳戶 AMI

行動：為每個環境建立 CMK，並搭配基於角色的金鑰政策。在映像檔建置帳戶中，加密黃金 AMI 並分享它們。更新 CMK 政策以允許目標帳戶建立授權，然後為那些目標帳戶中的服務連結角色建立授權。
理由：授權提供了範圍限定、可稽核的委派，而無需為每個消費者編輯金鑰政策，從而使 Auto Scaling 能夠跨帳戶從加密的 AMI 啟動。

標準化秘密輪換與跨帳戶存取

行動：將資料庫和 API 憑證儲存在 Secrets Manager 中。為非 RDS 目標實作 Lambda 輪換，並為 RDS 啟用內建的輪換功能。對於共享的平台秘密，附加基於資源的政策，將 GetSecretValue 權限授予其他帳戶中的消費者角色，並確保 CMK 政策允許解密。將輪換用的 Lambda 放置在具有必要端點的 VPC 中。
理由：自動輪換降低了憑證風險；基於資源的政策與 KMS 的配合，實現了安全的跨帳戶使用，同時保留了最低權限和稽核軌跡。

這個架構為 Expedia Group 提供了可強制執行的護欄、可證明的合規性、自動化的修復，以及嚴格控制的資料存取路徑，同時透過安全的自助服務和私有連線，保持了開發人員的開發速度。

← 監控、日誌記錄與可觀測性 · 所有領域 · 容器與無伺服器維運 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →