💡 先搞懂問題
虛構的「北辰醫院」資訊室同時被兩件事困擾。第一件是人：員工只要帳號密碼正確，不論在院內、在家、還是在國外的網咖都能登入財務報表系統；有位主任的密碼在別的網站外洩過，資訊室才發現沒有任何機制能說「從院外登入要多驗一次」或「財務系統只准醫院配發的電腦」。他們試過開啟安全性預設值（security defaults），所有人一律要 MFA，可是沒辦法針對財務系統或特定裝置另外設定。
第二件是程式：掛號網站要從 Azure Key Vault 讀資料庫密碼，工程師為了「先讓它動起來」，把存取 Key Vault 用的服務主體密碼寫在網站設定裡。這組密碼會到期、要輪替，又曾經被貼進工作群組，負責的工程師離職後沒人敢換。
這兩件事在 Azure 裡各有一個正解。條件式存取（Conditional Access）是 Microsoft Entra ID 的原則引擎，用「如果……就……」的規則決定一次登入能不能進來：如果是財務部的人、要開財務系統、裝置不符合規範，就封鎖；如果是從公司網路以外登入，就要求 MFA。受控識別（managed identity）則是 Azure 替資源自動建立、保管與輪替憑證的身分，程式向平台要一張 Entra 權杖（token）就能存取 Key Vault，整個過程看不到任何密碼。
新手最常卡的地方：以為條件式存取在輸入密碼之前就把人擋在門外，其實它在第一因素驗證之後才評估；以為多條原則「取最寬鬆的」，其實是全部都要滿足、而且封鎖優先；忘了條件式存取需要 Entra ID P1 授權、風險條件需要 P2；以為開了受控識別就能讀 Key Vault，其實還要另外用 Azure RBAC 指派角色；也分不清系統指派與使用者指派，在資源刪除時會發生什麼事。
生活比喻：辦公大樓的智慧門禁
想像一棟辦公大樓換了智慧門禁。保全總監在門禁主機裡寫了幾條規則：「任何員工從側門進來，要再按一次指紋」「要上財務樓層的人，手上必須是公司配發、有登記的平板，私人手機一律不行」「警衛通報某張卡疑似被盜，那張卡直接鎖住」。員工先刷卡，主機確認是本人之後，才開始比對這些規則；同一個人同時符合好幾條，每一條的要求都要做到，只要有一條說「擋下」，其他規則再寬鬆也沒用。新規則上線前，總監會先讓主機「只記錄、不執行」一週，看看會擋到哪些人；他自己也留一張不受這些規則限制的萬用備用卡，鎖在保險箱裡，免得規則寫錯時全公司都進不了門。
大樓裡還有送公文的機器人。以前它借用某位員工的門禁卡，那位員工離職、換卡，機器人就停擺。現在管理處直接替機器人做一張它自己的識別證，卡片內碼由管理處定期更換，機器人和工程師都不需要知道內碼；至於這張卡能進收發室還是檔案室，要另外在權限表上登記。
這個比喻有幾個地方和實際不同。第一，大樓門禁在門口就攔人，條件式存取則是在使用者完成第一因素（例如密碼）之後才評估，所以它不是擋阻斷服務攻擊的第一道防線。第二，智慧門禁只管進門那一刻；條件式存取也能設定工作階段控制，例如多久要重新登入一次。第三，條件式存取決定的是「這次登入能不能拿到權杖」，進來之後能對哪些 Azure 資源做什麼，仍由 Azure RBAC 決定，兩者不能互相取代。第四，機器人的識別證只在大樓裡有效：受控識別只能給 Azure 資源（以及透過 Azure Arc 連線的伺服器等）使用，在 GitHub Actions 或地端伺服器上執行的程式，要改用工作負載身分同盟或服務主體。
🎮 互動實驗室一：條件式存取原則評估模擬器
北辰醫院設了三條條件式存取原則（可直接修改每一條的狀態、指派、條件與授與控制）。在下方設定一次登入事件，或按情境按鈕帶入，再按「評估這次登入」。畫面會列出每條原則有沒有套用、為什麼，以及最後的結果。想挑戰自己，可以在評估前先猜結果。這裡假設使用者的密碼（第一因素）已經驗證通過、而且已經註冊好 MFA 方法；人名、群組與應用程式都是虛構的。
| 原則 | 狀態 | 是否套用與原因 | 這條原則的要求與結果 |
|---|
🎮 互動實驗室二：受控識別情境分診
每張卡是一個原創情境，請判斷最適合的身分做法：系統指派受控識別、使用者指派受控識別、應用程式註冊加服務主體，或者這根本不是受控識別該處理的事。答完會說明理由；選錯時也會告訴你你選的那一種適合什麼情境，並補充這個選擇在資源刪除或重建時會發生什麼事。
🛠️ 操作教學：替 Web 應用程式開啟受控識別並授權讀取 Key Vault
條件式存取是在 Microsoft Entra 系統管理中心設定的租用戶層級原則，不屬於 Azure 資源，所以這裡的操作以受控識別為主（條件式存取的自動化方式放在原理補完）。跟著 7 個步驟：替北辰醫院的掛號網站開啟系統指派受控識別、視需要加上使用者指派受控識別、確認 Key Vault 使用 Azure RBAC 權限模型，再把 Key Vault Secrets User 角色指派給這個身分。你填的名稱會即時反映到右邊的 Azure CLI 與 Bicep，目前步驟對應的那幾行以黃色底標示。
應用程式怎麼用這個身分：一段不含任何金鑰的程式碼
角色指派完成後，網站程式只要用 Azure 身分識別程式庫（azure-identity）向平台要權杖。DefaultAzureCredential 會依序嘗試環境變數、工作負載身分、受控識別、開發工具登入（例如 Azure CLI 的 az login）等方式，所以同一段程式在 Azure 上會用受控識別，在你自己電腦上會用你登入的帳號。官方建議部署到 Azure 後改用明確的 ManagedIdentityCredential，避免意外用到其他憑證，也比較好排查。
# pip install azure-identity azure-keyvault-secrets
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
# 在 Azure 上會用到 Web 應用程式的受控識別；在自己電腦上會用 az login 的帳號
credential = DefaultAzureCredential()
# 使用使用者指派受控識別時，指定它的用戶端識別碼（client ID，不是密碼）：
# credential = DefaultAzureCredential(managed_identity_client_id="<client-id>")
# 直接取得權杖：範圍是 Key Vault；不要把權杖本身印出或寫進紀錄
token = credential.get_token("https://vault.azure.net/.default")
print("權杖到期時間（Unix 時間）:", token.expires_on)
# 一般情況交給 SDK 處理權杖，程式碼裡沒有任何金鑰或連線字串
client = SecretClient(vault_url="https://kv-beichen-demo.vault.azure.net", credential=credential)
db_password = client.get_secret("db-password").value自己動手時要注意
權限：在 Web 應用程式上開啟受控識別，需要能修改該資源的角色，例如 Contributor 或 Website Contributor；建立使用者指派受控識別可用 Managed Identity Contributor。指派角色則需要 Owner、User Access Administrator 或 Role Based Access Control Administrator 這類能寫入角色指派的角色，單純的 Contributor 做不到。費用：受控識別與角色指派不另外收費，但 App Service 方案與 Key Vault 的作業會計費。注意：角色指派生效可能要等幾分鐘；把 Key Vault 從存取原則改成 Azure RBAC 前，先確認既有使用者與應用程式都已有對應的角色，否則他們會突然讀不到機密。練習完把資源群組刪除：
# 刪除練習用的資源群組與裡面所有資源（無法復原，確認名稱再執行）
az group delete --name rg-beichen-app --yes --no-wait範例裡沒有任何金鑰、密碼、連線字串或訂用帳戶 ID。用 az account set --subscription <your-subscription-id> 切換訂用帳戶時，佔位字請換成自己的值，不要把真實 ID 貼到公開的地方。
📘 原理補完
條件式存取原則的結構
每條條件式存取原則由兩部分組成。指派（assignments）回答「對誰、在什麼情況下套用」：使用者、群組或目錄角色（也能鎖定工作負載身分與 agent 身分，但需要對應授權），可以包含也可以排除；目標資源，例如所有資源或特定雲端應用程式；以及條件，例如登入風險、使用者風險、裝置平台、位置（IP 範圍或國家／地區，可設定受信任位置）、用戶端應用程式與裝置篩選。存取控制（access controls）回答「套用了之後怎樣」：封鎖存取，或授與存取但要求滿足控制，例如需要多重要素驗證、需要驗證強度（authentication strength）、需要將裝置標記為符合規範、需要已加入 Microsoft Entra 混合式的裝置、需要核准的用戶端應用程式、需要應用程式保護原則、需要變更密碼、需要接受使用規定；多個授與控制可以選「全部都要」（預設）或「其中一項即可」。另外還有工作階段控制，例如登入頻率。
評估時機與多條原則的合併
條件式存取在第一因素驗證完成之後才評估，不是阻斷服務攻擊的第一道防線。評估分兩個階段：先收集工作階段資訊（位置、裝置等），這一步開啟中與僅限報告的原則都會做；再進入強制執行，只有開啟中的原則會做。強制執行時，只要有任何一條套用的原則是封鎖，就直接拒絕；否則把所有套用原則的授與控制合起來，全部滿足才發出權杖。所以一條原則要 MFA、另一條要符合規範的裝置，使用者兩個都得做到。沒有任何原則套用時，條件式存取不會額外要求什麼，第一因素通過就放行，這也是為什麼要搭配一條涵蓋所有使用者的基準原則。
僅限報告模式的結果有四種：Report-only: Success（條件與控制都已滿足）、Failure（條件符合，但不互動的控制沒有滿足，例如裝置不符合規範）、User action required（需要使用者動作才能滿足，例如 MFA，但不會真的提示）、Not applied（條件不符，例如使用者被排除）。結果可以在登入紀錄的條件式存取與僅限報告分頁，以及條件式存取深入解析活頁簿查看。官方提醒，要求符合規範裝置的僅限報告原則，可能讓 macOS、iOS、Android 使用者反覆看到選取裝置憑證的提示，建議先排除這些平台。新原則的標準流程是：排除緊急存取帳戶、先用僅限報告觀察一段時間、確認影響再開啟。
條件式存取原則存放在 Microsoft Entra 租用戶裡，不是 Azure Resource Manager 的資源，所以不能用 az 的資源指令或 Bicep 建立。要自動化或納入版本控制，透過 Microsoft Graph 的 /identity/conditionalAccess/policies API（或 Microsoft Graph PowerShell）。原則的 state 有三種值：enabled、disabled，以及代表僅限報告的 enabledForReportingButNotEnforced。下面是用 Azure CLI 呼叫 Graph 列出原則的示意，實際能否執行取決於你的目錄角色與 Graph 權限：
# 列出租用戶中的條件式存取原則（只讀取；需要有讀取原則的權限）
az rest --method GET --uri https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies --query "value[].{name:displayName, state:state}" --output table授權與相近功能
條件式存取需要 Microsoft Entra ID P1（Microsoft 365 Business Premium 也包含）；以登入風險或使用者風險為條件的原則，需要 Microsoft Entra ID Protection，屬於 P2 功能；鎖定工作負載身分需要 Microsoft Entra Workload ID 授權，要求裝置符合規範則要搭配 Intune。沒有 P1、只想替所有人快速開啟 MFA 時，用免費的安全性預設值，但它無法細分使用者、應用程式或位置，而且和條件式存取不能同時使用。Azure AD 已在 2023 年更名為 Microsoft Entra ID，授權名稱也從 Azure AD Premium P1／P2 改為 Microsoft Entra ID P1／P2，功能與價格不變。
| 功能 | 回答的問題 | 重點 |
|---|---|---|
| 條件式存取 | 這次登入能不能拿到權杖、要先滿足什麼 | 指派＋條件＋授與／封鎖；需 P1，風險條件需 P2 |
| 安全性預設值 | 沒有 P1，怎麼替全員快速開 MFA | 免費、一鍵、無法細調，不能和條件式存取並用 |
| Azure RBAC | 登入後能對哪些 Azure 資源做什麼 | 安全性主體＋角色定義＋範圍；受控識別也是安全性主體 |
| PIM | 高權限角色怎麼及時啟用、有期限 | 符合資格指派、核准與時限；需 P2 或 ID Governance |
| 受控識別 | Azure 上的程式怎麼不用密碼取得權杖 | 系統指派或使用者指派；憑證由 Azure 管理，還要另外授權 |
受控識別：兩種類型與生命週期
受控識別是 Microsoft Entra ID 裡一種特殊的服務主體，憑證由 Azure 建立、保管與輪替，而且不另外收費。程式向資源內部的身分識別端點要權杖（VM 是 Instance Metadata Service，App Service 與 Functions 由平台提供端點），再拿權杖去存取支援 Microsoft Entra 驗證的服務，例如 Key Vault、儲存體帳戶、Azure SQL、Service Bus。權杖只能在那個資源內部取得，所以不能「把受控識別帶回家」在筆電上用。
兩種類型的差別在生命週期與共用。系統指派（system-assigned）直接在某個資源上開啟，和該資源同生共死：資源刪除，身分也一起刪除，角色指派跟著失效；它只能屬於一個資源，適合單一資源的工作負載，或需要每個資源有獨立身分以便稽核的情境。使用者指派（user-assigned）是獨立的 Azure 資源，可以指派給多個資源，要自己刪除；適合多個資源共用相同權限、資源經常刪除重建但權限要維持一致，或要在資源建立前先完成授權（預先授權）的情境。同一個資源可以同時有系統指派與使用者指派身分。
受控識別、服務主體與工作負載身分同盟怎麼選
受控識別只能用在支援它的 Azure 資源上（另外，透過 Azure Arc 連線的伺服器也能使用）。在 Azure 以外執行的程式，如果平台能發出 OpenID Connect 權杖（例如 GitHub Actions、其他雲端、Kubernetes），用工作負載身分同盟（workload identity federation）：在應用程式註冊或使用者指派受控識別上設定同盟認證，讓外部權杖換成 Entra 權杖，不用保存任何密碼。做不到同盟時，才用應用程式註冊與服務主體，並優先使用憑證而不是用戶端密碼，且要自己負責到期與輪替。需要讓其他公司的租用戶同意授權的多租用戶應用程式，也是應用程式註冊的範圍。至於「人」登入，就用使用者帳戶、單一登入與條件式存取，不是受控識別的工作。
判斷步驟
- 先分人與程式：人的登入用條件式存取管情境，程式用受控識別或其他工作負載身分。
- 條件式存取題：列出這次登入符合哪些原則（指派與條件全部符合才算），有封鎖就拒絕，否則所有授與控制都要滿足；被排除的使用者不受該原則影響。
- 檢查授權：用到登入風險或使用者風險就需要 P2；沒有 P1、只要全員 MFA 就用安全性預設值。
- 受控識別題：問程式在哪裡執行、身分要不要和單一資源同生共死、需不需要共用或預先授權。
- 最後確認授權：受控識別還要用 Azure RBAC 指派角色（例如 Key Vault Secrets User），Key Vault 要使用 Azure RBAC 權限模型，範圍盡量縮到單一資源。
容易考錯的地方
條件式存取在密碼之前執行：錯，第一因素驗證完成後才評估。
多條原則取最寬鬆：錯，套用的原則全部都要滿足，封鎖優先；同一條原則內的多個授與控制，預設是「全部都要」，可改成「其中一項」。
新原則直接開啟：建議先排除緊急存取帳戶、用僅限報告模式觀察，否則可能把所有系統管理員鎖在外面。
條件式存取取代 RBAC：兩者回答不同的問題，條件式存取管登入，Azure RBAC 管資源操作。
開了受控識別就能存取：還要角色指派；用 Key Vault 存取原則模型時，角色指派不會生效。
系統指派可以共用：不行，它只屬於一個資源；要共用、預先授權或資源常重建，選使用者指派。資源刪除時，系統指派身分一起刪除，使用者指派要自己刪除。
在 Azure 外也用受控識別：GitHub Actions 等外部工作負載用工作負載身分同盟；地端伺服器加入 Azure Arc 後才能使用受控識別。
相關考試：條件式存取出現在 AZ-900（身分與安全）、SC-900、SC-300、SC-500 與 SC-100；受控識別出現在 SC-500（Entra ID 與應用程式安全）、AZ-400（身分與機密）、AI-103 與 AI-300（以受控識別與 RBAC 存取 AI 服務），工作負載身分也是 SC-300 的一個領域。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6