Amazon SCS-C02: 治理、組態與自動化 — 學習指南
屬於 AWS Security Specialty SCS-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
Service Control Policies 與組織層級的護欄
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」。即使有權限邊界和身份政策的配合，本地管理員仍然可以為自己開後門。只有在根目錄或 OU 層級應用的 SCP 才值得信賴，因為它甚至能約束成員帳號的 root 使用者（除少數幾個無法限制的操作外）。
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 recorder 和 delivery channel。這解決了啟動（bootstrap）問題：合規性套件無法評估一個尚未啟用 Config 的帳號。從委派管理員帳號（例如
security-01）部署合規性套件，使用PutOrganizationConformancePack。這會將一致的規則集傳播到所有現有和未來的帳號，無需手動接觸每個帳號。
委派管理員 + 彙總器（aggregator）的模式很重要：它讓資安團隊可以在一個地方看到所有帳號的合規性狀態，同時仍然允許應用程式團隊在本地添加自己的規則。直接從管理帳號部署相同的規則雖然可行，但這違反了最小權限原則，也阻礙了職責分離的稽核。
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 容器步驟——可以在任何不合規的資源被創建之前就讓 pipeline 失敗。一旦發生違規，pipeline 會發布訊息到一個資安團隊訂閱的 SNS 主題，讓他們在不成為手動批准瓶頸的情況下獲得可見度。單獨依賴 StackSets 或 CloudFormation 變更集審查來通知資安團隊是一個陷阱：這兩個服務都不會發出每個資源的合規性結果，而且當堆疊創建完成時，資源早已存在於帳號中。
Service Catalog 為 Guard 補足了最後一哩路。平台團隊不讓開發人員隨意撰寫 CloudFormation，而是將經過審查的產品（如 VPC 基準線、RDS 模式、EKS 叢集）發布為 Service Catalog 產品組合，並透過 AWS RAM 在帳號間共享。開發人員使用受限的參數來啟動這些產品，並透過一個啟動限制 IAM 角色，以開發人員本身不持有的更高權限來佈建資源。這提供了一個可稽核的自助式部署模型，其中底層的範本已經通過了 Guard 的檢查。
StackSets 本身需要正確的配置：從組織管理帳號部署時使用 SERVICE_MANAGED 權限模型，在 Organizations 中為 CloudFormation 啟用信任存取，並謹慎設定執行角色。AdministrationRoleARN/ExecutionRoleName 組合（在自我管理模式下）或服務連結角色（在服務管理模式下）必須允許對實際創建資源的 CloudFormation 服務角色執行 iam:PassRole。忘記附加 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 規則觸發，一個 SSM Automation runbook AWS-DisableS3BucketPublicReadWrite 會對其進行修復。對於更複雜的流程——比方說，一個 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 金鑰政策，該政策僅在呼叫服務是 S3、DynamoDB、Lambda 或 EKS 時，透過 kms:ViaService 條件才允許 kms:Decrypt。
實務問題：使用案例情境
情境： Meridian Financial 營運一個多帳戶的 AWS Organization，其中包含生產、預備、沙箱和一個集中的安全帳戶。他們混合使用 CloudFormation 範本和開發人員在沙箱中自行驅動的範本來部署工作負載；所有權分散在各個團隊，且他們必須滿足內部對於資料加密和最小權限存取的治理要求。
挑戰： 沙箱中的開發人員意外地建立了公開的 S3 儲存貯體和過於寬鬆的 IAM 政策，這些問題擴散到了其他帳戶，而安全團隊缺乏在整個 Organization 中一致、自動化的強制執行和範本驗證機制。
建議方法：
- 建立組織層級的服務控制政策 (SCPs)，在 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 runbook，並透過 EventBridge 觸發額外的工作流程。
- 集中執行 IAM Access Analyzer 和政策驗證，將調查結果匯入 Security Hub，並針對發現的跨帳戶或過於寬鬆的政策，自動化建立工單或執行修復手冊。
理由： 此方法結合了預防性的全組織護欄 (SCPs)、持續偵測 (Config/Conformance Packs)、左移的範本驗證 (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？」這樣的問題，而無需費力地切換跨帳戶角色。請注意，彙總器是唯讀的：它們只呈現合規狀態，本身不執行修復。
使用合規包強制執行基準
合規包 (conformance pack) 將 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 處理常式接著會對有問題的 SG 呼叫 RevokeSecurityGroupIngress。無論您選擇哪條路徑，自動化程序都必須擔任一個擁有最低權限的 IAM 角色，以修改目標資源。一個常見的失敗模式是，Config 規則的合規狀態在 NON_COMPLIANT 和 COMPLIANT 之間無限循環切換，因為修復執行手冊因 AccessDenied 而出錯——Config 記錄了這次叫用，但會靜默地繼續執行。務必檢查 SSM Automation 的執行歷史記錄，並授予執行手冊角色所需的特定變更權限 (例如 ec2:CreateFlowLogs、用於 flow-log 交付角色的 iam:PassRole，以及 logs:CreateLogGroup)。
Systems Manager Automation 與 Patch Manager
SSM Automation 執行手冊是命令式修復的主力工具。它們是描述步驟——API 呼叫、核准、分支——的版本化 YAML/JSON 文件，由您指定的 IAM 角色執行。除了由 Config 觸發的修復外，它們也執行排程的維護任務：輪換存取金鑰、為未掛載的 EBS 磁碟區加上標籤，或終止已停止超過 30 天的執行個體。
Patch Manager 是 SSM 的一個子系統，它能讓作業系統符合修補基準 (patch baseline)——一組經核准的修補程式、分類和嚴重性篩選條件。執行個體透過 Patch Group 標籤被分組到修補群組 (patch groups) 中；一個維護時窗 (maintenance window) 會排程對它們執行 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 偵測規則與 SCP（例如s3:PutBucketPublicAccessBlock拒絕）配對使用，以彌補這個差距。
災難復原：備份、範本與原始碼控制
要達成 RPO/RTO 目標，需要確保資料與基礎設施定義兩者皆可復原。AWS Backup 集中管理跨 EBS、RDS、DynamoDB、EFS 與 FSx 的備份政策；組織備份政策能跨成員帳戶強制執行計畫，而跨區域、跨帳戶的複本可保護免於區域損失與帳戶洩露。RPO 由備份頻率設定；RTO 則取決於還原機制（DynamoDB PITR 還原只需幾分鐘；跨區域的 RDS 快照還原則可能需要一小時）。
基礎設施復原依賴儲存在 CodeCommit（或其他 Git 供應商）中的 CloudFormation 範本作為單一事實來源。從版本控制的範本重新部署 StackSet，可在幾分鐘內於復原區域重建 VPC、IAM 與應用程式堆疊。若只將範本保存在主控台中——沒有任何 repo——會使 RTO 無法預測，因為沒有可重現的產物。
陷阱分析
三個常見的誤解經常導致錯誤答案。第一，將 Config 視為預防性控制：它是在 CloudTrail 記錄變更之後才進行評估，因此真正的禁令需要 SCPs。第二，在設定修復時沒有提供足夠範圍的 IAM 角色——SSM 文件存在且 Config 規則觸發了，但 runbook 會因權限錯誤而無聲地失敗。第三，從管理帳戶執行組織範圍的服務，而不是註冊一個委派管理員，這會強制每個帳戶都需手動啟用，並阻礙組織範圍的彙總器正常運作。
實務問題：使用案例情境
情境： Meridian Financial 在 AWS Organizations 下執行一個多帳戶的 AWS 環境，其中包含獨立的生產、開發與安全帳戶。安全團隊必須在管理跨區域數百個 EC2 執行個體、S3 儲存貯體與 Lambda 函數的同時，向內部控制與監管機構證明其持續合規。
挑戰： 最近一次稽核發現有未修補的 EC2 執行個體、公開的 S3 儲存貯體，以及跨帳戶的基準線強制執行不一致；修復工作是手動且緩慢的，且預防性控制並未統一應用。
建議方法：
- 將安全帳戶指定為 AWS Config 委派管理員，並透過 CloudFormation StackSets 部署一個 AWS Config Aggregator，以收集來自所有帳戶與區域的組態與合規資料。
- 從安全帳戶（使用 StackSets）部署組織層級的 AWS Config Conformance Packs，將基準控制（S3 公開存取、加密、標籤）程式碼化，以確保相同的規則能一致地應用。
- 將 AWS Config 自動修復動作附加到高風險規則上，這些規則會叫用 AWS Systems Manager Automation 文件（註冊為修復 runbook），如此一來，違規行為將自動觸發 SSM Automation 或 Run Command 進行修復。
- 使用 AWS Systems Manager Patch Manager 搭配 SSM Patch Baselines 與 State Manager 來定義修補程式群組，並自動化跨帳戶的作業系統修補；將修補程式合規結果饋送至 Config Aggregator。
- 將經核准的 CloudFormation 範本發佈到 AWS Service Catalog，並使用 CloudFormation StackSets 來部署或更新合規的堆疊；透過 AWS Organizations Service Control Policies 強制執行預防性護欄，以阻擋不被允許的資源建立（例如，停用公開 S3 儲存貯體的建立）。
- 設定 Amazon EventBridge (CloudWatch Events) 與 SNS，以便在發生不合規時通知安全團隊，並針對複雜事件觸發額外的 SSM Automation 工作流程。
基本原理： 透過 Config Aggregator 與 conformance packs 集中偵測，透過 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.
通過考試 →