多帳號策略：AWS Organizations + Control Tower

凌晨 02:14 你收到告警：組織內某個開發帳號正在向外部 S3 bucket 滲出資料。你有十分鐘必須做到：(a) 撤銷被入侵主體的權限、(b) 防止其他同層帳號遭受相同攻擊方式、(c) 在防竄改的地方保存鑑識證據、(d) 在週一向合規稽核員證明艦隊其餘部分仍在政策範圍內。如果你唯一的工具是「一個接一個登入帳號點來點去」，以上四件事都無法完成。多帳號策略是安全工程師一次性、跨數百個帳號同步完成這四件事的槓桿——而且要在攻擊者跑完下一個迴圈之前。

本 SCS-C02 指南從安全工程師的日常現實出發解析 AWS Organizations 與 AWS Control Tower：偵測、圍堵、修復、稽核。本文假設你已知道如何撰寫 IAM 政策及跨帳號假設 role。重點是組織層級的控制平面——將整個艦隊變成單一安全面：SCP 作為預設拒絕守衛、Control Tower 控制項作為自見解基準線、委派管理員將安全工具從危險的管理帳號移出、AWS Config 聚合器作為全組織的證據引擎，以及稽核員必問的 root 帳號管控。

為什麼多帳號策略在 SCS-C02 Domain 6.1 中至關重要

Domain 6 佔 SCS-C02 的 14%，而 task statement 6.1 明確要求：「制定集中部署與管理 AWS 帳號的策略」。考試指南列出情境題所涵蓋的知識範疇——多帳號策略、支援委派管理的受管服務、政策定義的守衛、root 帳號最佳實務，以及跨帳號 role。上述每一項都是安全工程師在事件應變或稽核時能採用的圍堵或偵測手段。

SCS-C02 在這個領域的題目幾乎從不問「什麼是 SCP？」，它們讀起來像真實的值班工單：帳號遭入侵、開發人員停用了 CloudTrail、法規機關要求七年的證據留存、安全團隊厭倦了登入管理帳號。正確答案通常是多帳號控制——root 層級的 deny SCP、委派管理員模式、Control Tower 守衛、Config 聚合器查詢——而非單帳號的修補。如果你對艦隊層級的問題直覺反應是 ssh 進某台 EC2，你就會選到錯的答案。

白話文解釋 Multi-Account Security Strategy

三個符合安全工程師在事件應變中真實思維的類比。

類比一：醫院病房體系

把大型醫院想像成一個系統。每個 AWS 帳號就是一個病房，有自己的病患、設備和員工。管理帳號是院長室——極高特權、簽署主合約，但從不直接接觸病患。Organizational Units (OUs) 是院區，每個院區有共同的協定——加護院區、婦產院區、門診院區——各自遵守相同的感染管制規範。SCP 是貼在每扇門上的感染管制規章：「禁止外食、禁止未洗手進入、禁止未授權開立處方」。它從不賦予醫生處方權（IAM 政策才是執照）；它只是無論你資歷多深都禁止某些行為。Control Tower 是醫院評鑑機構，規定「每個病房必須有正常運作的火災警報（CloudTrail）、氧氣感測器（GuardDuty）、病歷系統（Config），以及隔離室（Audit 帳號）」。當出現傳染性病患（被入侵的 IAM 主體），委派的安全管理員——在獨立辦公室工作的感染管制護理師——可以隔離病房、調取紀錄、向院長彙報，無需使用院長持有的整棟醫院主鑰匙。

類比二：航空交通管制雷達

想像你是一名航管員。每個 AWS 帳號是你空域中的一架飛機。管理帳號是塔台本身——你像守護金庫一樣保護它，不讓日常航班穿越它。OU 是飛行走廊——國內線、國際線、貨運線、訓練線。SCP 是飛行規則——「任何飛機不得離開走廊」、「任何飛機不得關閉應答器」、「任何飛機在此走廊不得爬升至 FL410 以上」。飛機關閉應答器，等同於成員帳號呼叫 cloudtrail:StopLogging——SCP 直接在源頭拒絕無線電信號。AWS Config 聚合器是你的雷達顯示器——每架飛機的位置與航向都回報到同一個螢幕，讓你一眼掌握整個空域。委派管理員是雷達顯示器的值班督導員：他能看到每一班航班的完整資訊，卻不持有機場的主鑰匙。Control Tower 偏移偵測就是當飛機偏離走廊時——警報響起，你展開調查，再把它導回正軌。

類比三：連鎖銀行分行網絡

全國銀行有 200 家分行。管理帳號是總行，主金庫在那裡。每個 AWS 帳號是一家分行，有自己的出納台、客戶和監視系統。OU 是區域群組（「東北區分行」、「純線上分行」、「已結束營業的分行」）。SCP 是銀行的防詐條例——「任何分行未經總行核准不得開立外幣帳戶」、「任何分行不得刪除監視錄影」、「任何分行出納未經雙重授權不得移動超過 50 萬元」。當一名出納員涉嫌舞弊，中央舞弊調查組（Audit 帳號的委派管理員）可以從一個主控台（CloudTrail 組織追蹤 + Athena）調閱每家分行的交易記錄、透過 OU 層級的 SCP 凍結出納員的存取，並向監管機關提交證據——全程不需要取得總行的主鑰匙。Control Tower 強制控制項是監管機關對每家分行的不可妥協安全底線（運作中的警報、上鎖的金庫、簽署的稽核軌跡）；強烈建議控制項是銀行自身在監管底線之上的強化姿態。

安全工程師視角的 AWS Organizations

你接手或設計一個組織。安全問題是：危險帳號放哪裡、安全工具在哪裡跑、哪些 API 呼叫必須在任何地方都無法成功？

讓事件應變得以實現的 OU 配置

AWS Security Reference Architecture (SRA) 與「Organizing Your AWS Environment」白皮書描述了相同的標準 OU 模式。從 SecOps 角度，每個 OU 的存在是因為它有獨特的安全姿態：

• Security OU — 安全組織擁有的非工作負載帳號，包含：
  • Log Archive 帳號 — 接收組織 CloudTrail 追蹤與 AWS Config 快照的唯寫 S3 bucket；透過 S3 Object Lock + SCP 封鎖刪除動作確保防竄改。
  • Audit（Security Tooling）帳號 — GuardDuty、Security Hub、Macie、Detective、Inspector、IAM Access Analyzer、Config 聚合器的委派管理員。這是你身為 SecOps 工程師每天工作的地方。
  • Forensics 帳號 — 被入侵 EBS 磁碟區快照、記憶體傾印與隔離 EC2 AMI 的隔離目的地（另見 incident-response-isolation-forensics 主題）。
• Infrastructure OU — 網路帳號（Transit Gateway、AWS Network Firewall、Firewall Manager 委派管理員）與共享服務帳號。
• Workloads OU — 分為 Prod 與 Non-Prod 子 OU；每個應用程式團隊在其中擁有自己的帳號。
• Sandbox OU — 實驗帳號，位於積極的允許清單 SCP 與嚴格預算上限之後。
• Suspended OU — 被入侵或已退役帳號的隔離區，位於全拒絕 SCP 之後。這是事件圍堵時移入帳號的目標。
• Policy Staging OU — 新受邀帳號（例如收購）在納入完整守衛集之前的過渡區。

Suspended OU 就是凌晨 02:14 你會採用的槓桿：將被入侵帳號移入後，全拒絕 SCP 立即生效，攻擊者的主體在下一次 API 呼叫時即失去授權，且帳號保持完整以供鑑識擷取，而非直接關閉。

管理帳號衛生是不可妥協的底線

管理帳號是組織中最危險的帳號。SCS-C02 題目反覆測試你是否了解它的特性：

• SCP 不套用於管理帳號。 即使是 root 層級的全拒絕 SCP 也無法約束它。
• 在管理帳號中執行零工作負載。 把它當作硬體金庫：你造訪、為特定操作登入、然後離開。
• 鎖定 root 帳號：硬體 MFA、無存取金鑰、憑證封存、透過 CloudTrail 監控任何 root 帳號的 userIdentity.type == "Root" 事件的 CloudWatch 警報。
• 使用 IAM Identity Center 進行人員存取管理帳號；不使用 IAM 使用者。
• 透過委派管理員將所有安全服務移出（見下節）。

Service Control Policies 作為安全守衛

對安全工程師而言，SCP 是 AWS 給你最強的控制，因為它在任何 IAM allow 生效之前就已完成評估。掌握少數幾種 SCP 模式，就能覆蓋大部分 SCS-C02 的題目範圍。

SCP 如何評估

成員帳號發出的每次 API 呼叫必須滿足：

1. 從組織 root 到 OU 再到帳號的路徑上，每一份 SCP 都必須允許該動作（允許的交集）。
2. 路徑上任何明確拒絕絕對勝出——單一 deny 否決一切。
3. 成員帳號內主體的 IAM 身分型政策也必須允許該動作。
4. 以資源為基礎的政策（S3 bucket、KMS 金鑰等）和工作階段政策仍然適用。
5. 管理帳號免除；服務連結角色免除。

預設的 FullAWSAccess 受管 SCP 掛載於每個新 OU 和帳號，允許一切。若要執行允許清單姿態，你需要移除 FullAWSAccess 並掛載窄範圍的允許 SCP。大多數生產組織在 root 與 OU 層級執行拒絕清單姿態（允許一切，但枚舉的風險除外），並在 Sandbox 與 Suspended OU 疊加允許清單。

模式 A：稽核防竄改 deny SCP（root 層級，必備）

此 SCP 掛載於組織 root，保護安全遙測不受任何成員帳號管理員的修改：

• Deny cloudtrail:StopLogging、cloudtrail:DeleteTrail、cloudtrail:UpdateTrail、cloudtrail:PutEventSelectors，目標為組織追蹤。
• Deny config:DeleteConfigurationRecorder、config:StopConfigurationRecorder、config:DeleteDeliveryChannel。
• Deny guardduty:DeleteDetector、guardduty:DisassociateFromMasterAccount、guardduty:StopMonitoringMembers。
• Deny securityhub:DisableSecurityHub、securityhub:DisassociateFromMasterAccount。
• Deny macie2:DisableMacie、inspector2:Disable。
• Deny iam:DeleteRole 與 iam:DeletePolicy，目標為 AWSControlTowerExecution。
• Deny s3:DeleteBucket、s3:DeleteBucketPolicy、s3:PutBucketPolicy，目標為透過標籤條件篩選的集中日誌存檔 bucket。
• Deny kms:ScheduleKeyDeletion、kms:DisableKey，目標為透過標籤篩選的稽核關鍵 KMS 金鑰。

這是最重要的 SCP 模式。將其與 centralized-logging-cloudtrail-vpcflow 主題互相連結——集中日誌架構只有在 SCP 作為後盾的情況下才能防竄改。

模式 B：區域限制 SCP

大多數安全團隊透過只允許核准區域來縮小攻擊面。使用 aws:RequestedRegion 搭配 Deny+NotAction，排除雖然看似區域服務但實際不是的全域服務：

"Effect": "Deny",
"NotAction": [
  "iam:*", "organizations:*", "route53:*",
  "cloudfront:*", "waf:*", "waf-regional:*",
  "sts:*", "support:*", "globalaccelerator:*",
  "budgets:*", "ce:*", "health:*", "tag:*"
],
"Resource": "*",
"Condition": { "StringNotEquals": { "aws:RequestedRegion": ["us-east-1","eu-west-1"] } }

漏掉 NotAction 中的任何全域服務，就會讓組織內的 IAM、KMS 或 CloudTrail 全面失效——這是最常見的 SCP 錯誤。這是 Deny+NotAction 唯一合法的使用場景；它之所以有效，是因為與區域條件配對使用。

模式 C：Root 帳號封鎖 SCP

若要強制 root 帳號 MFA 並完全防止 root 被使用，在 root 或所有 OU 層級掛載：

• "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } }.

這單一條 SCP 陳述句讓組織中每個 root 帳號的 API 呼叫都回傳 AccessDenied（管理帳號除外，管理帳號的 root 仍需在運維層面管控）。搭配 Control Tower 強烈建議控制項「Require MFA for the root user」，讓任何沒有 MFA 的主控台登入嘗試失敗——見下一節的 Control Tower 控制項類別。

模式 D：資料邊界 SCP（身分側）

資料邊界確保只有可信身分能從可信網路存取可信資源。身分側屬於 SCP：

• Deny s3:*、kms:*、secretsmanager:*，當 aws:PrincipalOrgID 不符合你的組織 ID 時——封鎖透過跨帳號主體的混淆代理人滲出。
• Deny 當 aws:PrincipalIsAWSService 為 false 且 aws:SourceVpc/aws:SourceVpce 不存在時——收緊網路側。

資源側（bucket 政策、KMS 金鑰政策）使用相同的條件金鑰；兩者合一形成邊界。此模式是高頻考點。

安全工程師的 AWS Control Tower——登陸區與控制項類別

Control Tower 是圍繞 Organizations 的有自見解封裝，負責佈建並維護最佳實務登陸區。對安全工程師而言，價值主要在控制項目錄——依業務類別分組的預防性、偵測性與主動性政策——以及其餘工具所依賴的標準 Log Archive + Audit 帳號拓撲。

Control Tower 為你佈建的內容

在新的管理帳號中啟動 Control Tower，大約一個小時內會完成：

• Security OU，包含 Log Archive 與 Audit 帳號。
• Sandbox OU 作為起始容器。
• 全組織 CloudTrail 追蹤，傳送至 Log Archive bucket。
• AWS Config 記錄器，在每個已加入帳號中啟用，並傳送至 Log Archive bucket。
• AWS Config 聚合器，位於 Audit 帳號。
• IAM Identity Center，每個 OU 有預設的權限集。
• AWS KMS CMK，用於日誌與 Config 加密（可選客戶管理）。
• 強制控制項基準線，套用至每個 OU。

三種控制項類別——考試關鍵

Control Tower 以業務類別標記每個控制項。SCS-C02 期望你了解差異，因為考試常問「這個控制項是自動的還是自選的？」。

• Mandatory 控制項 — 在登陸區建立時自動套用至每個 OU，不可移除。它們保護登陸區本身：拒絕刪除 Log Archive bucket、拒絕停用 CloudTrail、拒絕修改 Log Archive 帳號的 CloudTrail 追蹤、拒絕變更稽核 role 設定。將其視為組織無法跌破的底線。
• Strongly recommended 控制項 — 自選但 AWS 建議幾乎所有組織都開啟。例如：「Require MFA for the root user」、「Disallow public read access to log archive S3 buckets」、「Enable encryption at rest for Amazon EBS by default」、「Disallow Internet connection through SSH」。在受監管行業的 SecOps 團隊通常全部開啟。
• Elective 控制項 — 針對特定合規框架的自選項目。例如：「Disallow Amazon S3 buckets without versioning」、「Require an Amazon S3 bucket to have replication enabled」、「Disallow Amazon EC2 instances from creating an Elastic IP」。

除了 Control Tower 自己的目錄，統一的 Controls Catalog 還公開了 Security Hub 框架控制項（NIST 800-53、PCI-DSS、CIS），你可以在每個 OU 層級啟用。SCS-C02 關於「透過 Control Tower 在組織範圍套用 NIST 800-53 控制項」的題目，就是指這個統一目錄。

預防性 vs 偵測性 vs 主動性——底層實作

每個 Control Tower 控制項也依執行方式分類。這是考生最常遺漏的部分：

• **Preventive（預防性）**控制項是 Control Tower 掛載到 OU 的 SCP。它們直接封鎖不合規的 API 呼叫。例如：「Disallow deletion of log archive」是以 deny SCP 實作，針對 log bucket 的 s3:DeleteBucket。
• **Detective（偵測性）**控制項是在資源建立後標記不合規資源的 AWS Config 規則。例如：「Detect whether public read access to S3 buckets is allowed」是一條 Config 受管規則，將不合規發現發送至 Config 聚合器和 Security Hub。
• **Proactive（主動性）**控制項是在 CREATE/UPDATE 期間、資源實際存在之前評估範本的 CloudFormation Hook。例如：「Require encryption on new RDS DB instances」是一個主動 hook，若加密未設定則讓堆疊操作失敗。

Drift（偏移）是一個事件信號

Control Tower 中的 Drift 意味著有人在系統外變更了登陸區狀態：SCP 被移除、OU 成員結構被更改、Log Archive bucket 政策被修改、Config 記錄器被停止。從 SecOps 角度，drift 本身就是一個可能的 IoC——持有竊取管理員憑證的攻擊者試圖在資料竊取前削弱控制。

架構模式為：

1. Root 層級的稽核防竄改 deny SCP（上方模式 A）從源頭防止最具破壞性的 drift。
2. Control Tower drift 偵測持續運行並呈現 drift 發現。
3. 在 aws.controltower drift 事件上設置的 EventBridge 規則，路由至 SNS / Slack / PagerDuty 供 SecOps 告警。
4. Systems Manager Automation runbook 在確認 drift 未獲授權後，重新加入 OU 或還原設定。

委派管理員——將安全工具移出管理帳號

在 SCP 之後，SCS-C02 多帳號策略中最重要的概念是委派管理員。AWS Organizations 允許成員帳號代表組織接管整合 AWS 服務的管理。Audit（Security Tooling）帳號成為 SecOps 團隊的作業中心，無需任何人持有管理帳號憑證。

支援委派管理員的服務（必知清單）

考試期望你認識以下所有服務都支援委派管理員：

• Amazon GuardDuty — 集中探測器管理、成員帳號自動加入、威脅發現聚合。
• AWS Security Hub — 全組織發現聚合、框架標準啟用、跨區域發現聚合。
• Amazon Macie — 全組織 S3 敏感資料探索、允許清單與自訂資料識別器管理。
• Amazon Detective — 跨組織聚合 CloudTrail、VPC Flow Logs、GuardDuty 發現的圖形資料庫。
• Amazon Inspector — 全組織 EC2/ECR/Lambda 漏洞掃描。
• AWS IAM Access Analyzer — 全組織外部存取分析器加上未使用存取分析。
• AWS Config — 多帳號多區域合規證據的組織聚合器。
• AWS Audit Manager — 跨組織的集中證據收集。
• AWS Firewall Manager — 全組織 WAF、Shield Advanced、Network Firewall、安全群組規則。
• AWS Backup — 全組織備份計畫與 Vault Lock。
• AWS CloudFormation StackSets（服務管理式）— 全組織基礎設施部署。
• AWS Systems Manager（Quick Setup）— 全組織修補基準。

標準分配，也反映於 AWS Security Reference Architecture (SRA)：

• Audit / Security Tooling 帳號 — GuardDuty、Security Hub、Macie、Detective、Inspector、IAM Access Analyzer、Audit Manager、Config 聚合器的委派管理員。
• Network 帳號 — Firewall Manager 的委派管理員。
• Log Archive 帳號 — 接收 CloudTrail 組織追蹤與 Config 快照；本身不是委派管理員。

為何這在事件應變時至關重要

凌晨 02:14 收到告警，你登入 Audit 帳號（透過 IAM Identity Center，搭配 MFA）。從那裡：

• 你在一個主控台讀取整個組織的所有 GuardDuty 發現。
• 你查詢 Security Hub，取得最高嚴重等級的有效發現。
• 你進入 Detective，追蹤主體過去 30 天的行為。
• 你查詢 Config 聚合器，找出組織中每個具有相同漏洞設定的帳號。
• 你可選地觸發一個 Lambda runbook（透過 StackSets 部署至每個帳號），隔離被入侵的資源。

這一切都不需要碰觸管理帳號。也不需要你在每個成員帳號中持有管理員 IAM——委派管理員模式透過整合服務的服務連結角色，授予 Audit 帳號主體必要的跨帳號讀寫介面。

AWS Config 聚合器作為全組織合規證據

AWS Config 聚合器是將多帳號組織轉變為可查詢清冊的單一工具。它運行於 Audit 帳號（委派管理員），從每個受管區域的每個帳號拉取組態項目與規則合規狀態，並透過聚合器的查詢、進階查詢 SQL，以及它驅動的 Security Hub Insights 公開這些資訊。

設定模式

1. 從管理帳號，將 Audit 帳號登記為 Config 委派管理員。
2. 在 Audit 帳號中，以 AWS Organizations 作為來源建立 Config 聚合器（一鍵點選——自動探索每個區域的每個帳號）。
3. 透過具有服務管理式權限的 CloudFormation StackSets，在每個成員帳號大規模啟用 Config 記錄器（若已使用 Control Tower，其強制基準線已完成此步驟）。
4. 集中定義組織 Config 規則；規則自動傳播至每個帳號。
5. 透過 EventBridge 將 Config 規則不合規事件接通至 Security Hub（或直接接通至你的 SIEM）以供告警。

SCS-C02 出現的使用案例

• 「找出組織中所有未加密的 S3 bucket」——針對聚合器執行單一 Config 進階查詢。
• 「向稽核員證明 us-east-1 中 100% 的 EC2 執行個體已強制 IMDSv2」——聚合器查詢加 CSV 匯出。
• 「偵測艦隊中任何允許 0.0.0.0/0 在 port 22 的安全群組」——全組織評估的 Config 受管規則 restricted-ssh。
• 「SOC 2 稽核的持續證據」——Config 聚合器 + 使用 Config 證據來源的 Audit Manager 評估。

聚合器與 Security Hub（發現）和 Audit Manager（證據包）配對，形成全組織的合規鐵三角。深度覆蓋請見 compliance-evaluation-config-auditmanager 主題。

全組織的 Root 帳號強化

SCS-C02 task 6.1 明確將「保護 AWS 帳號 root 帳號憑證」列為技能。每個成員帳號都有一個 root 帳號，預設具有完整的無條件權力。安全工程師的工作是讓 root 在實質上無法使用，除了少數只有 root 能執行的操作（關閉帳號、更改帳號電子郵件、恢復已刪除的 KMS 加密 S3 bucket）。

Root 的三層防禦

1. 預防性——root 帳號 deny SCP（上方模式 C）。成員帳號的任何 root API 呼叫都回傳 AccessDenied。管理帳號的 root 仍在運維層面管控。
2. 預防性——Control Tower 強烈建議控制項「Require MFA for the root user」。主控台登入頁面在未設定 MFA 的情況下拒絕任何嘗試。管理帳號 root 搭配硬體安全金鑰使用。
3. 偵測性——CloudTrail 事件過濾 userIdentity.type == "Root"。將組織追蹤中的任何符合事件（透過 CloudWatch Logs 訂閱過濾器）轉送至 CloudWatch 警報、EventBridge 規則和 SNS 主題，讓 SOC 即時看到每次 root 帳號使用。

對於新帳號，AWS Organizations 集中管理 root 帳號憑證（2024 年底推出）讓管理帳號能從每個成員帳號完全移除 root 帳號的密碼與 IAM 憑證，讓 root 只能透過登記電子郵件的密碼恢復程序觸達。SCS-C02 題目框架為「如何在組織層級消除各帳號 root 憑證問題？」就是指向這個功能。

SecOps 與鑑識的跨帳號 Role

跨帳號 role 是多帳號安全運維的基礎。考試指南知識點「cross-account roles」並非在問 Associate 等級的 sts:AssumeRole；它在問 SecOps 工程師使用的模式：

• 唯讀稽核者 role，在每個帳號中，信任 Audit 帳號，供 Security Hub 自訂整合和 Athena 跨帳號查詢使用。
• 事件應變 role，在每個帳號中，信任 Audit 帳號的回應者主體，並帶有將其限制在隔離動作的權限邊界（修改安全群組、快照 EBS、替換被入侵執行個體上的 IAM role 政策）。
• 鑑識擷取 role，信任專用的 Forensics 帳號，具備跨帳號複製 EBS 快照至 Forensics 帳號加密快照儲存區，以及從 Log Archive S3 複製 CloudTrail/VPC Flow Logs 至 Forensics S3 bucket 的權限。
• Break-glass role，在管理帳號中，信任硬體 MFA 保護的安全主體，僅用於全組織緊急操作（登記新的委派管理員、修改 root 層級 SCP）。每次假設此 role 都會觸發 SOC 告警。

透過具有服務管理式權限的 CloudFormation StackSets，以組織 root 為目標統一部署這些 role，讓新建立的帳號自動繼承它們。這是多帳號版的「每台伺服器有相同的 SSH 金鑰設定」，也是讓凌晨 02:14 的跨帳號鑑識真正可行的關鍵。IaC 部署模式請交叉參照 secure-deployment-iac-firewallmanager 主題。

圍堵被入侵帳號——多帳號的槓桿

把所有部分組合起來。假設告警是真實的：帳號 123456789012 有一個被入侵的 IAM role 正在滲出 S3 物件。從 Audit 帳號，你有以下多帳號槓桿，依優先順序排列：

1. 將帳號移至 Suspended OU（或專用的 Quarantine OU）。掛載在那裡的全拒絕 SCP 讓帳號中所有主體的每次 API 呼叫在數秒內開始失敗。這是最高槓桿率的第一個動作。
2. 透過 IR role 進入帳號，套用一份 quarantine IAM role 政策，明確拒絕可疑主體的 s3:*、kms:*、iam:CreateAccessKey 與 sts:AssumeRole——以防 SCP 移動有延遲的縱深防禦。
3. 從 Audit 帳號的委派管理員 GuardDuty 主控台，審查過去 24 小時該帳號及相關主體的發現。
4. 從 Detective，以主體為起點，追蹤它存取的資源和呼叫的 IP。
5. 從 Forensics 帳號，快照相關的 EBS 磁碟區，並從 Log Archive 複製 S3 存取日誌（組織追蹤的 S3 bucket）。
6. 從 Config 聚合器，查詢組織中每個具有相同危險設定的其他帳號（例如被濫用的同一個 OIDC 信任政策），以便主動修補兄弟帳號。
7. 更新稽核防竄改 deny SCP，若在事件中發現了新的濫用路徑。

步驟 1、3、4、5、6 只有因為本主題所涵蓋的多帳號控制平面才得以實現。沒有它，你就得透過管理帳號憑證逐一串行執行所有七個步驟，既更慢又是新的風險來源。

常見陷阱——SCS-C02 多帳號策略

陷阱 1：從管理帳號執行安全工具

考試會提供「在管理帳號建立 IAM role 供安全團隊假設」的答案。這是錯的。使用委派管理員並從 Audit 帳號操作。

陷阱 2：相信 SCP 單獨能防禦外部存取

SCP 約束的是成員帳號內部的主體。它不約束被你帳號 S3 bucket 政策允許的第三方 AWS 帳號。要封閉這個漏洞，資源政策需要設置 aws:PrincipalOrgID 條件。相同的思路，兩個政策位置。

陷阱 3：Deny+NotAction 作為允許清單

{"Effect":"Deny","NotAction":["s3:*"]} 拒絕所有非 S3 的動作——包括 IAM、KMS、CloudTrail。安全的允許清單做法是 {"Effect":"Allow","Action":[核准的動作]} 搭配移除 FullAWSAccess。Deny+NotAction 只在與條件（區域、principal-org-id）搭配，縮限 deny 範圍時才使用。

陷阱 4：混淆 Control Tower 控制項類別

Mandatory ≠ Strongly recommended ≠ Elective。聲稱「所有 Control Tower mandatory 控制項都涵蓋 NIST 800-53」的答案選項是錯的：NIST 800-53 對應在統一 Controls Catalog 中，疊加在上方並使用 Security Hub 框架控制項。

陷阱 5：假設 Control Tower 涵蓋應用程式資源偏移

Control Tower drift 偵測涵蓋登陸區自身的狀態。應用程式資源偏移（開發人員手動編輯安全群組、工作負載 S3 bucket 被公開）是 AWS Config 的工作，不是 Control Tower 的。兩者都要接線。

陷阱 6：在組織中使用自管式 StackSets

若帳號在啟用 Organizations 的組織中，服務管理式權限加自動部署才是正確答案。自管式只在跨組織或非組織目標時才正確。

陷阱 7：假設可以遷移 Control Tower 登陸區區域

Control Tower 主區域在登陸區建立時設定，無法更改。你可以新增或移除受管區域，但 Log Archive 與 Audit 帳號始終錨定在主區域。

陷阱 8：忘記管理帳號忽略 SCP

我們已說了兩次，因為考試要考三次。

決策矩陣——多帳號安全目標對應控制

常見問題——SCS-C02 多帳號策略

Q1：組織中有個帳號疑似遭到入侵。影響整個帳號（而非單一資源）最快速的圍堵動作是什麼？

將帳號移至已掛載全拒絕 SCP 的專用 Quarantine 或 Suspended OU。SCP 在 IAM 政策之前評估，因此在數秒內，該帳號所有主體的每次 API 呼叫都開始回傳 AccessDenied。這停止了進一步的資料滲出、阻止攻擊者建立新的 IAM 存取金鑰、阻止他們修改 CloudTrail。接著，在帳號實質上凍結的情況下，你進行詳細分類：將 EBS 快照拉入 Forensics 帳號、查詢 Detective 以了解主體行為、透過 Athena 查詢 Log Archive bucket 的歷史活動，並在 IR 計畫要求時，只透過 SCP 例外選擇性地重新啟用特定動作。交叉參照：incident-response-isolation-forensics。

Q2：為什麼「透過委派管理員在 Audit 帳號集中安全工具」幾乎總是 SCS-C02 的正確答案？

三個原因。第一，爆炸半徑：若 SecOps 工程師在管理帳號中有 IAM，任何被釣魚的憑證都可能摧毀整個組織。委派管理員讓管理帳號遠離日常人員活動。第二，最小權限：整合服務的服務連結角色授予的跨帳號範圍恰好是所需的（讀取 GuardDuty 發現、寫入 Security Hub 設定），不多也不少。第三，規模：從委派管理員為整個組織啟用 Security Hub 或 GuardDuty 只需一次點擊，並自動延伸至包含未來帳號在內的每個成員帳號；逐帳號操作在超過幾個帳號後就無法擴展。在答案選項中，建議把 SecOps 工作路由到管理帳號的，是在測試你是否知道要避免這個反模式。

Q3：Control Tower mandatory 控制項如何與 PCI-DSS 或 NIST 800-53 等合規框架關聯？

Mandatory 控制項保護登陸區本身——它們並非針對任何外部合規框架設計的。Strongly recommended 控制項涵蓋廣泛的衛生實務（不公開日誌 bucket、root 使用 MFA、預設靜態加密）。若要對應特定框架，你要在 Control Tower 的統一 Controls Catalog 中，在 OU 層級啟用該框架的 Security Hub 標準（PCI-DSS、NIST 800-53 Rev 5、CIS AWS Foundations Benchmark、AWS Foundational Security Best Practices）。Audit Manager 接著收集那些 Security Hub 控制項產生的證據。因此分層是：Control Tower mandatory + strongly-recommended（你的底線）→ Security Hub 框架標準（你的合規姿態）→ Audit Manager 評估（你給稽核員的證據包）。

Q4：我們有 50 個帳號，稽核員要求證明每個 S3 bucket 都已啟用 Block Public Access。如何生成這份證據？

使用 Audit 帳號中的 AWS Config 聚合器（委派管理員）。查詢聚合器中的受管 Config 規則 s3-bucket-level-public-access-prohibited（SELECT accountId, resourceId, configuration.publicAccessBlockConfiguration FROM aws:s3:bucket WHERE ...），或直接拉取規則的合規狀態報告。聚合器每個帳號每個 bucket 回傳一筆資料列，附帶合規狀態。匯出為 CSV，附上作為稽核證據。若要跨多個 bucket 和框架持續收集證據，使用以 AWS Config 為證據來源的 Audit Manager 評估，定期自動執行相同查詢並將結果打包成框架特定報告。SCP 和 Control Tower elective 控制項增加了預防性後盾，阻止開發人員在第一時間停用 Block Public Access。

Q5：Sandbox 帳號中的開發人員提了一個支援案，抱怨他們無法為一個快速測試啟動 g5.12xlarge GPU 執行個體。IAM 政策明確允許 ec2:RunInstances。為何呼叫失敗？

Sandbox OU 可能有一個允許清單 SCP，移除了 FullAWSAccess 並只列出低成本服務，或者有一個使用 ec2:InstanceType 條件封鎖昂貴執行個體系列的 deny SCP。SCP 在 IAM 政策之前評估，所以即使寬鬆的身分型允許也無法解鎖該動作。透過 CloudTrail 走查評估鏈來確認：失敗的 RunInstances 事件中，DENIED 決策附帶 AccessDenied 以及指向 SCP 的原因碼。正確回應取決於政策：在允許清單允許 GPU 的帳號中執行實驗、仔細更新 Sandbox SCP（搭配標籤條件如 Experiment: GPU 加上對應的預算告警），或拒絕請求因為 Sandbox 本就不適合 GPU 實驗。普遍的教訓：當考試情境說「IAM 允許 X 但呼叫失敗」，首先懷疑 SCP，其次是權限邊界，再來是資源政策或工作階段政策。交叉參照：SCS-C02 上每道多帳號授權失敗題目都可歸結為走查這條梯子。

Q6：我可以在沒有 AWS Control Tower 的情況下使用 AWS Organizations 與 SCP 嗎？

可以。AWS Organizations 是底層服務；Control Tower 帶著自見解坐在上面。許多安全成熟的組織透過 AWS Control Tower Account Factory for Terraform (AFT) 或自訂 IaC pipeline 執行 Terraform 管理的登陸區，並直接使用 Organizations 管理 SCP、委派管理員和 Config 聚合器。這些組織仍能獲得完整的 SCP、標籤政策、備份政策、AI 退出、聊天機器人政策和委派管理員介面——這些都是 Organizations 的功能。他們只是自行建立 Log Archive / Audit 帳號拓撲和控制項目錄，而非接受 Control Tower 的預設值。對於 SCS-C02，當情境說「安全團隊想要最快路徑建立受管最佳實務基準線」，答案是 Control Tower；當情境說「安全團隊想要 Terraform 驅動的基礎設施，沒有 AWS 管理的自見解」，答案是 Organizations 搭配 AFT 或自訂 IaC。

Q7：如何防止成員帳號中的特權使用者在攻擊期間停用 GuardDuty 或 Security Hub？

兩層防禦。第一，在組織 root 設置稽核防竄改 deny SCP，拒絕 guardduty:DeleteDetector、guardduty:DisassociateFromMasterAccount、securityhub:DisableSecurityHub、securityhub:DisassociateFromMasterAccount，加上類似的 Macie、Detective、Inspector 停用動作。即使成員帳號管理員也無法繞過，因為 SCP 在 IAM 之上評估。第二，由於這些服務是在 Audit 帳號的委派管理員下設定的，只有 Audit 帳號中的主體（具備必要的 IAM 權限）才能在組織層級停用它們——成員帳號管理員根本沒有可呼叫的委派介面。兩層都要搭配 Control Tower drift 偵測告警，以及對停用 API 名稱的 CloudTrail 指標過濾器，讓任何嘗試（即使被拒絕的）都能生成 SOC 告警。交叉參照：threat-detection-guardduty-securityhub。

Q8：Control Tower 預防性控制項與我自己撰寫的 deny SCP 有什麼差異？

在機制上沒有差異——Control Tower 預防性控制項就是 SCP。差異在於運維。Control Tower 控制項在 Controls Catalog 中是有名稱、有版本、由 AWS 維護的：它在 Control Tower 主控台中顯示，附帶描述、意圖和合規證據，且 AWS 會隨著威脅環境變化更新它。自行撰寫的 SCP 由你自己維護——你撰寫 JSON、掛載、進行版本控制，稽核員必須相信你對它做了什麼的說詞。對於廣泛適用的控制（拒絕停用 CloudTrail、拒絕公開 S3 bucket），優先使用 Control Tower 控制項，因為你可以免費獲得維護和稽核對應。對於組織特定的風險（拒絕我們特定的 KMS 金鑰被刪除、拒絕未核准的執行個體系列），自己撰寫 SCP。大多數組織最終兩者混用，Control Tower 目錄加上你的自訂 SCP 一起構成完整的預防層。

延伸閱讀

• AWS Organizations User Guide
• Service Control Policies
• SCP Evaluation Logic
• SCP Strategies and Examples
• AWS Control Tower User Guide
• Control Tower Controls (Guardrails) Reference
• Control Tower Drift Detection
• AWS Services that Integrate with Organizations (delegated admin list)
• Managing GuardDuty Multi-Account
• Managing Security Hub Multi-Account
• Managing Macie Multi-Account
• Managing Detective Multi-Account
• Config Multi-Account Multi-Region Aggregation
• AWS Account Root User
• Organizing Your AWS Environment Using Multiple Accounts (Whitepaper)
• AWS Security Reference Architecture (SRA)
• AWS SCS-C02 Exam Guide