【Day 23】Role-Based Access Control (RBAC)：最小權限原則與 Azure 存取控制實戰 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：Azure RBAC、Security Principal（使用者/群組/服務主體/受控身分）、Role Definition（Owner/Contributor/Reader/User Access Administrator）、Scope（Management Group/Subscription/Resource Group/Resource）、Deny Assignments、權限繼承性、AWS IAM Policy / Role 對照。

🎯 前言與今日目標

本文一樣使用的，agycli 產出及校正在 Day 22 中，我們學習了 Microsoft Entra ID（原 Azure AD）的核心驗證機制與條件式存取（Conditional Access），解決了「你是誰」（Authentication，身份驗證）的問題。然而，當使用者或服務順利通過 MFA 驗證登入系統後，隨之而來的關鍵問題是：「你可以做什麼」（Authorization，授權控管）。

如果把雲端架構比喻為一座古代要塞，Entra ID 是門口的衛兵，檢查護照並要求雙重驗證；而 Azure Role-Based Access Control (RBAC) 就是城堡內的權杖與通行證系統。即使衛兵放你進入城堡，你也不能隨意進入金庫或兵器庫——你必須出示對應特定區域（Scope）的權杖（Role）。

今天 Titan 科技面臨極具挑戰的資安治理課題：資深架構師要為新進工程師、自動化 CI/CD Pipeline 以及外包營運團隊設定存取權限。如果權限給太大（例如直接給予 Owner），工程師可能不小心刪除整個生產環境資料庫或隨意指派高權限給第三方；如果權限給太小（例如僅給予 Reader），維運人員則無法啟動與停止 VM，導致業務癱瘓。

對 AWS 背景的架構師而言，AWS 習慣將 JSON 格式的 IAM Policy 直接附加在 User、Group 或 Role 上（甚至搭配 Resource-based Policy）。而 Azure 採用嚴謹的 三要素分離模型（Role Assignment = Security Principal + Role Definition + Scope）。掌握這套抽象模型與最小權限原則（Least Privilege），不僅是 Pass AZ-900 考試的 30–35% 高頻得分區，更是避免雲端資安破口的核心功力。

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 Azure RBAC 三要素與權限繼承架構圖

┌──────────────────────────────────────────────────────────────┐
│ Titan 存取控制層：Azure RBAC 三要素                          │
├──────────────────────────────────────────────────────────────┤
│ 1. 安全性主體 (Who)  →  User / Group / Service Principal     │
│ 2. 角色定義   (What) →  Owner / Contributor / Reader         │
│ 3. 存取範圍   (Where)→  Management Group / Sub / RG          │
├──────────────────────────────────────────────────────────────┤
│ 權限繼承方向：上層 (Subscription)  ──向下繼承──►  下層 (RG)  │
└──────────────────────────────────────────────────────────────┘

💡 架構師重點筆記：Azure RBAC 將「授給誰 (Principal)」、「能做什麼 (Role Definition)」與「在哪生效 (Scope)」三個維度完全解耦。權限預設由上層資源容器向下自動繼承；任何在父層設定的 Role Assignment，都會影響其底下所有的子資源。

📖 AZ-900 核心名詞解釋與速查

1. Azure RBAC 的三大核心要素與二維矩陣

在 Azure 中，若要給予某人存取權限，必須建立一個 Role Assignment（角色指派）。一個完整的 Role Assignment 由三個要素組合而成：

1. Who（安全性主體 Security Principal）：

   • User：Entra ID 中的個人帳戶（如 alice@titan.com）。
   • Group：多個使用者的集合。最佳實踐是將 Role 指派給 Group，再把 User 加入 Group。
   • Service Principal：應用程式或腳本存取資源時使用的服務身分。
   • Managed Identity：Azure 資源專用的受控身分，無需管理密碼與金鑰。

2. What（角色定義 Role Definition）：

   • 一組 JSON 格式的權限集合。列出控制面（Control Plane）與資料面（Data Plane）的 Allow 與 Deny 操作。

3. Where（存取範圍 Scope）：

   • 指派生效的邊界。階層由上至下為：
     Management Group ➔ Subscription ➔ Resource Group ➔ Resource

┌──────────────────────────────────────────────────────────────┐
│ AWS IAM Policy vs Azure RBAC 結構比較                        │
├──────────────────────────────────────────────────────────────┤
│ [AWS IAM Policy] 策略綁定身分                                │
│ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" }     │
├──────────────────────────────────────────────────────────────┤
│ [Azure RBAC] 角色、主體與範圍三者分離                        │
│ Principal (誰) + Role Definition (權限) + Scope (範圍)       │
└──────────────────────────────────────────────────────────────┘

2. 四大核心內建角色（Built-in Roles）深度拆解

AZ-900 考試中最高頻的試題之一，就是要求架構師根據給定的業務需求，選出最適切的內建角色。最常見的四大內建角色比較如下：

⚠️ 考題陷阱一：「新進工程師需要部署與維修 Web App，但不應該擁有改動權限設定的能力。」
👉 正解是 Contributor（參與者）。許多考生會誤選 Owner（以為做事情需要 Owner）或 User Access Administrator（以為叫 Administrator 就很萬能）。

3. Scope 權限繼承與 Deny Assignment 的特殊機制

權限繼承性 (Inheritance)

Azure RBAC 遵循嚴格的父層向下繼承原則：

• 如果在 Subscription 範圍將某人指派為 Reader，則該使用者對該 Subscription 底下的所有 Resource Group 與所有 Resource 自動擁有 Reader 權限。
• 權限是加法累積 (Additive) 的：若在 Subscription 是 Reader，但在其中的 RG-App 被另外指派為 Contributor，則在 RG-App 內擁有 Contributor 權限，在其他 RG 仍為 Reader。

拒絕指派 (Deny Assignment) 的獨特性

在 AWS IAM 中，我們隨時可以在 Policy 中寫 "Effect": "Deny" 來蓋過 Allow。但在 Azure RBAC 中：

1. Azure RBAC 預設為 Allow-only 模型：你所建立的角色定義基本上都是 Actions（允許）。
2. Deny Assignment 無法手動建立：一般雲端管理員（即便是 Owner）無法在 Azure Portal 或 CLI 中手動建立 Deny Assignment。
3. 由 Azure 系統服務專用：Deny Assignment 主要由 Azure Blueprints 或 Azure Managed Applications 等平台級服務自動建立，用來防止使用者誤刪全套合規資源。

4. 內建角色不足時的解法：自訂角色 (Custom Roles)

雖然 Azure 提供了超過 100 種涵蓋運算、儲存與網路的內建角色，但在大型企業中常有「特定工程師只能重啟 VM，但不能刪除 VM 或變更網路」的極細緻資安要求：

• 自訂角色 (Custom Roles)：允許架構師自行挑選 Actions 與 NotActions 組合成專屬角色。
• 支援建立工具：可使用 Azure Portal、Azure PowerShell、Azure CLI 或 ARM/Bicep 範本定義。
• AZ-900 考點識別：只要題幹出現「內建角色無法符合團隊特定權限需求，需要更精確限制操作」，答案直指 Azure Custom Roles。

5. 跨雲架構對照：AWS 組織治理 vs Azure RBAC 邊界

┌──────────────────────────────────────────────────────────────┐
│ 企業多層級存取控制邊界：AWS 組織治理 vs Azure RBAC 範圍      │
├──────────────────────────────────────────────────────────────┤
│ [AWS 組織治理模型 (cxcxc-io 圖16 觀點)]                      │
│ AWS Organization ➔ OU (Organizational Unit) ➔ AWS Account    │
│  • 邊界控制：SCP (Service Control Policy) 限制最高權限       │
│  • 存取指派：IAM Identity Center / IAM Role 跨帳號 Assume    │
├──────────────────────────────────────────────────────────────┤
│ [Azure 階層存取控制模型]                                     │
│ Management Group ➔ Subscription ➔ Resource Group ➔ Resource  │
│  • 邊界控制：Azure Policy 限制資源合規性                     │
│  • 存取指派：Azure RBAC 在特定 Scope 綁定 Role 與 Principal  │
└──────────────────────────────────────────────────────────────┘

💡 來源：改編自 cxcxc-io diagram_16（多帳號治理與企業級安全架構），已對照 Azure 服務調整。

在 AWS 企業級安全實務中（如 cxcxc-io 圖16 所展示的治理架構），多帳號邊界與跨帳號 AssumeRole 是核心隔離機制；而在 Azure 中，管理群組（Management Group）與訂用帳戶（Subscription）提供了天然的階層架構，RBAC 權限與 Azure Policy 沿著 Scope 自動向下繼承，使大型組織的最小權限控制能以一致的宣告式語法集中落實。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的新進工程師與自動化維運權限管控

Titan 科技正在加速其混合雲專案的維運部署。DevOps 隊長提報了三個極需規範的權限管理情境：

1. 情境 A：團隊加入了一位新進資深工程師 Leo，需要負責建立 Azure Kubernetes Service (AKS) 與虛擬網路，但 Chief Security Officer (CSO) 規定：「Leo 絕對不能有權限把其他人加進管理員名單，避免權限過度擴張。」
2. 情境 B：外部第三方資安公司要進場對 Titan 科技的資源進行安全合規審查，他們只需要查看所有設定，絕不能異動任何架構。
3. 情境 C：自動化部署工具 (GitHub Actions) 需要在夜間自動關閉不使用的測試 VM 以節省成本。

Chief Cloud Architect 必須為這三個情境選出最符成本與資安標準的 RBAC 設定。

🧩 決策任務

針對情境 A（新進工程師 Leo 的權限配置），應在目標 Resource Group 上指派哪個角色？

• A. 在 Resource Group 範圍指派 Owner 角色。
• B. 在 Resource Group 範圍指派 Contributor 角色。
• C. 在 Subscription 範圍指派 User Access Administrator 角色。
• D. 在 Resource 範圍指派 Reader 角色，搭配系統手動賦予的 Admin 權限。

🎯 解題拆解與解析（架構師推理鏈）

✅ 正解：B

為什麼選 B？

• Contributor 角色擁有完全管理資源（建立、修改、刪除 VM、VNet、AKS）的能力，滿足 Leo 建立維運資源的需求。
• 同時，Contributor 完全不具備權限管理（Microsoft.Authorization/*）的能力，無法指派角色給其他人或提升自己權限，完美符合 CSO 的要求與「最小權限原則」。

❌ 陷阱分析：

• A 錯誤 (Owner)：Owner 包含了 Microsoft.Authorization/* 權限，Leo 將能隨意將自己或外部人員指派為 Owner，打破資安防線。
• C 錯誤 (User Access Administrator)：該角色專門用來指派別人的權限，但無法建立或管理任何 Azure 實體資源（如無法建立 VM/AKS），Leo 將完全無法開工。
• D 錯誤 (Reader)：Reader 只能讀取，無法建立與維修資源；且手動賦予 Admin 權限說法模糊，不符標準 RBAC 規範。

🎯 Part 3：AZ-900 精選高頻真題解析

📝 AZ-900 高頻真題 1：Owner 與 Contributor 權限邊界區分（ExamTopics 題型改編）

題目情境

Titan 科技的系統管理員希望授權給維運主管 Alice，讓她可以建立 Resource Group 並管理其中的 VM，同時 Alice 還需要能夠將小組成員納入該 Resource Group 的存取清單中。應給予 Alice 哪種內建角色？

• A. Reader
• B. Contributor
• C. Owner
• D. Management Group Contributor

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：「管理 VM」＋「將小組成員納入存取清單（指派權限）」。
2. 核心考點定位：只有 Owner 與 User Access Administrator 具備指派權限的能力；而要同時管理 VM 資源與指派權限，只有 Owner。
3. 陷阱識破：Contributor 可以管理 VM，但無法將成員加入存取清單（無法指派權限）。

• 來源與驗證：改寫自 ExamTopics AZ-900 Owner vs Contributor 高頻題型（票數待以 examtopics-az900-search skill 定向覆核）；並經 Microsoft Learn：Azure 內建角色 交叉驗證。

📝 AZ-900 高頻真題 2：Scope 權限繼承規則（ExamTopics 題型改編）

題目情境

Titan 科技在 Azure 上有一個名為 Sub-Production 的訂用帳戶。資安主管在 Sub-Production 範圍將工程師 Bob 指派為 Reader 角色。請問 Bob 對該訂用帳戶內名為 RG-Data 的資源群組擁有什麼權限？

• A. 完全沒有權限，必須在 RG-Data 重新指派權限。
• B. 自動繼承 Reader 權限，可檢視 RG-Data 內的所有資源。
• C. 自動升級為 Contributor 權限。
• D. 只能檢視 RG-Data 本身，無法檢視內部的資源。

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：「在 Subscription 裝設 Reader」➔「對子層 RG-Data 的權限」。
2. 核心考點定位：Azure RBAC 遵循父層向子層自動向下繼承（Inheritance）的原則。
3. 陷阱識破：上層設定的權限會自動貫穿至底下所有的 Resource Group 與 Resource，不需要重複指派。

• 來源與驗證：改寫自 ExamTopics AZ-900 Scope 繼承高頻題型（票數待以 examtopics-az900-search skill 定向覆核）；並經 Microsoft Learn：瞭解 Azure RBAC 的範疇 交叉驗證。

📝 AZ-900 高頻真題 3：自動化程式的最佳身分選擇（ExamTopics 題型改編）

題目情境

Titan 的開發生態系需要讓運行在 Azure VM 上的 Python 程式自動存取 Azure Key Vault 讀取金鑰。為符合資安最佳實務，應使用何種身分並搭配 RBAC？

• A. 將管理員的帳號密碼寫死在 Python 程式碼中。
• B. 啟用 VM 的受控身分 (Managed Identity)，並於 Key Vault 授予該身分 RBAC 角色。
• C. 為該程式建立一個具備 Owner 權限的使用者帳號。
• D. 關閉 Key Vault 的權限控管。

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：「Azure 資源上的程式」＋「自動存取其他服務」＋「資安最佳實務」。
2. 核心考點定位：Azure Managed Identity 是專為 Azure 資源設計的身分，免去在程式碼中寫死 credentials 的風險。
3. 陷阱識破：硬編碼帳密 (A) 或指派 Owner (C) 皆嚴重違反最小權限與安全原則。

• 來源與驗證：改寫自 ExamTopics AZ-900 Managed Identity 應用題型（票數待以 examtopics-az900-search skill 定向覆核）；並經 Microsoft Learn：什麼是 Azure 資源的受控識別 交叉驗證。

📝 AZ-900 真題 4：Deny Assignment 的建立限制（2020 gratisexam 題庫改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（歷史題型改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證；題目觀念符合現行考綱。

題目情境

判斷以下敘述是否正確：
「Titan 科技的 Subscription Owner 可以手動建立自訂的 Deny Assignment，以明確禁止特定團隊存取核心財務資源。」

• A. 正確 (Yes)
• B. 錯誤 (No)

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：「Owner 手動建立 Deny Assignment」。
2. 核心考點定位：Deny Assignment 唯有 Azure 平台與特定受控服務（如 Blueprints/Managed App）能自動建立，一般使用者（即便身為 Owner）均無法手動建立 Deny Assignment。
3. 解決方案：若要阻止建立特定資源，應使用 Azure Policy 的 Deny 效果，而非 RBAC Deny Assignment。

• 來源與驗證：改寫自 2020 年 gratisexam 題庫 Deny Assignment 觀念題；並經 Microsoft Learn：瞭解 Azure 拒絕指派 交叉驗證。

📝 AZ-900 真題 5：Azure Policy 與 Azure RBAC 的權責邊界（2020 gratisexam 題庫改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（歷史題型改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證；題目觀念符合現行考綱。

題目情境

Titan 科技希望限制所有員工只能在「East US」區域建立資源。請問這項規則應該透過 Azure RBAC 還是 Azure Policy 來實施？

• A. Azure RBAC，指派特定的 Regional Role。
• B. Azure Policy，建立並指派 Allowed Locations 的政策。
• C. Entra ID Conditional Access。
• D. Resource Lock。

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：「限制資源只能在特定區域建立（資源屬性合規）」。
2. 核心考點定位：RBAC 管人（誰能做什麼），Policy 管資源（資源長什麼樣子才符合規定）。
3. 解析說明：RBAC 無法限制資源的地理位置或規格大小，這類資源合規性要求必須靠 Azure Policy。

• 來源與驗證：改寫自 2020 年 gratisexam 題庫 Policy vs RBAC 題型；並經 Microsoft Learn：Azure Policy 與 Azure RBAC 的比較 交叉驗證。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

在 AWS 認證（CLF-C02 / SAA-C03）中，IAM 的靈魂是將 JSON 策略（Policy）附加至 User/Group/Role，或透過 Organizations SCP (Service Control Policy) 進行跨帳號限制。而在 Azure 觀念轉換時，請務必掌握以下連動邏輯：

🎲 AWS 經典情境一：跨帳號/跨範圍存取的角色設計

題目： 某企業在 AWS 擁有多個 AWS Account，需要讓 Dev 帳號中的 EC2 能夠存取 Prod 帳號中的 S3 Bucket。AWS 的最佳實踐是讓 EC2 透過 AssumeRole 取得暫時性金鑰。請問在 Azure 中，若要讓訂用帳戶 A 的 VM 存取訂用帳戶 B 的 Storage Account，應如何設計？

• A. 複製 Storage Account Key 並寫在 VM 設定檔中。
• B. 啟用 VM 的 Managed Identity，並在訂用帳戶 B 的 Storage Account 上直接對該 Managed Identity 進行 RBAC 角色指派（如 Storage Blob Data Reader）。
• C. 在 Entra ID 建立一個全局 Owner 帳號。
• D. 無法跨 Subscription 授權。

答案：B。
Azure 知識映射：Azure RBAC 的 Scope 具備高度彈性。Managed Identity 屬於 Entra ID 租戶層級，可以被直接指派給同租戶下任何 Subscription 的任何資源，無需像 AWS 一樣編寫複雜的跨帳號 Trust Policy 信任鏈。

🎲 AWS 經典情境二：最小權限與權限分離

題目： AWS IAM 中，PowerUserAccess 策略與 AdministratorAccess 策略的主要差異在於後者包含 IAM 的管理權限。請問這與 Azure 中的哪一對內建角色完全對應？

• A. Contributor（對應 PowerUserAccess）與 Owner（對應 AdministratorAccess）。
• B. Reader 與 Contributor。
• C. User Access Administrator 與 Owner。
• D. Custom Role 與 Built-in Role。

答案：A。
雙雲考場口訣：
AWS PowerUserAccess = Azure Contributor（能管資源、不能管權限）；
AWS AdministratorAccess = Azure Owner（資源與權限雙管）。

📐 Part 4：以戰代訓課程對照

🚀 今日總結與明日預告

🏆 今日 3 點速記

1. RBAC 三要素黃金公式：Role Assignment = Security Principal (誰) + Role Definition (權限) + Scope (範圍)。
2. Owner vs Contributor 關鍵界線：兩者都能完全建立與刪除資源，但只有 Owner 能夠把權限指派給別人（擁有 Microsoft.Authorization/*）。
3. RBAC 管人、Policy 管資源：RBAC 決定「誰有資格操作」，Azure Policy 決定「資源屬性是否合規」；Deny Assignment 一般人無法手動建立，專由 Azure 系統服務維護。

🔮 明日預告：Day 24 Zero Trust Model & Defender for Cloud

掌握了 RBAC 的權限邊界後，我們將進一步築起縱深防禦網路！明天 Titan 科技將面臨網路邊界失效後的終極考驗：進入 Day 24 Zero Trust Model & Defender for Cloud（零信任架構與資安中心），剖析「永不信任，始終驗證」的零信任三大支柱，以及如何透過 Microsoft Defender for Cloud 自動掃描並修補雲端資安漏洞！