AWS Organizations 的 SCP 有一個眾所周知的例外：它們不適用於管理帳號中的主體。即使是附加在根層級的全拒絕 SCP，也讓管理帳號保有完全的權限。這是刻意設計的，以確保管理員永遠不會意外將自己鎖定在組織管理之外。架構上的結論是：絕對不可在管理帳號中執行工作負載、自動化或日常使用者的操作。在管理帳號中執行帳務團隊的 IAM 使用者是一種反模式；這意味著這些使用者可以在沒有任何 SCP 防護欄的情況下對組織追蹤呼叫 cloudtrail:StopLogging。正確的做法是清空管理帳號，將工作負載移至成員帳號，並透過 IAM Identity Center 權限集、硬體 MFA、緊急存取程序和 CloudTrail 監控，管理少數合法的管理帳號操作員。在根層級附加一條拒絕 CloudTrail 竄改的 SCP 仍屬設計的一部分，但僅用於保護成員帳號；管理帳號需要完全不同的控制策略。

白話文解釋

想像一棟公寓大廈的業主。業主制定了適用於所有住戶的管委會規定，但業主本人並不受自己規定的約束。如果你讓業主同時住在出租單位並在大廳經營事業，就無法阻止他違反任何規定——解決方法是一開始就不要在業主的辦公室裡運作任何東西，並讓主鑰匙置於嚴格的借出記錄管理之下。

選項分析

A：錯誤。根層級的 SCP 適用於所有成員帳號，但明確排除管理帳號不受評估。
B：正確。SCP 不限制管理帳號，因此修復方式是將工作負載和日常使用者移出管理帳號，並透過 IAM Identity Center、MFA 和監控來管控存取。
C：服務連結角色不受 SCP 約束，但這不是此處的缺口。真正的風險是架構師在管理帳號中執行一般 IAM 使用者和腳本。
D：僅附加到 Security OU 反而更糟，因為其他所有 OU 都會失去 CloudTrail 保護。根層級附加是正確的；管理帳號只是需要另一套獨立的策略。