Day 3 介紹了 IAM，說明如何使用 User、Group、Role 與 Policy 管理 AWS 中的身分與權限。

但企業通常不會把正式、測試、開發等環境全部放在同一個 AWS 帳號，而是拆成多個帳號，降低不同環境互相影響的風險。

帳號變多之後，就會出現兩個問題：

1. 如何集中管理多個 AWS 帳號，並統一限制它們的權限？
2. 使用者需要操作另一個帳號中的資源時，該如何取得權限？

這就是 AWS Organizations、SCP 與跨帳號存取要解決的問題。

🗂️ AWS Organizations 是什麼？

AWS Organizations 是用來集中管理多個 AWS 帳號的服務，他可以：

• 集中建立及管理多個 AWS 帳號
• 將帳號分類到不同的 OU
• 使用 SCP 統一限制成員帳號的權限上限
• 集中管理部分 AWS 服務
• 整合多個帳號的帳務資訊

🤔 為什麼不用 IAM Group？

IAM Group 也能集中管理權限，但它管理的是同一個 AWS 帳號內的 IAM User；Organizations 管理的則是多個 AWS 帳號。

假設同一個 AWS 帳號中有三位開發人員：

Developers Group
├── User A
├── User B
└── User C

這時候可以把 Policy 附加到 Developers Group，讓三位 User 取得相同權限。

但如果公司要管理的是以下環境：

Production Account
Development Account
Testing Account
Security Account

這些 AWS 帳號不能被加入 IAM Group。Group 也不能包含 IAM Role、其他 Group 或 AWS 帳號。

因此，兩者不是互相取代，而是負責不同層級：

AWS Organizations
└── 管理多個 AWS 帳號
    └── 每個帳號再使用 IAM
        └── 使用 Group 管理多個 User

最直覺的區分方式是：

Group 管一個帳號裡的人；Organizations 管整間公司的 AWS 帳號。

🏗️ Organizations 的帳號階層

AWS Organizations 主要由以下元件組成：

OU 可以依照環境、部門或用途分類：

Organization Root
├── Security OU
├── Production OU
├── Development OU
└── Sandbox OU

將帳號放入 OU 後，就能對整組帳號套用相同的治理規則，不必逐一設定。

🛡️ SCP：設定帳號的權限上限

SCP 是 Service Control Policy 的縮寫，用來限制成員帳號的最大可用權限範圍。

SCP 可以附加在以下層級：

• Organization Root
• OU
• 個別 Member Account

附加在上層的 SCP 會向下影響其包含的 OU 與帳號。

SCP 不會直接授予權限

SCP 最重要的觀念是：

SCP 不會授予任何權限，只會設定權限上限。

假設某位使用者的 IAM Policy 允許所有 S3 操作：

s3:*

但上層 SCP 明確拒絕：

s3:DeleteObject

即使 IAM Policy 允許所有 S3 操作，這位使用者仍然不能刪除 S3 物件。

兩者的關係可以簡化成：

IAM Policy 授予的權限
            ∩
SCP 允許的最大範圍
            =
      實際可用權限

IAM Policy 與 SCP 的差異

因此：

⚖️ SCP 的 Deny list 與 Allow list

SCP 常見的設計策略有兩種。

Deny list：允許大部分操作，只禁止特定行為

AWS Organizations 預設會附加 FullAWSAccess SCP。在保留這項設定的情況下，可以另外加入明確的 Deny：

SCP 沒有拒絕某個 Action
→ 繼續交由 IAM Policy 判斷

SCP 明確拒絕某個 Action
→ 無論 IAM Policy 如何設定，操作都會被拒絕

這種方式適合禁止少數高風險操作，例如：

• 禁止停用 CloudTrail
• 禁止離開 Organization
• 禁止使用未核准的 AWS Region

Allow list：只開放指定服務或操作

另一種方式是只在 SCP 中保留允許使用的操作：

SCP 明確允許某個 Action
→ 繼續交由 IAM Policy 判斷

SCP 沒有允許某個 Action
→ 該操作無法執行

因此，不能直接說「SCP 沒有寫到的 Action 就不會阻擋」。結果取決於組織採用的是 Deny list 還是 Allow list。

⚠️ 核心規則
只要任何一層適用的 SCP 出現明確 Deny，就沒有任何 IAM Allow 可以覆蓋它。

⚠️ 設定提醒
如果移除預設的 FullAWSAccess，卻沒有用其他 SCP 補上需要的 Allow，成員帳號中的 AWS 操作可能全部失敗。

🧾 情境：禁止成員帳號關閉 CloudTrail

假設公司要求所有成員帳號都必須保留 CloudTrail 稽核紀錄，不能讓個別帳號停止記錄或刪除 Trail。

如果只依靠帳號內的 IAM Policy，就必須逐一檢查每個帳號中的 User 和 Role。只要其中一個帳號漏設，就可能形成治理漏洞。

這種跨帳號的統一限制，適合透過 SCP 套用到 Organization Root 或指定 OU。

以下簡化範例禁止停止 CloudTrail Logging，以及刪除 Trail：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

套用後，即使成員帳號中的 User 或 Role 擁有 AdministratorAccess，仍然不能執行被 SCP 明確拒絕的操作。

這也是 IAM Group 無法取代 SCP 的原因：

• Group Policy 只影響加入該 Group 的 User。
• SCP 會限制成員帳號中的 User、Role，甚至該帳號的 root user。

SCP 的重要例外

• SCP 不影響 Management Account 中的 User 和 Role。
• SCP 不限制 AWS 的 service-linked role。
• SCP 只設定權限上限，不會替 User 或 Role 授予權限。

因此，Management Account 應盡量只用於必要的組織管理工作，不應執行一般工作負載。

🔄 多帳號環境中的跨帳號存取

AWS Organizations 可以集中管理多個帳號，SCP 則負責限制各帳號的權限上限，但它們不會自動讓不同帳號互相存取。

當 Account A 的使用者需要操作 Account B 的資源時，仍然必須另外建立跨帳號授權。

常見做法有兩種：

1. 在 Account B 建立 IAM Role，讓 Account A 的身分透過 AssumeRole 取得臨時權限。
2. 直接在 Account B 的資源上設定 resource-based policy，允許 Account A 的身分存取。

📌 跨帳號存取不要求兩個帳號位於同一個 AWS Organization。
即使兩個帳號屬於不同 Organization，仍然可以建立跨帳號授權。

兩種方式的差異

方式一：IAM Role＋AssumeRole

假設：

• 工程師平常登入 Account A
• 工程師需要管理 Account B 中的資源

不建議直接在 Account B 為工程師建立另一組長期 IAM User 與 Access Key。

比較適合的做法，是讓工程師暫時取得 Account B 中某個 Role 的權限。

要完成跨帳號 AssumeRole，來源帳號與目標帳號都必須進行設定。

Account A：允許提出 AssumeRole 請求

來源帳號中的 User 或 Role 必須擁有：

sts:AssumeRole

如果 Account A 有多位 User 都需要取得相同 Role，也可以將 sts:AssumeRole 權限附加到 IAM Group，再由 Group 統一授權這些 User。

Account B：建立可被取得的 Role

目標帳號中的 Role 需要兩類 Policy：

• Trust Policy：規定 Account A 中的哪些 Principal 可以取得這個 Role
• Permissions Policy：規定取得 Role 後可以操作 Account B 中的哪些資源

📌 IAM Group 可以統一授予 User 呼叫 AssumeRole 的權限，但 Group 不能直接成為 Trust Policy 中的 Principal，也不能取代 Account B 中的 Role。

兩邊都允許後，AWS STS 會發出：

Access Key ID
Secret Access Key
Session Token

這組臨時憑證具有有效期限，到期後會自動失效，因此不需要在 Account B 建立另一組長期 Access Key。

CloudTrail 可以記錄 AssumeRole 事件，以及後續由 assumed-role session 執行的 API 操作，方便追蹤 Role 的使用情況。

方式二：Resource-based policy

部分 AWS 服務允許直接在資源上設定 Policy，指定其他帳號中的哪些 Principal 可以存取該資源。

常見情境包括：

• Account B 有一個 S3 bucket，用來存放報表檔案
• Account A 的分析人員只需要讀取這些報表
• 分析人員不需要管理 Account B 的其他資源

在典型的跨帳號情境中，兩邊通常都要允許這項操作：

這種方式不需要先切換成 Account B 的 Role，但只有支援 resource-based policy 的 AWS 服務才能使用。

該選哪一種？

• 需要操作多種 AWS 服務或使用臨時憑證：選擇 IAM Role＋AssumeRole
• 只需要分享特定資源，而且該服務支援資源型 Policy：可以使用 resource-based policy

🧠 整體關係

整體層級如下：

AWS Organizations
├── OU：分類多個 AWS 帳號
│   └── SCP：限制帳號的最大權限
│
└── Member Account
    ├── IAM Group：管理一群 User
    ├── IAM Policy：授予 User 或 Role 權限
    └── IAM Role：提供可被暫時取得的身分

✅ 小結

本篇從單一帳號擴展到多帳號環境的治理與存取。

核心觀念如下：

• IAM Group 管理同一個帳號內的一群 User。
• Organizations 集中管理整間公司的多個 AWS 帳號。
• OU 負責將帳號分類。
• SCP 不會授予權限，只會限制帳號的最大可用權限。
• IAM Policy 與 SCP 都允許，操作才可能成功。
• 明確 Deny 的優先順序高於任何 Allow。
• 跨帳號存取可以使用 resource-based policy 或 IAM Role。
• AssumeRole 會透過 AWS STS 發出有期限的臨時憑證。

摘要整理：

Group 管帳號裡的人，Organizations 管公司的帳號，SCP 設定帳號的權限上限，AssumeRole 則讓身分暫時取得另一個帳號中的權限。

🧠 AI 出題

問題 1

某公司使用 AWS Organizations 管理 40 個帳號，結構為 Root → OU「Workloads」→ 子 OU「Prod」與「Dev」，各層都保留預設的 FullAWSAccess SCP。安全團隊先前在 OU「Workloads」另外掛了一條 SCP，明確 Deny ec2:RunInstances，以防止未經審核的機器被啟動。現在 Prod 團隊需要在自己的帳號裡正常啟動 EC2，Dev 帳號則必須維持禁止。一位解決方案架構師必須在不影響其他 OU 既有管控、且維運負擔最低（LEAST operational overhead）的前提下滿足這個需求。

哪一個做法最符合需求？

• A. 在子 OU「Prod」掛一條明確 Allow ec2:RunInstances 的 SCP，用較靠近帳號的層級覆蓋父層 OU 的 Deny
• B. 將那條 Deny ec2:RunInstances 的 SCP 從 OU「Workloads」卸除，改掛到子 OU「Dev」，讓「Prod」不再繼承這條限制
• C. 在每個 Prod 帳號的管理員 IAM Role 上附加 AdministratorAccess，用帳號內的 Allow 抵銷 SCP 的 Deny
• D. 將 Prod 帳號移出 Organizations，改由各帳號自行用 IAM Policy 管理啟動 EC2 的權限

問題 2

某公司的資安團隊要求，Organizations 底下所有成員帳號的 CloudTrail 稽核紀錄都不得被關閉、刪除或改寫設定——這條規則必須連各帳號掛著 AdministratorAccess 的管理員、甚至該成員帳號的 root user 都無法繞過。目前每個帳號各自維護 IAM Policy，公司希望用管理工作最少（LEAST amount of administrative effort）的方式一次覆蓋現有與未來新增的帳號。

解決方案架構師應該怎麼做？

• A. 在涵蓋這些帳號的 OU 掛一條 SCP，明確 Deny cloudtrail:StopLogging、cloudtrail:DeleteTrail 與 cloudtrail:UpdateTrail，並保留該 OU 預設的 FullAWSAccess
• B. 在每個成員帳號的所有 IAM User 與 Role 上設定 Permission Boundary，拒絕 CloudTrail 的停止、刪除與更新操作
• C. 在每個成員帳號部署一條 AWS Config 規則，偵測到 trail 被停止時觸發自動修復，重新開啟記錄
• D. 在 management account 建立一份 Deny CloudTrail 變更的 IAM Policy，直接附加到所有成員帳號的管理員身份上

問題 3

某公司的資料分析團隊在帳號 A 運行一個每小時執行的 ETL 工作，需要讀取帳號 B 中的一個 S3 bucket 與一個 DynamoDB table。資安部門要求：只允許帳號 A 的 ETL 執行 Role 存取，帳號 A 內其他身份不得存取；不允許任何長期有效的憑證離開帳號 B；所有跨帳號的服務都用同一種機制管理，並且帳號 B 的 CloudTrail 必須能看到「哪個來源身份、在什麼時間」取得了存取權。一位解決方案架構師需要在維運負擔最低（LEAST operational overhead）的前提下設計這個存取方式。

哪一個方案最符合需求？

• A. 在帳號 B 的 S3 bucket policy 與 DynamoDB resource-based policy 中，各自加入 Principal 為帳號 A root（arn:aws:iam::<A>:root）的 Allow 陳述
• B. 在帳號 B 建立一個 IAM User，產生 Access Key 存入帳號 A 的 AWS Secrets Manager，ETL 工作執行時從 Secrets Manager 取出金鑰使用
• C. 在帳號 B 建立一個 IAM Role，Trust Policy 的 Principal 限定為帳號 A 的 ETL 執行 Role ARN，並在帳號 A 的 ETL Role 上附加允許對該 Role 執行 sts:AssumeRole 的 Policy
• D. 使用 AWS RAM 將帳號 B 的 S3 bucket 與 DynamoDB table 共享給帳號 A，並在帳號 A 接受對應的 resource share

問題 4

某公司在 Organizations 的 Root 掛了一條 SCP，明確 Deny cloudtrail:StopLogging 與 cloudtrail:DeleteTrail，所有成員帳號都已確認無法關閉 CloudTrail。一次內部稽核卻發現，management account 裡一位掛著 AdministratorAccess 的工程師成功停止了該帳號的 trail。進一步調查發現，這家公司把好幾個正式環境的工作負載和十幾位工程師的 IAM User 都放在 management account 裡。

解決方案架構師應該建議哪兩項做法，以最有效降低這類風險？（選擇兩項）

• A. 將正式環境的工作負載與大多數工程師的身份遷移到成員帳號，management account 只保留組織管理用途並強制 MFA
• B. 把這條 SCP 從 Root 卸除，改為直接附加到 management account 上
• C. 在 management account 內對所有 IAM User 與 Role 附加一份 IAM Policy，明確 Deny cloudtrail:StopLogging 與 cloudtrail:DeleteTrail
• D. 在 Root 的 SCP 中加入 Principal 元素，明確指定 management account 的帳號 ID，讓 SCP 也套用到它
• E. 在 management account 啟用 AWS Config 規則，偵測到 trail 被停止時自動重新開啟

問題 5

某公司（帳號 B）採購了一家第三方監控 SaaS，廠商要求帳號 B 建立一個 IAM Role 供廠商的 AWS 帳號 assume。資安團隊查看廠商文件後發現，廠商用同一個 Role 服務所有客戶；他們擔心如果有另一位客戶在廠商的設定頁面填入帳號 B 的 Role ARN，廠商的系統就可能拿著那位客戶的請求來 assume 帳號 B 的 Role。公司要求用最安全（MOST secure）的方式設定這個 Role 的 Trust Policy。

解決方案架構師應該怎麼設定？

• A. 將 Trust Policy 的 Principal 設為廠商的帳號 ID，並在帳號 B 端用 CloudTrail 監控所有 AssumeRole 事件
• B. 將 Trust Policy 的 Principal 限定為廠商指定的 Role ARN，並加入 Condition 要求 sts:ExternalId 必須等於帳號 B 產生、只登錄在廠商設定頁面的識別值
• C. 將 Trust Policy 的 Principal 設為 *，改由附加在 Role 上的 IAM Policy 限制它能執行的動作範圍
• D. 不建立 Role，改在帳號 B 建立一個 IAM User，將 Access Key 交給廠商並要求每 90 天輪替

💡 解答

1. B

SCP 的有效範圍是 Root 到帳號路徑上每一層 SCP 的交集，所以要讓 Prod 能啟動 EC2，唯一的辦法是讓 Deny 不再出現在 Prod 的路徑上：把那條 Deny 從「Workloads」改掛到「Dev」，Dev 仍被擋、Prod 自然放行，不用碰任何帳號內的設定。

A 是最常見的誤解：子 OU 的 Allow 開不回父層的 Deny，因為 SCP 是交集、不是「離帳號近的優先」。C 是另一個誤解：帳號內的 IAM Policy 不管多寬，都蓋不過 SCP 的天花板。D 技術上能達到目的，但等於放棄整個 Organizations 的治理，維運負擔和風險都最高。

2. A

SCP 作用於成員帳號內的所有 IAM principal，包含該成員帳號的 root user，而且 explicit Deny 沒有任何帳號內的 Allow 能蓋過；掛在 OU 上一次生效，未來新加入這個 OU 的帳號自動繼承。要注意 Deny 要一起涵蓋 DeleteTrail 和 UpdateTrail，只擋 StopLogging 還是能用刪除或改寫設定繞過；同時保留 FullAWSAccess，否則整個 OU 會什麼都不能做。

B 做不到題目要求：Permission Boundary 只作用於 IAM User／Role，管不到 root user，而且要每個帳號、每個身份各設一次。C 是偵測型的事後補救，不是預防，trail 被關到重新開啟之間的紀錄已經沒了。D 行不通：IAM Policy 是帳號內的，不能從 management account 附加到其他帳號的身份上。

3. C

跨帳號 AssumeRole 的臨時憑證有時效、沒有長期金鑰離開帳號 B；Trust Policy 的 Principal 直接鎖定帳號 A 的那一個 Role ARN；S3 和 DynamoDB 都透過同一個 Role 授權；帳號 B 的 CloudTrail 會記錄 AssumeRole 事件（含來源 Role ARN 與時間），四條要求一次滿足。

A 技術上可行，也能靠 CloudTrail 的 S3 data events 看到呼叫者，但 Principal 寫成帳號 A 的 root 等於放行 A 帳號內所有身份，違反「只允許 ETL Role」；而且兩個服務要各自維護一份 resource-based policy。B 違反「不允許長期憑證離開帳號 B」，還要自行處理 Access Key 輪替。D 是常見誤解：AWS RAM 支援共享 subnet、Transit Gateway 這類特定資源，S3 bucket 和 DynamoDB table 不透過 RAM 共享。

4. A、C

SCP 從設計上就不作用於 management account，不論掛在 Root 還是直接掛在它身上都一樣。所以能做的是兩件事：一是縮小 management account 的攻擊面（A，這也是 AWS 的官方建議——management account 只做組織管理、不放工作負載）；二是在 management account 內用 IAM Policy 自己補上 Deny（C，這是唯一能在該帳號內生效的機制）。

B 和 D 都是對 SCP 的誤解：SCP 對 management account 無效，而且 SCP 根本沒有 Principal 元素可以指定帳號。E 是偵測型補救，trail 停止到重新開啟之間的紀錄已經遺失，不算「降低風險」的預防措施。

5. B

題目描述的就是 confused deputy 問題：廠商是「被利用的代理人」，另一位客戶只要知道帳號 B 的 Role ARN 就可能透過廠商的系統冒用。解法是兩層：Principal 鎖定廠商的特定 Role（不只是帳號 ID），再加上 sts:ExternalId 條件——廠商在替帳號 B 發出 AssumeRole 時必須帶上帳號 B 登錄的識別值，其他客戶的設定帶不出這個值，請求就會被拒。ExternalId 不是密碼，它的作用是讓廠商分辨「這次是替哪個客戶」，所以要和 Principal 限定一起用。

A 只有事後監控、沒有預防。C 把 Principal 開成 * 等於任何 AWS 帳號都能嘗試 assume。D 放棄了臨時憑證，長期 Access Key 交到廠商手上是更大的外洩面，輪替也只是縮短外洩窗口。