跨帳號安全控制（Cross-Account Security Controls）是架構師在整個 AWS Organizations 中強制執行最小權限、偵測威脅、並向稽核人員提供合規證明的架構模式、政策層次與集中化服務集合——不是只針對單一帳號，而是覆蓋每一個帳號。在 SAP-C02 考試的 Task 1.2「規定安全控制（Prescribe security controls）」中，測試的重點是你是否能夠將跨帳號 IAM 角色、KMS 金鑰政策、SCP、Permission Boundary，以及 GuardDuty、Security Hub、AWS Config、Macie、Audit Manager、IAM Access Analyzer 等服務的委派管理員功能，整合成一套連貫且可稽核的安全模型。跨帳號安全控制是多帳號治理（帳號結構）與工作負載安全（帳號內部護欄）的交會點，而考試最容易懲罰的，正是那些搞混「哪一層在執行什麼」的考生。
本 Pro 深度指南涵蓋你將在 SAP-C02 中遭遇的所有跨帳號安全控制：使用 aws:PrincipalOrgID、aws:SourceAccount 及 ExternalId 混淆代理人防禦的信任政策機制；允許跨帳號使用的 KMS 金鑰政策及 Grant 機制；三層授權模型（SCP、身份政策、資源政策、Permission Boundary、Session Policy）及其評估順序；GuardDuty、Security Hub、Config、Macie 搭配委派管理員的全組織佈署；以及 IAM Access Analyzer 的三項互補工作——外部存取偵測、未使用存取偵測、政策生成——在組織信任區（zone of trust）內的運作方式。讀完本文，你將能夠看著一個 200 帳號的情境，精確開出考題要求的跨帳號安全控制組合。
什麼是跨帳號安全控制？
跨帳號安全控制是 AWS 客戶在 AWS Organizations 內的多個帳號中強制實施一致安全姿態的一套身份、資源政策與集中偵測機制。它們在四個不同的層次上運作：身份層（IAM 角色、信任政策、Permission Boundary、Identity Center 權限集）、資源層（KMS 金鑰政策、S3 儲存桶政策、Lambda/SNS/SQS/Secrets Manager 的資源型政策）、預防層（OU 上的 Service Control Policies）、以及偵測/聚合層（GuardDuty、Security Hub、Config、Macie、Access Analyzer 搭配委派管理員）。
為什麼跨帳號安全控制對 SAP-C02 至關重要
SAA-C03 的單帳號 IAM 知識在 Professional 考試中是不夠用的。SAP-C02 Task 1.2 的題幹幾乎都把情境放在一個擁有 50 個以上帳號的 Organizations 中，其中包含共用服務、安全工具、Log Archive 及工作負載等 OU。考試測試的是你能否開出不需要逐帳號手動設定的跨帳號安全控制。這句話——「不需要逐帳號手動設定」——是答案涉及委派管理員、全組織聚合器或 RAM 共用 KMS 金鑰的明確訊號。
跨帳號安全控制在 Landing Zone 中的位置
在 Control Tower 或自訂 landing zone 中，跨帳號安全控制主要存在於兩個帳號：Security/Audit 帳號（GuardDuty 委派管理員、Security Hub 聚合器、Config 聚合器、Macie 管理員、Access Analyzer 組織分析器、Audit Manager）和 Log Archive 帳號（集中式 S3 儲存桶，搭配授予成員 CloudTrail 及 Config 跨帳號寫入的儲存桶政策）。兩個帳號均受 SCP 保護，防止工作負載管理員竄改安全發現或日誌目的地。
白話文解釋 Cross-Account Security Controls
跨帳號安全控制聽起來很抽象，但三個貼近日常的類比能讓它具體化。每個類比都呈現跨帳號安全控制不同的特性，請全部讀完。
類比一：社區管委會保全系統（大樓 / 社區類比）
把整體架構想像成台灣一棟有 200 戶的大型社區。每一戶就是一個 AWS 帳號；整棟大樓是 AWS Organizations；管理委員會是管理帳號。跨帳號安全控制就是管委會建置的全棟共用系統，讓安全不必仰賴每戶自行安裝。
萬用門禁卡是跨帳號 IAM 角色——大樓總幹事持有一張門禁卡，憑著正確的信任關係可以進入任何住戶的機房。信任政策是書面規定，說明哪些住戶的鎖可以接受這張卡；ExternalId 是第二道驗證，要求總幹事公司在每次刷卡時輸入專屬代碼，確保即使離職員工偷走門禁卡，也無法單憑那張卡開任何一扇門。大樓保全監控中心是搭配委派管理員的 GuardDuty——單一中控室接收每一戶的煙霧偵測、移動感應、強行開門等所有警報。大廳公告欄的合規看板是 Security Hub——一張顯示「200 戶中有 3 戶未通過煙霧偵測器檢查」的計分卡。維修巡查員是搭配 conformance packs 的 AWS Config——逐戶檢查每一戶的滅火器是否充壓。文件保管員是 Audit Manager——彙整可交給政府檢查員的稽核證據。最後，閒置門禁卡稽查員是 IAM Access Analyzer 未使用存取功能——每個月有人審查哪些大樓工作人員持有 90 天都沒用過的門禁卡，並予以停用。
類比二：全國性統一考試的監考體系（考試 / 測驗類比）
想像一場在全台各縣市都設有考場的全國統一考試。每個考場是一個 AWS 帳號；全國考試院是管理帳號；考生是工作負載。跨帳號安全控制就是考試院在不派員駐場的情況下，如何保證每個考場的考試完整性。
監考員憑證是跨帳號 IAM 角色，任何授權的考試管理員都能承擔它——信任政策說「我信任全國考試院帳號」，aws:PrincipalOrgID 說「但只有當呼叫者仍在我們的官方組織內」，ExternalId 則阻止第三方廠商對考場發動混淆代理人攻擊。考試規則手冊是 SCP——考試院發給每個考場一本規定冊：「不得在核准區域外進行考試、不得關閉攝影機、未經核准不得採用新試題格式。」全場即時監控網路是 GuardDuty——每個考場的攝影機訊號匯入由擁有委派管理員權限的安全團隊負責的同一個監控室。每日成績單是 Security Hub FSBP/PCI 合規——每個考場依照相同評分標準計分，聚合器讓考試院看到單一全貌。逐一掃描答案卷尋找外洩個資的模式辨識稽查員是 Macie。符合法規的存檔要求是 Audit Manager，它自動將 CloudTrail、Config、Security Hub 的證據打包成 SOC 2 / PCI / HIPAA 框架報告。這些跨帳號安全控制合力讓考試院無需親臨現場，即可向監管機關證明數百個考場的考試完整性。
類比三：捷運路網的營運控制系統（基礎建設 / 公共設施類比）
想像一個擁有 150 個站點的都會捷運路網。每個站點是一個 AWS 帳號。跨帳號安全控制就是讓單一行控中心得以管理所有 150 個站點、不需派員常駐每站的防護機制。
各站出入憑證是跨帳號 IAM 角色，信任政策決定行控中心哪些人員可以承擔它。Permission Boundary 是員工憑證上的電路保護器額定值——即使有人的職務說明寫得比較寬泛，憑證本身也無法通過超出邊界允許的電流。SCP 是主管機關強制施加於每個站點的安全法規，無論現場操作員的意願為何——任何人不得繞過停電隔離程序，不得在核准路線以外營運。KMS 金鑰政策是通往受保護設備機櫃的鑰匙；機櫃鑰匙可以明確授權給另一個站點（跨帳號金鑰政策），或透過 KMS Grant 機制進行短期委派（供另一個 AWS 服務短暫使用）。路網 SCADA 監控系統是 GuardDuty、Security Hub、Config 聚合器的組合——每個站點的感測器數據流匯入同一個行控室。閒置授權清查是 Access Analyzer 未使用存取功能——90 天內未開過任何機櫃的憑證自動撤銷。這些跨帳號安全控制讓 150 個站點如同一個安全路網一般運作。
三層授權模型 — SCP vs IAM vs Permission Boundary vs Resource Policy
SAP-C02 上最常被考到的跨帳號安全控制概念，就是當多種政策類型同時作用於同一個 API 呼叫時的評估順序。請熟記它。
第 0 層 — 組織層的 SCP
Service Control Policies 附加於 root、OU 或帳號。SCP 從不授予權限；它們定義受影響帳號中所有 principal 的最大可用權限。如果 SCP 拒絕 s3:DeleteBucket，任何身份政策、Permission Boundary 或資源政策都無法恢復它。管理帳號豁免於 SCP——這是常見的陷阱，考生往往以為 SCP 普遍適用。
第 1 層 — Principal 上的 Permission Boundary
Permission Boundary 是附加於使用者或角色的 IAM 受管政策，用來限制身份政策所能授予的權限上限。與 SCP 相同，Permission Boundary 本身不授予任何權限。它讓中央安全團隊得以允許工作負載開發人員自行建立 IAM 角色，而不必擔心他們會提升自己的權限——開發人員的 IAM 角色附加一個 Permission Boundary，規定「你建立的角色絕對不能授予 IAM 管理員、停用 CloudTrail，或執行 organizations:LeaveOrganization。」
第 2 層 — 身份政策（Principal 上的 IAM Policy）
附加於呼叫使用者或角色的身份政策是主要的授予介面。有效權限是身份政策、SCP 與 Permission Boundary 的交集，任一層的明確 Deny 都具有決定性效力。
第 3 層 — 目標上的 Resource Policy
資源型政策（S3 儲存桶政策、KMS 金鑰政策、SNS 主題政策、SQS 佇列政策、Lambda 資源政策、Secrets Manager 密鑰政策）在同帳號存取的情況下，即使 principal 的身份政策沒有對應授權，也能授予存取。但對於跨帳號存取，雙方都必須允許：呼叫帳號的身份政策必須允許該動作，目標帳號的資源政策也必須允許呼叫者。
第 4 層 — AssumeRole 上的 Session Policy
當 principal 呼叫 sts:AssumeRole 時，呼叫者可以傳入一個僅限本次 session 生效的內嵌 Session Policy，進一步限縮所承擔角色的權限。Session Policy 是角色權限與 Session Policy 的交集——它無法擴大權限。
典型評估範例
假設 dev 帳號的 Lambda 嘗試讀取 data 帳號 S3 中以 data 帳號 KMS 金鑰加密的物件：
- dev 帳號的 SCP 不得拒絕
s3:GetObject或kms:Decrypt。 - Lambda 執行角色（身份政策）必須允許對儲存桶 ARN 執行
s3:GetObject、對金鑰 ARN 執行kms:Decrypt。 - data 帳號的儲存桶政策必須允許 Lambda 角色 principal 執行
s3:GetObject。 - data 帳號的 KMS 金鑰政策必須允許 Lambda 角色 principal 執行
kms:Decrypt。 - 如果 data 帳號的 SCP 拒絕組織外的
s3:GetObject，則呼叫者必須在組織內（透過aws:PrincipalOrgID確認）。
共五份政策。五份必須同時同意。任何一個明確的 Deny 都會終止請求。
跨帳號存取要求雙方都允許。 與同帳號存取（大多數服務僅靠資源政策或身份政策其中一個即可）不同，跨帳號存取需要呼叫者的身份政策以及目標的資源政策都明確允許。唯一例外是 IAM 角色：目標角色的信任政策取代了資源政策的角色。任一方缺少允許都會產生 AccessDenied，而且極難偵錯。排查跨帳號安全控制問題時，務必同時檢查雙方。
跨帳號 IAM 角色架構
跨帳號 IAM 角色是跨帳號安全控制的原子單位。每一個聯合登入、每一條跨帳號的 CI/CD pipeline、每一個第三方 SaaS 整合，最終都會對目標帳號的角色呼叫 sts:AssumeRole。
信任政策的解剖
信任政策是附加於 IAM 角色的資源政策。它指定哪些 principal（IAM 使用者、IAM 角色、AWS 服務、SAML 提供者、Web Identity 提供者或整個帳號）可以對這個角色呼叫 sts:AssumeRole（或 sts:AssumeRoleWithSAML、sts:AssumeRoleWithWebIdentity）。Principal 元素是區分同帳號與跨帳號信任關係的關鍵。
跨帳號安全控制的信任政策條件
三個條件鍵是強化跨帳號信任政策的主力：
aws:PrincipalOrgID 將呼叫者限制為特定 AWS Organizations 內的任何 principal。設定 "aws:PrincipalOrgID": "o-abc123xyz" 意味著只有主帳號屬於該組織成員的呼叫者才能承擔此角色。這是組織內共用跨帳號 IAM 角色最重要的護欄——它確保即使信任政策意外將外部帳號列入白名單，角色也無法被承擔。
aws:SourceAccount 和 aws:SourceArn 適用於 AWS 服務信任的場景。當 AWS 服務（S3 儲存桶通知、SNS、EventBridge）承擔角色以呼叫你的帳號時，加入 SourceAccount 條件可防止混淆代理人問題——即另一個客戶的 S3 儲存桶觸發你帳號中的動作。對於服務對服務的跨帳號存取，務必將 aws:SourceAccount 固定為觸發資源所在的帳號。
sts:ExternalId 是防禦第三方 SaaS 情境中混淆代理人攻擊的機制。監控廠商需要承擔你帳號中的角色以讀取 CloudWatch 指標。若沒有 ExternalId，廠商的共用角色可能被另一個客戶欺騙，進而承擔你的角色。你產生一個唯一的 ExternalId，與廠商共用，並在信任政策中要求它。如此一來，你的角色只接受攜帶該特定 ExternalId 值的 sts:AssumeRole 呼叫，防止跨租戶偽造。
ExternalId — 混淆代理人防禦
混淆代理人問題的運作方式如下：第三方 SaaS 廠商在其端持有一個單一 IAM 使用者，用來 AssumeRole 進入所有客戶的帳號。如果攻擊者 Alice 知道客戶 Bob 的角色 ARN，並能欺騙廠商以 Bob 的 ARN 呼叫 AssumeRole，那麼從 Bob 的角度來看，廠商的信任（廠商帳號被列入白名單）就會成功。ExternalId 封堵了這個漏洞：Bob 的信任政策要求一個唯一的密鑰值，廠商按客戶儲存該值。Alice 無法產生 Bob 的 ExternalId，因此詭計失敗。
ExternalId 僅用於第三方存取；對於同組織內的跨帳號角色，正確的防禦方式是 aws:PrincipalOrgID。混淆兩者是常見的 SAP-C02 陷阱——考試會問「對於同一組織內另一個帳號承擔的角色，是否需要 ExternalId？」答案是否定的。
基於 Principal vs 基於 Resource 的跨帳號存取
部分 AWS 服務支援資源型政策，可直接授予跨帳號存取，無需透過信任政策角色承擔：S3、KMS、SNS、SQS、Lambda、Secrets Manager、API Gateway、ECR、EventBridge、CodeArtifact、Backup vaults、Glacier 以及 EFS。其他服務則需要角色承擔：DynamoDB、RDS、EC2、Systems Manager Parameter Store 標準層。架構選擇很重要——資源政策可以擴展到眾多呼叫者，無需每個呼叫者各自建立一個角色；但角色提供 session 層級的可稽核性（每次 AssumeRole 呼叫都會以唯一 session 形式出現在 CloudTrail 中）。
ExternalId 是給第三方用的，不是給組織內部的跨帳號存取用的。 考生常常把 ExternalId 過度套用到每一個跨帳號信任政策上。在你自己的 Organizations 內部，正確的護欄是 aws:PrincipalOrgID，它確保呼叫者仍是組織成員（帳號一旦離開組織就自動失去存取權）。ExternalId 是專為持有單一身份、服務多個客戶的 SaaS 廠商設計的——用來防止廠商端的跨租戶混淆。請針對正確的威脅模型使用正確的工具。
KMS 金鑰政策與跨帳號加密
KMS 是跨帳號安全控制中特別棘手的服務，因為 KMS 要求金鑰政策明確允許外部 principal——不像大多數 AWS 服務，同帳號存取時僅靠 IAM 政策就已足夠。
KMS 金鑰政策基礎
每個 KMS 金鑰只有一份金鑰政策。預設情況下，金鑰政策只包含擁有帳號的根作為受信任 principal，意味著該帳號的 IAM 政策可以委派使用權。對於跨帳號使用，你必須在金鑰政策中新增外部帳號（或其中特定的角色）。外部帳號的身份政策以及擁有帳號的金鑰政策都必須允許 KMS 動作。
標準跨帳號 KMS 模式
data-lake 帳號擁有一個 KMS 金鑰，用來加密 S3 中的物件。消費者帳號需要解密這些物件。金鑰政策新增一個敘述，例如："Principal": {"AWS": "arn:aws:iam::CONSUMER-ACCOUNT:role/DataReaderRole"}，"Action": ["kms:Decrypt", "kms:DescribeKey"]。消費者帳號也對 DataReaderRole 附加身份政策，授予相同動作於該金鑰 ARN。當消費者帳號的 Lambda 讀取物件時，S3 透明地呼叫 KMS Decrypt；呼叫會穿越兩份政策，兩者都必須允許。
KMS Grant 用於服務層級委派
KMS Grant 是通常由 AWS 服務（EBS、RDS、Aurora、DynamoDB、FSx）在代表 IAM 使用者解密時發出的短期委派。Grant 可避免為每次服務互動而編輯金鑰政策。Grant 可撤銷、可退役、可在 CloudTrail 中稽核，並限制允許的操作（加密情境、Grant 限制條件）。在 SAP-C02 考試中，Grant 出現於以下情境：另一個區域的 Aurora Global Database 副本需要加密存取，而無需每次新增副本都編輯金鑰政策。
KMS 多區域金鑰（MRK）
多區域金鑰是在跨區域間共用相同金鑰 ID 的 KMS 金鑰。在 us-east-1 以 MRK 加密的物件，可以在 us-west-2 用副本 MRK 解密，因為它們共用金鑰材料。MRK 對於需要跨區域複製加密資料的 DR 模式至關重要。金鑰政策是每個副本各自設定的，因此跨帳號授予必須在每個區域各別設置。不要將 MRK 與 KMS Grant 混淆——MRK 解決的是地理問題，Grant 解決的是委派問題。
KMS 金鑰政策與 SCP 的互動
在組織層拒絕 kms:Decrypt 的 SCP，會阻止受影響帳號中的任何 principal 解密，即使金鑰政策允許也一樣。這在敏感資料 SCP 中被刻意利用：拒絕對標記為 Classification=Restricted 的金鑰執行 kms:Decrypt，除非 principal 位於 security OU。SCP 是外層護欄，金鑰政策是內層授權。
跨帳號 KMS 存取 = 金鑰政策 + IAM 政策 + （選用）Grant。 金鑰政策具有決定性——沒有金鑰政策允許就沒有存取，無論 IAM 如何設定。同帳號的模式是：金鑰政策說「委派給 IAM 政策」，IAM 政策再授予動作。跨帳號的情況下，金鑰政策必須明確新增外部 principal，且外部帳號的身份政策也必須授予。Grant 在頂層再委派短期使用給 AWS 服務。這個三元素模型是加密領域中跨帳號安全控制的骨幹。
SCP vs IAM vs Resource Policy — 跨帳號決策指南
設計跨帳號安全控制時，你會反覆選擇由哪一層來強制執行特定規則。正確的層次取決於該規則是預防性還是偵測性、適用於全組織還是特定工作負載。
使用 SCP 進行全組織預防
SCP 適用於不論工作負載為何都必須套用至整個 OU 的規則。典型用途：拒絕核准清單以外的區域、拒絕停用 CloudTrail/Config/GuardDuty、拒絕對標記為 SecurityManaged 的角色執行 iam:DeleteRole、拒絕使用根帳號憑證、拒絕在標記邊界外部署。SCP 保證這些規則無法被工作負載管理員打破。
使用 Permission Boundary 進行委派角色建立
Permission Boundary 適用於想讓開發人員為自己的 Lambda 或 EC2 工作負載建立 IAM 角色，但又不希望他們建立提權角色的情境。邊界限制了任何被建立角色的能力上限。開發人員的角色附加政策授予 iam:CreateRole 和 iam:PassRole，但僅限於附加了強制邊界的角色（以 iam:PermissionsBoundary 條件強制執行）。
使用身份政策進行逐 Principal 授權
身份政策是預設的授予介面。透過 Identity Center 權限集指派給人類使用者，透過附加於 Lambda/EC2/ECS 的 IAM 角色指派給工作負載身份，透過服務連結角色指派給 AWS 服務。
使用 Resource Policy 進行多帳號共享
資源型政策（S3 儲存桶、KMS 金鑰、SNS 主題、SQS 佇列、Lambda、Secrets Manager）適用於一個資源必須被來自不同帳號的眾多 principal 存取、而不需要建立 N 份身份政策的情境。結合 aws:PrincipalOrgID，資源政策可以用單一敘述對組織的所有帳號開放。
生產環境的組合模式
典型的生產多帳號安全設計會同時使用這四層：SCP 在組織層面防止災難性動作，Permission Boundary 限制委派的自助服務，身份政策授予日常權限，資源政策啟用跨帳號共享。在 SAP-C02 考試中，正確答案通常是多層組合——留意那些僅靠單一政策類型、卻需要多種政策的選項。
GuardDuty 多帳號與 Organizations 整合
GuardDuty 是跨帳號安全控制中的威脅偵測支柱。在多帳號環境中，GuardDuty 必須在工作負載運行的每個帳號和每個區域中啟用，且發現必須匯流至中央安全團隊。若沒有 Organizations 整合，大規模操作 GuardDuty 是不切實際的。
GuardDuty 委派管理員
從管理帳號指定一個成員帳號（通常是 Security/Audit 帳號）作為 GuardDuty 委派管理員。該委派管理員即可在任何區域、跨組織所有帳號啟用 GuardDuty，而無需在日常任務中操作管理帳號。這種分離讓管理帳號保持最少使用——這是 landing zone 的核心原則。
新帳號自動啟用
一旦委派管理員設定完成，你可以針對每個區域切換「為新帳號自動啟用」。任何透過 Account Factory 或手動邀請新增至組織的帳號，在加入時就會自動在該區域啟用 GuardDuty。這解決了擴張問題——若沒有自動啟用，安全團隊必須記得對每個新帳號手動啟用 GuardDuty。
多帳號發現聚合
所有成員帳號的發現匯流至委派管理員帳號的 GuardDuty 主控台。安全團隊可看到附有成員帳號情境（每個發現帶有 AccountId 標籤）的發現、建立組織層級的抑制規則，並將所有發現推送至 Security Hub 或 EventBridge 匯流排以供 SIEM 整合。
GuardDuty 防護計畫 — 逐區域啟用
GuardDuty 具有額外的防護計畫：Malware Protection for EC2（在可疑發現後掃描 EBS 磁碟區）、S3 Protection（分析 S3 資料事件）、EKS Protection（EKS 稽核日誌異常偵測）、Lambda Protection（監控 Lambda 調用模式）、RDS Protection（異常資料庫登入模式）。每個防護計畫獨立啟用，各有獨立定價。在組織模式下，委派管理員可強制規定新成員自動啟用哪些防護計畫。
GuardDuty 跨區域注意事項
GuardDuty 是區域性服務。在一個區域啟用不等於覆蓋另一個區域。全組織部署意味著委派管理員需要在所有必要區域逐一迭代並設定自動啟用。常見的成本優化方式是只在實際運行工作負載的區域啟用 GuardDuty——搭配拒絕非核准區域的 SCP，可建立完整的覆蓋模型。
GuardDuty Organizations 心智模型。 管理帳號委派給 Security 帳號。Security 帳號按區域切換自動啟用。每個新成員帳號在加入時自動啟用 GuardDuty。發現帶著 AccountId 標籤流向安全團隊。管理帳號不是日常操作帳號——委派讓它遠離日常作業。這個相同的委派管理員模式適用於 Security Hub、Macie、Inspector、Detective、Access Analyzer 和 AWS Config——學會一次，套用六次。
Security Hub 多帳號與跨區域聚合
Security Hub 是合規計分與發現聚合服務。在多帳號 Organizations 中，Security Hub 同時具備兩個正交維度：多帳號聚合（透過委派管理員）與跨區域聚合（透過聚合區域）。兩者都必須刻意設計。
Security Hub 委派管理員
與 GuardDuty 相同，Security 帳號被指定為 Security Hub 委派管理員。該帳號可以在選定區域跨所有成員帳號啟用 Security Hub，並在組織層面啟用或停用安全標準（AWS Foundational Security Best Practices、CIS AWS Foundations Benchmark、PCI DSS、NIST SP 800-53）。
跨區域聚合 — 聚合區域
在一個選定的聚合區域（例如 us-east-1）中的 Security Hub，可以從每個連結帳號的每個其他區域的 Security Hub 拉取發現。聚合區域成為組織整個 AWS 區域範圍的單一管理視窗。在聚合區域中對發現所做的任何更新（狀態變更、新增備注）都會同步回來源區域。
聚合區域是一個設計決策。選擇一個對安全作業中心延遲低的區域、一個支援你所需所有 Security Hub 功能的區域，以及一個已承載你的 SIEM pipeline 的區域。us-east-1 是常見的預設選擇，因為它的功能上線最久。
安全標準 — FSBP、CIS、PCI、NIST
Security Hub 執行自動化合規標準。SAP-C02 可考的四個標準：
- AWS Foundational Security Best Practices (FSBP) — AWS 自行精選的 200 多項控制。預設啟用。
- CIS AWS Foundations Benchmark (v1.4 / v3.0) — 業界標準 CIS 控制，對應至 AWS。
- PCI DSS — 處理信用卡資料的工作負載所需的支付卡產業控制。
- NIST SP 800-53 Rev. 5 — 美國聯邦標準，FedRAMP 及許多政府合約所要求。
每個標準會針對每個資源的每個控制產生通過/失敗的發現。Security Hub 會計算每個標準的合規分數以及整體「安全分數」。組織層面的啟用確保每個帳號依照相同的評分標準計分。
整合來自 GuardDuty、Inspector、Macie、Access Analyzer 的發現
Security Hub 原生接收來自 GuardDuty、Inspector、Macie、IAM Access Analyzer、AWS Firewall Manager、AWS Config（conformance pack 發現）、AWS Systems Manager Patch Manager 及 AWS Health 的發現。所有發現正規化為 AWS Security Finding Format (ASFF)。第三方發現（CrowdStrike、Palo Alto、Trend Micro 等）也透過合作夥伴整合目錄進入 Security Hub。
自訂動作與 EventBridge 自動化
Security Hub 自訂動作在分析師點擊發現上的動作時，會發出至 EventBridge。自動化規則（Security Hub 較新的功能）允許以屬性為基礎的自動發現更新——例如自動抑制標記為 Environment=Sandbox 的發現，或將 CRITICAL 發現升級至 PagerDuty EventBridge 目的地。
Security Hub vs GuardDuty — 範圍提醒
GuardDuty 偵測威脅。Security Hub 聚合發現並對合規計分。在考試中，提到「中央儀表板」、「合規分數」、「FSBP 標準」或「聚合來自 GuardDuty 和 Inspector 的發現」的情境指向 Security Hub。提到「異常 API 活動」、「憑證遭竊」或「加密貨幣挖礦」的情境指向 GuardDuty。兩者通常都在同一個 Security 帳號中啟用。
AWS Config 多帳號 — 聚合器與 Conformance Packs
AWS Config 記錄隨時間變化的設定狀態。在多帳號情境中，Config 扮演兩個角色：針對規則和 conformance packs 集中評估合規，以及聚合 Config 資料以提供單一管理視窗的合規儀表板。
Config 聚合器 — 全組織合規檢視
Config 聚合器是在一個帳號和區域中建立的資源，從 AWS Organizations 所有成員帳號所有區域拉取設定項目和合規狀態。聚合器是唯讀的；它不對聚合的資料評估規則。它的工作是視覺化與查詢。
設置路徑：在管理帳號（或指定 Config 委派管理員帳號後在委派管理員帳號）中，使用「來源：我的組織」建立聚合器，選擇聚合區域，並透過 Organizations 信任進行授權。幾分鐘後，聚合器儀表板就能顯示跨所有帳號的資源、合規計數及不合規詳情。
Config 規則 — 受管規則與自訂規則
Config 規則將設定項目與期望狀態進行評估。受管規則（150 多個）涵蓋常見需求：s3-bucket-public-read-prohibited、encrypted-volumes、rds-storage-encrypted、iam-root-access-key-check。自訂規則執行 Lambda 函數以進行任意邏輯。逐帳號部署的規則產生合規狀態；聚合器將其匯總。
Conformance Packs — 將多個規則作為一個單位部署
Conformance pack 是捆綁多個 Config 規則與補救動作的 YAML 範本。AWS 提供適用於 PCI DSS、HIPAA、NIST 800-53、CIS、FedRAMP、作業最佳實踐等的預建 conformance packs。你可以將 conformance pack 部署至一個帳號（單帳號 pack）或整個組織（組織 conformance pack）——在組織情況下，每個成員帳號都會接收並評估相同的 pack。
組織 conformance packs 是合規框架的跨帳號安全控制模式。從管理帳號或 Config 委派管理員進行單一部署，即可將 PCI DSS 合規推送至 100 個成員帳號。每個帳號對聚合器回報相同的規則，安全團隊看到單一合規視圖。
使用 SSM Automation 自動補救
Config 規則可以在發現不合規時觸發 Systems Manager Automation runbooks——例如自動為任何未加密的 S3 儲存桶啟用預設加密。結合 SSM automation runbooks 的全組織 conformance packs，建立了一個閉環的偵測與補救跨帳號安全控制。
Config vs Security Hub 的重疊
Config 和 Security Hub 都能偵測不合規設定，這讓考生感到困惑。區別在於：Config 是隨時間記錄設定狀態（歷史、漂移、變更時序）並評估規則；Security Hub 是安全發現聚合與合規計分，消費 Config conformance pack 發現作為其中一個輸入。兩者是互補的，不是競爭關係。在 landing zone 中，兩者都會啟用：Config 用於設定鑑識與規則評估，Security Hub 用於計分卡。
Macie 全組織部署
Macie 在 S3 中發現敏感資料。在多帳號情境中，Macie 的運作方式與 GuardDuty 和 Security Hub 完全相同：委派管理員在所有成員帳號中啟用 Macie。
Macie 委派管理員模式
Security 帳號被指定為 Macie 委派管理員。從該帳號，你可以在需要的每個區域的每個成員帳號中啟用 Macie，並為新帳號啟用自動啟用。所有成員的發現匯流至委派管理員的 Macie 主控台。
自動化敏感資料探索
Macie 執行兩種類型的工作：自動化敏感資料探索（組織層面持續進行的抽樣式掃描——這是減少手動工作管理的新功能）和排程分類工作（你設定特定儲存桶和頻率）。自動化探索是建議的基準；工作用於特定高風險儲存桶的深度掃描。
受管資料識別符與自訂資料識別符
受管資料識別符涵蓋 100 多個類別：信用卡號、AWS 存取金鑰、各國社會安全號碼、護照號碼、駕照號碼、醫療識別符。自訂資料識別符讓你可以定義正規表達式模式，用於組織特定的敏感資料（員工 ID 格式、內部案件 ID）。
Macie 發現進入 Security Hub
Macie 發現（偵測到敏感資料、S3 儲存桶政策錯誤設定、含敏感資料的公開儲存桶）自動流入 Security Hub，與聚合器帳號儀表板中的 GuardDuty 和 Inspector 發現並排顯示。Macie 是唯一掃描 S3 物件內容以偵測敏感資料的 AWS 安全服務——沒有其他 AWS 服務以這種方式進行資料分類。
成本考量 — 抽樣 vs 完整掃描
Macie 掃描以每個被掃描的物件計費。對 PB 級資料湖的完整掃描成本高昂。自動化敏感資料探索透過智慧抽樣來控制成本。對於有成本限制的組織，模式是預設採用自動化探索，針對高風險儲存桶（PII 處理、受管制資料）執行目標性工作。
Macie 只掃描 S3，僅此而已。 在考試中，如果情境提到 RDS、DynamoDB、EFS 或 EC2 檔案系統中的敏感資料，Macie 不是答案——它只掃描 S3。對於非 S3 資料儲存，模式是將資料複製/快照至 S3 供 Macie 掃描，或使用透過 Security Hub 合作夥伴發現整合的第三方 DLP 工具。Macie 只掃描 S3 的範圍是 CLF-C02、SAA-C03 和 SAP-C02 中持續存在的陷阱。
AWS Audit Manager — 跨帳號合規的自動化證據收集
AWS Audit Manager 針對預建合規框架和自訂框架自動化收集稽核證據。它是能回答「你能向稽核人員證明組織中每個帳號在上一季符合控制 X.Y 嗎？」這個問題的服務。
Audit Manager 的功能
Audit Manager 從 CloudTrail（使用者活動）、AWS Config（設定合規）、Security Hub（安全發現）及手動附件彙集證據。它將這些證據對應至預建框架（SOC 2、PCI DSS、HIPAA、GDPR、FedRAMP、ISO 27001、AWS Well-Architected、AWS Foundational Security Best Practices）或你自訂的框架中的控制。
多帳號評估
Audit Manager 評估的範圍涵蓋指定的帳號和區域。在 Organizations 模式下，委派管理員評估自動包含每個成員帳號。在評估期間持續收集的證據會被打包成可匯出為 PDF 或結構化資料的稽核報告。
框架與控制
預建框架包含 SOC 2 Type 2、PCI DSS v3.2.1 和 v4.0、HIPAA Security Rule、GDPR、NIST 800-53、NIST CSF、CIS、FFIEC 及 AWS Well-Architected Framework。每個框架有數百個控制，每個控制指定證據來源。Audit Manager 處理對應關係，讓你不必手動將 CloudTrail 事件關聯到 SOC 2 CC6.1。
Audit Manager vs Security Hub vs Config — 邊界
Security Hub 對當前合規計分。Config 記錄當前及歷史設定。Audit Manager 將兩者打包成針對外部報告的框架控制的稽核就緒證據。在考試中，如果情境說「稽核人員要求提供證據」、「SOC 2 報告準備」或「持續合規證據收集」，答案是 Audit Manager。
IAM Access Analyzer — 一個服務的三項工作
IAM Access Analyzer 是偵測身份與資源政策風險的跨帳號安全控制。在 2023–2024 年，Access Analyzer 從一項工作擴展為三項互補工作。三項工作在 SAP-C02 考試中都很重要。
工作 1 — 外部存取發現（原始功能）
Access Analyzer 掃描資源型政策（S3 儲存桶、IAM 角色的信任政策、KMS 金鑰、Lambda 函數、Secrets Manager 密鑰、SQS 佇列、SNS 主題、EFS 檔案系統、ECR 倉庫、RDS 快照、EBS 快照），尋找授予信任區以外 principal 存取權的政策。信任區可以是當前帳號，或——對跨帳號安全控制至關重要的——整個 AWS Organizations。
當你從委派管理員帳號建立組織層級的分析器時，信任區變成整個組織。Access Analyzer 就只會呈現真正的外部發現——將資料暴露給組織外帳號的資源政策。與逐帳號分析器相比，這大幅降低了誤報噪音（在逐帳號分析器中，每一個合法的組織內跨帳號資源政策都會顯示為外部）。
工作 2 — 未使用存取發現（2023 年新增）
未使用存取分析器識別在可設定的追蹤期間（預設 90 天）內未被使用的 IAM 使用者、IAM 角色、存取金鑰和權限。三種發現類型：
- 未使用的 IAM 使用者/角色 — principal 在 N 天內未認證。
- 未使用的存取金鑰 — 金鑰未被使用。
- 未使用的權限 — 角色被使用過，但其授予的某些 IAM 動作從未被呼叫。
這些發現驅動最小權限清理。安全團隊看到「角色 X 有 s3:* 但實際上只用過 s3:GetObject 和 s3:PutObject」——作為收緊政策的起點。
工作 3 — 政策生成（從 CloudTrail 內嵌）
Access Analyzer 可以根據 IAM 角色在指定時間窗口內的實際 CloudTrail 活動，生成最小權限的 IAM 政策。你選擇一個角色和一個時間範圍，Access Analyzer 就會產生一個政策敘述，列出該角色實際存取過的動作和資源。這是將現有角色從寬泛權限精確調整至最小權限、而不需要猜測的實用工具。
組織分析器 — 正確的信任區
逐帳號分析器有效，但多帳號組織應使用從 Access Analyzer 委派管理員帳號（通常是 Security 帳號）建立的組織層級分析器。只有組織分析器將組織內的跨帳號存取視為內部存取，只顯示外部（組織外）的發現。逐帳號分析器將每個同組織帳號都視為「外部」，產生掩蓋真正問題的噪音。
封存規則 — 抑制預期的發現
某些外部存取是刻意的（監控廠商的跨帳號角色是預期的）。封存規則自動抑制符合條件的發現，使其不會混亂活躍清單。封存規則依帳號 ID、資源類型或 principal ARN 等條件進行匹配。
Access Analyzer vs Security Hub
Access Analyzer 發現流入 Security Hub，因此委派管理員可以與 GuardDuty 和 Inspector 發現一起看到它們。但 Access Analyzer 也是一個獨立的服務，有自己的主控台和三種工作類型。在考試中，如果情境說「找出組織外可存取的 S3 儲存桶」、「找出從未使用過的 IAM 角色」或「從實際使用情況生成最小權限政策」，答案分別是 Access Analyzer 的外部存取工作、未使用存取工作和政策生成工作。
Access Analyzer 有三項工作，考試三者都考。 外部存取發現是資源政策將資料暴露給信任區外的情況。未使用存取發現是過時的 IAM principals、金鑰和角色內未使用的權限。政策生成是從 CloudTrail 活動建立最小權限政策。這三者是獨立的分析器設定，未使用存取層有獨立的定價。只記住「Access Analyzer 找出公開 S3 儲存桶」的考生，在 SAP-C02 上會錯過三分之二的 Access Analyzer 題目。務必了解三項工作。
大規模集中式修補與弱點合規
跨帳號安全控制不僅限於身份和發現，還延伸至修補和弱點管理。
Systems Manager Patch Manager 跨帳號
多帳號設置中的 Patch Manager 使用集中定義的修補基準，並透過 State Manager 關聯將其套用至跨帳號的 EC2 群組。結合 Organizations，你可以針對「Production OU 中的所有 EC2 執行個體」使用 Linux 修補基準和更新排程。合規報告流入 Security Hub，並可由 Audit Manager 收集證據。
Inspector v2 進行全組織弱點掃描
Amazon Inspector v2 支援與 GuardDuty 相同的委派管理員模式。從 Inspector 委派管理員帳號，你可以在所有成員帳號跨 EC2、ECR 和 Lambda 掃描啟用 Inspector。發現帶著 CVE ID、CVSS 分數和修復可用性流入 Security Hub。
修補 + 掃描 + 偵測的閉環
整合式跨帳號安全控制弱點循環：Inspector 偵測 CVE → Security Hub 聚合 → Patch Manager 透過 State Manager 套用修補 → Inspector 重新掃描並確認補救 → Audit Manager 收集證據。所有環節從 Security 帳號協調，無需工作負載團隊介入。
AWS Certificate Manager (ACM) 與 Private CA 跨帳號 TLS
AWS Certificate Manager 中的 Private CA 為微服務發出內部 TLS 憑證。在多帳號環境中，CA 階層通常託管於共用服務或 Security 帳號，並透過 AWS RAM 與工作負載帳號共用。
使用 AWS RAM 共用 Private CA
Private CA 資源可以透過 Resource Access Manager 共用給特定帳號、OU 或整個組織。工作負載帳號可以從共用的 CA 為其自己的 ALB、API Gateway 和內部服務發出憑證，而不需要每個工作負載各自運行 CA 基礎設施。
透過 ACM 的公開憑證
ACM 公開憑證是帳號本地的，且免費。它們無法直接跨帳號共用（除非在每個帳號重新佈建）。對於許多帳號的公開服務，模式是每帳號 ACM；對於內部微服務 mTLS，模式是共用 Private CA。
情境模式 — 開發人員自助服務而不提升權限
SAP-C02 的典型情境：「成員帳號的開發人員需要部署 Lambda 函數，包括建立執行角色。他們不能被授予 IAM 管理員權限。安全團隊必須防止權限提升。」以跨帳號安全控制分層解決。
分層答案
- Permission Boundary 名為
DeveloperWorkloadBoundary，定義開發人員建立的任何角色的最大權限（允許讀取服務配額、Lambda 調用、CloudWatch Logs、特定 S3 前綴；拒絕 IAM、Organizations、任何提升權限的動作）。 - 開發人員角色獲授
iam:CreateRole、iam:PutRolePolicy、iam:AttachRolePolicy、iam:PassRole——但附帶條件"iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/DeveloperWorkloadBoundary"。開發人員只能建立附加邊界的角色。 - SCP 在工作負載 OU 拒絕停用 CloudTrail、停用 GuardDuty、刪除邊界政策、刪除 Security 帳號的 Config 聚合器——不可破壞的護欄。
- Access Analyzer 組織分析器監視任何將資料暴露給組織外的資源政策，捕捉開發人員的錯誤。
結果：開發人員擁有 Lambda 自助服務，無法提升權限，無法竄改安全工具，任何意外的資料暴露都能被偵測。
情境模式 — 跨 100 個帳號偵測 CloudTrail 停用
情境：「安全團隊必須在任何成員帳號停用 CloudTrail 後數分鐘內收到警報。」多種跨帳號安全控制可以解決此問題；考試測試哪種最佳。
選項比較
- SCP 拒絕
cloudtrail:StopLogging和cloudtrail:DeleteTrail— 預防性，不可破壞。這是第一線答案。 - GuardDuty
Stealth:IAMUser/CloudTrailLoggingDisabled發現 — 偵測性，一旦 GuardDuty 在全組織啟用即自動生效。發現流入 Security Hub 和 EventBridge。 - Config 規則
cloud-trail-enabled— 偵測性，附帶可選的 SSM runbook 自動補救以重新啟用 CloudTrail。 - CloudWatch Events / EventBridge 規則對應 CloudTrail 管理事件 — 偵測性，需要 Organizations CloudTrail 來跨帳號捕捉。
正確設計使用 SCP 作為預防護欄（使壞動作不可能發生），加上 GuardDuty 和 Config 作為偵測備援（捕捉邊緣情況並強制執行全組織證據）。純偵測性答案弱於預防 + 偵測的組合。
SCP 不適用於管理帳號。 SAP-C02 上的常見陷阱：考生以為附加到組織 root 的 SCP 適用於所有帳號，包括管理帳號。事實並非如此。管理帳號完全豁免於 SCP。最佳實踐是讓管理帳號不運行工作負載，並透過 Security 帳號中的委派管理員操作安全服務。這項豁免也是為什麼你永遠不在管理帳號中啟用 Control Tower 自訂或工作負載部署。
跨帳號安全控制 — 成本與營運取捨
每個跨帳號安全控制都有成本。在 SAP-C02 考試中，題目有時要求在覆蓋範圍與成本之間取得平衡。
GuardDuty 成本模型
GuardDuty 按分析的 CloudTrail 事件數量及 VPC Flow Log / DNS log 流量計費。額外的防護計畫（Malware Protection、S3 Protection、EKS Protection、Lambda Protection、RDS Protection）各有獨立定價。全組織部署會將成本乘以帳號數，但考慮到威脅偵測的價值，幾乎總是值得的。
Security Hub 成本模型
Security Hub 按接收的發現數量和合規標準評估次數計費。跨區域聚合不會倍增接收成本——在來源區域接收一次的發現會被複製到聚合區域，不會重複計費。
Config 成本模型
Config 按記錄的設定項目和規則評估次數計費。Conformance pack 規則按評估次數計費；組織 conformance packs 乘以成員帳號數。
Macie 成本模型
Macie 自動化敏感資料探索按評估的 S3 資料 GB 計費（附抽樣）。排程工作按掃描的物件計費。對於大型資料湖，Macie 通常是成本最高的跨帳號安全控制——自動化探索加上目標性工作是成本管控模式。
Access Analyzer 成本模型
外部存取發現免費。未使用存取發現按每個受監控的 IAM 角色每月計費。政策生成免費。未使用存取層對管理數千個角色的組織是刻意的成本訊號。
Audit Manager 成本模型
Audit Manager 按每個活躍評估每月每個受評估資源計費。停止未使用的評估以控制成本；僅在稽核準備期間排程高成本框架。
跨帳號安全控制的常見考試陷阱
陷阱 1 — Permission Boundary 授予權限
錯誤。Permission Boundary 限制權限；它從不授予權限。身份政策仍需明確允許動作才能被允許——邊界只限制身份政策能授予的範圍。
陷阱 2 — SCP 適用於管理帳號
錯誤。SCP 豁免管理帳號。這就是為什麼最佳實踐是讓管理帳號不含工作負載，並透過 Security 帳號的委派管理員操作。
陷阱 3 — Access Analyzer 找出所有跨帳號存取問題
部分正確。Access Analyzer 外部存取發現分析資源型政策，而非 IAM 身份政策。透過信任政策進行的跨帳號 IAM 角色承擔是角色上的資源型政策，因此 Access Analyzer 能捕捉到它。但 Access Analyzer 不分析每一個可能的跨帳號路徑；它的範圍限於支援服務上的資源政策。
陷阱 4 — KMS 金鑰政策單獨授予跨帳號存取
錯誤。跨帳號 KMS 存取需要金鑰政策允許以及呼叫者的身份政策允許。同帳號存取只需其中一個，但跨帳號需要兩者。
陷阱 5 — 組織內存取需要 ExternalId
錯誤。ExternalId 防禦的是第三方混淆代理人問題。組織內跨帳號角色應使用 aws:PrincipalOrgID，而非 ExternalId。考試會具體測試這一點。
陷阱 6 — Security Hub 自行生成威脅發現
部分正確。Security Hub 確實生成合規標準發現（FSBP、CIS），但對於威脅偵測，它是消費 GuardDuty 發現的聚合器。回答威脅偵測問題時選擇 Security Hub 的考生會錯過正確答案 GuardDuty。
陷阱 7 — Macie 掃描 RDS 或 EFS
錯誤。Macie 只掃描 S3。對於其他資料儲存的敏感資料，使用資料庫活動串流、第三方 DLP，或將資料複製至 S3 供 Macie 掃描。
陷阱 8 — Config 和 Security Hub 是同一回事
錯誤。Config 隨時間記錄設定狀態並評估 Config 規則。Security Hub 聚合發現並對合規計分，消費 Config conformance pack 發現作為眾多輸入之一（GuardDuty、Inspector、Macie、Access Analyzer）。兩者一起啟用。
陷阱 9 — 一個 Access Analyzer 設定涵蓋三項工作
錯誤。外部存取分析器和未使用存取分析器是獨立的設定。政策生成是按角色按需調用的。三者獨立設定，定價也不同。
陷阱 10 — 委派管理員等同於管理帳號
錯誤。委派管理員是另外指定的成員帳號（通常是 Security 或 Audit 帳號）。管理帳號執行委派，但本身不是日常安全工具的操作帳號。
關鍵數字與必記跨帳號安全控制事實
信任政策條件鍵
aws:PrincipalOrgID 用於組織內。aws:SourceAccount 和 aws:SourceArn 用於服務對服務。sts:ExternalId 用於第三方 SaaS。aws:PrincipalOrgPaths 用於 OU 範圍的信任。
KMS 跨帳號
跨帳號需要金鑰政策 + IAM 政策兩者兼備。Grant 用於服務委派。MRK 用於多區域相同金鑰 ID 複製。
政策評估
明確 Deny 優先於任何 Allow。SCP + Permission Boundary + 身份政策 + 資源政策全部必須允許才能進行跨帳號存取。
GuardDuty Organizations
從 Security 帳號委派管理員。按區域為新帳號切換自動啟用。六個資料來源和防護計畫（CloudTrail、VPC Flow、DNS + Malware、S3、EKS、Lambda、RDS 防護）。
Security Hub
委派管理員。聚合區域選擇一次。FSBP、CIS、PCI DSS、NIST 800-53 標準。ASFF 正規化。
Config 聚合器與 Conformance Packs
聚合器 = 唯讀的跨帳號跨區域視圖。組織 conformance packs 透過單一 API 呼叫部署至所有成員帳號。
Macie
只掃描 S3。自動化敏感資料探索（抽樣式，持續運行）或排程工作（特定儲存桶）。委派管理員與 GuardDuty 相同。
Audit Manager
SOC 2、PCI DSS、HIPAA、NIST 800-53、GDPR、FedRAMP、ISO 27001、AWS Well-Architected 等框架。證據來自 CloudTrail、Config、Security Hub 及手動上傳。
IAM Access Analyzer 三項工作
外部存取（資源政策）、未使用存取（過時 principal 和權限）、政策生成（從 CloudTrail 活動）。組織層級分析器用於組織信任區。
FAQ — 跨帳號安全控制熱門問題
Q1 — aws:PrincipalOrgID 與 sts:ExternalId 有什麼區別，各自在什麼情況下使用？
aws:PrincipalOrgID 是 AWS 管理的條件鍵，用於信任政策中，將角色承擔限制為特定 AWS Organizations 內的 principal。對所有組織內的跨帳號角色使用它。若帳號離開組織，其 principal 就無法再承擔角色——自動撤銷。sts:ExternalId 是客戶指定的唯一值，用於第三方 SaaS 情境以防止混淆代理人攻擊。第三方在每次 AssumeRole 呼叫時提供 ExternalId；信任政策要求它。僅對第三方存取使用 ExternalId，不要用於你自己組織內的跨帳號角色。
Q2 — 如果我啟用 Security Hub 並設定跨區域聚合，我還需要在每個區域啟用 GuardDuty 嗎？
是的。GuardDuty 是偵測器；Security Hub 是聚合器。你需要在工作負載運行的每個區域啟用 GuardDuty，以確保那裡的威脅能被偵測到。Security Hub 跨區域聚合只是重新定位發現——它不執行偵測。在每個使用中的區域為新成員自動啟用 GuardDuty，然後將 Security Hub 跨區域聚合指向單一整合區域。
Q3 — 如何讓帳號 A 的 Lambda 存取帳號 B 中以帳號 B KMS 金鑰加密的 S3 物件？
五份政策必須對齊：（1）帳號 A 的 SCP 不拒絕 s3:GetObject 或 kms:Decrypt；（2）Lambda 執行角色身份政策允許對儲存桶和金鑰 ARN 的兩個動作；（3）帳號 B 的儲存桶政策允許 Lambda 角色 principal 執行 s3:GetObject；（4）帳號 B 的 KMS 金鑰政策允許 Lambda 角色 principal 執行 kms:Decrypt 和 kms:DescribeKey；（5）帳號 B 的 SCP 不拒絕組織成員的任一動作。任何缺少的允許都會返回 AccessDenied。最常被遺忘的元素是 KMS 金鑰政策，因為 KMS 跨帳號使用需要明確的金鑰政策允許。
Q4 — Permission Boundary 和 SCP 有什麼區別，我需要兩者兼用嗎？
Service Control Policy 附加於 Organizations OU 或帳號，限制受影響帳號中任何 principal 所能執行的動作——包括 root。SCP 是全組織的預防護欄。Permission Boundary 是附加於特定 IAM 使用者或角色的 IAM 受管政策，限制該 principal 的身份政策能授予的範圍——當委派角色建立給開發人員時至關重要，確保他們無法建立權限超過邊界的角色。是的，通常兩者都用：SCP 用於全組織不可變規則（區域限制、禁止停用 CloudTrail），Permission Boundary 用於逐 principal 委派（開發人員建立的角色必須附加邊界）。它們獨立運作並疊加。
Q5 — IAM Access Analyzer 未使用存取與 Access Advisor 或 Credential Report 有何不同？
Access Advisor 顯示 principal 最後存取服務的時間——適用於臨時調查，但提供的是逐服務的細粒度視圖。Credential Report 是包含 IAM 使用者和最後使用日期的全帳號 CSV。Access Analyzer 未使用存取是持續運行的全組織分析器，為未使用的角色、未使用的存取金鑰以及已使用角色內的未使用權限產生發現。它可以擴展至 100 個以上的帳號並饋送 Security Hub。對於點時間的深度調查，使用 Access Advisor；對於組織規模的持續清理，使用 Access Analyzer 未使用存取。
Q6 — Macie 能掃描 RDS 或 DynamoDB 中的敏感資料嗎？
不能。Macie 只掃描 Amazon S3。對於 RDS，仰賴 Database Activity Streams 加上 CloudTrail 加上查詢稽核。對於 DynamoDB，仰賴屬性層級設計（不在 DynamoDB 中儲存敏感資料，或以 KMS 信封加密在客戶端加密欄位）。對於 EFS，沒有原生的敏感資料掃描器。非 S3 資料儲存的模式是要麼避免在那裡儲存敏感資料，要麼在應用層實施 DLP。
Q7 — 如果管理帳號豁免於 SCP，我如何防止持有管理帳號憑證的攻擊者造成損害？
多重防禦：（1）在管理帳號上啟用根帳號 MFA，並將憑證儲存在保險庫（實體保險箱）中——根帳號幾乎不應被使用。（2）在所有其他帳號啟用 AWS Organizations SCP，這樣即使管理帳號憑證外洩，爆炸半徑也很窄（管理帳號本身通常不持有工作負載）。（3）使用 Identity Center 進行所有人工存取——管理帳號中沒有 IAM 使用者。（4）啟用 CloudTrail Organizations trail 至具有 vault lock 的不可變 Log Archive 儲存桶。（5）設定 GuardDuty 對根帳號使用發現發出警報。哲學是深度防禦：讓管理帳號盡量少用，並立即偵測任何偏差。
Q8 — AWS Config 規則和 Security Hub 安全標準有什麼區別？
Config 規則將 AWS 資源設定與期望狀態進行評估，並產生每個資源每個規則的合規狀態。Security Hub 安全標準（FSBP、CIS、PCI、NIST）是精選的安全最佳實踐套件，許多底層是由 Config 規則支持的。Security Hub 新增了正規化的發現格式、跨帳號和跨區域聚合，以及每個標準的合規分數。通常兩者都啟用：Config 規則用於細粒度的自訂合規邏輯和歷史漂移可見性，Security Hub 標準用於跨組織開箱即用的業界標準合規計分。
Q9 — 組織 conformance packs 與逐帳號 conformance packs 有何不同？
逐帳號 conformance pack 將規則部署至單一啟用 Config 的帳號。組織 conformance pack（從 Organizations 管理帳號或 Config 委派管理員部署）自動將相同規則部署至選定的所有成員帳號，更新和刪除也會一併傳播。這就是安全團隊如何在一次部署中將 PCI DSS 合規推送至 100 個工作負載帳號。在 SAP-C02 考試中，如果情境說「對所有成員帳號套用一致的合規規則」，答案是組織 conformance pack。
Q10 — landing zone 的正確委派管理員模式是什麼？
標準 landing zone 有兩個非管理帳號負責安全：Security/Audit 帳號和 Log Archive 帳號。Security 帳號被指定為 GuardDuty、Security Hub、Config（聚合器 + conformance packs）、Macie、Inspector v2、IAM Access Analyzer 和 Audit Manager 的委派管理員。Log Archive 帳號擁有集中式 CloudTrail 和 Config 交付儲存桶，附帶物件鎖定 / vault lock。工作負載團隊在自己的 OU 範圍帳號中運作，對 Security 或 Log Archive 帳號沒有直接存取——由 SCP 強制執行的護欄。這個模式是每個 SAP-C02 情境隱式假設的參考架構。
進一步閱讀 — 跨帳號安全控制官方 AWS 文件
在 SAP-C02 範圍之外的深度閱讀，權威 AWS 來源包含：IAM 使用者指南（特別是政策評估邏輯和角色信任政策）、AWS Organizations 使用者指南（SCP、委派管理員）、KMS 開發人員指南（金鑰政策、Grant、多區域金鑰）、GuardDuty 使用者指南（Organizations 整合）、Security Hub 使用者指南（跨區域聚合、標準）、AWS Config 開發人員指南（聚合器、conformance packs）、Macie 使用者指南（組織管理）、Audit Manager 使用者指南，以及 IAM Access Analyzer 使用者指南（三種工作類型）。
AWS Security Reference Architecture (SRA) 白皮書是 SAP-C02 的必讀材料——它將本指南中所有跨帳號安全控制的 Security 帳號 / Log Archive 帳號 / 委派管理員模式系統化。AWS Well-Architected Security Pillar 白皮書是概念性錨點。過去兩年的 AWS re:Inforce 錄製課程以真實客戶架構涵蓋了每一個委派管理員功能。
總結 — 跨帳號安全控制決策樹
在考試當天，遇到跨帳號安全控制情境時，執行這個決策樹：
- 規則是關於在全組織範圍內防止某個動作嗎？→ SCP。
- 規則是關於限制委派開發人員所能授予的權限嗎？→ Permission Boundary。
- 情境是關於組織內跨帳號角色承擔嗎？→ 信任政策中含
aws:PrincipalOrgID的 IAM 角色。 - 情境是關於第三方 SaaS 存取嗎？→ 信任政策中含
sts:ExternalId的 IAM 角色。 - 情境是關於跨帳號 KMS 存取嗎？→ 金鑰政策和 IAM 政策都必須允許；服務層級使用 Grant。
- 情境是關於跨帳號威脅偵測嗎？→ GuardDuty 搭配委派管理員，新帳號自動啟用。
- 情境是關於跨帳號和跨區域的合規計分嗎？→ Security Hub 搭配委派管理員 + 聚合區域。
- 情境是關於跨帳號設定合規嗎？→ AWS Config 聚合器 + 組織 conformance packs。
- 情境是關於跨帳號 S3 敏感資料嗎？→ Macie 搭配委派管理員。
- 情境是關於找出將資料暴露給組織外的資源政策嗎？→ IAM Access Analyzer 組織分析器，外部存取發現。
- 情境是關於過時的 IAM 角色和未使用的權限嗎？→ IAM Access Analyzer 未使用存取發現。
- 情境是關於從實際使用情況生成最小權限政策嗎？→ IAM Access Analyzer 政策生成。
- 情境是關於 SOC 2 / PCI / HIPAA 的稽核證據嗎？→ AWS Audit Manager。
- 情境是關於集中式修補嗎？→ Systems Manager Patch Manager 搭配 Organizations + Inspector v2。
熟練掌握這十四個分支，你就能正確回答 SAP-C02 Task 1.2 中的每一道跨帳號安全控制題目。跨帳號安全控制獎勵的是架構思維，而非單一服務的死記硬背——深入研究各層如何組合，正確的跨帳號安全控制設計自然就會浮現。