IAM 的心智模型

IAM（Identity and Access Management）是雲端平台用來回答「某個身分能不能對某個資源做某件事」的授權系統。它把授權拆成三個獨立的零件：identity（身分，發起動作的主體）、policy（政策，描述允許或拒絕的規則）、role（角色，一組可以被臨時取得的權限集合）。理解這三者的分工，是後面所有憑證決策的前提。

identity：長期主體 vs 臨時假扮

identity 分兩類，這個區分在後面設計權限邊界時會反覆用到。一類是 user，代表一個長期存在的主體，通常對應到一個真人或一個固定的服務帳號，本身可以持有長期憑證（密碼或 access key）。另一類是 role，代表一組權限的暫時授予 — 沒有自己的長期密碼，而是讓某個被信任的身分「假扮（assume）」成它、換取一段有時效的臨時憑證。

把 identity 想成「護照」和「通行證」的差別：user 是護照，長期有效、全程攜帶；role 是通行證，到了管制區域臨時換發、離開就失效。多數安全事故源自於把通行證當護照用 — 某個 role 被長期假扮且從未被撤回，或某個 user 持有永不輪替的 access key。

policy：描述「允許對什麼做什麼」

policy 是貼在 user 或 role 上的規則文件，列出 Action（能做什麼，如 s3:GetObject）、Resource（對哪個資源，如特定 bucket 的 ARN）、Effect（Allow 或 Deny）。一條 policy 可以包含多個 statement，每條 statement 描述一組操作許可。

1# 最小權限範例：CI 只能讀寫特定 bucket，不給整個 S3
2data "aws_iam_policy_document" "ci_artifacts" {
3  statement {
4    effect    = "Allow"
5    actions   = ["s3:GetObject", "s3:PutObject"]
6    resources = ["arn:aws:s3:::myapp-artifacts/*"]
7  }
8}

這段 policy 只允許對 myapp-artifacts 這一個 bucket 做讀寫。如果寫成 resources = ["*"]，同一把身分被攻破時，攻擊者就能讀寫帳號內所有 bucket — 差別不在語法，在 Resource 欄位收到多緊。

role：臨時身分的載體

role 本身不持有長期密碼。它靠 trust policy（信任政策）定義「誰能假扮我」，靠 permissions policy 定義「假扮後能做什麼」。trust policy 和 permissions policy 是兩份獨立的文件，分別回答「誰進得來」與「進來後能做什麼」。

 1# trust policy：只允許 ECS 服務假扮此 role
 2data "aws_iam_policy_document" "ecs_trust" {
 3  statement {
 4    actions = ["sts:AssumeRole"]
 5    principals {
 6      type        = "Service"
 7      identifiers = ["ecs-tasks.amazonaws.com"]
 8    }
 9  }
10}
11
12resource "aws_iam_role" "api_task" {
13  name               = "api-task-prod"
14  assume_role_policy = data.aws_iam_policy_document.ecs_trust.json
15}

trust policy 裡的 principals 決定能進門的身分。上面這段把進門權限限給 ECS 服務本身，意味著只有跑在 ECS 上的 task 才能取得這個 role 的臨時憑證 — 一個在本地筆電跑的程式呼叫 AssumeRole 會被拒絕。

最小權限：持續收斂而非一次設定

最小權限（least privilege）是貫穿整套系統的設計原則：一個身分只應該拿到完成它本職工作所需的最小權限集合。多一個 action 是多一條攻擊面，多一個 resource 是多一個爆炸半徑。

最小權限是持續收斂的過程，而非一次設定就結束的靜態狀態。服務初期常為了快速上線給寬鬆權限 — 一個新的 ECS task role 掛上 AmazonS3FullAccess 讓它能跑起來，半年後這個 role 實際只用了 s3:GetObject 和 s3:PutObject 兩個 action、針對一個 bucket，但 policy 裡寫的還是全部 S3 操作對所有 bucket。

收斂的工具是 access analyzer。AWS IAM Access Analyzer 能分析 CloudTrail 日誌，列出某個 role 在過去 N 天內實際用了哪些 action 與 resource，據此產出一份建議的最小 policy。用它的步驟是：開著寬 policy 跑一段時間 → 用 access analyzer 產出實際使用清單 → 把 policy 收斂到這份清單 → 確認服務仍正常。

 1# 產出建議 policy：分析 api-task-prod role 過去 90 天的實際用量
 2aws accessanalyzer generate-policy \
 3  --policy-generation-details '{
 4    "principalArn": "arn:aws:iam::123456789012:role/api-task-prod",
 5    "cloudTrailDetails": {
 6      "trailArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/main",
 7      "startTime": "2026-03-01T00:00:00Z",
 8      "endTime": "2026-06-01T00:00:00Z"
 9    }
10  }'

一個快速的盤點方式：列出所有掛著 AdministratorAccess、PowerUserAccess、*FullAccess 這類寬鬆 managed policy 的 role，每個命中都問一次「這個 role 確實需要這些權限嗎」。CI role 的 policy 裡出現 *:* 更是明確的收斂目標。

長期 access key 的風險

長期 access key 是一組沒有到期時間的靜態憑證（access key ID + secret），任何持有它的人或程式都能以對應身分的全部權限呼叫 API，直到有人手動撤銷為止。它最大的問題是「沒有時效」這個性質本身，會在三個方向上累積風險，而且風險隨團隊規模與時間單調上升。

散落

長期 key 為了被程式使用，會被複製進 .env 檔、CI 設定、本機 ~/.aws/credentials、Slack 訊息、甚至誤推進 git 歷史。每多一個副本就多一個外洩點。一把 key 在半年內可能被貼到六個地方 — 部署腳本、兩個 CI 平台的環境變數、某台共用跳板機的 profile、一封交接信、一位已離職同事的筆電 — 而這六個副本沒有任何中央清單能列舉。

權限過大

因為輪替麻煩，團隊傾向給一把 key 配足夠寬的權限「一次搞定」。建立時圖方便掛了 AdministratorAccess，打算「等穩定了再收斂」，但那天從來沒有到來。於是一把本來只該讀 artifact 的 key 同時握有刪除 production 資料庫的能力。

難以輪替

輪替一把長期 key 意味著找出所有副本、同步替換、確認沒有遺漏。這個成本高到讓多數團隊選擇拖延，於是 key 的有效期變成「無限」，外洩後的曝險窗口也跟著變成無限。用一個問題辨認風險：能不能在五分鐘內回答「這把 key 被用在哪些地方、上次輪替是什麼時候」？答不出來，它就已經是技術債。

常見的散落路徑：部署腳本使用的 admin key 留在 CI 環境變數，建立者離職後沒人知道這把 key 的存在與權限範圍。這類情境的風險在於外洩後沒有手段限制影響範圍 — key 的權限有多大，影響範圍就有多大。用 credential report 定期盤點帳號內所有 access key 的建立時間與使用時間，見模組負一：還沒有 infra 的環境。

長期憑證風險的實際規模可以從兩個案例看到。Snowflake 2024 事件中，攻擊者利用外洩的長期憑證登入缺少 MFA 的客戶環境，執行大量資料匯出，造成跨客戶的資料竊取與勒索（見 Snowflake 2024：憑證濫用與資料竊取）。LastPass 2022 事件則顯示備份路徑的憑證管理缺口會讓影響範圍沿信任鏈擴散——開發環境取得的資訊被用來存取雲端備份，整條路徑的金鑰隔離不足是根因（見 LastPass 2022：備份路徑與鏈式入侵）。兩個案例的共同教訓是：長期憑證的風險不止於外洩本身，而在於外洩後缺乏限制影響範圍的機制。

OIDC：給 CI/CD 的短期憑證

OIDC（OpenID Connect）聯合讓 CI/CD 平台用一段每次執行才簽發、幾分鐘後就失效的短期憑證取代長期 key，從根本上消掉「靜態密鑰散落」這個問題。它的運作方式是建立信任關係：雲端帳號信任某個外部 identity provider（如 GitHub Actions 的 OIDC issuer），當管線執行時，CI 平台簽發一個帶有可驗證 claim 的 token（描述「這是哪個 repo、哪個 branch、哪個 workflow 在跑」），雲端用這個 token 換出一段臨時憑證。沒有任何長期 secret 需要被儲存在 CI 設定裡。

trust policy 的收斂

關鍵設計在 role 的 trust policy 上 — 它規定「哪個外部身分被允許假扮成這個 role」。trust policy 要用 token 的 claim 把假扮條件收到最緊。

 1# OIDC trust policy：只允許特定 repo 的 main branch 假扮此 role
 2data "aws_iam_policy_document" "ci_trust" {
 3  statement {
 4    actions = ["sts:AssumeRoleWithWebIdentity"]
 5
 6    principals {
 7      type        = "Federated"
 8      identifiers = [aws_iam_openid_connect_provider.github.arn]
 9    }
10
11    condition {
12      test     = "StringEquals"
13      variable = "token.actions.githubusercontent.com:aud"
14      values   = ["sts.amazonaws.com"]
15    }
16
17    condition {
18      test     = "StringLike"
19      variable = "token.actions.githubusercontent.com:sub"
20      values   = ["repo:my-org/my-app:ref:refs/heads/main"]
21    }
22  }
23}

每個 condition 各守一段邊界。aud 的 StringEquals 確認 token 是發給 AWS STS 的（防止用錯 audience 的 token 闖入）。sub 的 StringLike 把假扮限定在特定 repo 的 main branch — 設成 repo:my-org/* 等於讓組織內任何 repo 的任何 branch 都能假扮這個 role，這是常見的設定陷阱。

收斂 trust policy 的判讀問法是：「如果 my-org 底下某個公開 fork 跑了一個惡意 workflow，它能不能假扮這個 role？」如果答案是能，sub 條件就太鬆了。

分離 plan 與 apply 的 role

進一步的收斂是替 plan 和 apply 分別建立 role。plan 只需要唯讀存取（讀 state、讀雲端現況），apply 需要寫入權限。把兩者分成獨立 role，讓 PR 階段的 CI 用唯讀 role 跑 plan、合併後才用寫入 role 跑 apply。任何拿到 plan role 的 token 無法修改基礎設施。

 1# plan role：只需讀取 state 與雲端現況
 2resource "aws_iam_role" "ci_plan" {
 3  name               = "infra-ci-plan"
 4  assume_role_policy = data.aws_iam_policy_document.ci_trust.json
 5}
 6
 7resource "aws_iam_role_policy_attachment" "ci_plan_read" {
 8  role       = aws_iam_role.ci_plan.name
 9  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
10}
11
12# apply role：需要寫入權限，trust policy 限定只有 main branch
13resource "aws_iam_role" "ci_apply" {
14  name               = "infra-ci-apply"
15  assume_role_policy = data.aws_iam_policy_document.ci_trust_main_only.json
16}

這一章把 role 與 trust policy 設計好，OIDC 的實際回報要到模組七：infra 走 PR 流程建管線時才兌現 — 屆時管線用這裡定義好的 role 取得短期權限執行 plan 與 apply，CI 環境裡不需要存任何 access key。

權限邊界設計

權限邊界是把不同類型的身分與不同環境之間的權限刻意隔開，讓任何一個身分被攻破時，爆炸半徑都被限制在它本職的範圍內。邊界設計有兩條軸線需要分別處理：人 vs 機器，以及環境之間。

人 vs 機器

兩者的存取模式根本不同，混在同一個身分上會同時喪失兩邊的保護。

人類身分需要互動式登入、應該強制 MFA、權限隨職責變動，且通常透過 SSO 集中管理。機器身分（CI runner、ECS task、Lambda function）需要的是程式化、無人值守的存取，應該用 role 假扮取得短期憑證，永遠不該配長期 key。

機器身分還要再依「跑在哪裡」分兩類。跑在雲上的 workload（EC2 instance、ECS task、Lambda）由平台直接把 role 綁在執行環境上 — AWS 用 instance profile 把 role 掛在 EC2、用 task role 掛在 ECS task，workload 從實例 metadata 端點自動取得輪替的短期憑證。跑在雲外的 CI/CD（GitHub Actions、GitLab CI）拿不到實例 metadata，需要前面那套 OIDC 信任關係換憑證。

一個常見陷阱是工程師用自己的個人 key 跑自動化腳本 — 這把人的廣泛權限直接送進了無人值守的執行環境，MFA 保護形同虛設（API 呼叫不需要 MFA challenge），權限範圍比任何 CI role 都大。

環境之間

環境之間的邊界，目的是讓 production 的權限與 staging、dev 完全不交叉。驗證邊界的方式是用 dev 環境的 CI role 嘗試列出或刪除 production 的資源——能做到，就代表邊界沒有建立。

帳號級護欄：SCP

Organizations 把環境拆成獨立帳號，再用 SCP（Service Control Policy）對整個帳號或組織單位設定權限天花板，連帳號內的管理員都越不過去。SCP 是 deny-based 的頂層限制 — 它不授予任何權限，只限制「即使有人給了權限也不准做」。

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyLeaveOrg",
 6      "Effect": "Deny",
 7      "Action": ["organizations:LeaveOrganization"],
 8      "Resource": "*"
 9    },
10    {
11      "Sid": "DenyDisableCloudTrail",
12      "Effect": "Deny",
13      "Action": [
14        "cloudtrail:StopLogging",
15        "cloudtrail:DeleteTrail"
16      ],
17      "Resource": "*"
18    }
19  ]
20}

這份 SCP 掛在整個組織底下的所有帳號上，確保任何帳號都不能關閉稽核日誌或退出組織 — 即使該帳號裡有人持有 AdministratorAccess。SCP 的定位是組織層的不可踰越底線。

Role 級護欄：Permissions Boundary

Permissions Boundary 是掛在單一 role 上的權限上限。它跟 SCP 的差別在粒度：SCP 管整個帳號，Permissions Boundary 管單一身分。即使有人後來給一個 role 貼了過寬的 policy，Boundary 也會擋住超出上限的部分。

 1# Permissions Boundary：CI role 最多只能操作特定服務
 2resource "aws_iam_policy" "ci_boundary" {
 3  name = "ci-boundary-prod"
 4  policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [
 7      {
 8        Effect   = "Allow"
 9        Action   = ["ecs:*", "ecr:*", "s3:*", "logs:*"]
10        Resource = "*"
11      },
12      {
13        Effect   = "Deny"
14        Action   = ["iam:*", "organizations:*", "account:*"]
15        Resource = "*"
16      }
17    ]
18  })
19}
20
21resource "aws_iam_role" "ci_apply" {
22  name                 = "infra-ci-apply"
23  assume_role_policy   = data.aws_iam_policy_document.ci_trust.json
24  permissions_boundary = aws_iam_policy.ci_boundary.arn
25}

SCP 與 Permissions Boundary 疊起來的效果是：SCP 在帳號層鎖住最危險的操作（關日誌、退組織），Boundary 在 role 層限制單一身分最多能做什麼，permissions policy 在這兩層天花板之內授予實際需要的權限。三者各管一層，缺一層就少一道屏障。

身分控制面本身的韌性在兩個案例中被檢驗。Azure AD 2021 事件中，身分服務的控制面故障導致所有依賴身份驗證的服務同時受影響，事故處理需要在身份恢復與服務降級策略之間排優先序（見 Azure AD：Identity Control-plane 事件）。Microsoft Storm-0558 事件則顯示簽章金鑰一旦失守，token 驗證的信任鏈會跨租戶失效，修復不只是修補漏洞、而是重建整條 key lifecycle 與 issuer 驗證流程（見 Microsoft：Storm-0558 簽章金鑰事件）。這兩個案例揭露的是：權限邊界只管「某個身分能做什麼」，但身分系統本身的控制面如果失效，所有建立在它之上的邊界都跟著失效。

環境隔離的更完整實作（帳號結構、模組化參數）會在模組四：環境分離與模組化展開。

身分層 vs 應用層 secret 的邊界

這一章談的是身分與憑證 — 誰是誰、怎麼證明、能動什麼。憑證背後引用的應用層 secret（資料庫密碼、第三方 API key）怎麼安全儲存與注入，屬於模組八：治理好習慣的 secret management 範圍。兩者的交集是：身分層決定「誰能讀到 secret store」，secret 層決定「secret 怎麼存與輪替」。把 IAM role 的 policy 收到只能讀取該服務路徑下的 secret（如 prod/payments/*），是同時落實最小權限與 secret 隔離的結合點。

身分與憑證的地基備妥後，下一步是劃清服務之間的網路邊界——這正是模組三：網路地基的範圍。

跨分類引用

• → 模組負一：還沒有 infra 的環境：長期 key 盤點與護欄
• → 模組三：網路地基：身分備妥後，劃清服務之間的網路邊界
• → 模組四：環境分離與模組化：環境之間的帳號結構與隔離強度
• → 模組七：infra 走 PR 流程：CI/CD 管線用 OIDC 取得短期權限
• → 模組八：治理好習慣：應用層 secret 的儲存與引用
• → backend 模組七：資安與資料保護：Secret Management 與憑證管理交集
• → Access Key 輪替手冊：key 盤點與輪替的操作步驟
• → OIDC Trust Policy 設定指南：GitHub Actions OIDC 的 step-by-step 設定

單帳號 vs 多帳號：什麼時候該切

單帳號在早期是合理的起點 — 資源少、人少、管理成本低。帳號邊界帶來的隔離收益要跟它的管理成本比較：每多一個帳號就多一份 CloudTrail、多一組 IAM 基線、多一個需要管理的 state backend。

三個訊號出現時，單帳號的邊際風險開始超過多帳號的管理成本：

第一，production 和 dev 的資源開始互相影響。一個 dev 環境的壓力測試把帳號的 EC2 instance quota 吃滿，production 的 auto-scaling 因為拿不到新 instance 而失敗 — 這個故障跟程式碼品質無關，純粹是兩個環境共用同一組配額。帳號分開後，dev 吃滿自己的 quota 不會碰到 production。

第二，權限邊界用 IAM 已經管不住。一個工程師的 IAM policy 限制他只能操作 env=dev 的資源，但他手滑用了一個沒有 tag 條件的 policy、或者某個 IAM role 的 trust policy 太寬，他就能碰到 production 資源。帳號邊界是比 IAM policy 更硬的護欄 — 即使 IAM 設定出錯，帳號邊界本身就是物理隔離。

第三，合規或稽核要求明確區分環境。SOC 2 或金融監管可能要求 production 環境有獨立的存取紀錄和變更審計，與開發環境完全分離。同帳號裡做這件事要靠大量的 IAM 條件和 CloudTrail filter，跨帳號則天然滿足。

OU 結構：帳號怎麼分群

AWS Organizations 用 Organizational Unit（OU）把帳號分群，OU 是 SCP 的掛載點 — 一條 SCP 掛在 OU 上，底下所有帳號都受約束。OU 的設計決定了護欄的作用範圍。

常見的 OU 拓撲有四層：

環境怎麼對應到帳號，跟模組四的環境分離是同一個問題的不同層次 — 模組四用目錄和 state 分離環境的 IaC，這裡用帳號分離環境的雲端資源。兩者可以疊加：每個帳號裡的 IaC 仍然用獨立目錄和 state 管理。

OU 結構的設計原則是「按信任等級分群、按職責隔離」。Prod 跟 NonProd 分開是因為信任等級不同（prod 的 SCP 更嚴格）。Security 獨立是因為它的職責是「監控其他所有帳號」— 如果 security 帳號被攻破，攻擊者能修改稽核日誌來掩蓋行蹤，所以它的存取權限要收到最小。

一個常見的錯誤是把 OU 當成組織架構的映射（按部門分 OU）。OU 的分群依據是安全邊界和 SCP 策略，不是彙報線。兩個部門如果需要相同的 SCP，它們的帳號應該在同一個 OU 底下；一個部門如果有 prod 和 dev 環境，它們應該在不同 OU 底下。

SCP：連管理員都越不過的護欄

Service Control Policy（SCP）是掛在 OU 或帳號上的權限天花板。它跟 IAM policy 的差別是層級：IAM policy 控制「這個身分能做什麼」，SCP 控制「這個帳號裡的任何身分最多能做什麼」。即使帳號內的 root user 或 AdministratorAccess role，也受 SCP 約束。

SCP 的設計策略以 deny-list 為主 — 預設允許所有動作，用 SCP 明確禁止少數高風險操作。相比 allow-list（預設禁止、逐一開放），deny-list 的管理成本低得多，因為 AWS 的 service 和 action 數量龐大，逐一列舉允許清單容易漏、也容易在新服務上線時擋住正常使用。

三條適合從第一天就掛上去的 SCP：

禁止關閉 CloudTrail

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [{
 4    "Sid": "DenyCloudTrailDisable",
 5    "Effect": "Deny",
 6    "Action": [
 7      "cloudtrail:StopLogging",
 8      "cloudtrail:DeleteTrail",
 9      "cloudtrail:UpdateTrail"
10    ],
11    "Resource": "*"
12  }]
13}

CloudTrail 是事後追溯「誰做了什麼」的唯一來源。攻擊者入侵帳號後的第一步往往是關掉稽核日誌來掩蓋行蹤，用 SCP 禁止這個動作，讓日誌在帳號層級不可關閉。

禁止離開指定 region

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [{
 4    "Sid": "DenyOutsideRegion",
 5    "Effect": "Deny",
 6    "NotAction": [
 7      "iam:*",
 8      "sts:*",
 9      "organizations:*",
10      "support:*"
11    ],
12    "Resource": "*",
13    "Condition": {
14      "StringNotEquals": {
15        "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
16      }
17    }
18  }]
19}

限制資源只能建在指定 region，避免有人在沒人注意的 region（如 af-south-1）開資源 — 不管是誤操作還是攻擊者利用。NotAction 裡排除 IAM 和 STS 等全域服務，因為它們不分 region。us-east-1 通常要保留，因為 CloudFront、ACM（global cert）等服務的 API 端點在 us-east-1。

禁止刪除 VPC Flow Logs

1{
2  "Version": "2012-10-17",
3  "Statement": [{
4    "Sid": "DenyDeleteFlowLogs",
5    "Effect": "Deny",
6    "Action": "ec2:DeleteFlowLogs",
7    "Resource": "*"
8  }]
9}

VPC Flow Logs 記錄網路層的流量軌跡，是安全事件排查的關鍵資料。跟 CloudTrail 的邏輯一樣 — 稽核資料不允許被帳號內的操作者刪除。

SCP 的繼承模型

SCP 沿著 OU 樹向下繼承：掛在 Root OU 的 SCP 對所有帳號生效，掛在子 OU 的 SCP 只對該 OU 底下的帳號生效。多層 SCP 的效果是交集 — 父 OU 禁止的動作，子 OU 無法用 SCP 重新允許。這個交集模型讓安全團隊能在頂層設「絕對底線」，各子 OU 只能在底線之內進一步收斂、不能放寬。

把 SCP 用 Terraform 管理：

 1resource "aws_organizations_policy" "deny_cloudtrail_disable" {
 2  name        = "deny-cloudtrail-disable"
 3  description = "Prevent anyone from stopping or deleting CloudTrail"
 4  type        = "SERVICE_CONTROL_POLICY"
 5  content     = file("policies/deny-cloudtrail-disable.json")
 6}
 7
 8resource "aws_organizations_policy_attachment" "root_deny_cloudtrail" {
 9  policy_id = aws_organizations_policy.deny_cloudtrail_disable.id
10  target_id = aws_organizations_organization.main.roots[0].id
11}

SCP 的 JSON 存在 repo 的 policies/ 目錄，變更走 PR review，讓護欄本身也在版本控制與審查流程裡。

控制面 token 的治理是 SCP 護欄之外需要同步處理的議題。Cloudflare 2023 事件中，控制面 token 的生命週期與最小權限沒有對齊，機器憑證形成跨服務的高權限風險（見 Cloudflare：Control-plane Token 事件）。Okta 2023 事件則顯示身份治理若只覆蓋生產系統而忽略支援工具鏈，支援系統的 session 和 token 會成為跨租戶的風險放大點（見 Okta：Support System 事件）。兩個案例的共同教訓是：SCP 管的是 AWS API 層的動作上限，但 token / session 這類應用層的機器憑證需要獨立的 lifecycle 治理。

帳號工廠：每個新帳號自帶安全基線

跨帳號策略（帳號數量、OU 結構、SCP 規則）屬於影響全組織的架構決策，建議在實施前取得技術主管或 CTO 的對齊。SCP 一旦套用到 OU，該 OU 下所有帳號立即受影響，回退需要修改 SCP 或移動帳號到不同 OU。

手動建帳號的問題跟手動建資源一樣 — 每次都靠人記得「開完帳號後要開 CloudTrail、要刪預設 VPC、要設基線 IAM role」。帳號工廠（Account Factory）把這些步驟自動化成一個可重複的流程：建一個帳號、自動套用安全基線、自動加進正確的 OU。

AWS Control Tower 是 AWS 提供的帳號工廠實作，它包裝了 Organizations、SCP、Config Rules 和 CloudFormation StackSet，提供一個「建帳號 → 自動配置」的流水線。它的好處是一鍵啟用、內建一組 AWS 建議的護欄；代價是它對 OU 結構和 SCP 有自己的意見，跟團隊已有的設計可能衝突，而且它用 CloudFormation StackSet 做基線配置，跟 Terraform 管理的資源需要劃清邊界。

不用 Control Tower 時，帳號工廠可以用 Terraform + 腳本自建。核心是一個 module 接受帳號名稱和 OU 作為參數，產出：帳號建立、CloudTrail trail、預設 VPC 刪除、基線 IAM role（讓管理帳號能 assume 進來做維護）、Config recorder 啟用。

每個新帳號該自帶的安全基線至少包含：

• CloudTrail 開啟並寫到集中的 Log Archive 帳號
• 預設 VPC 刪除（預設 VPC 的 security group 全通、CIDR 固定且跨帳號重複，留著是隱患）
• 基線 IAM role 讓管理帳號能 assume 進來
• Config recorder 啟用（記錄資源設定變更歷史）
• 掛上所屬 OU 的 SCP

導入時程參考：初次設定 Organizations + OU 結構 + day-1 SCP 約需 2-3 天；之後每開一個新帳號（含基線配置）約需 2-4 小時。

跨帳號存取：role assumption

多帳號架構裡，人或自動化需要在不同帳號之間切換操作。跨帳號存取用 IAM role 的 trust policy 實現 — 目標帳號建一個 role，trust policy 允許來源帳號的特定身分 assume 這個 role。

AWS Organizations 在建子帳號時會自動建一個 OrganizationAccountAccessRole，讓管理帳號的 admin 能 assume 進去。這個 role 的權限是 AdministratorAccess — 它的用途是初始設定和緊急存取，日常操作不該用它。日常的跨帳號存取應該建立職責專用的 role：部署用的 role 只有部署相關權限、唯讀稽核用的 role 只有 read 權限。

 1resource "aws_iam_role" "deploy_from_cicd" {
 2  name = "deploy-from-cicd-account"
 3
 4  assume_role_policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [{
 7      Effect    = "Allow"
 8      Principal = { AWS = "arn:aws:iam::111111111111:role/cicd-runner" }
 9      Action    = "sts:AssumeRole"
10      Condition = {
11        StringEquals = { "sts:ExternalId" = "deploy-prod-2026" }
12      }
13    }]
14  })
15}

ExternalId 是防止 confused deputy 攻擊的機制 — 如果 trust policy 只用帳號 ID 驗證，任何能在來源帳號建 role 的人都能 assume 目標 role。加上 ExternalId 讓 assumption 多一個只有雙方知道的驗證值。

跨帳號存取的設計與模組二的 OIDC 短期憑證互補 — OIDC 解決「雲外到雲內」的身分聯合（CI/CD → AWS），role assumption 解決「雲內帳號之間」的身分切換。

帳單整合

Organizations 的附帶收益是合併帳單（Consolidated Billing）。所有子帳號的用量合併到管理帳號的帳單裡，一方面簡化付款流程（一張帳單而非多張），另一方面可以享受跨帳號的用量折扣 — 例如 S3 的定價階梯是看總用量，三個帳號各用 1TB 分開計費跟合併成 3TB 計費，後者的單位價格更低。

合併帳單跟成本歸屬的 tagging 互補。合併帳單讓所有費用匯到一張帳單，tagging 讓這張帳單能拆到各團隊和用途 — 這兩件事在模組八的成本可見性展開。帳號邊界本身也是一層成本隔離：每個帳號的用量可以獨立查看，讓「這個帳號這個月花了多少」變成自動可查、不需要依賴 tag。

跨分類引用

• → 身分與憑證地基：IAM role / policy / OIDC 是帳號內的身分控制，本篇是帳號間的隔離
• → 環境分離與模組化：目錄與 state 分離環境的 IaC，帳號分離是雲端資源層的對應
• → 成本可見性：合併帳單 + tagging 的成本歸屬
• → infra 走 PR 流程：SCP 的 JSON 存 repo、變更走 PR review

IAM 的心智模型

IAM（Identity and Access Management）是雲端平台用來回答「某個身分能不能對某個資源做某件事」的授權系統。它把授權拆成三個獨立的零件：identity（身分，發起動作的主體）、policy（政策，描述「允許/拒絕對哪些資源做哪些動作」的規則）、role（角色，一組可以被臨時取得的權限集合）。理解這三者的分工，是後面所有憑證決策的前提。

identity 分兩類，這個區分在後面設計權限邊界時會反覆用到。一類是 user，代表一個長期存在的主體，通常對應到一個真人或一個固定的服務帳號，本身可以持有長期憑證。另一類是 role，代表一組權限的暫時授予 — 沒有自己的長期密碼，而是讓某個被信任的身分「假扮（assume）」成它、換取一段有時效的臨時憑證。policy 則是貼在 user 或 role 上的規則文件，列出 Action（能做什麼，如 s3:GetObject）、Resource（對哪個資源）、Effect（允許或拒絕）。

最小權限（least privilege）是貫穿這套系統的設計原則：一個身分只應該拿到完成它本職工作所需的最小權限集合，多一個 action、多一個 resource 都是攻擊面。最小權限是持續收斂的過程，而非一次設定就結束的靜態狀態 — 服務初期常為了快速上線給寬鬆權限，之後要靠 access analyzer 這類工具觀察「實際用到哪些 action」，再把沒用到的權限收掉。判讀訊號很直接：如果一個 CI role 的 policy 裡有 *:* 或 AdministratorAccess，它就是下一個 incident 的入口。

1# 最小權限：CI 只能讀寫特定 bucket、不給整個 S3
2data "aws_iam_policy_document" "ci_artifacts" {
3  statement {
4    actions   = ["s3:GetObject", "s3:PutObject"]
5    resources = ["arn:aws:s3:::myapp-artifacts/*"]
6  }
7}

長期 access key 的風險

長期 access key 是一組沒有到期時間的靜態憑證（access key ID + secret），任何持有它的人或程式都能以對應身分的全部權限呼叫 API，直到有人手動撤銷為止。它最大的問題是「沒有時效」這個性質本身，會在三個方向上累積風險，而且風險隨團隊規模與時間單調上升。

第一是散落。長期 key 為了被程式使用，會被複製進 .env 檔、CI 設定、本機 ~/.aws/credentials、Slack 訊息、甚至誤推進 git 歷史。每多一個副本就多一個外洩點，而你很難盤點清楚一把 key 到底被貼進了多少地方。第二是權限過大。因為輪替麻煩，團隊傾向給一把 key 配足夠寬的權限「一次搞定」，於是一把本來只該讀 artifact 的 key 同時握有刪除 production 資料庫的能力。第三是難以輪替。輪替一把長期 key 意味著找出所有副本、同步替換、確認沒有遺漏，這個成本高到讓多數團隊選擇拖延，於是 key 的有效期變成「無限」，外洩後的曝險窗口也跟著變成無限。

判讀訊號是：如果你無法在五分鐘內回答「這把 key 被用在哪些地方、上次輪替是什麼時候」，它就已經是技術債。早期新創特別容易踩這個坑 — 一個工程師為了讓部署腳本跑起來，在筆電上建了一把 admin key，半年後這把 key 還在 CI 環境變數裡，建立它的人已經離職。這類事故的代價不在於「key 外洩」這個事件本身，而在於外洩之後你沒有任何手段限制爆炸半徑。

OIDC：給 CI/CD 的短期憑證

OIDC（OpenID Connect）聯合讓 CI/CD 平台用一段每次執行才簽發、幾分鐘後就失效的短期憑證取代長期 key，從根本上消掉「靜態密鑰散落」這個問題。它的運作方式是建立信任關係：雲端帳號信任某個外部 identity provider（如 GitHub Actions、GitLab CI 的 OIDC issuer），當管線執行時，CI 平台簽發一個帶有可驗證 claim 的 token（描述「這是哪個 repo、哪個 branch、哪個 workflow 在跑」），雲端用這個 token 換出一段臨時憑證。沒有任何長期 secret 需要被儲存在 CI 設定裡。

關鍵設計在 role 的 trust policy（信任政策）上 — 它規定「哪個外部身分被允許假扮成這個 role」。trust policy 要用 token 的 claim 把假扮條件收到最緊：限定 issuer、限定 audience、限定特定 repo 與 branch。收得太鬆（例如只驗 issuer、不驗 repo）等於任何掛在同一個 CI 平台的專案都能假扮你的 role，這是常見的設定陷阱。

 1# OIDC trust policy：只允許特定 repo 的 main branch 假扮此 role
 2data "aws_iam_policy_document" "ci_trust" {
 3  statement {
 4    actions = ["sts:AssumeRoleWithWebIdentity"]
 5    principals {
 6      type        = "Federated"
 7      identifiers = [aws_iam_openid_connect_provider.github.arn]
 8    }
 9    condition {
10      test     = "StringEquals"
11      variable = "token.actions.githubusercontent.com:aud"
12      values   = ["sts.amazonaws.com"]
13    }
14    condition {
15      test     = "StringLike"
16      variable = "token.actions.githubusercontent.com:sub"
17      values   = ["repo:my-org/my-app:ref:refs/heads/main"]
18    }
19  }
20}

這一章只把 role 與 trust policy 設計好，OIDC 的實際回報要到模組七：infra 走 PR 流程建管線時才兌現 — 屆時管線用這裡定義好的 role 取得短期權限執行 plan 與 apply，CI 環境裡不需要存任何 access key。下一步路由很明確：role 與最小權限的 policy 屬於這裡的地基，管線怎麼觸發、怎麼卡 review 屬於模組七。

權限邊界設計

權限邊界是把不同類型的身分與不同環境之間的權限刻意隔開，讓任何一個身分被攻破時，爆炸半徑都被限制在它本職的範圍內。邊界設計有兩條軸線需要分別處理：人 vs 機器，以及環境之間。

人 vs 機器的邊界，源自兩者的存取模式根本不同。人類身分需要互動式登入、應該強制 MFA、權限隨職責變動，且通常透過 SSO 集中管理而非各自持有 key。機器身分（CI、跑在運算資源上的服務）需要的是程式化、無人值守的存取，應該用 role 假扮取得短期憑證，永遠不該配長期 key。機器身分還要再分跑在哪裡：跑在雲上的 workload（運算實例、容器任務）由平台直接把 role 綁在執行環境上 — AWS 用 instance profile 把 role 掛在 EC2 instance、用 ECS task role 把 role 掛在容器任務，workload 從實例 metadata 自動取得輪替的短期憑證，這是早於 OIDC 就存在的標準解；只有跑在雲外的 CI/CD（如 GitHub Actions）拿不到實例 metadata，才需要前面那套 OIDC 信任關係換憑證。把這兩類混在同一個身分上，會讓你既無法對人強制 MFA，也無法對機器收斂權限。一個常見陷阱是工程師用自己的個人 key 跑自動化腳本 — 這把人的廣泛權限直接送進了無人值守的執行環境。

環境之間的邊界，目的是讓 production 的權限與 staging、dev 完全不交叉，避免一次誤操作或一個被攻破的低敏感環境波及到核心資產。實作上常見的做法是每個環境用獨立的帳號（account）或獨立的 role，部署到 production 的身分拿不到 staging 的資源、反之亦然。這條邊界在 AWS 上有兩層具體機制可以落地：帳號級的護欄用 Organizations 把環境拆成獨立帳號，再用 SCP（Service Control Policy）對整個帳號或組織單位設定權限天花板，連帳號內的管理員都越不過去；role 級的護欄用 Permissions Boundary 這個 IAM 字面功能，給單一 role 設一個權限上限，限制它「最多能拿到什麼」，即使有人後來給它貼了過寬的 policy 也會被天花板擋住。前者收的是帳號與組織的整體範圍，後者收的是單一身分的上限，兩者疊起來才讓「權限邊界」從概念變成擋得住誤設的具體工具。判讀訊號是：如果一個 dev 環境的 CI role 能列出或刪除 production 的資源，邊界就沒有真正建立。環境隔離的更完整實作（帳號結構、模組化參數）會在模組四：環境分離與模組化展開，這裡先確保身分層的權限不跨環境。

這一章談的是身分與憑證 — 誰是誰、怎麼證明、能動什麼。憑證背後引用的應用層 secret（資料庫密碼、第三方 API key）怎麼安全儲存與注入，屬於模組八：治理好習慣的 secret management 範圍，不在這裡處理。兩者的交集是：身分層決定「誰能讀到 secret store」，secret 層決定「secret 怎麼存與輪替」。

章節文章

跨分類引用

• → 模組三：網路地基：身分備妥後，劃清服務之間的網路邊界
• → backend 模組七：資安與資料保護：Secret Management 與這裡的憑證管理交集
• → 模組七：infra 走 PR 流程：CI/CD 用 OIDC 取得短期權限
• → 接手維運：接手時的 credential 盤點與輪替

權限分級：admin / operator / viewer

團隊成員的日常操作權限用三級來劃分，每一級對應不同的操作範圍與風險。分級的依據是「這個角色的日常工作需要碰到什麼層級的資源」，不是職稱或年資。

Admin

Admin 能修改 IAM policy、網路拓撲、帳號層級設定（Organizations、SCP、billing）。這是影響範圍最大的一級——一條 SCP 寫錯可以鎖死整個帳號的操作，一條 IAM policy 開太寬可以讓任何角色取得不該有的權限。

持有 admin 權限的人數應該收斂到最少：通常是平台團隊的 1-2 人加上一個 break-glass 備援角色。Admin 權限不應該是某個人的「日常身分」——即使是平台工程師，日常操作也用 operator 等級，只有在需要改 IAM 或帳號設定時才 assume 到 admin role。

 1# Admin role 的信任政策：只允許特定 IAM user assume
 2data "aws_iam_policy_document" "admin_trust" {
 3  statement {
 4    actions = ["sts:AssumeRole"]
 5    principals {
 6      type        = "AWS"
 7      identifiers = [
 8        "arn:aws:iam::123456789012:user/platform-lead",
 9        "arn:aws:iam::123456789012:user/platform-backup",
10      ]
11    }
12    condition {
13      test     = "Bool"
14      variable = "aws:MultiFactorAuthPresent"
15      values   = ["true"]
16    }
17  }
18}
19
20resource "aws_iam_role" "admin" {
21  name               = "infra-admin"
22  assume_role_policy = data.aws_iam_policy_document.admin_trust.json
23  max_session_duration = 3600  # 1 小時後自動失效
24}

max_session_duration 限制 assume 後的有效時間。Admin session 設 1 小時是讓操作者完成當次任務後權限自動回收，不需要手動登出。MFA 條件確保即使帳號密碼外洩，沒有第二因素也無法提權。

Operator

Operator 能部署服務、修改應用層資源（ECS task、RDS parameter group、S3 lifecycle）、查看與操作日常維運所需的一切。多數工程師的日常身分落在這一級。

Operator 的 policy 用 resource scope 限制它碰不到 IAM 和帳號層級設定——能改 ECS service 但不能改 ECS service 用的 IAM role，能改 RDS 參數但不能改 RDS 的 subnet group。這個邊界讓 operator 的操作失誤影響範圍停在服務層，不會擴散到地基層。

 1data "aws_iam_policy_document" "operator" {
 2  # 允許操作應用層資源
 3  statement {
 4    actions = [
 5      "ecs:UpdateService", "ecs:DescribeServices",
 6      "rds:ModifyDBInstance", "rds:DescribeDBInstances",
 7      "s3:GetObject", "s3:PutObject",
 8      "logs:GetLogEvents", "logs:FilterLogEvents",
 9    ]
10    resources = ["*"]
11  }
12
13  # 明確拒絕碰 IAM 和帳號設定
14  statement {
15    effect = "Deny"
16    actions = [
17      "iam:*",
18      "organizations:*",
19      "account:*",
20    ]
21    resources = ["*"]
22  }
23}

Deny 語句確保即使未來有人不小心把過寬的 managed policy attach 到 operator role，IAM 和帳號操作仍然被擋。Deny 在 IAM 評估中優先於 Allow。

Viewer

Viewer 能讀取 Console、查 log、看 metric dashboard，但不能修改任何資源。適合的角色包括：值班但不需要改設定的 on-call、需要查 log 排查問題的 support 團隊、需要看資源狀態的管理層。

Viewer 用 AWS 的 managed policy ReadOnlyAccess 作為基線，再根據需要排除敏感資料的讀取（例如 Secrets Manager 的 GetSecretValue）。

三級的對應關係：

導入時程參考：三級權限的 IAM role 與 policy 建立約需 1-2 天，包含 trust policy 設定與初次分配。後續的權限變更走版本控制的 PR 流程，讓每次 policy 調整都有提案、審查與歷史紀錄（見infra 走 PR 流程）。

臨時提權（break-glass）

Operator 在日常工作中偶爾需要 admin 層級的操作——排查一個涉及 IAM 的事故、緊急修改一條 security group 規則、回應安全事件。常態性地把 admin 權限開給所有 operator 會讓三級分級失效，但每次都等 admin 角色的人上線又太慢。Break-glass 流程處理的就是這個中間地帶。

機制

Break-glass 的實作是一個平時不被 assume 的 admin role，加上一套提權紀錄。Operator 在需要時 assume 這個 role，取得一段時效有限的 admin session。這個 assume 動作會在 CloudTrail 留下紀錄（誰、什麼時候、session 多長），事後可稽核。

1resource "aws_iam_role" "break_glass" {
2  name                 = "infra-break-glass"
3  assume_role_policy   = data.aws_iam_policy_document.break_glass_trust.json
4  max_session_duration = 3600
5
6  tags = { Purpose = "emergency-escalation" }
7}

如果團隊有 ChatOps 或 ticketing 系統，把 break-glass 的觸發綁進去可以增加一層人為確認：operator 在 Slack 或 ticket 裡申請提權、另一個人核可、系統開放 assume。這層確認的目的是在事後稽核時留下一條清楚的「誰授權了這次提權」紀錄，而非阻止操作本身。

事後回顧

每一次 break-glass 使用都應該進入事後回顧：為什麼需要提權？這個操作能不能改寫成 operator 層級的權限就能完成？如果某類操作反覆觸發 break-glass，代表 operator 的權限邊界需要調整——把那類操作從 admin 降到 operator，而不是讓 break-glass 變成常態。

回顧的輸出是權限邊界的校準，不是對操作者的檢討。

定期 access review

權限分配不是一次性的設定。人會換組、離職、從 contractor 轉正職、從開發角色轉管理角色，每一次角色變動都可能讓既有的權限配置過期。定期 review 的責任是找出「權限比當前角色需要的更寬」的身分，把它們收斂回來。

節奏與方法

每季做一次 access review 是多數團隊能維持的最小節奏。Review 的步驟：

1. 拉出所有 IAM user 和 role 的清單，標注每個身分目前的分級（admin / operator / viewer）
2. 比對每個身分的實際角色——這個人現在還在做需要 operator 權限的工作嗎？
3. 用 IAM Access Analyzer 檢查哪些權限在過去 90 天沒被使用過——沒用到的權限是收斂候選
4. 特別檢查 break-glass 的使用紀錄——有沒有人的 break-glass 使用頻率高到代表他的基線權限該調整

1# 產出 credential report，列出所有 user 的 key 建立時間與使用時間
2aws iam generate-credential-report
3aws iam get-credential-report --output text --query Content | base64 -d | head -20
4
5# 查 Access Analyzer 的 finding（哪些權限可收斂）
6aws accessanalyzer list-findings --analyzer-arn <analyzer-arn> \
7  --filter '{"status": {"eq": ["ACTIVE"]}}'

管理層報告

Access review 的結果適合用兩個數字向管理層報告：覆蓋率（已 review 的身分數 / 總身分數）與異常數（權限過寬或長期未使用的身分數）。異常數的趨勢比單次數字更有意義——持續上升代表新人 onboarding 時的權限配置流程有缺口，持續下降代表 review 在發揮作用。

導入時程參考：第一次 access review 約需半天到一天（盤點 + 比對 + 收斂），後續每季約需 2-4 小時。

職務交接與離職處理

一個人離開團隊時，他持有的所有存取路徑都需要被回收。手動建立的存取路徑越多，離職處理越容易遺漏。

離職 checklist

權限設計越集中在 role-based（用 IAM group 或 SSO permission set），離職處理越簡單——停用 SSO 帳號就自動切斷所有透過 SSO 取得的 role。反過來，如果有大量手動 attach 的 policy 或直接寫在 trust policy 裡的 user ARN，離職時要逐一找出並移除，容易遺漏。

離職後的 credential rotation 有一個常被忽略的風險：輪替範圍沒有按作用域分批。一個反例是多個服務共用同一把 secret，輪替時切新憑證的服務跟還只認舊憑證的服務之間出現認證窗口不一致，導致跨系統連鎖中斷。穩定的做法是先分域隔離受影響服務、恢復雙憑證窗口、再逐批收斂（見 反例：憑證輪替未分 Scope）。

交接的可執行性

交接的成本取決於知識有多少沉澱在程式碼裡、有多少留在個人腦中。如果環境的建立方式是一份 IaC、變更方式是 PR 歷史，新接手的人讀 code 跟 PR 描述就能重建脈絡。如果關鍵操作（某台資料庫的特殊 parameter、某條 security group 規則的理由）只存在離職者的記憶裡，交接窗口一過就永久遺失。

可操作的檢驗：問「如果這個人下週離職，團隊能不能只靠讀 repo 就安全地操作他負責的環境？」答案是否定的部分，就是交接的優先補強項——優先把它們寫進 IaC 或 PR 描述，而不是寫進交接文件（交接文件會過期，IaC 跟著環境一起演進）。

這個議題在知識共享優於個人英雄主義有組織層面的展開。

Contractor 與外部 vendor 存取

外部人員（contractor、顧問、SaaS vendor 的技術支援）需要存取雲端環境時，原則是給最小範圍、設明確時限、留完整紀錄。

範圍限制

外部人員的 role 用 Permissions Boundary 設定權限天花板，確保即使有人誤 attach 了過寬的 policy，操作範圍也不超過 boundary 允許的上限。Scope 到具體的資源 ARN（某個 S3 bucket、某台 RDS instance），而非帳號級別的 wildcard。

如果團隊已經有跨帳號策略，把外部人員的 workload 放在獨立帳號或 sandbox OU 裡，用 SCP 限制該帳號能操作的服務類型，是比 role 級別限制更強的隔離。

時限控制

外部存取的 IAM user 或 SSO 帳號在建立時就設定到期日。多數雲端平台支援 session duration 限制（role 的 max_session_duration）和帳號層級的停用排程。合約結束日應該對應到存取到期日——這個對應關係寫進 IaC（用 tag 標注到期日）或團隊的 access review checklist，避免合約結束後存取仍然開著。

稽核紀錄

外部人員的操作需要比內部人員更嚴格的稽核。CloudTrail 預設記錄所有 API 呼叫，但 review 的頻率要提高——外部人員的操作紀錄每週抽查，而非等到季度 access review 才回頭看。查的是：有沒有存取超出約定範圍的資源？有沒有在非工作時間操作？有沒有大量的 read 操作指向敏感資料？

這些紀錄同時也是合約管理的依據——如果外部 vendor 的技術支援存取了超出約定範圍的資源，紀錄是釐清責任的事實基礎。

跨分類引用

• → 身分與憑證地基：IAM role / policy / OIDC 的技術機制
• → 跨帳號策略：用 OU 和 SCP 在帳號層級隔離外部人員
• → 治理好習慣：tagging 標注存取到期日、secrets 不進 code
• → 怎麼把 infra 推動起來：知識共享與交接的組織面

這是 infra 工作最常見的真實入口。比起從零自學建一套環境，「接到指派、拿到帳號、搞清楚狀況」才是多數工程師第一次碰 infra 的方式。

這篇用 AWS 為主要範例。GCP 和 Azure 的判讀邏輯相同（安全底線 → 現況盤點 → 路線分流），但具體服務名稱、IAM 模型和 Console 操作位置不同。

第一小時：安全底線

登入帳號後，在做任何其他事之前先完成這些。這些步驟的共同目的是確保帳號的存取控制處於安全狀態——雲端帳號被入侵的代價遠高於本機電腦被入侵，因為雲端資源可以在幾分鐘內被大量建立（產生帳單）或被刪除（資料遺失）。

確認 root 帳號的 MFA

Root 帳號是雲端環境的最高權限，能做任何事，包括關閉整個帳號。如果 root 帳號沒有 MFA（Multi-Factor Authentication，多因子驗證），任何拿到 root 密碼的人都能完全控制整個環境。

確認路徑（AWS）：Console 右上角帳號名稱 → Security credentials → Multi-factor authentication (MFA)。如果顯示「No MFA device」，立刻設定一個——手機 app（Google Authenticator / Authy）或硬體 key（YubiKey）都可以。

如果你拿到的帳號是公司用 AWS Organizations 開出來的子帳號，子帳號 root 的密碼和 MFA 是獨立的——管理帳號無法代設。子帳號 root 通常需要先用帳號 email 做密碼重置才能首次登入。確認 root MFA 後，日常操作用 IAM Identity Center 登入。

確認你的登入身分

你登入用的是哪種身分？這決定了你的權限範圍和操作方式。

IAM user：Console 右上角會顯示 username @ account-id。這是最傳統的登入方式——帳號管理員幫你建了一個使用者，給了你一組帳密。

IAM Identity Center（SSO）：你透過一個特別的登入頁面（通常是 https://d-xxxxxxxxxx.awsapps.com/start）登入，然後選擇帳號和角色。這是較新的做法，多帳號組織常用。

Root 帳號：Console 右上角顯示帳號 email 而非 username。如果你拿到的是 root 帳號的帳密，日常操作應該換成 IAM user 或 SSO 登入——root 帳號只在需要 root-only 操作（如設定 MFA、關閉帳號）時使用。建立 IAM user 的方式見模組一的動手前的前提段。

檢查既存的 access key

帳號如果被前人用過，可能有暴露風險的 access key——之前的管理員建了 IAM user、生了 key，但那組 key 可能已經寫在某個 Git repo 或環境變數裡而沒有停用。

確認路徑：Console → IAM → Users → 逐一點每個 user → Security credentials 分頁 → Access keys。檢查每組 key 的狀態（Active / Inactive）和建立時間。超過 90 天未 rotate 的 Active key 是風險——帳號接手後優先 rotate 或停用這些 key。如果帳號裡沒有任何 IAM user，這步跳過。

確認 CloudTrail 是否開啟

CloudTrail 記錄帳號內所有 API 操作（誰在什麼時間做了什麼）。AWS 預設會開啟 90 天的事件歷史，但長期保存需要建一個 Trail 把 log 寫到 S3。

確認路徑：Console 搜尋 CloudTrail → Dashboard。如果有 Trail 已建立，表示操作紀錄有長期保存。如果只有預設的 Event history，90 天前的紀錄會消失——這是一個需要但不緊急的改善點，模組六：可觀測性會展開。

現階段只需要確認 CloudTrail 存在，不需要馬上改它。

設定帳單警報

雲端帳單是開放式的——資源跑著就持續產生費用，被入侵後被開出大量資源更可能在幾小時內累積數千美元帳單。設一個帳單警報，超過閾值時收到通知。

設定路徑（AWS）：Console 搜尋 Billing → Budgets → Create budget → Cost budget。設一個月預算（如 $50 或 $100，依你的環境規模），超過 80% 和 100% 時發 email 通知。

帳號現況判讀：空帳號還是有東西？

安全底線做完後，下一步是搞清楚帳號的現況。這決定了你接下來走哪條路線。

怎麼判斷

EC2 Dashboard 只顯示當前 region 的資源。Console 右上角有 region 選擇器——先切幾個主要 region（us-east-1、ap-northeast-1、ap-southeast-1）看一下，確認資源是否分散在不同 region。

打開 EC2 Dashboard（Console 搜尋 EC2）。如果 Running instances 是 0、沒有 volumes、沒有 security groups（除了 default）——大概率是空帳號。也檢查 Lambda（Console 搜尋 Lambda → Functions）——如果有 function 在跑但 EC2 是空的，可能是 serverless 架構，帳號不是空的。

再看 S3（Console 搜尋 S3）。S3 是全域服務，不分 region。如果沒有 bucket，或只有 CloudTrail 的 log bucket——大概率是空帳號。

如果有正在跑的 EC2 instance、有 Lambda function、有 RDS 資料庫、有 S3 bucket 存著資料——這是一個有東西的帳號，可能是前人建的、可能是其他團隊在用的。

空帳號 → 從零建置

帳號是空的，你要從零開始建基礎設施。這是最乾淨的起點。

路線：先讀模組零建立心智模型（什麼是 infra、成熟度階梯），然後照模組一到五的順序走。模組一的動手前的前提段會帶你設好本機工具和認證。

有東西的帳號 → 接手維運

帳號裡已經有資源在跑。你需要先搞清楚「有什麼」「誰建的」「哪些還在用」，再決定怎麼處理。

路線：讀接手維運模組。它按環境類型（全手動的遺留環境、部分有 IaC、多帳號結構）分篇，教你怎麼盤點、怎麼在不搞壞的前提下逐步接管。

不確定 → 先盤點再說

如果帳號裡有東西但你不確定是不是還在用、能不能動，先盤點。以下指令需要 AWS CLI 並完成認證——安裝和 aws configure 設定見模組一的前提段（macOS 快速安裝：brew install awscli && aws configure）：

 1# 列出所有 region 的 EC2 instance
 2for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
 3  echo "=== $region ==="
 4  aws ec2 describe-instances --region "$region" \
 5    --query 'Reservations[].Instances[].[InstanceId,State.Name,Tags[?Key==`Name`].Value|[0]]' \
 6    --output table
 7done
 8
 9# 列出所有 S3 bucket
10aws s3 ls
11
12# 列出所有 RDS instance
13aws rds describe-db-instances \
14  --query 'DBInstances[].[DBInstanceIdentifier,Engine,DBInstanceStatus]' \
15  --output table

這些指令只做讀取，不會改變任何東西。如果輸出很多資源，去讀接手維運再決定下一步。如果幾乎是空的，走「從零建置」路線。

雲端 Console 的基本導覽

AWS Console 列出幾百個服務，日常 infra 工作常用的集中在以下幾個：

Console 左上角的搜尋列可以直接搜服務名稱，不用從選單找。

每個服務在 Console 上的操作都有一個對應的 AWS CLI 指令和 API 呼叫。這個對應關係是 IaC 的基礎——模組一會教怎麼把 Console 上的操作轉成程式碼。

你接下來該讀什麼

根據你的情境選一條路線：

如果你不確定自己屬於哪種情境，先做完本篇的「帳號現況判讀」再決定。

盤點：帳號裡有哪些 key

第一步是拿到帳號內所有 IAM user 的 access key 清單。AWS 的 credential report 是這個問題的標準資料來源，它列出每個 user 的 key 狀態、建立時間與最後使用時間。

1aws iam generate-credential-report
2aws iam get-credential-report \
3  --query 'Content' --output text | base64 -d > credential-report.csv

產出的 CSV 包含每個 IAM user 的兩把 key（access_key_1、access_key_2）各自的狀態。關注的欄位：

用 csvkit 或試算表打開這份報告，按 access_key_1_last_rotated 排序，最舊的 key 排最前面。超過 90 天未輪替的 key 列為第一批處理對象。

以下腳本使用 gawk 的 systime() 函式。如果系統的 awk 是 mawk（Ubuntu 預設），改用 gawk 或用 date 指令替代時間計算。

 1# 快速列出所有啟用中、超過 90 天的 key
 2aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read user; do
 3  aws iam list-access-keys --user-name "$user" \
 4    --query "AccessKeyMetadata[?Status=='Active'].[UserName,AccessKeyId,CreateDate]" \
 5    --output text
 6done | awk -F'\t' '{
 7  cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%dT%H:%M:%S+00:00\" \"" $3 "\" +%s"
 8  cmd | getline created; close(cmd)
 9  age = (systime() - created) / 86400
10  if (age > 90) printf "%s\t%s\t%.0f days\n", $1, $2, age
11}'

識別每把 key 的用途

知道 key 存在之後，下一個問題是「這把 key 用在哪裡」。credential report 只告訴你 key 最後被用來呼叫什麼 service（access_key_1_last_used_service），但不告訴你它被存放在哪裡。

用途識別需要交叉比對多個來源：

對每把要輪替的 key，在以上位置逐一確認。找不到用途的 key 可以先停用觀察（而非直接刪除），停用後如果有服務壞了就知道它用在哪裡。

輪替步驟：五步流程

輪替一把 key 的標準流程分五步，順序不能跳：

第一步：建立新 key

1aws iam create-access-key --user-name deploy-bot

輸出會包含新的 AccessKeyId 和 SecretAccessKey。SecretAccessKey 只在這一刻顯示一次，存進密碼管理器或 Secrets Manager，不要貼在 Slack 或 email 裡。

一個 IAM user 最多同時有兩把 key。如果已經有兩把，需要先刪除一把不用的才能建新的。

第二步：更新所有消費者

把新 key 部署到上一節識別出的所有存放位置。CI 變數、Lambda 環境變數、SSM Parameter Store、開發者的 ~/.aws/credentials 都要同步更新。

每更新一個消費者就做一次功能驗證——CI 跑一次 pipeline、Lambda 觸發一次、開發者跑一次 aws sts get-caller-identity 確認新 key 能用。

第三步：驗證新 key 生效

所有消費者更新完後，等待一個完整的業務週期（至少 24 小時），確認沒有任何服務還在用舊 key。檢查方式是看舊 key 的 LastUsedDate 有沒有在更新之後還被使用：

1aws iam get-access-key-last-used --access-key-id AKIAOLD12345

如果 LastUsedDate 在你更新消費者之後仍有新的使用紀錄，代表有漏網的消費者還在用舊 key。

第四步：停用舊 key

確認無殘留使用後，停用（不是刪除）舊 key：

1aws iam update-access-key \
2  --user-name deploy-bot \
3  --access-key-id AKIAOLD12345 \
4  --status Inactive

停用是安全的中間狀態——用到這把 key 的服務會開始報 InvalidClientTokenId 錯誤，但 key 還在、可以隨時重新啟用。如果停用後有意料之外的服務壞了，重新啟用就能立刻恢復。

第五步：寬限期後刪除

停用後保持 7-14 天的寬限期。這段時間是「如果有漏掉的消費者」的安全網。寬限期內無異常，刪除：

1aws iam delete-access-key \
2  --user-name deploy-bot \
3  --access-key-id AKIAOLD12345

刪除後不可回復。如果有服務還在用這把 key，只能建一把新 key 然後去更新那個服務。

自動化輪替：Secrets Manager

手動輪替的瓶頸在「找到所有消費者」這一步。如果 key 的消費者都從 Secrets Manager 讀取（而非各自存一份副本），輪替就簡化成「在 Secrets Manager 裡更新值」——所有消費者下次讀取時自動拿到新 key。

Secrets Manager 支援自動輪替：設定一個 Lambda function 作為 rotation function，它負責建新 key → 更新 secret value → 停用舊 key 的全流程。

 1resource "aws_secretsmanager_secret" "deploy_key" {
 2  name = "prod/deploy-bot/access-key"
 3}
 4
 5resource "aws_secretsmanager_secret_rotation" "deploy_key" {
 6  secret_id           = aws_secretsmanager_secret.deploy_key.id
 7  rotation_lambda_arn = aws_lambda_function.key_rotator.arn
 8
 9  rotation_rules {
10    automatically_after_days = 90
11  }
12}

自動輪替的前提是所有消費者都改成從 Secrets Manager 讀 key，而非從環境變數或設定檔。這個前提本身就是一次 migration——跟手動輪替的固定成本（盤點 + 更新 + 驗證）相比，migration 的一次性成本更高，但之後的每次輪替接近零成本。

判斷該不該投入自動化的依據是 key 的數量和輪替頻率。3 把 key、每季輪替一次，手動流程 2-3 小時可以完成，自動化的 ROI 不高。10 把以上、或合規要求 30 天輪替，手動已經吃掉固定的工程師時間，自動化的投入才有回報。

Key age 監控

輪替做完不代表可以不管——如果沒有監控，三個月後又會回到「不知道有幾把超齡的 key」的狀態。

最低成本的監控是一條定期跑的 check，掃描所有 key 的年齡並在超過閾值時告警：

1# 列出所有超過 90 天的 active key（用 AWS Config 規則更可靠）
2aws configservice put-config-rule --config-rule '{
3  "ConfigRuleName": "access-keys-rotated",
4  "Source": {
5    "Owner": "AWS",
6    "SourceIdentifier": "ACCESS_KEYS_ROTATED"
7  },
8  "InputParameters": "{\"maxAccessKeyAge\":\"90\"}"
9}'

AWS Config 的 ACCESS_KEYS_ROTATED managed rule 會持續掃描所有 IAM user 的 key age，超過設定天數的標記為 non-compliant。把 Config 的 non-compliant 事件接到 SNS → Slack 或 email，就有了持續的 key 超齡告警。

Prowler 也提供 key age 檢查（prowler aws --checks access_key_1_rotated），適合當一次性掃描工具。Config rule 適合持續監控。

管理層報告可以用 Config 的 compliance dashboard：compliant key 數 / 總 key 數 = key rotation 覆蓋率，這個百分比適合放進月報。

IAM Access Analyzer 的 unused access 功能（需啟用 analyzer）可以持續掃描帳號內未使用的 key 和 permission，跟 Config rule 互補——Config 看 key age，Access Analyzer 看 key 是否被使用。兩者搭配可以同時回答「這把 key 多久沒輪替」和「這把 key 有沒有在用」。

跨分類引用

• → 身分與憑證地基：access key 風險的系統性分析、OIDC 作為長期 key 的替代方案
• → 團隊權限分級與存取管理：離職時的 key 撤銷流程
• → 治理好習慣：secret 的儲存與引用紀律

本篇以 GitHub Actions 為主，其他平台替換 issuer URL 和 sub condition 即可。

建立 OIDC Provider

OIDC provider 是 AWS 帳號裡的一個資源，聲明「我信任這個外部 identity provider 簽發的 token」。GitHub Actions 的 OIDC issuer URL 是固定的，每個 AWS 帳號只需要建一個 provider。

1resource "aws_iam_openid_connect_provider" "github" {
2  url             = "https://token.actions.githubusercontent.com"
3  client_id_list  = ["sts.amazonaws.com"]
4  thumbprint_list = ["ffffffffffffffffffffffffffffffffffffffff"]
5}

client_id_list 設為 sts.amazonaws.com 是 GitHub 官方建議的 audience 值。thumbprint_list 在 2023 年之後 AWS 不再用它驗證 GitHub 的憑證鏈（改用 AWS 自己維護的根憑證清單），但欄位仍然是必填，填 40 個 f 作為佔位值即可。

這個 provider 建一次就好。多個 role 可以共用同一個 provider，差別在各自的 trust policy 怎麼寫。

Trust Policy 設計：claim 收斂

Trust policy 決定「誰能假扮這個 role」。OIDC token 裡帶有多個 claim（描述「這是哪個 repo、哪個 branch、哪個 workflow 在跑」），trust policy 用 condition 比對這些 claim，全部命中才允許 assume。

最小可行的 trust policy

 1data "aws_iam_policy_document" "ci_trust" {
 2  statement {
 3    actions = ["sts:AssumeRoleWithWebIdentity"]
 4
 5    principals {
 6      type        = "Federated"
 7      identifiers = [aws_iam_openid_connect_provider.github.arn]
 8    }
 9
10    condition {
11      test     = "StringEquals"
12      variable = "token.actions.githubusercontent.com:aud"
13      values   = ["sts.amazonaws.com"]
14    }
15
16    condition {
17      test     = "StringLike"
18      variable = "token.actions.githubusercontent.com:sub"
19      values   = ["repo:my-org/my-app:ref:refs/heads/main"]
20    }
21  }
22}

兩個 condition 各守一個邊界。aud 驗證 audience 對不對（防止其他用途的 token 被拿來 assume）。sub 驗證請求來自哪個 repo 和 branch——這是最關鍵的收斂點。

sub claim 的結構

GitHub Actions 的 sub claim 格式是 repo:{owner}/{repo}:{context}，其中 context 隨觸發方式不同：

Trust policy 的 sub condition 要根據實際需要選擇收斂到哪個層級。只允許 main branch 的 push 就寫 repo:my-org/my-app:ref:refs/heads/main；只允許 production environment 的 deploy 就寫 repo:my-org/my-app:environment:production。

environment-based 收斂（推薦）

GitHub Actions 的 environment 功能讓 sub claim 帶上 environment 名稱。搭配 environment protection rules（required reviewers、wait timer），可以在 trust policy 層和 GitHub 層各設一道 gate：

1condition {
2  test     = "StringEquals"
3  variable = "token.actions.githubusercontent.com:sub"
4  values   = ["repo:my-org/my-app:environment:production"]
5}

Workflow 裡對應的設定：

1jobs:
2  apply:
3    environment: production
4    permissions:
5      id-token: write
6      contents: read

只有 workflow 宣告了 environment: production 且通過 environment 的 protection rules 後，runner 拿到的 token 才會帶上 environment:production 的 sub claim，才能 assume 這個 role。

Plan Role 與 Apply Role 分離

把 plan 和 apply 拆成兩個 role，各自給最小權限。plan 只需要 read 權限（讀 state、讀雲端現況），apply 需要 write 權限（建立/修改/刪除資源）。分離的好處是 PR 階段的 plan 即使被攻破，攻擊者也只能讀不能改。

 1resource "aws_iam_role" "infra_plan" {
 2  name               = "infra-plan"
 3  assume_role_policy = data.aws_iam_policy_document.plan_trust.json
 4}
 5
 6resource "aws_iam_role" "infra_apply" {
 7  name               = "infra-apply"
 8  assume_role_policy = data.aws_iam_policy_document.apply_trust.json
 9}
10
11resource "aws_iam_role_policy_attachment" "plan_readonly" {
12  role       = aws_iam_role.infra_plan.name
13  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
14}

Trust policy 的差異：plan role 允許任何 branch 的 PR 觸發（repo:my-org/my-app:pull_request）；apply role 只允許 main branch 或 production environment（repo:my-org/my-app:environment:production）。

 1jobs:
 2  plan:
 3    if: github.event_name == 'pull_request'
 4    permissions:
 5      id-token: write
 6      contents: read
 7      pull-requests: write
 8    steps:
 9      - uses: aws-actions/configure-aws-credentials@v4
10        with:
11          role-to-assume: arn:aws:iam::123456789012:role/infra-plan
12          aws-region: ap-northeast-1
13      - run: terraform plan -out=plan.tfplan
14
15  apply:
16    if: github.ref == 'refs/heads/main'
17    environment: production
18    permissions:
19      id-token: write
20      contents: read
21    steps:
22      - uses: aws-actions/configure-aws-credentials@v4
23        with:
24          role-to-assume: arn:aws:iam::123456789012:role/infra-apply
25          aws-region: ap-northeast-1
26      - run: terraform apply -auto-approve

常見設定錯誤

audience 不匹配

1Error: Not authorized to perform sts:AssumeRoleWithWebIdentity

最常見的原因是 trust policy 的 aud condition 值跟 OIDC provider 的 client_id_list 不一致。兩者都要是 sts.amazonaws.com。如果用了舊版的 configure-aws-credentials action（v1），它預設用 sigstore 作為 audience，跟 sts.amazonaws.com 對不上。確認 action 版本是 v4+。

sub condition 太寬

1condition {
2  test     = "StringLike"
3  variable = "token.actions.githubusercontent.com:sub"
4  values   = ["repo:my-org/*"]
5}

這允許 my-org 底下任何 repo 的任何 branch assume 這個 role。如果組織裡有公開 repo 或 fork 權限寬鬆的 repo，攻擊者可以在那些 repo 裡觸發 workflow 來 assume 生產環境的 role。至少收斂到 repo 層級（repo:my-org/my-app:*），生產環境收斂到 branch 或 environment。

sub condition 太緊

1condition {
2  test     = "StringEquals"
3  variable = "token.actions.githubusercontent.com:sub"
4  values   = ["repo:my-org/my-app:ref:refs/heads/main"]
5}

這只允許 push to main 觸發的 workflow。PR 觸發的 workflow 拿到的 sub 是 repo:my-org/my-app:pull_request，跟這個 condition 不匹配，plan 階段會失敗。如果 plan 需要在 PR 階段跑，plan role 的 trust policy 要加 PR 的 sub pattern。

忘記設 permissions

1jobs:
2  deploy:
3    # 缺少 permissions 區塊
4    steps:
5      - uses: aws-actions/configure-aws-credentials@v4

GitHub Actions 的 OIDC token 只有在 workflow 宣告 permissions: { id-token: write } 時才會簽發。缺了這一行，configure-aws-credentials 拿不到 token，報「OIDC token not available」。這個錯誤訊息不直觀——它說的是 token 不存在，不是權限不夠。

多帳號時忘記指定 provider

如果組織有多個 AWS 帳號，每個帳號都要各自建 OIDC provider。trust policy 的 Federated principal 要指向本帳號的 provider ARN，不能跨帳號引用。跨帳號部署時，workflow 用不同的 role-to-assume 切換帳號，每個帳號的 role 各自信任同一個 GitHub OIDC issuer 但是各自獨立的 provider 資源。

測試與驗證

設定完成後的驗證步驟：

1. 手動觸發 workflow：push 一個無害的 commit 到 main、開一個 test PR，觀察 configure-aws-credentials 步驟是否成功
2. 檢查 CloudTrail：搜尋 AssumeRoleWithWebIdentity 事件，確認 source identity 和 assumed role 正確
3. 反向驗證：從一個不在 trust policy 允許範圍的 repo 或 branch 觸發 workflow，確認 assume 被拒絕
4. 權限範圍驗證：在 plan job 裡嘗試一個 write 操作（如 aws s3 rm），確認被拒絕——驗證 plan role 的 read-only 限制確實生效

1# 在 CloudTrail 搜尋 OIDC assume 事件
2aws cloudtrail lookup-events \
3  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
4  --max-items 5

驗證通過後，這套 OIDC 設定就取代了所有存放在 CI 環境變數裡的 access key。原有的 key 可以排程停用和刪除，排程的節奏見access key 輪替。trust policy 的持續維護重點是：新增 repo 時 sub condition 要同步更新、組織改名時 issuer 的 repo 路徑要全面修正。

時程參考：OIDC provider 建立 + trust policy 設計 + workflow 驗證約需 1-2 小時。OIDC provider 與 IAM role 本身不產生額外費用。

跨分類引用

• → 身分與憑證地基：OIDC 的概念基礎與權限邊界設計
• → infra 走 PR 流程：plan/apply 的 CI pipeline 怎麼用這裡設定好的 role
• → 跨帳號策略：多帳號環境下的 OIDC provider 配置

服務定位

AWS IAM 是 cloud resource permission engine、人類 workforce 的 SSO 與 lifecycle 應該走 AWS IAM Identity Center 或外部 IdP（Okta / Keycloak）。Identity Center 把人類映射到 Permission Set、Permission Set 在每個目標帳號裡實際上是 AWS-Reserved IAM Role — 也就是說：人類登入走 Identity Center、實際的 API 授權判斷一定回到 IAM。兩層責任分清楚、policy 才不會錯放在「誰是誰」的地方。

AWS IAM 跟 Google Cloud IAM / Azure RBAC 在 policy model 上設計差異很大。AWS 的表達力最強 — identity-based policy、resource-based policy、Service Control Policy（SCP）、Permission Boundary、Session Policy 是五個獨立的層、最終結果由 Explicit Deny > Org SCP > Resource-based > Identity-based > Permission Boundary > Session Policy 的評估順序決定。表達力換來的代價是 最容易設定錯：S3 bucket policy 設錯 = public、KMS key policy 漏一個 condition = 跨帳號可以解密、Trust Policy 沒設 ExternalID = confused deputy 攻擊面。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 IAM first-class concept（User / Group / Role / Policy / STS）對應到自己的場景、哪些要避免（例如：給人類發 IAM User access key）
2. 跨帳號信任、CI / 第三方 SaaS 連進 AWS、service-to-service 認證該走 Role assumption / OIDC trust 還是 Roles Anywhere
3. SCP、Permission Boundary、resource-based policy 三層上限的疊加方式、何時用哪一層
4. CloudTrail + Access Analyzer 的稽核 baseline、出事時的最短取證路徑

最短判讀路徑

判斷一個 AWS 帳號的 IAM 配置是否健康、最少看四件事：

• 誰能 assume 哪個 Role：所有 Role 的 Trust Policy（誰能呼叫 sts:AssumeRole）、有沒有跨帳號 trust、跨帳號 trust 是否帶 ExternalID、有沒有 * 在 Principal 裡
• Resource-based policy 暴露面：S3 bucket policy、KMS key policy、Lambda function policy、SNS / SQS policy 是否有 Principal: * 或來自非預期帳號；用 IAM Access Analyzer 找 unintended external access
• Permission Boundary 與 SCP 是否生效：開發者建的 Role 是否 attach Permission Boundary（防止 admin 自己給自己升權）、Organization 是否 attach SCP 做整個 OU 的上限
• CloudTrail 是否完整、是否進 SIEM：management event 跟 data event 都開、跨 region、跨帳號、保留期符合稽核要求、特定事件（AssumeRole 失敗、root login、CreateAccessKey）接 alert runbook

四件事任一缺失、就是 Authorization 與 Audit Log 邊界的待補項目。

日常操作與決策形狀

Role 設計（cross-account / service / OIDC trust）：所有 持續性 的身份都應該是 Role、不是 IAM User。Service Role（給 EC2 / Lambda / ECS task）是 AWS 內部 service-to-service；Cross-account Role 給 partner 帳號或自家其他帳號用 sts:AssumeRole 進來；OIDC trust 是現代 CI 必備路徑（GitHub Actions / GitLab / 自管 K8s 用短期 OIDC token 換 AWS STS 短期憑證、不在 secret store 存 long-lived access key）。

Policy 種類分工：identity-based policy attach 在 User / Group / Role 上、回答「這個身份能做什麼」。Resource-based policy attach 在 resource 上（S3 bucket、KMS key、SNS topic、Lambda function）、回答「誰能對這個 resource 做什麼」— 同帳號內 identity-based 跟 resource-based 任一個 allow 就通過、跨帳號 兩邊都要 allow。SCP 是 Organization 層級的上限、不是 grant — SCP allow 不會給任何權限、SCP deny 會擋掉整個 OU 的所有 identity。Permission Boundary 是 user 角度的上限、給 admin 用來限制「我把 admin 權限委派給 developer 後、developer 自己建的 role 不能超過這條線」。

STS 與臨時憑證：所有 cross-account、service-to-service、人類 console federation 都應該走 STS — sts:AssumeRole（跨帳號 / 跨 role）、sts:AssumeRoleWithSAML（SAML IdP）、sts:AssumeRoleWithWebIdentity（OIDC）、sts:GetFederationToken（外部 broker）。Session 預設 1 小時、最長可設 12 小時（依 Role 設定）。Debug 起手式：aws sts get-caller-identity 確認當前 caller 是誰、是 User、Role 還是 federated session。

Access Key 治理：IAM User 的 long-lived access key 是 最後手段、用於 break-glass 或無法跑 IMDS / Roles Anywhere 的 legacy。所有 access key 走 Secret Management、定期 rotation、IAM Access Analyzer 的 unused access finding 找閒置 key。

CloudTrail / Access Analyzer baseline：CloudTrail organization trail 開到所有帳號、management event 必開、data event（S3 object level、Lambda invoke）依資料敏感度開。Access Analyzer 至少跑 external access（找 resource-based policy 把資源暴露給外部帳號）跟 unused access（找閒置 Role、user、permission）。

Trust Policy / ExternalID：第三方 SaaS（監控、CSPM、備份服務）要進你的 AWS 帳號時、其 Trust Policy 必須要求 ExternalID — 否則攻擊者只要知道 Role ARN 就能假冒第三方 SaaS 的呼叫端、走 confused deputy 攻擊面（AWS confused deputy 官方說明）。自家跨帳號 trust 不一定要 ExternalID、第三方一定要。

核心取捨表

AWS IAM 是 表達力最強、最容易設定錯 的雲端 IAM。Google Cloud IAM 設計較統一、policy model 易讀但精細度有限。Azure RBAC 走 inheritance + scope、靠 Management Group 結構治理。三家都不能直接互換、跨雲環境需要在每家自己的 IAM 模型裡建等價的 least-privilege baseline。

進階主題

Service Control Policy（SCP）：Organization 層級的上限、用來宣告「整個 OU 永遠不能做什麼」 — 例如禁止 root user 操作、禁止關閉 CloudTrail、禁止在非允許 region 建 resource。SCP 是 deny-list 防護網、不是日常授權；日常授權交給 identity-based policy。SCP 過嚴會擋住合法操作、過鬆等於沒設、設計時要對齊 organization 的安全政策骨幹。

Permission Boundary：用在 委派 admin 場景 — 公司想讓 platform team 自己建 IAM Role 給應用、但又不想讓他們建出 admin role。Admin 給 platform team 一個 Permission Boundary policy、platform team 建的所有 Role 都會被這個 boundary 限制 上限、就算 attach 了 AdministratorAccess 也只能在 boundary 範圍內生效。

ABAC（attribute-based / tag-based access control）：大規模 multi-account 環境、每個 service 一個 Role 會 Role 爆炸。ABAC 用 tag（principal tag、resource tag、request tag）做 policy condition — 例如「Role 上有 team=payments tag 的人能操作 team=payments tag 的 resource」。設計成立的前提是 tag 來源可信、不能讓使用者自己改 principal tag。

IAM Roles Anywhere：給 AWS 之外的 workload（地端 K8s、其他雲、邊緣設備）用 X.509 憑證換 STS 短期憑證。前提是有一個可信的 PKI（自管 CA 或公開 CA）跟 trust anchor。比起把 IAM User access key 放在地端 secret store、Roles Anywhere 是更安全的設計。

OIDC trust（GitHub Actions / GitLab CI / 第三方 CI）：CI / CD 連 AWS 的標準做法。在 AWS 建一個 OIDC identity provider 指向 CI 的 OIDC issuer、Role 的 Trust Policy condition 限制 repo:org/repo:ref:refs/heads/main、CI workflow 直接 aws sts assume-role-with-web-identity。完全不需要在 CI secret store 存 long-lived AWS access key、token TTL 隨 job 結束自動失效。

Resource-based policy 跨帳號設計：S3 bucket policy、KMS key policy、SNS / SQS / Lambda policy 都支援跨帳號授權。設計時兩件事必查：Principal 是否包含預期的帳號 / Role ARN、condition 是否限制來源（aws:SourceAccount、aws:SourceArn、aws:PrincipalOrgID）。漏了 condition、就可能讓任何拿到「假裝是某個 service」身份的人都能呼叫 — Capital One 2019 事件本質就是 SSRF 取得 EC2 IMDS 的 Role credential、再用該 Role 的權限去 S3 列舉跟讀取資料、揭示 resource-based policy + identity-based policy 沒有最小化、就會在事故時最大化。

排錯與失敗快速判讀

• AccessDenied 但 policy 看起來 allow：先用 IAM Policy Simulator 或 aws iam simulate-principal-policy 重算、確認是 SCP 擋、Permission Boundary 擋、resource-based policy 沒 allow、還是 condition key 不匹配。Explicit Deny 永遠贏。
• 跨帳號 sts:AssumeRole 失敗：兩邊都要設 — caller 帳號的 identity-based policy 要 allow sts:AssumeRole 到目標 Role ARN、目標 Role 的 Trust Policy 要 allow caller 的 Principal。漏其一就失敗。
• S3 bucket 不小心 public：用 Access Analyzer 的 external access finding 找、用 Block Public Access 帳號級別開關擋掉（即使 bucket policy 寫了 public、Block Public Access 也會擋）。常見根因：bucket policy 寫 Principal: * 沒加 condition、或 ACL 殘留歷史設定。
• Role / access key 殘留：用 Access Analyzer 的 unused access finding、或 IAM credential report 找超過 90 天沒用的 user / role、配 Failure: Credential Rotation Without Scope 的分域分批 rotation 流程清理
• 第三方 SaaS Role 缺 ExternalID：稽核第三方 vendor 的 onboarding 文件、若沒要求 ExternalID 是 vendor 自己安全模型有破口、自己這邊也要拒絕這種 onboarding
• CloudTrail 落地不全：Organization trail 沒覆蓋新建帳號、data event 沒開、log 沒進 SIEM、保留期不足 — 這四件事都會讓事故發生時拿不到證據

何時改走其他服務

不在本頁內的主題

• IAM policy JSON 語法完整 reference 與所有 condition key 清單
• 每個 AWS service 的細部 IAM 動作對照
• AWS Organization、Control Tower、Landing Zone 完整建置流程
• KMS / Secrets Manager / Certificate Manager 的內部細節（見對應 vendor 頁）

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：AWS IAM Identity Center、Google Cloud IAM、Azure RBAC
• 下游：7.6 秘密管理與機器憑證治理（AWS KMS vendor 頁 S2 批次撰寫中）
• 跨模組：8 事故處理 vendor 清單（CloudTrail / Access Analyzer 訊號如何 routing 進 IR 流程）
• 官方：AWS IAM User Guide、AWS IAM Identity Center User Guide

服務定位

Google Cloud IAM 的核心抽象是 role binding on a resource scope：把 role grant 給 principal、生效範圍是某個 Organization / Folder / Project / 個別 resource、沿 resource hierarchy 向下繼承。同一個 principal 在不同 scope 可以有不同 role、有效權限是所有 binding 的 union。這跟 AWS IAM 的「identity policy + resource policy + SCP + boundary 多層 intersect / union」相比、推理成本低、但也意味著 guardrail 必須走 Organization Policy 這另一個系統 — 不是 IAM grant 的一部分。

跟 Azure RBAC 相比、兩者都是 scope-based、都靠 hierarchy 繼承。差異在 Service Account 是 GCP 的 first-class identity：有自己的 email、可被 impersonate、可以 grant role 給它也可以 grant iam.serviceAccountUser 讓人類 act-as 它。Azure 的對應是 Managed Identity、語義接近但 impersonation chain 的表達更隱晦。選 GCP（= 用 Google Cloud IAM）的核心訴求通常是：BigQuery / Vertex AI / GKE workload、想用 Workload Identity Federation 取代 long-lived key、團隊偏好較統一的 policy 模型。

本章目標

讀完本頁、讀者能判斷：

1. Google Cloud IAM 該承擔哪一段權限（resource access、service-to-service、cross-cloud federation）、哪一段該交給 Okta / IdP
2. Role 的選擇順序（Predefined > Custom > Basic）與 IAM Conditions 何時補上
3. Service Account / Workload Identity Federation 的信任邊界、何時不該再發 service account key
4. 何時改走 AWS IAM / Azure RBAC / Organization Policy / VPC Service Controls

最短判讀路徑

判斷一個 GCP project 的 IAM 配置是否健康、最少看五件事：

• Principal 級別：誰是 Owner / Editor / Viewer（Basic Role 應該幾乎為空）、Service Account 是否獨立列管、有沒有 user 直接 grant 沒走 group
• Role 種類：Predefined Role 是 baseline、Custom Role 收斂 least privilege、Basic Role 視為待修；user-managed Service Account key 是否存在（理想是 0）
• Impersonation chain 展平稽核：誰有 iam.serviceAccountTokenCreator / iam.serviceAccountUser 對哪個 SA、間接 chain（A → B → C）展平後 誰最終能 act as 高權限 SA。這是 GCP IAM 最容易漏稽核的一條 — 直接 binding 看 Role、但 lateral movement 走 impersonation chain
• IAM Conditions：高敏 resource（prod bucket、KMS key、BigQuery dataset）是否用 condition expression 補 attribute-level 限制（resource name prefix、request time、IP）
• Audit Logs：Admin Activity 預設開、Data Access logs 在 sensitive resource 是否手動開、System Log 是否同步到 SIEM 並 alert role 變更與 service account key 建立

五件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Role 選擇順序：Predefined Role 是 baseline、覆蓋 80% 場景；Custom Role 用於收斂 least privilege（例如只給 bigquery.dataViewer 的特定子集）；Basic Role（Owner / Editor / Viewer）幾乎不該再用 — Editor 預設帶寫權限到幾乎所有資源類型、Owner 還能改 IAM policy 本身、粒度過粗。Project 建立預設給的 Owner role 是 人類自己 grant 自己、不是無法避免的 baseline。

Principal type：人類用 Google Workspace user / external user，群組走 Google Group（grant 給 group 比 grant 給 user 更穩、離職 lifecycle 由 IdP / HRIS 推 group 變更即可）。Service Account 是 第一級身份、跟 user 同等、有自己的 email（name@project.iam.gserviceaccount.com）、可被 grant role 也可被 impersonate。Workload identity（K8s SA、外部 OIDC subject）是 federation 層、不在 IAM 內直接列管、但 最後仍 impersonate 一個 Service Account 來拿 GCP 權限。

IAM Conditions：在 role binding 上加 attribute-based 條件、補純 RBAC 不足。常見 expression：resource.name.startsWith("projects/_/buckets/prod-")、request.time < timestamp("2026-12-31T00:00:00Z")、resource.type == "storage.googleapis.com/Bucket"。適合 temporary access、resource name 範圍限定、環境隔離；不適合複雜 ABAC 規則（會難以稽核、且 condition 只能用在支援的 resource type 上）。

Service Account impersonation：人類或另一個 Service Account 透過 iam.serviceAccountTokenCreator role 借用目標 SA 的權限、不需要 SA key。impersonation chain 可以串（A 可 impersonate B、B 可 impersonate C）— 這條鏈是 lateral movement 風險、稽核時要展平看 誰最終能 act as 高權限 SA。對應 Failure: Credential Rotation Without Scope 的教訓：rotation 沒分域時、單點 SA compromise 會跨環境擴散。

Workload Identity Federation（WIF）：GCP 接受外部 OIDC / SAML issuer（GitHub Actions、AWS、Azure、自管 K8s OIDC、CircleCI 等）發的 token、在 Workload Identity Pool 設 attribute mapping 後、外部 token 換成 short-lived GCP credential、最後 impersonate 指定 Service Account。是 取代 SA JSON key 的 modern best practice、CI / 跨雲 / 邊緣 workload 都該優先用。Trust 條件要鎖 issuer + audience + subject（例：assertion.repository == "myorg/myrepo"）— 缺一個就可能被同 issuer 下其他 subject 借用，這是 Microsoft Storm-0558 Signing Key Chain 對 external OIDC 信任的提醒：發 token 的 issuer 一旦被攻破、所有信任它的 audience 都跟著受害。

Service Account key（避免）：user-managed JSON key 是 long-lived credential、無 TTL、無 IP 限制、外洩偵測難。應該以 Workload Identity Federation 或 Service Account Impersonation 取代；若必須用、走 Organization Policy iam.disableServiceAccountKeyCreation 預設禁用、例外申請走 ticket、key 進 Secret Management、季度盤點未使用 key 刪除。

Organization Policy（guardrail）：跟 IAM 完全不同層 — 不是 grant、是 限制可以做什麼設定。常用 constraint：iam.disableServiceAccountKeyCreation、iam.allowedPolicyMemberDomains（限制只能 grant 給特定 domain 的 principal）、compute.vmExternalIpAccess（限制 VM external IP）、storage.publicAccessPrevention。Org Policy 在 Organization / Folder / Project 層設定、IAM 即使想 grant 也擋得住。

Audit / handoff：Admin Activity Log 預設開、不能關、保留 400 天免費；Data Access Log 預設關、開了會大量 log（也大量計費）— 對 sensitive resource（KMS key access、BigQuery dataset read、Secret Manager access）應該手動開；System Event Log 補基礎設施事件。三類都接 Cloud Logging sink 推到 SIEM、特別 alert 三件事 — IAM policy 變更、Service Account key 建立 / 上傳、Workload Identity Pool / Provider 變更。

核心取捨表

選 Google Cloud IAM 的核心訴求：已在 GCP 上、或想用 BigQuery / Vertex AI / GKE、團隊偏好較統一的 policy 模型、跨雲場景靠 WIF 對外發 trust 而不維護多套 key。

進階主題

Workload Identity Federation 的深層應用：除了 GitHub Actions、AWS、Azure 這類常見 issuer、WIF 也支援自管 K8s OIDC issuer（OSS K8s cluster 跑 GKE workload identity 等價物）、SaaS（Snowflake、Terraform Cloud）發的 OIDC token。trust 設定要鎖 issuer URL、audience、subject pattern 三件事 — 任何一個太寬都是同 issuer 下別人借用你 SA 的入口。

Organization Policy 的 dry-run / 例外：constraint 可以先設 dryRun 觀察會擋掉哪些操作再 enforce；例外用 exception folder（特定 folder 不繼承上層 constraint）或 condition（特定 resource pattern 不擋）。直接全 org 一次 enforce 通常會打掉既有 workload、要分階段。

IAM Conditions 的有限性：condition 只能用在支援的 resource type 上、不是全 GCP 通用；複雜 expression 難稽核（CEL 語法、不易讀）；condition 不能否決 — 只能限制 binding 的生效範圍、不能像 AWS policy 那樣寫 Deny。複雜 ABAC 場景該走 Organization Policy + 應用層授權邊界、不是把所有規則塞進 IAM Conditions。

Service Account Impersonation chain 的稽核：列出 有 serviceAccountTokenCreator 的 principal 是基本；展平 chain（A → B → C）需要 graph walk 工具或 Policy Analyzer；高權限 SA（owner-equivalent custom role、跨 project 寫權限）的 impersonation 來源應該是 寫死的少數 admin SA + break-glass、不該開放給 CI / 一般 service。

VPC Service Controls（資料邊界、跟 IAM 互補）：在 IAM 之外加 資料 perimeter — 即使 principal 有 IAM 權限、如果請求不是來自 perimeter 內（VPC、特定 IP、特定 service account），仍然會被擋。適合 BigQuery / GCS / Secret Manager 這類存資料的 service、防 合法 credential 從外部 exfiltrate 資料（Azure AD Identity Control Plane 2021 場景的下游補位：identity 控制面失守時、資料層仍有獨立 perimeter）。

排錯與失敗快速判讀

• Basic Role 還在用：Project Owner / Editor 散落、新人 onboard 直接 Editor — 改 group + Predefined Role、Basic Role 改成 break-glass 限定
• Service Account key 散落：CI 用 JSON key、key 進 git 或環境變數、無 rotation — 改 WIF（GitHub Actions / GitLab CI 都支援）、Org Policy 禁用 SA key 建立
• WIF trust 太寬：只鎖 issuer 沒鎖 subject、同 GitHub org 任何 repo 都能借用 SA — trust 要含 assertion.repository、assertion.ref（main branch only）等 condition
• IAM Conditions 越寫越多：condition expression 過度複雜、稽核時沒人讀得懂 — 簡化條件、把複雜規則上移到應用層或 Org Policy
• Data Access Logs 沒開：sensitive resource 出事時只有 Admin Activity、看不到 誰讀了什麼 — KMS key、Secret Manager、BigQuery 高敏 dataset 必開 Data Access Log
• Impersonation chain 失控：太多人有 serviceAccountTokenCreator 到高權限 SA — 用 Policy Analyzer 展平、收斂到必要 admin + break-glass
• Org Policy 沒設：root org 沒有 baseline constraint、新建 project 預設可建 SA key / public IP / public bucket — 至少設 disableServiceAccountKeyCreation + publicAccessPrevention + allowedPolicyMemberDomains

何時改走其他服務

不在本頁內的主題

• 各 Predefined Role 的完整權限清單與細部 permission 差異
• IAM Conditions CEL 語法的完整 spec
• Workload Identity Federation 跟特定 issuer（GitHub / AWS / Azure）的逐步設定教學
• BigQuery / GCS / KMS 等服務的 service-specific IAM 行為細節
• GCP 計費 / SKU 對 Audit Log 開關的影響

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.6 秘密管理與機器憑證治理
• 平行：AWS IAM、Azure RBAC、Okta、AWS IAM Identity Center
• 下游：7.6 秘密管理與機器憑證治理（Google Secret Manager / Google Cloud KMS 個別 vendor 頁 S2 批次撰寫中）
• 跨模組：8 事故處理 vendor 清單（GCP IAM 事件如何 routing 進 IR 流程）
• 官方：Google Cloud IAM Documentation

服務定位

Entra ID 是 Microsoft 自有的 workforce IdP、跟 Okta 是直接競爭者。M365 / Azure-heavy 的組織通常直接用 Entra ID 當主 IdP；Okta-first 的組織可以把 Entra ID 當下游 SP（federation）、也可以雙 IdP 並存、但雙 IdP 的 break-glass 跟 lifecycle 路徑要重新設計。Entra ID 同時承擔 consumer-side 跟 partner-side 的 multi-tenant app 信任、跟 Auth0 在 B2C 場景有交集。

Azure RBAC 是 cloud resource permission engine、跟 AWS IAM / Google Cloud IAM 同層 — 都在解「身份對 cloud resource 能做什麼」。差異在 scope hierarchy — Azure 用 Management Group → Subscription → Resource Group → Resource 四層繼承、AWS 用 account + organization、Google 用 organization → folder → project。Azure RBAC 預期 role assignment 沿 scope 向下繼承、這跟 AWS 在每個 account 重新指派的習慣不一樣、跨雲團隊轉過來常踩到。

本章目標

讀完本頁、讀者能判斷：

1. 哪一段控制屬於 Entra ID（身份）、哪一段屬於 Azure RBAC（resource permission）、不要把兩層當同一件事
2. Entra ID tenant 的最低稽核需求（Global Admin、App Registration、Conditional Access、Managed Identity）
3. Azure RBAC 的 scope 設計、Custom Role 跟 PIM 何時必要
4. Entra ID 控制面事故的降級路徑、跟 Azure RBAC 出事的徵兆差異

最短判讀路徑

判斷 Azure 雙層體系是否健康、要分兩層各看兩件事、跟「日常操作與決策形狀」段的兩層結構對齊。

Entra ID 層（身份控制面）：

• 誰能做什麼：Global Admin / Privileged Role Administrator 的人數、是否走 PIM just-in-time、Conditional Access 是否強制 phishing-resistant 認證、break-glass 帳號是否 exclude 自所有 CA policy 又單獨監控
• 入口如何暴露：App Registration 是否限定 single-tenant、multi-tenant app 的 admin consent 流程是否經審查、Managed Identity 是否取代 service principal client secret

Azure RBAC 層（resource permission）：

• 誰能對 resource 做什麼：Owner / Contributor 在哪個 scope（Management Group 還是 Subscription）、production 環境是否用 Custom Role 收緊權限、有沒有 standing assignment 該改 PIM
• 證據是否可回查：Entra ID Sign-in Log / Audit Log 是否同步到 SIEM、Azure Activity Log 是否設保留與 alert、admin consent / role assignment 變更是否觸發 alert runbook

兩層任一邊任一條缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Entra ID 層

User / Group / lifecycle：HRIS 推 SCIM 進 Entra ID、Entra ID 同步到下游 SaaS 跟 Azure RBAC group。決策點是 source of truth — 多數組織把 HRIS 設為人員來源、Entra ID 當分發層、避免雙寫造成 stale account。

Conditional Access 是 MFA 主要強制機制：MFA 不是設在 user 屬性上、是 Conditional Access policy 在登入時判斷 user / device / location / app / risk 後觸發。常見設定錯誤包含 exclude legacy auth 沒做、break-glass 規則太寬、emergency access 帳號沒獨立監控。Conditional Access 規則設計錯、就是高權限 bypass 的入口。

App Registration vs Enterprise Application：開發者註冊 multi-tenant app 走 App Registration（app 的定義）、組織 admin 為某 app 設定 SAML SSO / admin consent 走 Enterprise Application（該 tenant 對 app 的信任）。兩者常被混講、但安全意義不同 — App Registration 是「我們做了一個 app」、Enterprise Application 是「我們信任這個 app 用我們的身份」。Consent phishing 攻擊就是針對後者。

Managed Identity：Azure resource（VM、Function、AKS pod）自帶身份、不需要 service principal client secret、跟 Google Workload Identity Federation 同概念但 Azure-internal。System-assigned 跟 resource 生命週期綁定、resource 刪掉 identity 跟著刪；User-assigned 獨立、可跨 resource 共用。production 環境的服務存取 Key Vault / Storage 應走 Managed Identity、不該用 client secret。

Workload Identity Federation：Entra ID 可以 trust 外部 OIDC issuer（GitHub Actions、AWS、Google）、讓外部 workload 直接拿 Entra ID token、不用儲存 client secret。CI/CD 的 OIDC 整合是這層的主用例、比把 client secret 塞進 CI variable 安全很多。

Signing key 是 control plane 託管：Entra ID 不暴露 signing key、客戶沒有 rotate 它的能力。這層信任邊界一旦失守、客戶側 直接修不了、要等供應商發 patch 或公告 — Storm-0558 揭示了這條依賴的代價。客戶側能做的補強是 下游檢查 而非 上游修復：

• 訂閱 Microsoft Security Advisory（MSRC）+ tenant-specific notification、讓事件公告第一時間進 IR pipeline、不要靠新聞才知道
• SIEM alert anomalous token issuance pattern（跨租戶 token 在 Exchange / Graph API 出現異常存取序列）、不能只信 token signature valid
• 高敏 app 的 token validation 不只看 Entra ID 標準驗證、加 issuer + tenant + audience + nonce 多層比對、攻擊者偽造跨租戶 token 時可能漏掉某層
• Conditional Access 配 token protection（token binding to device）、降低 stolen token replay 的命中率
• IR playbook 預設 signing key 事件 一條 — 一旦供應商公告、強制 sign-out 高權限 user、token TTL 收短、回頭看 90 天 sign-in log 找異常

Azure RBAC 層

Scope 設計：role assignment 沿 Management Group → Subscription → Resource Group → Resource 向下繼承。在 Management Group 給 Contributor、底下所有 subscription / RG / resource 都繼承 — 這既是優點（統一治理）也是風險（誤指派擴散範圍大）。設計原則是 指派盡量低、不要對全 Management Group 給 Contributor。

Built-in role vs Custom Role：Owner（含 user access admin）/ Contributor（不含權限管理）/ Reader 是 built-in、通常太粗。production 環境需要 Custom Role 把 Microsoft.Storage/storageAccounts/listKeys/action 之類的高風險 action 收掉、只留 read。Custom Role 是 least privilege 在 Azure 的落實工具、不做就是用 Contributor 當預設、權限過寬。

Privileged Identity Management（PIM）：高權限角色（Global Admin、Subscription Owner、User Access Administrator）應走 just-in-time activation、需要 MFA 跟 approval、不該 permanent assignment。沒上 PIM 的組織通常會發現 standing Global Admin 超過 10 個、那是 phishing / token theft 的高價值靶。

Service principal vs Managed Identity：service principal 是 app 在 Entra ID 的代表、可以用 client secret 或 certificate 認證；Managed Identity 是 service principal 的特殊形式、由 Azure 自動管 credential。能用 Managed Identity 就不用 service principal client secret — 後者要自己 rotate、要存 secret management、容易 stale。

Azure Policy 是 RBAC 的補位：RBAC 管 principal 能不能對 resource 做這個 action、Azure Policy 管 允不允許這樣設定 resource（例如 storage account 強制加密、VM 只能用認可的 image）。RBAC 給 Contributor 的人可以建 storage account、但 Azure Policy 可以拒絕未加密的 storage account 建立 — 兩層互補、缺一不可。

核心取捨表

Azure 雙層體系的取捨要分開看 — 一張表回答 cloud resource permission 該選哪家（Azure RBAC vs AWS IAM vs Google IAM）、一張表回答 workforce IdP 該選哪家（Entra ID vs Okta）。兩個決策獨立、可以混搭（例如：Okta 當 workforce IdP + federate 到 Entra ID + 走 Azure RBAC 管 Azure resource）。

Azure RBAC vs AWS IAM vs Google Cloud IAM

Entra ID vs Okta（workforce IdP）

選 Entra ID 的核心訴求：M365 / Azure 重度使用、要跟 RBAC + Managed Identity 直接整合、能接受 Microsoft 控制面風險；選 Okta 的核心訴求看 Okta vendor 頁。

進階主題

Conditional Access 進階規則：除了 user / device / location 基本條件、進階場景包含 risk-based（Identity Protection 給的 user risk / sign-in risk）、token protection（token binding 到 device、防止 token replay）、authentication strength（強制 phishing-resistant factor）。production tenant 至少要有「Global Admin 必須走 phishing-resistant + compliant device」這條規則。

Privileged Identity Management（PIM）的設計細節：activation 要求 MFA、approval（高權限角色）、justification、時限（預設 8 小時、最長 24）。Access Review 是 PIM 的配套 — 季度檢視 standing assignment 是否還需要、不需要的撤掉。沒做 Access Review 的 PIM 等於只把問題從 standing 推到 誰申請就給 — 不是 least privilege。

Workload Identity Federation 跨雲：Entra ID 可以 trust GitHub Actions / GitLab / AWS / Google 的 OIDC issuer、讓 CI 直接拿 Azure token。同向也成立 — Azure workload 可以拿 Google ID token federate 進 GCP。多雲 CI 不該存任何 client secret、走 federation 比較安全。

Custom Role 設計實務：用 Microsoft.Authorization/roleDefinitions API 或 portal 定義、actions / notActions / dataActions 各自獨立 — actions 是 control plane、dataActions 是 data plane（讀寫 blob、key vault secret 內容）。常見錯誤是只收 actions 沒收 dataActions、結果 storage account 設定改不了但 blob 內容隨便讀。

Azure Policy 跟 Initiative：Policy 是單一規則、Initiative 是 policy 的集合（用來組 baseline、例如 CIS、ISO 27001）。Policy effect 有 audit / deny / deployIfNotExists、後者可以自動補洞（例如自動加 diagnostic setting）。RBAC + Policy 一起設計才是完整的 Authorization 邊界。

排錯與失敗快速判讀

• Global Admin 過多：standing Global Admin 超過 5 個就要警惕 — 上 PIM、把日常運維改用 Privileged Role Administrator + 特定 admin role group
• Conditional Access 規則漏 legacy auth：規則只 cover modern auth、IMAP / POP / SMTP 等 legacy protocol 不走 CA — 用「Block legacy authentication」baseline policy 補
• App Registration / Enterprise Application admin consent 沒審查：使用者自己 consent 把 mail.read 給三方 app、變 consent phishing 入口 — 關閉 user consent、改 admin consent workflow
• Service principal client secret 散落：CI / 服務裡有大量 client secret、rotate 沒節奏 — 改 Managed Identity（內部）或 Workload Identity Federation（跨雲 CI）
• Subscription Owner 太多：subscription 級 Owner 是高風險、應該收到 Management Group 級 Reader + 必要時 PIM activate Owner
• Azure Activity Log 沒進 SIEM：role assignment 變更、Key Vault access policy 變更只在 Azure portal 看得到、沒 alert — 用 Diagnostic Setting 推 Event Hub / Log Analytics、再進 SIEM
• Break-glass 帳號 exclude 自所有 CA policy、但沒監控：emergency access 帳號不能被 CA 鎖、但 任何登入都該 alert — 配對 Sign-in Log alert + 季度驗證可用

何時改走其他服務

不在本頁內的主題

• Entra ID 完整 SAML / OIDC / SCIM 規格細節
• Azure RBAC built-in role 完整清單與 action 對照
• Conditional Access policy template 細節
• Azure Policy 內建 initiative 完整清單
• Microsoft 365 / Defender for Identity 等周邊產品

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：AWS IAM、Google Cloud IAM、Okta
• 下游：7.6 秘密管理與機器憑證治理（Entra ID / Managed Identity 之後的 secret / key 層、Azure Key Vendor 個別 vendor 頁 S2 批次撰寫中）
• 跨模組：8 事故處理 vendor 清單（Entra ID / Azure 事件如何 routing 進 IR 流程）
• 官方：Microsoft Entra Documentation、Azure RBAC Documentation

概念位置

IAM 是模組二：身分與憑證地基的核心機制。它決定了誰能動什麼——人、服務、CI pipeline 各拿剛好夠用的權限（最小權限），憑證有明確的生命週期。身分層失守的代價在五個 infra 責任面向中最高，因為它是其他所有資源的閘門。

在 infra 系列中，IAM 的設計從三個維度展開：最小權限的持續收斂（不是一次設定就結束）、用 OIDC 短期憑證取代長期 access key、以及跨帳號的權限邊界（SCP + Permissions Boundary）。

可觀察訊號

IAM 需要關注的訊號：某個 role 的 policy 有 *:* 或 AdministratorAccess（權限過大）；credential report 顯示有長期 access key 超過 90 天未輪替（憑證散落風險）；Access Analyzer 顯示某個 role 的實際使用 action 遠少於授予的 action（權限擴散）；dev 環境的 CI role 能列出 production 的資源（環境隔離失效）。

設計責任

IAM 設計時要決定：

• 身分類型區分：人用 SSO 登入（強制 MFA）、雲上服務用 instance profile / task role、雲外 CI 用 OIDC 聯合
• 權限分級：admin / operator / viewer 三級，見團隊權限分級
• 環境隔離：每個環境的 role 不能存取其他環境的資源
• 收斂節奏：定期用 Access Analyzer 觀察實際使用的 action，收掉沒用到的權限

鄰卡

• OIDC — 用短期 token 取代長期 access key 的聯合機制
• Security Group — 網路層的存取控制（IAM 是 API 層的存取控制）
• CloudTrail — 記錄 IAM 身分的 API 呼叫歷史