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.

總覽

Azure 上的金鑰管理以 Azure Key Vault 和 Azure Managed HSM 為核心。這些服務提供安全的密碼編譯材料儲存、一致的 API，以及可稽核的操作，為靜態加密、傳輸中加密及應用程式層級的密碼學奠定基礎。操作上的目標是將金鑰保管權與應用程式執行階段分離，透過限定範圍的授權和網路來最小化爆炸半徑，並強制執行可復原性和輪替，以降低長期秘密所帶來的風險。

Azure Key Vault 與 Managed HSM 架構及授權

Azure Key Vault 架構

• 服務組成：多租用戶前端、資料平面的區域性分割區、每個租用戶的隔離，以及由 Azure AD 支援的驗證。金鑰可由軟體保護 (Standard 層) 或由 HSM 保護 (Premium 層)。秘密和憑證一律由軟體保護。
• 層級：Standard (軟體金鑰) 用於一般用途和成本效益；Premium (HSM 支援的金鑰) 則在需要 FIPS 140-2 Level 2/3 等級的保護或金鑰材料需要專用 HSM 邊界時使用。若有法規遵循要求，或使用帶有 “RSA-HSM” 或 “EC-HSM” 的金鑰時，請選擇 Premium。
• 虛刪除與清除保護：虛刪除一律開啟，並可設定保留天數 (7–90 天，通常為 90 天)。清除保護啟用後，即使是高權限使用者，也無法在保留期結束前永久刪除保存庫或物件。操作上的考量：在任何支援客戶自控金鑰 (CMK) 的保存庫上啟用清除保護。若未啟用，意外或惡意的清除可能會使相依的資料 (例如，用該金鑰加密的儲存體或資料庫) 無法復原。
• 復原：可列出並復原已刪除的保存庫物件；支援保存庫層級的復原。備份會產生加密的 blob，可還原至相同 Azure 區域和雲端中的相容保存庫。考量：定期匯出金鑰備份並分開妥善保管；測試還原以驗證 RTO。

授權模型

• 權限模型：保存庫存取原則 (舊版) vs Azure RBAC (建議)。
  • 存取原則：針對每個保存庫定義；授予金鑰、秘密和憑證的細微權限。當您需要為少數主體提供非常嚴格、特定於物件類型的執行階段權限時，此為最佳選擇。
  • Azure RBAC：將保存庫的權限模型設定為「Azure 角色型存取控制」以使用 RBAC 資料平面角色。優點：可在訂用帳戶/資源群組/保存庫層級設定範圍；符合 PIM 資格的指派；集中式治理和稽核。建議用於新部署和管理操作。
• 內建保存庫角色 (範例)：Key Vault Administrator (完整管理)、Key Vault Crypto Officer (金鑰管理，但不含存取原則)、Key Vault Secrets Officer、Key Vault Certificates Officer、Key Vault Reader。操作指引：
  • 在委派存取模型和網路 ACL 的設定時，請使用 RBAC (例如 Key Vault Administrator)。
  • 在單一保存庫中，若要以最低權限插入/刪除憑證，請使用存取原則或資料平面 RBAC 角色，例如 Key Vault Certificates Officer。
• 範圍設計：建議在保存庫範圍指派 RBAC，以避免權限過大。僅在多個保存庫共用相同的操作團隊時，才使用資源群組範圍；避免為執行階段存取指派訂用帳戶範圍的權限。

Managed HSM

• 架構與安全性網域：Managed HSM 是為每個客戶提供的單一租用戶、經 FIPS 140-2 Level 3 驗證的 HSM 叢集。安全性網域保護叢集的金鑰材料可攜性；跨叢集的備份/還原需要安全性網域私密金鑰的仲裁。考量：在不同的保管人之間產生並託管網域金鑰；測試還原至 DR HSM。
• 角色模型：與 Azure RBAC 整合。角色包括 Managed HSM Administrator、Crypto Officer、Crypto User 和 Reader。職責分離：管理員管理叢集；密碼編譯管理員管理金鑰；密碼編譯使用者使用金鑰進行操作。
• 高可用性：透過多個 HSM 分割區和有 SLA 支援的服務實現區域性備援；在支援的區域中提供區域備援。對於跨區域的災難復原，則依賴備份 + 安全性網域。
• 使用案例：支付處理、程式碼簽署、用於信封加密的金鑰包裝，以及需要 Level 3 HSM 邊界的受監管工作負載。

物件與生命週期：金鑰、秘密、憑證與輪替

金鑰、秘密、憑證

• 金鑰：用於密碼學操作 (簽署、驗證、包裝/解包、加密/解密)。根據演算法強度和效能需求選擇金鑰類型/大小 (例如，為符合法規遵循選擇 RSA 3072/4096，或為求效能選擇 ECC P-256/P-384)。
• 秘密：任意的位元組/字串，例如密碼、連線字串和 API 權杖。不用於密碼學操作。
• 憑證：帶有私鑰的 X.509。同時儲存為一個憑證物件和一個對應的秘密 (PFX/PEM)。適用於 TLS/MTLS 和程式碼簽署的生命週期。

生命週期操作與輪替

• 版本控制：每次設定或匯入都會產生一個不可變的版本。應用程式應根據變更管理需求，參考有版本的秘密以獲得確定性行為，或參考無版本的 URI 以自動取得最新版本。
• 輪替策略：
  • 金鑰：對於支援無版本金鑰 URI 的 Azure 服務 (例如 Storage、SQL TDE、AKV 管理的秘密)，應優先使用。透過新增新版本來進行輪替；支援此功能的服務會自動重新綁定。如果服務需要固定版本，則需自動化一個重新設定的步驟。透過 AKV 輪替原則和警示來強制執行輪替。
  • 秘密：透過由 Event Grid 通知觸發的 Azure Automation、Functions 或 Logic Apps 進行輪替，或使用提供者原生輪替 (例如，輪替 SAS 或資料庫密碼)。盡可能用受控識別取代長期存在的靜態秘密。
  • 憑證：定義帶有「生命週期動作」的憑證原則，以在到期前自動續約；使用整合的簽發者以實現無人為介入的續約。

憑證管理

• 匯入/產生：匯入現有的 PFX/PEM (含私鑰)，或產生一個 CSR 並讓 Key Vault 透過已設定的 CA 完成簽發。
• 自動續約與簽發者：透過 Key Vault 設定如 DigiCert、GlobalSign 或企業 Microsoft CA 等簽發者。啟用自動續約，並設定通知和續約閾值。
• 應用程式整合：
  • App Service 與 Functions：使用帶有受控識別的 Key Vault 參考；平台會自動同步輪替後的秘密。
  • Application Gateway/WAF：從 Key Vault 參考憑證秘密 ID；Gateway 會自動取得新版本。
  • AKS：透過 Secrets Store CSI 驅動程式和 Azure Key Vault 提供者來掛接憑證。

用於最低權限憑證操作的 RBAC 指派範例：

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

網路安全與服務整合

Key Vault 網路

• 防火牆規則：設定為「選取的網路」以限制到經核准的來源。理由：即使有有效的權杖，也能防止來自網際網路的流量。
• 虛擬網路服務端點：允許來自特定子網路的流量，無需私有 IP。易於啟用並減少曝險。當您需要快速隔離且不需要變更 DNS 時使用。
• 私有端點：在您的 VNet 中指派一個私有 IP 給保存庫，以實現真正的私有連線。封鎖公用網路存取。理由：最強的資料外洩控制，在高信任環境和對外網際網路受限時為必要。
• 信任的服務：「允許信任的 Microsoft 服務」讓特定的 Azure 服務即使在有網路限制的情況下也能存取保存庫。在輪替期間，對於像 Storage 加密掃描金鑰這類情境是必要的。應精確地啟用並記錄相依性。

客戶管理的金鑰 (CMK) 與金鑰 URI

• 支援的服務：Azure Storage、SQL Database (TDE)、Synapse、Databricks、AKS 秘密靜態加密、App Configuration、Event Hubs、Service Bus，以及透過 Disk Encryption Set 的 Managed Disks。
• 金鑰 URI 策略：
  • 無版本 URI：當服務支援在新金鑰版本上自動重新綁定時，應優先使用；這能實現無縫輪替，無需更新服務。
  • 有版本 URI：某些服務要求使用；需將服務設定更新自動化，並與輪替事件連結。
• 輪替模式：
  • 分階段輪替：建立新的金鑰版本；驗證服務可以存取；監控錯誤；然後在一個安全期過後，可選擇性地停用舊版本。
  • 事件驅動：在「金鑰新版本」事件上使用 Event Grid 來觸發驗證或服務重新設定的工作流程。

信封加密整合

• Azure 服務在本地端使用資料加密金鑰 (DEK) (例如 AES-256)，並在 Key Vault/HSM 中使用金鑰加密金鑰 (KEK) 來包裝 DEK。在操作上，需確保 KEK 的可用性和網路存取，因為遺失或存取受阻可能導致服務運作停滯。

範例：用一個 AKV 金鑰來包裝 DEK

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

密碼學、靜態資料加密選項與機密資訊衛生

核心密碼學概念

• 對稱式加密：使用單一把金鑰進行加密/解密 (例如 AES-GCM/CTR)。速度快；適合大量資料。
• 非對稱式加密：使用公鑰/私鑰對 (RSA/ECC) 進行金鑰交換與簽章。速度較慢；適合建立信任及包裝 DEK。
• 雜湊：單向摘要 (例如 SHA-256)。用於確保完整性；非加密。
• 簽章：私鑰產生簽章；公鑰進行驗證。具備不可否認性與完整性。
• 信封加密：結合非對稱式 KEK 與對稱式 DEK，以提升效能並隔離金鑰保管權。

Azure Disk Encryption 與儲存體加密

• Managed Disks 預設加密：使用平台管理金鑰 (PMK) 的伺服器端加密 (SSE)。營運開銷極小。
• 使用 Disk Encryption Set (DES) 的 CMK：為磁碟、快照與映像檔使用參考 Key Vault 或 Managed HSM 金鑰的 DES。理由：集中化的金鑰生命週期控制與撤銷；滿足客戶控制的合規性要求。
• ADE (Azure Disk Encryption)：客體作業系統內的 BitLocker (Windows) 或 dm-crypt (Linux)。當您需要作業系統層級的加密態勢、綁定到網域的磁碟層級金鑰保護裝置，或既有的合規性強制要求時使用。營運上的權衡：複雜度較高、擴充功能管理，以及可能影響 VM 佈建。
• 雙重加密：
  • 磁碟：在基礎架構層結合使用 PMK 的 SSE，再加上透過 DES 使用的 CMK，以實現兩個獨立的加密層。
  • 儲存體帳戶：為每個容器/工作負載使用帶有獨立 CMK 的加密範圍；在可用時結合基礎架構加密以達到雙層加密。
• 加密範圍 (Azure Storage)：為每個容器或每個 blob 定義具有不同 CMK 的範圍，以隔離租用戶/工作負載的風險，並能在不造成廣泛影響的情況下進行目標性輪替。

機密資訊衛生與營運實務

• 受控識別：為 Azure 資源使用系統指派或使用者指派的受控識別，以取得用於 Key Vault 和其他服務的權杖，從而消除內嵌的認證。將 RBAC 或存取原則的範圍縮到最小。
• 機密掃描：啟用 Microsoft Defender for DevOps、GitHub Advanced Security 的機密掃描功能與儲存庫保護。與 pull request 整合以阻擋已知的認證模式。
• 管線與 IaC：在 Azure Pipelines 中使用 Key Vault 工作整合，並在 GitHub Actions 中使用基於 OIDC 的聯合認證，以避免保存機密資訊。不要在日誌中印出機密；遮罩輸出內容。立即輪替任何外洩的資料。
• 應用程式設計：在安全的情況下，優先使用無版本參考；盡可能減少快取，並透過重新取得權杖和重新擷取機密來處理 401/403 錯誤，以支援金鑰輪替事件。

← 資料、儲存與資料庫安全 · 所有領域 · 安全態勢管理與治理 →

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

瀏覽 Microsoft →