Microsoft AZ-500: 身分與存取管理 — 學習指南

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

屬於 Microsoft Azure Security Engineer Associate AZ-500 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Microsoft Azure 中的身分識別與存取管理 (IAM) 以 Microsoft Entra ID (前身為 Azure AD) 為核心。它控管了誰可以在何種條件下，以何種權限存取哪些資源。有效的 IAM 架構能將常駐權限降至最低、強制執行條件式與風險式存取，並為人員與工作負載採用現代化驗證，同時支援混合式與外部協作情境。

Microsoft Entra 身分識別建構與範圍

租用戶、使用者與群組
- 租用戶代表您組織的身分識別邊界與信任結構。使用者可以是成員或來賓 (B2B) 帳戶。使用安全性群組進行授權，並使用 Microsoft 365 群組來實現協作功能；建議優先使用動態群組以減少手動管理成員的工作。
管理單位 (AU)
- AU 可讓您將目錄角色委派給一部分的使用者/裝置 (例如，區域服務台只能管理歐洲的使用者)。這有助於實現目錄任務的最低權限原則。
目錄角色與角色指派範圍
- 目錄角色 (例如 Global Administrator、User Administrator) 適用於 Microsoft Entra 資源。盡可能將目錄角色的範圍限定在 AU 層級，以限制衝擊範圍。初次設定 Privileged Identity Management (PIM) 時，需要 Global Administrator 角色。
Azure 角色型存取控制 (Azure RBAC) 範圍
- Azure RBAC 控管對 Azure 資源的存取。在管理群組、訂用帳戶、資源群組或資源層級的範圍指派角色。繼承是向下流動的；務必選擇實際可行的最窄範圍，以減少過度授權。
維運考量
- 將目錄角色 (Entra) 與 Azure RBAC (資源授權) 分開。使用 AU 和嚴格的 RBAC 範圍來限制管理權限的觸及範圍、減少橫向移動的機會，並簡化存取權檢閱。

使用 Azure RBAC 與最低權限進行存取控制

內建角色與最低權限
- 優先選擇最符合任務需求的特定內建角色。例如：使用 AcrPull 授予容器映像的唯讀拉取權限，使用 AcrPush 授予上傳/推送權限，而不是授予寬泛的 Contributor 角色。對於 Key Vault，僅透過 RBAC 將管理控制權授予保存庫管理員，同時針對特定物件操作 (如憑證管理) 使用細微的存取原則。
角色指派的繼承
- 在最低的可能範圍進行指派。管理群組或訂用帳戶層級的指派會向下層疊；除非刻意為之，否則應避免寬泛的繼承權限。當您需要在多個訂用帳戶間維持一致的 RBAC 時，應透過 Azure Blueprints (或現代的 IaC 替代方案) 來套用一致的角色指派，而非手動進行 PIM 指派。
拒絕指派
- 拒絕指派會明確地阻擋某些動作，無論是否有允許的指派，且通常由 Azure Policy 或 Blueprints 等 Azure 服務建立。使用它們來強制執行不可協商的護欄 (例如，防止在敏感資源上設定公用網路規則)。
自訂角色
- 當內建角色權限過於寬泛時，請定義僅包含必要動作的自訂角色。透過最低權限測試和存取權檢閱來進行驗證。

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

維運考量
- RBAC 範圍界定與自訂角色可減少過多的授權和稽核的攻擊面。拒絕指派將「硬性」的合規性限制寫入規則，這些限制不會因錯誤授予的寬泛「允許」權限而被繞過，從而提升安全態勢的韌性。

特權存取、條件式存取與 Identity Protection

Privileged Identity Management (PIM)
- 合格 vs. 作用中：合格的指派不會授予常駐權限；使用者必須透過 JIT 啟用才能成為作用中狀態。在啟用時強制要求核准、理由說明與 MFA；設定有限的持續時間並要求提供工單編號以供追溯。首先應探索特權角色，以了解當前的曝險情況。使用定期的存取權檢閱來驗證權限的持續需求，理想情況下由資源或群組擁有者擔任檢閱者。
條件式存取 (CA)
- 指派的目標為使用者/群組、工作負載身分識別、雲端應用程式與動作。條件包括登入風險、裝置平台/狀態、位置、用戶端應用程式，以及針對裝置和應用程式的篩選器。授權控制項可以要求 MFA、符合規範或混合式 Azure AD 加入的裝置、應用程式保護原則或使用規定。工作階段控制可限制登入頻率、持續性工作階段，以及由應用程式強制執行的限制 (例如，SharePoint 僅限網頁存取)。在強制執行前，使用僅限報告模式來安全地驗證原則的影響。為緊急存取帳戶和分階段推出維護排除項目，以防止帳戶被鎖定。
Identity Protection
- 使用者風險反映帳戶遭入侵的可能性；登入風險則反映特定工作階段具備風險的可能性。設定原則以要求安全地修復：
  - 具有外洩認證的使用者：視為高使用者風險；強制重設密碼並封鎖直到修復完成。
  - 來自具可疑活動 IP 的登入：至少視為中度登入風險；使用 MFA 進行挑戰，或針對敏感應用程式予以封鎖。
- 與 CA 整合以即時調整信任級別。追蹤風險歷史記錄與修復措施以衡量成效。
維運考量
- PIM 消除了常駐權限，並強制執行強健且可稽核的啟用流程。CA 與 Identity Protection 應用了零信任原則——根據使用者、裝置、工作階段與風險來驗證每一次的存取嘗試——從而減少認證竊取與權杖重送攻擊的成功率。

混合式與工作負載身分識別

混合式身分識別選項
- Password hash synchronization (PHS)：將密碼雜湊同步至 Entra ID。簡單且具備彈性；但在驗證當下不會強制執行地端的登入原則。
- Pass-through authentication (PTA)：透過輕量級連接器，對照地端 DC 來驗證密碼；即時強制執行地端的密碼原則與帳戶限制，且無需 AD FS。
- 同盟 (例如 AD FS)：將驗證轉移至地端的 STS。僅在需要複雜宣告或處理舊版情境時使用；它會導入更多伺服器與維運開銷。
- Seamless single sign-on (Seamless SSO)：讓使用者在公司網路內已加入網域的裝置上登入時，只需最少的提示。
- 維運上的選擇：若要強制執行地端密碼原則與帳戶限制，同時又要最少化伺服器數量，應部署 PTA 與 Seamless SSO，並同時啟用 PHS 以作為非 PTA 相依情境的備援/容錯移轉。單獨使用同盟會增加複雜性，且不符合「最少化伺服器」的目標。
從混合式加入的 Windows 裝置對 Azure SQL 進行應用程式驗證
- 使用 Active Directory 整合式驗證以最少化提示，並在適用情況下利用 Kerberos/SSO。
受控識別與服務主體
- 受控識別 (系統指派或使用者指派) 是 Azure 託管工作負載的首選，因為它們能免除密碼，並自動輪替認證。應在資源範圍內將最低權限的 RBAC 指派給該身分識別。
- 服務主體支援著應用程式註冊；應優先使用憑證認證而非用戶端密碼，並設定最短的可行生命週期。
工作負載身分識別同盟
- 使用 OIDC 同盟，讓外部工作負載身分識別 (例如 GitHub Actions、Kubernetes) 無需儲存密碼即可為 Entra 應用程式取得權杖。精確定義 issuer、subject 與 audience 宣告，以限制誰可以交換權杖。

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

AKS 對 ACR 的存取
- 使用 attach-acr 流程，將目標登錄庫的 AcrPull 權限授予 AKS 叢集的受控識別，此流程會自動化正確的範圍設定並避免錯誤指派。

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

維運考量
- PTA+PHS+Seamless SSO 能強制執行即時的地端控制，同時維持雲端的彈性。受控識別與同盟則能從管線與執行階段中移除靜態密碼，從而封鎖高頻率的認證竊取途徑。

外部協作、驗證方法與應用程式存取

外部身分與 B2B 協作
- 使用 B2B 來賓帳戶，搭配跨租用戶存取設定、使用規定，以及針對來賓的 CA。限制可邀請的人員，並透過權利管理優先採用 JIT (Just-In-Time) 存取。
權利管理與存取套件
- 將群組、應用程式和 SharePoint 網站綑綁成存取套件，並透過原則定義誰可以請求（包含外部使用者）、核准流程、指派期間與存取審核。在選擇審核者時，使用「群組擁有者」(Group Owners) 以將業務責任歸屬給資源保管人。
驗證方法與無密碼
- 標準化採用強式方法：FIDO2 安全性金鑰、商務用 Windows Hello，以及 Microsoft Authenticator 手機登入。使用合併式安全性資訊註冊 (SSPR + MFA) 並對所有使用者強制執行 MFA 註冊原則。若有需要，啟用具備內部部署回寫功能的 SSPR；要求使用安全的方法，並盡可能將要素限制在企業管理的範圍內。停用舊版/基本驗證通訊協定，並在風險允許的情況下，封鎖僅限 SMS 的弱式 MFA。
Microsoft Entra 應用程式 Proxy
- 發佈內部部署的 Web 應用程式，無需開啟輸入防火牆。使用連接器群組以達成 HA、透過 Entra ID 進行預先驗證，並疊加 CA、裝置合規性與 Identity Protection，以在舊版應用程式上實現零信任。
應用程式註冊安全性
- 要求管理員同意工作流程；限制可建立應用程式的人員；將權限分類；僅在不需要使用者情境時才優先使用應用程式權限，並將 API 範圍縮至最小。盡可能停用隱含授與，要求對企業應用程式進行指派，並優先使用憑證而非祕密，且採自動輪替。

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

操作上的考量
- 存取套件與應用程式 Proxy 提供受監管、可稽核的外部存取。強式、無密碼的方法可提升抗釣魚能力。嚴格的應用程式註冊控制可防止過度廣泛的同意，並降低應用程式模擬的機會。

實務問題情境

Adobe Inc. 需要授予第三方廠商對一部分 Azure 資源的臨時管理存取權限，並向該廠商發佈一個內部舊版 Web 應用程式，同時強制執行強式驗證與零常設權限。

界定與模型化存取範圍

建立一個資源群組 rg-vendor-ops，並僅將所需資源移入其中。指派最低限度的 Azure RBAC 角色（例如：rg-vendor-ops 上的 Contributor；診斷資源群組上的 Reader）。
理由：狹窄的範圍界定可防止橫向移動。角色繼承被限制在 rg-vendor-ops 內，從而控制爆炸半徑。

使用 PIM 監管身分與啟用

讓廠商管理員對所需角色具備「符合資格」(eligible) 而非「永久性」(permanent) 的權限；要求核准、票證 ID、啟用時進行 MFA，並將啟用時間限制為 4 小時。首先執行 PIM 的「探索特殊權限角色」(Discover privileged roles) 功能，為現有指派建立基準。
理由：符合資格的指派移除了常設權限。核准與 MFA 強制執行了與支援時間範圍一致的 JIT 存取，並提供可稽核的控制。

強制執行條件式存取與風險原則

建立一個 CA 原則，目標鎖定廠商群組以及 Azure 入口網站與 ARM API，要求 MFA、合規/混合式加入的裝置，並封鎖來自有風險位置的存取。先啟用「僅限報告」(report-only) 模式，然後再強制執行。設定 Identity Protection：封鎖「高」使用者風險（外洩的認證）直到密碼重設為止；對「中」登入風險（可疑的 IP）要求 MFA。
理由：CA 將存取權限與裝置信任度和即時風險綁定。僅限報告模式可防止在推行期間發生服務中斷。風險原則會自動修復受損的會話與帳戶。

使用 Microsoft Entra 應用程式 Proxy 發佈舊版應用程式

在不同的、暴露給廠商的子網路中部署兩個連接器以達成 HA。設定使用 Entra ID 進行預先驗證，要求指派給企業應用程式，並套用相同的 CA 原則。使用存取套件授予廠商使用者對企業應用程式和 RG 角色的有時限存取權；將「群組擁有者」(Group Owners) 設定為審核者。
理由：應用程式 Proxy 消除了輸入暴露並集中化驗證。權利管理將上線/離線流程標準化，並確保由資源擁有者進行定期審核。

保護工作負載與應用程式認證

將服務主體的任何用戶端祕密替換為憑證認證；對於 CI/CD，使用 workload identity federation 而非儲存祕密。對於需要映像檔的 AKS 工作負載，將 ACR 附加到叢集，以授予受控識別 AcrPull 權限。
理由：移除靜態祕密可關閉一個常見的入侵途徑；聯盟與受控識別提供了最低權限、自動輪替的存取。

保護緊急存取帳戶並進行監控

將兩個緊急存取帳戶從 CA 中排除，但使用儲存在離線環境的長亂數密碼來保護它們。每季啟用存取審核，並將 PIM 與 CA 的日誌匯出到一個 Log Analytics 工作區，並針對異常啟用設定警示。
理由：緊急存取帳戶可防止租用戶被鎖定，同時在操作上是安全的。持續監控能快速偵測濫用行為，維持合規性與事件應變整備度。

所有領域 · 網路安全架構 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →