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 Storage、Azure SQL 與 Azure Cosmos DB，選擇正確的身分識別與金鑰策略，並防止資料外洩。此處描述的每項控制措施都附有其操作上的理由，以便您能為生產環境中的設定提供正當性並加以維護。

保護 Azure 儲存體帳戶與資料存取

儲存體帳戶的授權與共用

• 適用於 Azure Storage 的 Azure RBAC：偏好使用基於 Azure AD 的授權 (Blob 和 Queue)，透過內建角色如 Storage Blob Data Reader/Contributor 進行。理由：透過條件式存取 (Conditional Access) 實現基於權杖、有時間限制的存取，並記錄於 Entra ID；避免使用永久性的帳戶金鑰，並支援即時 (just-in-time) 指派。
• 共用金鑰：帳戶的主要/次要金鑰授予完整的資料平面權限。應在程式碼中停用金鑰，並經常輪替。理由：共用金鑰是持有人秘密 (bearer secrets)，沒有使用者綁定或條件式存取；一旦外洩，等於資料完全暴露。
• SAS 類型：
  • 服務 SAS：授予對特定資源 (blob、file、queue、table) 的範圍限定存取權，並可設定權限、IP、通訊協定與時間限制。理由：為無法使用 AD 權杖的應用程式提供精確的最低權限。
  • 帳戶 SAS：影響範圍較廣 (例如，跨多個服務)；應謹慎使用。理由：若外洩會擴大爆炸半徑 (blast radius)。
  • 使用者委派 SAS：使用 Azure AD 與使用者委派金鑰為 Blob 發行。理由：綁定至 Azure AD 身分識別與條件式存取；提供更優越的可稽核性與撤銷能力。
• 預存存取原則：為容器/共用上的 SAS 定義可重複使用的限制 (到期日、權限)；撤銷或更新原則會使其下發行的 SAS 失效。理由：無需重新產生嵌入在用戶端中的權杖，即可集中撤銷。

範例：使用 Azure AD 為 blob 產生使用者委派 SAS

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

依類型的服務安全性

• Blob/Queue/Table：在支援的情況下 (Blob、Queue) 使用 Azure AD RBAC。將 AllowBlobPublicAccess 設為 false，要求使用 HTTPS，並啟用版本設定與虛刪除。理由：移除匿名的暴露路徑並實現可恢復性。
• Azure Files：透過 Entra ID (或 AD DS 整合) 為 SMB 使用 Azure AD Kerberos，並強制執行最低權限的共用/檔案權限。要求 SMB 加密。理由：透過 SMB 實現具傳輸安全性的身分識別綁定存取；使用者空間中沒有共用金鑰。
• Table service：使用具有嚴格 IP/時間限制的 SAS，並避免使用帳戶 SAS。理由：服務層級的粒度不夠豐富；應積極地限縮範圍。

所有儲存體服務的網路隔離

• 儲存體防火牆規則：僅在 Private Link 不可行時，才限制為選定的公用 IP 範圍。理由：可減少攻擊面，但流量仍會經過公用網際網路。
• 私人端點：對於 Blob、Queue、Table 與 Files，偏好使用 Private Link。將私人 DNS 區域對應到資源特定的名稱。將公用網路存取設為「已停用」。理由：流量會保留在 Azure 骨幹網路上；資源身分識別會透過私人 DNS 進行驗證；可減輕資料外洩至相似服務的風險。
• 服務端點與原則：若無法使用 Private Link，請啟用服務端點並套用服務端點原則，將出口 (egress) 流量限制到特定的儲存體帳戶。理由：即使流量是透過虛擬網路出口，也能加以限制；可限制將資料傳送到攻擊者所擁有帳戶的風險。

標準化的操作設定

• 強制僅使用 HTTPS，最低 TLS 1.2。
• 若使用 AD，則停用 Blob 與 Queue 的共用金鑰存取 (視功能支援情況而定)。
• 在關鍵的容器/共用上設定不可變原則，以符合法規保留要求並具備勒索軟體恢復力。

加密與金鑰管理

靜態加密層

• 服務管理的金鑰 (SMK)：由 Azure 管理的預設伺服器端加密。理由：零操作開銷；適用於許多工作負載。
• 客戶管理的金鑰 (CMK)：將用於 Storage、SQL 與 Cosmos DB 的金鑰存放在 Key Vault 或 Managed HSM 中。理由：外部化的信任邊界、客戶對輪替/撤銷的控制權，以及提供合規性證據。
• 基礎結構加密 (雙重加密)：使用獨立金鑰的額外加密層。理由：提供深度防禦，以防儲存媒體加密被繞過或加密邊界被攻破。

金鑰輪替與操作

• SMK 會自動輪替；無需任何操作。
• CMK 的輪替方式是建立新的金鑰版本，授予 wrap/unwrap 權限，然後將資源重新指向最新版本 (或在支援時使用無版本金鑰參考)。理由：這是一種具可稽核變更的非中斷式輪替。
• 使用 Key Vault 的虛刪除與清除保護來保護金鑰；透過 RBAC 控制管理員，並透過存取原則或 RBAC (對於 Managed HSM，使用 RBAC) 控制資料平面。理由：防止破壞性的金鑰遺失並強制執行最低權限。

範例：為儲存體帳戶設定 CMK

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

加密範圍

• 當不同的資料集需要不同的金鑰時，在 Storage 中使用每個容器的加密範圍。理由：可分割爆炸半徑，並實現差異化的金鑰生命週期。

資料庫平台安全性：Azure SQL 與 Azure Cosmos DB

Azure SQL 驗證與存取

• Microsoft Entra 驗證：建立一個伺服器層級的 Azure AD 管理員；使用自主資料庫使用者 (CREATE USER FROM EXTERNAL PROVIDER)。理由：避免使用 SQL 登入/密碼，並啟用條件式存取與 PIM。
• 自主使用者：身分識別存在於資料庫中，而非 master 資料庫。理由：簡化異地還原與容錯移轉，無需重新佈建登入。
• 防火牆規則：避免寬鬆的用戶端 IP 規則；建議使用 Private Link 並停用公用網路存取。若必須使用 IP 規則，應將範圍限定於確切的位址並自動化審查。理由：縮小攻擊面並減少透過公用端點被發現的機會。
• 私人端點：透過 VNet 與私人 DNS 路由所有資料平面流量。理由：消除曝險並簡化資料外洩防護。
• 驗證模式：使用 Active Directory 整合式 (適用於已加入網域的裝置) 或互動式/裝置程式碼來取得權杖；服務工作負載應使用受控識別。理由：移除密碼並啟用權杖生命週期/原則。

資料保護功能

• 透明資料加密 (Transparent Data Encryption, TDE)：預設開啟；加密資料/日誌/備份。理由：保護靜態媒體，無需變更應用程式。搭配 CMK 使用 TDE 以實現外部化控制。
• Always Encrypted：針對敏感欄位的用戶端加密，金鑰存放在 Key Vault 中。理由：防止 SQL 操作員或引擎看到明文；用於 PII/PCI 欄位。
• 動態資料遮罩 (Dynamic Data Masking, DDM)：為非特權使用者模糊化查詢結果。理由：減少非正式的資料曝險，但並非安全邊界；應與 RBAC 結合使用。
• 稽核：傳送到 Log Analytics、Event Hubs 或 Storage。理由：為調查與合規性建立不可變的軌跡。

範例：啟用伺服器層級稽核至 Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• 弱點評估 (Vulnerability Assessment, VA)：建立基準並掃描結構描述/組態；匯出至儲存體；與 DevSecOps 閘道整合。理由：持續的健康狀態與漂移偵測，並提供清晰的修復指引。
• 威脅偵測：偵測 SQL 隱碼攻擊、異常登入、從不熟悉的地點登入、濫用權限。理由：低營運開銷的受控偵測；輔助網路控制。
• 警示回應：路由至 Logic Apps、電子郵件、SIEM。建立劇本以進行分類、暫停使用者、撤銷權杖及收緊防火牆。理由：程式化的回應可縮短平均圍堵時間 (MTTC)。

Azure Cosmos DB 安全性

• 金鑰與權杖：主要/次要金鑰具備高權限；應定期輪換。資料平面操作建議使用 Azure AD RBAC，搭配如 Cosmos DB Built-in Data Contributor/Reader 等角色。理由：具備條件式存取與稽核的身分識別綁定存取。
• 網路控制：IP 防火牆允許清單作為應變措施；私人端點作為預設路徑；若可行則停用公用存取。理由：保證路徑控制與端點驗證。
• 加密：預設靜態加密；啟用 CMK 以取得額外控制。理由：滿足外部加密需求與職責分離。
• 診斷日誌與指標：啟用 DataPlaneRequests、ControlPlaneRequests 及 API 特定類別 (例如 MongoRequests)。理由：提供存取模式、節流與異常請求的端對端可觀察性。

監控、分類與外洩控制

由 Key Vault 支援的祕密與連線字串

• 在執行階段使用受控識別來擷取祕密/金鑰；絕不將祕密儲存在程式碼或設定中。理由：消除應用程式中憑證的四處散布與祕密的輪替。
• App Service/Functions 的 Key Vault 參考

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• 盡可能優先使用 Azure AD 存取權杖來存取 SQL，而非基於祕密的連線字串。理由：更強的原則與撤銷能力。

資訊保護與資料分類

• Microsoft Purview Information Protection 敏感度標籤：為文件和電子郵件套用帶有加密和使用權限的標籤；與自動標籤功能整合。理由：提供超越儲存邊界的持續性保護。
• SQL Information Protection (Azure SQL)：使用內建的資料探索與分類功能，為資料行建議標籤，並匯出至 Purview。理由：在整個資料資產中實現集中治理與一致的原則。

資料外洩控制與安全存取模式

• 優先使用 Private Link：用於 Storage、SQL 和 Cosmos DB。停用公用端點。理由：防止來自公用網際網路的存取，並強制流量源自於經核准的 VNet。
• 出口流量篩選：使用 Azure Firewall 搭配 FQDN 標籤和 DNAT 規則，僅允許必要的 Azure 端點；在 Private Link 不可行時，新增服務端點原則。理由：出口流量的允許清單可阻擋資料外洩至攻擊者控制的端點。
• 資源執行個體規則：對於 Storage 防火牆，僅允許特定的受信任資源執行個體（例如 Synapse 工作區）存取。理由：將存取權限綁定至已知的生產者/消費者，而不僅僅是網路。
• SAS 強化：盡可能使用使用者委派 SAS，限制為 HTTPS，限制 IP，使用最小權限和最短的生命週期；並與預存存取原則綁定以便撤銷。理由：減少權杖濫用並簡化緊急失效程序。
• AKS 與服務端點：若依賴服務端點，請使用 Azure CNI，讓 pod 取得 VNet IP 並繼承端點存取權。理由：將容器流量橋接到 VNet 原生控制項；否則，端點不適用於經過 NAT 的 pod 流量。
• 記錄與分析：啟用 Storage、SQL 和 Cosmos DB 的診斷記錄至 Log Analytics；針對異常資料量、SAS 核發高峰和頻繁的 403 錯誤建立警示。理由：及早偵測資料外洩的企圖。

實務問題情境

Spotify 需要防止資料從開發人員子網路和 AKS 工作負載外洩至未經授權的 Storage 和 SQL 端點，同時讓 CI/CD 管線能夠執行整合測試。

1. 停用公用網路存取，並為所有生產環境的 Storage 帳戶和 Azure SQL 伺服器建立 Private Endpoints。 理由：強制所有資料平面流量都透過 Private Link 傳輸，消除公用入口/出口流量，並透過 VNet 和私有 DNS 實現嚴格的來源強制執行。

2. 設定私有 DNS 區域，使用 A 記錄將儲存體和資料庫資源的 FQDN 對應到私有端點 IP；並連結所有必要的 VNet。 理由：防止 DNS 洩漏至公用端點，並確保用戶端解析到預期的私有資源。

3. 在 Storage 防火牆中，僅為生產環境的 AKS 叢集和建置代理程式擴展集的身分識別新增資源執行個體規則；將預設動作設定為拒絕。 理由：即使在同一個 VNet 內，也只有經核准的資源身分識別才能存取該帳戶，從而阻止來自不受信任工作負載的橫向移動和資料外洩。

4. 在 AKS 上強制使用 Azure CNI，並啟用帶有服務端點原則的服務端點，以允許開發命名空間僅能連線至一個專用的非生產儲存體帳戶。 理由：開發 pod 取得 VNet IP，因此網路原則得以適用；端點原則將任何非私有流量嚴格限制在經核准的帳戶內。

5. 在應用程式程式碼中，將 Blob 和 Queue 的共用金鑰替換為 Azure AD RBAC；在測試中無法避免共用時，則核發帶有預存存取原則且效期為 1 小時的使用者委派 SAS。 理由：與身分識別綁定的權杖是可稽核且可撤銷的；短生命週期的 SAS 可將權杖在建置日誌中暴露的風險降至最低。

6. 啟用 Defender for SQL 的威脅偵測和弱點評估功能；將警示和 SQL 稽核日誌路由到一個中央的 Log Analytics 工作區，並使用自動化的 Logic Apps 進行分類處理（停用使用者、撤銷會話、新增暫時的防火牆拒絕規則）。 理由：受控的偵測功能可加速對 SQL 資料隱碼攻擊和異常存取的圍堵，而 playbook 則可標準化並加速應變措施。

7. 使用 Key Vault 來存放保護 TDE 和 Storage 加密範圍的 CMK；啟用虛刪除和清除保護；每季輪替金鑰，並將資源參考更新至最新的金鑰版本。 理由：具備安全輪替機制的外部化密碼編譯控制符合法規遵循要求，並降低操作錯誤的風險。

8. 使用 SQL Information Protection 在 Azure SQL 中分類敏感資料行，並將其上線至 Microsoft Purview；為下游的匯出資料套用 MIP 敏感度標籤。 理由：持續性的標籤會隨著資料的擷取而移動，從而限制濫用，並使 DLP 工具能夠在各種工具和裝置上強制執行控制措施。

9. 使用 Azure Firewall 鎖定出口流量，僅允許建置/測試所需的 Azure 服務，對 Storage 和 SQL 使用 FQDN 標籤，並拒絕萬用字元的出口 HTTP(S) 流量。 理由：正面表列的安全模型確保流量只能到達經核准的端點，防止資料外流至攻擊者的網域。

此順序可防止公用存取，限制了「誰」和「什麼」可以存取資料，將存取權限與身分識別而非祕密綁定，並將監控和快速應變操作化——同時透過範圍限定、有時間限制的例外情況來維持開發人員的開發速度。

← 運算、容器與端點安全 · 所有領域 · 金鑰管理、密碼學與憑證 →

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

瀏覽 Microsoft →