💡 先搞懂問題
虛構公司「青松物流」剛把訂單系統搬上 Azure。一開始為了方便，IT 主管把三位工程師都設成訂用帳戶的擁有者，外包廠商借用其中一人的帳號上線除錯。三個月後，一位工程師清理測試資源時刪錯了資源群組，正式環境的儲存體帳戶跟著消失；事後查活動記錄，只看到那個共用帳號，不知道是誰按的。稽核要求「每個人只能有工作需要的權限」，但團隊不知道該從哪裡收：收太緊，工程師連重開 VM 都要開單；收不對地方，權限照樣滿天飛。
新手在這裡最常卡住的有三件事。第一，不知道「在哪一層給權限」會影響多大範圍：同一個角色給在訂用帳戶，等於整個訂用帳戶裡現在與未來的所有資源都適用。第二，以為角色名稱看起來夠大就什麼都能做，結果 Owner 打開儲存體帳戶裡的 Blob 卻被拒絕，或是 Microsoft Entra 的全域管理員在 Azure 入口網站裡看不到任何訂用帳戶。第三，搞不清楚為什麼明明拿掉了某個角色，對方還是有權限，原因是他從別的地方繼承或疊加到了同樣的權限。
Azure 用來處理這些問題的機制叫角色型存取控制（Azure role-based access control，Azure RBAC）。它的單位是角色指派（role assignment）：把一個安全性主體（security principal），也就是使用者、群組、服務主體或受控識別，和一個角色定義（role definition），也就是一組允許的動作，綁在某個範圍（scope）上。範圍就是 Azure 的資源階層：管理群組、訂用帳戶、資源群組、資源四層，指派在上層的角色會往下繼承。
生活比喻：連鎖企業的門禁卡
青松物流在全台有幾間分公司，每間分公司有好幾層樓，每層樓又有不同房間。總務處發門禁權限時，不會一個房間一個房間設定，而是決定這張卡「在哪一層有效」：總部的稽核主任拿到全公司通行，任何分公司、任何樓層都刷得過；台中分公司的主管拿到台中分公司通行，台中的每層樓、每個房間都能進，但刷不進台北分公司；機房工程師只拿到 3F 機房這一個房間。另外，卡片的權限也分等級：有的卡只能進門參觀，有的卡進門後可以搬動設備，總務處的人除了自己能進，還能替別人發卡。
同一個人也可能同時拿到好幾項授權，例如他本來就有 3 樓辦公室的通行，後來又被加上機房的權限，那他能進的地方就是兩者的總和。換部門時如果只撤掉其中一項，另一項還在，他照樣刷得進。
比喻有三個地方和 Azure 不一樣，正好也是最常考錯的地方。第一，門禁系統通常只有「授權」，Azure 另外有拒絕指派（deny assignment），它比任何角色指派都優先，就算你是 Owner 也會被擋；不過客戶不能自己直接建立拒絕指派，它是由 Azure 建立與管理的，例如部署堆疊（deployment stacks）的拒絕設定。第二，門禁卡刷進房間後，房裡的東西大多能碰；Azure 的 Owner、Contributor 管的是控制平面（建立、設定、刪除資源），要讀 Blob 裡的檔案這種資料平面動作，還需要像 Storage Blob Data Reader 這類資料角色，或是透過存取金鑰繞道。第三，員工帳號本身是人資系統建立的，門禁系統只負責開門；在 Azure 裡，帳號與群組放在 Microsoft Entra ID，管理帳號的是 Entra 角色（例如全域管理員），管理 Azure 資源的是 Azure 角色，兩套系統預設互不相通。
🎮 互動實驗室一：權限繼承模擬器
「資源樹與有效權限」是青松物流的資源樹（桌機在右邊，手機在下方）。先選一個安全性主體與角色，再點樹上的任一個節點當作範圍，按「新增角色指派」。樹上每個節點會即時標出這個主體在那裡繼承到哪些權限：綠色是可以、灰色刪除線是不行、紅色是被拒絕指派擋下、黃色是要特別注意的旁路。可以替同一個主體加好幾筆指派，看權限怎麼累加。上方有四個任務，做完按「檢查任務」會告訴你範圍與角色選得對不對。點樹上的節點也會在下方顯示「為什麼」。
新增角色指派
資源樹與有效權限
🎮 互動實驗室二：最小權限分診台
每張卡是一個虛構公司的需求。先挑「角色」，再挑「範圍」，按「確認」。兩個都要對：角色要夠用但不多給，範圍要涵蓋需求但不擴散到不相關的資源。有些需求其實不是 Azure RBAC 管的，要選「Entra 角色」。答完會說明原因，選錯時也會說明你選的那個什麼時候才適合。
🛠️ 操作教學：建立資源群組並指派角色
情境：青松物流要替訂單系統的正式環境開一個資源群組，並讓「維運組」群組能管理裡面的資源。左邊是簡化的入口網站，照步驟填欄位、按「下一步」；右邊的 Azure CLI 與 Bicep 會跟著你填的名稱、區域與角色即時更新，目前步驟對應的那幾行會用底色標出來。可以故意填錯名稱，看看驗證訊息。
自己動手時要注意
權限：建立資源群組需要在訂用帳戶上有能寫入資源群組的角色，例如 Contributor；新增角色指派則需要 Microsoft.Authorization/roleAssignments/write，內建角色中的 Owner、User Access Administrator、Role Based Access Control Administrator 才有。所以只有 Contributor 的人可以照著做前三步，到「存取控制 (IAM)」時會發現「新增角色指派」無法使用，這是正常的。指派完成後要等幾分鐘才會生效，在管理群組層級指派可能更久。
費用：資源群組與角色指派本身不收費，Azure RBAC 也不另外計費；但如果你接著在資源群組裡建立 VM、儲存體帳戶等資源，就會開始依用量計費。
清理：練習完把整個資源群組刪掉，裡面的資源會一起刪除；指派在該資源群組範圍的角色指派也會一起消失。指派在訂用帳戶等上層範圍的角色指派不會跟著刪，要另外移除。
# 練習完刪除整個資源群組（裡面的資源一併刪除，無法復原）
az group delete --name rg-qingsong-app-prod --yes --no-wait
# 若曾在訂用帳戶層級做過練習用的指派，記得另外移除
az role assignment list --assignee-object-id "<group-object-id>" --all --output table不要寫進範例的東西：本頁所有指令都用 <your-subscription-id>、<group-object-id> 這類佔位字。真實的訂用帳戶 ID、物件識別碼、存取金鑰或連接字串不要貼進程式碼儲存庫、聊天群組或教學文件；部署用的服務主體優先改用受控識別或工作負載身分識別同盟，避免保存密碼。
📘 原理補完
四個範圍與它們上面的租用戶
Azure 的資源階層由上到下是管理群組（management group）、訂用帳戶（subscription）、資源群組（resource group）、資源（resource），這四層就是角色指派可以落點的範圍，Microsoft Learn 的說法是「從廣泛到狹窄的四個層級」。四層之上還有 Microsoft Entra 租用戶（tenant），它是身分的來源，存放使用者、群組、服務主體，但它本身不是 Azure RBAC 的範圍。每個租用戶有一個根管理群組（預設名稱 Tenant root group），它的 ID 就是租用戶 ID，不能移動或刪除；新建立的訂用帳戶預設會放在根管理群組下。管理群組最多 6 層（不含根層級與訂用帳戶層級），一個目錄最多 10,000 個管理群組，每個管理群組、訂用帳戶都只能有一個父層，每個資源也只能屬於一個資源群組（以上數字查證於 2026 年 10 月）。
有效權限怎麼算：繼承、累加、拒絕優先
Azure 判斷某個主體能不能對某個資源做某個動作時，會把所有相關的角色指派一起看：指派在這個資源本身的、在它的資源群組的、在訂用帳戶的、在各層管理群組的，以及指派給他所屬群組的，全部加起來。權限是累加（additive）的，只要有一筆指派允許，動作就被允許；所以把某人的 Contributor 拿掉，如果他所屬的群組在上層還有 Contributor，他照樣能改。唯一能壓過允許的是拒絕指派：拒絕指派優先於角色指派，就算有 Owner 也會被擋。客戶不能直接建立拒絕指派，它由 Azure 建立與管理，最常見的來源是部署堆疊的拒絕設定（例如 denyDelete、denyWriteAndDelete）。
常見內建角色比較
內建角色分成兩大類：管理 Azure 資源本身的控制平面角色，以及存取資源內資料的資料平面角色。入口網站的「新增角色指派」把 Owner、Contributor、User Access Administrator、Role Based Access Control Administrator 這類能影響權限的角色放在「特權管理員角色」分頁，其他放在「工作功能角色」分頁。每個內建角色都有固定的 GUID（可在官方內建角色頁或用 az role definition list --name Reader 查到），Bicep 常直接用 GUID 指定，CLI 則可以直接寫角色名稱。
| 角色 | 管理資源（建立、修改、刪除） | 指派角色給別人 | 讀取 Blob 資料（Entra 驗證） | 典型用途 |
|---|---|---|---|---|
| Owner | 可以 | 可以 | 不行，需另加資料角色 | 訂用帳戶或工作負載的負責人；人數越少越好，搭配 PIM 即時啟用 |
| Contributor | 可以 | 不行；也不能建立資源鎖定、管理 Blueprints 指派、分享映像庫 | 不行，需另加資料角色 | 專案團隊、部署管線的服務主體 |
| Reader | 只能檢視 | 不行 | 不行 | 稽核、支援人員、要看設定的人 |
| User Access Administrator | 只能檢視 | 可以，任何角色 | 不行 | 專門管理存取權的人；權限大，應少用 |
| Role Based Access Control Administrator | 只能檢視 | 可以，只透過 Azure RBAC | 不行 | 只需要分派角色、不需要用 Azure Policy 等其他方式管理存取的人 |
| Virtual Machine Contributor | 只限 VM 與磁碟等，不含所連的虛擬網路與儲存體帳戶 | 不行 | 不行 | 只負責 VM 的維運人員或廠商 |
| Storage Blob Data Reader | 不行（只有容器讀取等少數動作） | 不行 | 可以讀取與列出 | 只需要讀檔的應用程式或受控識別 |
| Storage Blob Data Contributor | 不行（只有容器讀寫等少數動作） | 不行 | 可以讀、寫、刪除 | 要上傳或整理檔案的應用程式 |
內建角色不夠精準時，可以建立自訂角色（custom role），自己列出允許的 Actions 與 DataActions，並設定它可以被指派的範圍。另外，2024 年 8 月 31 日起，傳統訂用帳戶管理員角色（Co-Administrator、Service Administrator）已停止支援，2026 年 5 月完全退役，現在要管理存取一律用 Azure RBAC。
控制平面和資料平面：Owner 為什麼讀不到 Blob
Azure 的請求分成兩條路。建立儲存體帳戶、改備援設定、刪除資源，這些是控制平面（control plane）操作，送到 Azure Resource Manager（management.azure.com）；上傳或讀取某個 Blob 檔案，是資料平面（data plane）操作，直接送到服務自己的端點（例如 <帳戶名稱>.blob.core.windows.net）。Owner、Contributor、Reader 的定義裡只有 Actions，沒有讀寫 Blob 的 DataActions，所以用 Microsoft Entra 身分讀 Blob 時，它們都不夠，要另外指派 Storage Blob Data Reader 或 Storage Blob Data Contributor。在入口網站用 Entra 身分瀏覽 Blob，至少還需要 Reader 才看得到儲存體帳戶。
這裡有一個容易被忽略的旁路：Owner 與 Contributor 具備 Microsoft.Storage/storageAccounts/listkeys/action，可以取得儲存體帳戶的存取金鑰，再用共用金鑰（Shared Key）存取資料。所以「Contributor 不能讀資料」只在帳戶停用共用金鑰授權時才完全成立；要真正收斂資料存取，除了給對的資料角色，也要考慮停用共用金鑰、改用 Entra 驗證。
所有請求都經過同一個關卡
不論是在入口網站點按、跑 Azure CLI 或 PowerShell，還是部署 Bicep 與 ARM 範本，控制平面的請求都送到 Azure Resource Manager。ARM 先驗證身分（Microsoft Entra ID 核發的權杖），再用角色指派與拒絕指派判斷授權，接著檢查 Azure Policy 與資源鎖定，通過之後才轉給負責的資源提供者（例如 Microsoft.Compute、Microsoft.Storage）。因為走同一個關卡，三種工具能做的事與權限結果一致；你在操作教學裡用入口網站做的角色指派，和右邊 CLI、Bicep 的結果是同一筆資源（Microsoft.Authorization/roleAssignments）。
判斷步驟：先選角色，再選範圍
- 先確認對方要管的是 Entra 目錄（帳號、群組、密碼、應用程式註冊）還是 Azure 資源。前者是 Entra 角色，不是 Azure RBAC。
- 如果是 Azure 資源，再問他要碰的是資源的設定，還是資源裡的資料。讀寫 Blob、佇列訊息這類需求，挑資料角色。
- 只需要看設定：Reader。要建立、修改、刪除，但不需要發權限：Contributor，或更窄的服務專屬角色（例如 Virtual Machine Contributor）。
- 要替別人指派角色：只需要用 RBAC 指派就選 Role Based Access Control Administrator；需要完整管理資源又要指派，才是 Owner。User Access Administrator 權限很大，保留給專門管理存取的人。
- 範圍挑需求所在的最小層級：一台 VM 就指派在那台 VM，一個專案就指派在它的資源群組；要涵蓋整個集團與未來新增的訂用帳戶，才用管理群組。
- 角色優先指派給群組，人員異動時只要調整群組成員；高權限角色用 Privileged Identity Management（PIM）的合格指派，需要時才啟用。
容易考錯的地方
Contributor 和 Owner 只差一件事：兩者都能完整管理資源，只有 Owner 能指派角色。題目問「能部署資源但不能授權給其他人」時答 Contributor；選項出現 Owner 通常是給太多的干擾選項。
Reader 不等於能讀資料：Reader 看得到儲存體帳戶與它的設定，但讀不到裡面的 Blob；要讀資料是 Storage Blob Data Reader。反過來，只有資料角色而沒有 Reader 的人，在入口網站裡可能連儲存體帳戶都看不到，但用程式透過 Entra 驗證存取資料是可以的。
全域管理員不會自動管 Azure 資源：Entra 角色和 Azure 角色是兩套系統。看到「全域管理員看不到訂用帳戶」的情境，正解通常是替他做 Azure 角色指派，或在緊急時使用提高存取權，而不是再給他一個 Entra 角色。
移除一筆指派不保證權限消失：權限累加，還要檢查他所屬的群組、上層範圍的指派。入口網站的「檢查存取權」與 az role assignment list --include-inherited --include-groups 就是用來看全貌的。
拒絕指派不是你建的：題目若問「如何建立拒絕指派」，要知道客戶不能直接建立，常見做法是用部署堆疊的拒絕設定；若只是要防止誤刪，資源鎖定也是選項（見地圖上的資源鎖定節點）。
範圍和標籤無關：RBAC 的範圍只有管理群組、訂用帳戶、資源群組、資源四層，不能「指派給有 env=prod 標籤的資源」。
以上概念在 AZ-900（Azure RBAC、管理群組與資源階層）、AZ-104（內建角色與範圍、管理群組、訂用帳戶與資源群組）與 SC-500（內建與自訂角色、找出過度授權）的技能大綱裡都有出現；AZ-305 的「設計身分識別、治理與監視解決方案」領域則會從設計角度問同樣的取捨。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6