服務定位

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