Microsoft AZ-204: Azure 驗證、授權和安全性 — 學習指南

By Laurynas Brazys · 6 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

總覽

Azure 的驗證與授權以 Microsoft 身分識別平台為核心，此平台會發行權杖給身分識別 (使用者、應用程式、工作負載)，並對 API 和資源的存取強制執行控管。應用程式透過 OAuth 2.0 和 OpenID Connect 進行整合，使用 MSAL 取得權杖，並請求在 Azure AD 應用程式註冊中所宣告的權限。在 Azure 上執行的工作負載可以使用受控識別來完全免除認證，並依靠 Azure RBAC 來存取 Key Vault、Storage 和 Microsoft Graph 等服務。祕密管理以 Azure Key Vault 為中心，明確區分了保存庫的資料平面存取與管理平面控制，並透過虛刪除和清除保護提供了強大的復原保證。對於儲存體，共用存取簽章 (SAS) 提供了限定範圍、有時間限制的委派存取權給用戶端，而無需暴露帳戶金鑰。

Microsoft 身分識別平台、OAuth 2.0、MSAL 與應用程式註冊

Microsoft 身分識別平台支援多種針對不同應用程式類型最佳化的 OAuth 2.0 流程：

• 授權碼流程：Web 應用程式、SPA 和原生應用程式的標準流程。公用用戶端必須使用 PKCE 來保護授權碼。應用程式將使用者重新導向至授權端點，在重新導向 URI 上接收授權碼，然後在權杖端點將其兌換為存取權杖 (以及可選的重新整理權杖)。對於 SPA，授權碼 + PKCE 取代了舊版的隱含流程，並減輕了權杖洩漏的風險。
• 用戶端認證流程：由沒有使用者的精靈程式和伺服器對伺服器服務使用。應用程式使用用戶端判斷提示 (憑證) 或用戶端祕密來請求權杖。此流程中僅能使用應用程式權限 (應用程式角色)，且其中大部分需要管理員同意。此流程使用 /.default 範圍來請求一組靜態設定的應用程式權限。
• 裝置碼流程：專為沒有內嵌瀏覽器的裝置或環境而設計。應用程式從身分識別平台取得使用者碼和驗證 URL，使用者在另一台裝置上進行驗證，然後應用程式輪詢權杖端點。因為有使用者登入，所以適用委派權限。
• 隱含授與流程：過去 SPA 用來直接從授權端點接收權杖。現在不建議使用，建議改用搭配 PKCE 的授權碼流程。如果仍要使用，在應用程式註冊期間仍然需要設定重新導向 URI。

MSAL (Microsoft 驗證程式庫) 提供了跨語言和平台的一致性權杖取得方式。公用用戶端應用程式 (桌面、行動、SPA) 使用 AcquireTokenInteractive 和 AcquireTokenSilent 來取得並快取權杖；原生應用程式也會在裝置碼流程中使用 AcquireTokenByDeviceCode，以及在機密用戶端情境中用 AcquireTokenByAuthorizationCode 來兌換授權碼。機密用戶端 (Web 應用程式/API/精靈程式) 在使用用戶端認證時，會用 AcquireTokenForClient 取得權杖；在 API 需要以使用者的委派內容呼叫下游 API 的 OBO (On-Behalf-Of) 情境中，則使用 AcquireTokenOnBehalfOf。

權杖快取是 MSAL 的一個重要部分：它儲存以帳戶、用戶端和範圍為索引鍵的存取權杖和重新整理權杖，讓 AcquireTokenSilent 能夠避免不必要的互動式提示。在多個執行個體上運行的 Web 應用程式和 API 必須使用共用、加密的儲存區 (例如，具備適當靜態加密與傳輸中加密的分散式快取) 來保存並保護權杖快取。MSAL 中的快取序列化掛鉤能夠實現安全地保存。範圍 (Scopes) 用於識別應用程式正在請求的權限。對於委派權限，應請求最小權限、針對特定資源的範圍 (例如 https://graph.microsoft.com/User.Read)。對於用戶端認證，應請求以資源為基礎的 /.default，它會對應到靜態授與給應用程式的應用程式權限 (例如 scope = https://graph.microsoft.com/.default)。使用增量同意來逐步請求範圍，以減少使用者操作上的阻力。

Azure AD 應用程式註冊定義了應用程式的身分識別、認證、重新導向 URI 和權限。委派權限需要有已登入的使用者，且通常可由使用者自行同意存取其個人資料；應用程式權限則是授與給應用程式本身，且幾乎總是需要管理員同意，因為它們的影響範圍是整個租用戶或更廣泛。公開 API 的應用程式會在「公開 API」區塊下宣告範圍 (用於委派權限) 和應用程式角色 (用於應用程式權限)。根據信任邊界設定單一租用戶或多租用戶存取，並使用憑證而非用戶端祕密，以獲得更強的認證且更容易輪替。

Microsoft Graph 使用相同的權杖發行機制。使用 MSAL 進行驗證時，應以 Graph 資源為目標，並請求最小權限範圍。常用的端點包括：

• GET https://graph.microsoft.com/v1.0/me 用於以委派權杖 (例如 User.Read) 取得使用者設定檔
• GET https://graph.microsoft.com/v1.0/users 和 /groups 用於取得目錄物件 (需要適當的委派或應用程式權限，例如 User.Read.All 或 Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites 或 /drives 用於 SharePoint/OneDrive 操作 使用用戶端認證時，請求 /.default 範圍，並確保所需的應用程式權限已有管理員同意。選擇正確的授權單位 (特定租用戶 vs. common/organizations) 來控制使用者可以在何處登入以及權杖可以在何處被鑄造 (minted)。

受控識別體與 Azure 資源的安全存取，以及 Key Vault 參考

Azure 資源的受控識別體 (Managed identities) 讓 Azure 管理服務主體 (service principal) 的憑證，從而免除密鑰 (secrets) 的使用。系統指派的受控識別體 (System-assigned managed identities) 與資源 (如 App Service、Function App、VM、VMSS、Logic App 等) 是一對一綁定，並共享其生命週期；當資源被刪除時，該識別體也會一併被刪除。使用者指派的受控識別體 (User-assigned managed identities) 則是作為獨立的 Azure 資源建立，可以附加到多個運算資源上，其生命週期獨立於任何單一工作負載。此模型支援身分識別的重複使用和職責分離。

若要使用受控識別體存取 Azure 資源，請在正確的範圍 (scope) 內授予其適當的 Azure RBAC 角色：

• 對於使用 Azure AD 的 Azure Storage 資料平面 (data plane)，請在儲存體帳戶、容器或 RG/訂用帳戶範圍內指派如 Storage Blob Data Reader/Contributor 等角色。
• 對於 Key Vault (RBAC 資料平面模型)，請指派如 Key Vault Secrets User 或 Key Vault Crypto Officer 等角色。
• 對於透過應用程式權限存取 Microsoft Graph，受控識別體只有在關聯了應用程式註冊 (app registration) 後才能呼叫下游 API。請使用工作負載身分識別同盟 (workload identity federation) 或視需要設定企業應用程式權限和管理員同意 (admin consent)。

在執行階段 (runtime)，可使用 VM 上的 Instance Metadata Service (IMDS) 或 App Service 管理的端點來取得權杖 (token)；像 Azure Identity 的 DefaultAzureCredential 這類 SDK 在偵測到受控識別體端點可用時，會自動使用它。這移除了儲存密鑰的需求，並支援由平台進行輪替。

App Service 和 Azure Functions 中的 Key Vault 參考 (references) 允許在不變更程式碼的情況下，將密鑰安全地擷取到應用程式設定中。在應用程式設定值中，使用參考語法 @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version})。平台會在應用程式啟動時使用其受控識別體來解析此參考，並定期重新整理。請確保該受控識別體透過 Key Vault 存取原則 (access policies) 擁有對密鑰的 Get 權限，或者在使用 RBAC 資料平面模型時，擁有 Key Vault Secrets User 角色。Key Vault 參考非常適合用於那些絕不應以純文字形式儲存在應用程式設定儲存區中的組態值，並且能將處理密鑰的邏輯從應用程式程式碼中移除。

Azure Key Vault：密鑰、金鑰、憑證與存取控制

Azure Key Vault 儲存三種物件類型：

• 密鑰 (Secrets)：不透明的字串，例如密碼、連接字串或 API 金鑰。具備版本控制；用戶端通常執行 Get 和 Set 操作。
• 金鑰 (Keys)：用於簽署/驗證 (sign/verify)、加密/解密 (encrypt/decrypt) 和包裝/解包 (wrap/unwrap) 操作的密碼編譯金鑰 (RSA、EC)。金鑰材料受到 HSM 支援的服務保護；用戶端是透過該服務呼叫密碼編譯操作，而不是匯出私鑰材料。
• 憑證 (Certificates)：具備生命週期管理的 X.509 物件，可選擇性地與合作夥伴 CA 整合。憑證會具現化為一個憑證加上一個對應的密鑰 (PFX)，並可選擇性地搭配一個受控金鑰。

預設情況下，虛刪除 (Soft delete) 是開啟的，它會在一個保留期間內保存被刪除的物件。啟用清除保護 (purge protection) 可以防止在保留期間內進行不可逆的刪除，並強制執行復原保證 (通常是 90 天的保留要求)。結合虛刪除和清除保護，以符合嚴格的復原策略。此外，應使用私有端點 (private endpoints) 來保護保存庫的網路存取，並在可能的情況下停用公用網路存取。

存取控制可以使用舊版的保存庫存取原則 (vault access policies) 或用於資料平面的 Azure RBAC。存取原則是針對每個保存庫進行設定，並明確地將權限 (Get、List、Set、Sign、Wrap) 授予主體 (principals)；這些原則不會被繼承，且在大規模部署時，操作上可能變得繁重。RBAC 資料平面模型使用 Azure 角色 (例如 Key Vault Administrator、Key Vault Secrets Officer、Key Vault Secrets User、Key Vault Crypto Officer)，並支援在訂用帳戶、資源群組或保存庫層級設定範圍，其稽核功能也與 Azure RBAC 整合。請選擇一種模型；如果為資料平面啟用了 RBAC，存取原則將被忽略。管理平面 (Management-plane) 的操作 (建立/更新保存庫) 始終使用 Azure RBAC。

使用 Azure SDK (例如 SecretClient、KeyClient、CertificateClient) 和 DefaultAzureCredential 將 Key Vault 與應用程式整合。進行身份驗證時，應優先使用受控識別體，避免嵌入憑證，並在呼叫 Vault API 時實作重試 (retry) 和節流 (throttling) 策略。

Azure Storage SAS 與預存存取原則

共用存取簽章 (Shared Access Signatures) 可在不洩露帳戶金鑰的情況下，將 Azure Storage 的細微、有時間限制的存取權限委派出去：

• 使用者委派 SAS (僅限 Blob)：由 Azure AD 支援。應用程式使用 Azure AD 憑證從 Blob 服務取得使用者委派金鑰，然後為用戶端建立 SAS 權杖。這是以使用者為中心情境中最安全的方法，因為它避免使用帳戶金鑰，並與角色型授權保持一致。
• 服務 SAS：範圍限定於特定資源 (blob、容器、佇列訊息、表格實體、檔案)。使用帳戶金鑰簽署。根據服務的不同，支援讀取、寫入、新增、建立、刪除、列出、設定不變性及標籤等權限。
• 帳戶 SAS：範圍最廣，可涵蓋多個服務 (Blob、Queue、Table、File) 和資源類型。由於其影響範圍廣泛，應謹慎使用。

SAS 權杖包含多種限制條件，例如到期時間 (se)、開始時間 (st)、權限 (sp)、IP 範圍 (sip)、允許的通訊協定 (spr)、已簽署的資源 (sr)，以及當綁定到預存存取原則時的已簽署識別碼 (si)。請遵循最低權限原則，僅授予必要的權限、保持較短的到期時間，並強制使用 HTTPS (spr=https)。盡可能優先選用使用者委派 SAS；否則，請使用帶有預存存取原則的服務 SAS，以便於撤銷。

預存存取原則存在於容器、檔案共用、佇列或表格上，並定義了一組可重複使用的限制條件 (權限、開始時間、到期時間)。在建立 SAS 時，可透過其識別碼來參考該原則。這樣就可以集中撤銷或收緊範圍，而無需重新發行所有 SAS 權杖；更新或刪除原則會立即影響所有與其連結的 SAS 權杖。如果使用服務或帳戶 SAS，請定期輪替帳戶金鑰，並透過診斷設定和 Azure Monitor 記錄來監控使用情況。

實際問題情境

Adobe 正在 Azure 上推出一個多租用戶的媒體處理入口網站。客戶使用自己的 Microsoft Entra ID 租用戶登入，將大型媒體檔案直接上傳到 Blob 儲存體，並追蹤處理狀態。此解決方案必須避免儲存祕密、集中管理權限，並確保祕密的可復原性至少達 90 天。

1. 在 Microsoft Entra ID 中註冊應用程式：

   • 為入口網站 UI 建立一個單頁應用程式 (SPA)，並為後端 API 建立一個機密用戶端。為委派存取公開 API 範圍，並為背景作業定義應用程式角色。設定 SPA 使用 authorization code + PKCE 流程與精確的重新導向 URI。這能讓每個用戶端與正確的 OAuth 流程對齊，並強制執行最低權限的同意邊界。

2. 在 SPA 和後端實作 MSAL：

   • SPA 使用 AcquireTokenInteractive/AcquireTokenSilent 搭配增量同意 (incremental consent) 來為後端 API 取得權杖。後端則使用 AcquireTokenOnBehalfOf 來呼叫 Microsoft Graph，以讀取已登入使用者的基本個人資料。這能端對端地保留使用者情境，並透過權杖快取將提示次數降到最低。

3. 在 App Service (API) 和 Azure Functions (媒體處理器) 上啟用系統指派的受控識別：

   • 在媒體容器上指派 Storage Blob Data Contributor 角色，並在金鑰保存庫上指派 Key Vault Secrets User 角色。受控識別消除了祕密擴散的問題，並允許平台自動輪替憑證，同時透過 Azure RBAC 實現對 Storage 和 Key Vault 的安全存取。

4. 設定 Azure Key Vault 使用 RBAC 資料平面、虛刪除和清除保護：

   • 儲存用於後端判斷提示 (assertion) 的簽署憑證、第三方 API 金鑰，以及任何無法用 AAD 取代的連線祕密。強制執行清除保護加上虛刪除，以保證 90 天內的可復原性。與每個保存庫的存取原則相比，RBAC 簡化了稽核工作，並能跨環境擴展。

5. 使用 Key Vault 參考進行組態設定：

   • 在 App Service 和 Functions 的應用程式設定中使用 @Microsoft.KeyVault(SecretUri=…) 來參考祕密。平台會使用受控識別來解析和重新整理這些值，從而無需修改程式碼，並防止祕密以純文字形式儲存在組態中。

6. 使用 SAS 委派直接從瀏覽器上傳：

   • 後端發行使用者委派 SAS 權杖，提供對特定 blob 路徑的短期、僅限寫入的存取權限，並透過 IP 和 HTTPS 限制範圍。對於營運用的批次處理工具，則建立與容器上預存存取原則綁定的服務 SAS，如此一來便可透過更新或刪除該原則來集中撤銷權杖。這使得高吞吐量的用戶端上傳成為可能，而無需暴露帳戶金鑰，並支援緊急撤銷。

7. 以最低權限整合 Microsoft Graph：

   • 在 SPA 中請求 https://graph.microsoft.com/User.Read 以顯示個人資料，若需要任何應用程式權限 (需經管理員事先同意)，則在後端使用 https://graph.microsoft.com/.default。使用 /.default 可確保後端遵循集中授予的應用程式權限，並避免在執行階段請求過多範圍。

此設計使用 authorization code + PKCE 來保護 SPA，使用 OBO 來保留下游的使用者情境，使用受控識別和 RBAC 來消除祕密，使用具備強大復原保證的 Key Vault，使用 Key Vault 參考來維持組態的整潔性，使用最低權限範圍的 Graph，並使用帶有預存存取原則的 SAS 來實現安全、可撤銷的用戶端上傳。

← Azure 容器解決方案 · 所有領域 · Azure API Management →

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

瀏覽 Microsoft →