Microsoft AZ-500: 應用程式安全與 DevSecOps — 學習指南

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 中的應用程式安全與 DevSecOps 著重於防止身分識別濫用、保護傳入流量與 API、在管線中實踐安全左移、保護靜態與傳輸中的密鑰，以及強制執行穩健的發布治理。有效的設計能消除長期有效的密鑰、採用最低權限、驗證每個呼叫者，並將程式碼、相依性、基礎設施及執行階段的持續偵測與修復制度化。

保護應用程式身分識別、傳入流量與 API

在 Microsoft Entra ID (Azure AD) 中保護應用程式身分識別，始於一個範圍界定良好的應用程式註冊與正確的 OAuth 2.0 流程：

• 委派權限適用於使用者已登入的情況，且同意權限可僅限於已驗證發行者的應用程式或管理員核准的範圍。應用程式權限 (僅限應用程式) 則一律需要管理員同意，因為它們授權的是在沒有使用者情況下運作的背景精靈或服務。
• 透過僅授予所需的最小範圍或應用程式角色，並要求管理員審查同意請求，來強制執行最低權限。停用終端使用者同意，或僅允許低風險、已驗證的發行者，以減少同意網路釣魚的風險。
• 偏好使用憑證認證或同盟身分識別，而非用戶端密鑰。憑證支援更強的保證與可預測的輪替。設定短生命週期並自動化輪替。除非必要，否則應封鎖公用用戶端流程。
• 對於 Azure 服務，請使用受控識別而非應用程式密鑰。指派如 Key Vault Secrets User 或 Storage Blob Data Reader 等資料平面角色，並在適用時使用 Private Endpoints 限制網路存取。

Application Gateway WAF v2 與 Azure Front Door WAF 可保護公用傳入流量，抵禦 OWASP Top 10 威脅：

• 啟用最新的 Microsoft 管理的 OWASP 核心規則集，並在調整後以預防模式執行。初期可使用異常評分，以在學習期間減少誤判。
• 設定自訂規則以進行地理圍欄、IP 信譽封鎖、標頭強制執行及請求大小限制。對於 Front Door，可新增依用戶端 IP 的速率限制規則，以減緩憑證填充攻擊與基本的 L7 DoS 攻擊。
• 使用強式加密套件與原則來終止 TLS；使用到來源的端對端 TLS。對於需要 mTLS 的情境，請在 Application Gateway 接聽程式上設定用戶端憑證驗證。
• 將 WAF 原則精確地附加到接聽程式/路由上；僅在完全了解誤判情況時才使用規則排除。將 WAF 記錄串流至 Log Analytics，以利偵測工程與事件應變。

API Management (APIM) 強制執行多層式安全態勢：

• 在閘道透過嚴格的簽發者、對象與範圍檢查來驗證 OAuth 權杖。要求全程使用 HTTPS，並在用戶端信任邊界有此要求時強制執行 mTLS。
• 結合訂用帳戶金鑰與 OAuth 以實現深度防禦及節流身分識別。使用產品層級的訂用帳戶金鑰來分割取用者，並在不影響他人的情況下輪替金鑰。
• 應用速率限制與配額，其精細度可依取用者、依範圍或依訂用帳戶設定。在適當時，使用 IP 篩選將合作夥伴網路加入允許清單。
• 使用相互 TLS 或受控識別來保護後端服務。將密鑰儲存為由 Key Vault 參考支援的具名值 (Named Values)，以避免在設定檔中使用純文字。

用於 JWT 範圍強制執行與節流的 APIM 原則範例：

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

DevSecOps 管線強化與 Defender for DevOps

Azure DevOps 與 GitHub Actions 必須在沒有長期有效密鑰的情況下向 Azure 進行驗證：

• 對於服務連線，請使用工作負載身分識別同盟 (OIDC)。在 Entra ID 中建立一個應用程式註冊/服務主體，然後新增一個同盟認證，將 repo、分支與工作流程/環境綁定到該身分識別。這樣可以產生不儲存密鑰的短期權杖，並支援透過 Azure RBAC 實現最低權限的範圍界定。
• 鎖定管線權限：要求核准才能使用服務連線、將管線限制於受保護的分支，並停用「允許指令碼存取 OAuth 權杖」除非必要。使用具有遮罩的變數群組與密鑰；透過記錄命令禁止回顯密鑰。在 GitHub 中，偏好使用環境與組織層級的密鑰而非 repo 層級的密鑰，以實現集中式控制，並在適用的情況下於託管的執行器中使用「防止密鑰出現在記錄中」的設定。
• 應用環境保護規則：必要的審查者、檢查 (例如：變更管理票證、測試通過) 及基於時間的核准。

使用 Azure CLI 建立同盟認證 (GitHub OIDC 範例)：

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps 與 Azure Repos 及 GitHub 整合以呈現：

• 常見語言的程式碼安全發現 (SAST)；提取要求註解會突顯新問題以防止功能退化。
• 使用針對 OSS 函式庫的弱點情報來評估相依性風險 (SCA)，並提供修復指南與已修復的版本。
• 密鑰暴露偵測及針對外洩的權杖/金鑰的建議輪替。
• 跨 ARM/Bicep/Terraform 的基礎設施即程式碼 (Infrastructure-as-Code) 設定錯誤 (例如：公用儲存體、過於寬鬆的 NSG)，並具備原則驅動的治理與漂移追蹤。 發現項目會彙總至 Defender for Cloud，並包含儲存庫與管線的上下文以利排定優先順序。根據嚴重性閾值來管制發布，以阻止不安全的部署。

密鑰管理與平台整合

Key Vault 提供集中式的密鑰、金鑰與憑證管理，並具備全面的控制項：

• 強制啟用清除保護 (purge protection) 與虛刪除 (soft delete)，以防止破壞性的遺失。優先使用 RBAC 而非存取原則 (access policies) 來進行統一授權；在可行情況下，啟用 Private Endpoints 並停用公用網路存取；啟用記錄功能並傳送到安全的工作區 (workspace)。
• App Service 與 Functions 透過受控識別 (managed identities)，在應用程式設定中使用 Key Vault 參考；無需重新部署即可通透地輪替密鑰。
• AKS 在執行階段透過 Secrets Store CSI Driver 搭配 Azure Key Vault provider 來擷取密鑰，並由 Azure AD Workload Identity (建議方式) 進行驗證。應避免將純文字密鑰放置在 Kubernetes 的 Secret 物件中。

App Service Key Vault 參考範例：

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (節錄)：

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

管線應在工作 (job) 執行階段擷取密鑰：

• Azure DevOps：使用 Key Vault 工作 (task) 搭配由受控識別支援的服務連線 (service connection)；將密鑰下載限制在最少數量的階段 (stage)。
• GitHub Actions：使用 azure/login 進行 OIDC 驗證，並用 azure/keyvault 來拉取僅需的密鑰。

安全的 SDLC、容器、記錄與發布

安全的 SDLC 實務可在部署前降低風險：

• 及早使用 STRIDE 或同等方法進行威脅模型分析，確保驗證、授權和資料流都經過明確的驗證。隨著架構演進，更新威脅模型。
• 在每個 PR 上執行 SAST；對於有明確負責人的高嚴重性問題，應中斷建置。DAST 則在部署到具備安全測試資料的預備（staging）位置/環境後執行。
• SCA 持續監控套件；強制使用固定的版本並符合授權規範。
• 透過分支原則進行嚴格的程式碼審查：要求指定的審查者、連結工作項目、建置驗證以及簽署的 commits。

容器映像檔的安全性是供應鏈完整性的基礎：

• 在建置過程中產生並儲存 SBOMs (SPDX 或 CycloneDX)，並將其作為 OCI 成品與映像檔一同發布，以利追溯。
• 使用 Defender for Cloud 的容器掃描功能，在推送前（pre‑push）及在登錄庫中靜態（at‑rest）掃描映像檔；根據重大發現來管控升版流程。
• 使用 cosign 搭配 Notary v2/OCI 成品來簽署映像檔與證明（attestations）。在准入（admission）時強制執行簽章驗證（例如，使用 Gatekeeper/OPA 或適用於 Kubernetes 的 AKS Policy）。
• Azure Container Registry (ACR) 的登錄庫控制項：停用管理員使用者、透過 Private Endpoints 限制網路存取、啟用客戶管理的金鑰、使用存放庫範圍的權杖進行細緻的存取控制，並應用保留與隔離模式。僅授予執行環境 AcrPull 權限，並授予 CI AcrPush 權限。對於 AKS，應使用支援的指令來附加 ACR 以建立正確的角色指派，而非手動設定角色。
• 如果容器必須從 VM 主機使用 VNet 服務端點，請安裝支援的 CNI 插件，以便每個容器的流量都源自其子網路。

應用程式記錄不得洩漏密鑰或 PII：

• 設定 Application Insights 使用 Telemetry Processors 來修訂或捨棄敏感欄位；避免記錄包含密鑰或 PII 的原始標頭、權杖或酬載。將資料欄位限制在業務需求範圍內，並啟用取樣以減少曝險。
• 將診斷資料路由到專用的 Log Analytics 工作區，該工作區應具備嚴格的 RBAC（至少授予 Log Analytics Reader 的最低權限），並在匯出到儲存體時使用不可變儲存體（以時間為基礎的保留鎖定）。
• 在可用時，使用 Private Link 保護遙測資料的擷取與查詢端點。將檢測連接字串儲存在 Key Vault 中並定期輪替。

安全的發布實務可強制執行受控的升版流程：

• Azure DevOps Environments 或 GitHub Environments 中的核准閘道要求指定的審查者、通過品質檢查以及變更工單。針對高風險部署，自動化設定暫緩部署的時段。
• 對服務連線與代理程式應用最低權限原則；根據不同環境將其範圍限定在特定的資源群組或訂用帳戶。使用具備窄範圍角色的受控識別。
• 在開發（Dev）、測試（Test）和生產（Prod）環境之間進行隔離，使用不同的訂用帳戶、VNet、Key Vault 和 ACR；禁止跨環境的橫向移動，並在每個環境中使用不同的密鑰/金鑰。

實務問題情境

Fabrikam 公司正在向網際網路發布一個多租戶 SaaS API。需求：阻擋 OWASP Top 10 攻擊、根據每個操作驗證 OAuth 範圍、防止密鑰出現在存放庫中、對濫用行為的用戶端進行節流，並確保只有經簽署的容器映像檔能在生產環境中執行。

1. 前端處理與 WAF

• 部署 Azure Front Door Standard，並搭配一個 WAF 原則，該原則使用最新 OWASP 受控規則集並設定為防護（Prevention）模式，再加上自訂的速率限制規則與地理位置封鎖。理由：集中化的全球邊緣強制執行可減少攻擊面，並在 L7 攻擊到達來源（origin）之前就將其吸收。

2. API 閘道原則

• 將 Azure API Management 放在 Front Door 後方；實作 validate-jwt 原則，針對每個操作進行簽發者/受眾/範圍檢查，並使用具備配額的產品層級訂用帳戶金鑰。理由：APIM 提供身分識別感知的強制執行與租戶隔離；金鑰加上 OAuth 提供了分層防禦和精確的節流控制。

3. 身分識別與同意授權

• 在 Entra ID 中註冊 SPA 與精靈應用程式，為使用者流程設定委派範圍，並為精靈應用程式設定應用程式角色；將使用者同意限制於已驗證的發行者，並要求應用程式權限需經管理員同意。為精靈應用程式使用憑證認證。理由：消除弱密鑰、強制執行最低權限原則，並減少同意授權釣魚的曝險。

4. 使用 OIDC 的 DevSecOps

• 設定 GitHub Actions 使用 OIDC 同盟，連線到一個 Azure 服務主體：建置用的服務主體範圍限定於非生產環境的訂用帳戶，而發布用的服務主體則限定於生產環境，兩者都僅具備最低權限角色（建置用為 AcrPush，發布用為限制在生產環境 RG 的 Contributor）。理由：不需儲存密鑰；每個環境的爆炸半徑都被最小化。

5. 容器供應鏈

• 透過 ACR Tasks 建置映像檔，產生 SBOMs (CycloneDX) 並用 cosign 簽署映像檔；將證明（attestations）儲存為 OCI 成品。設定 AKS 的准入控制原則，要求必須有有效的簽章。理由：來源（provenance）與完整性在部署時即可驗證，從而阻擋被竄改的映像檔。

6. 登錄庫與執行階段控制

• 停用 ACR 管理員使用者、啟用 Private Endpoint、透過支援的 attach-acr 流程將 AcrPull 權限指派給 AKS kubelet 身分識別，並啟用 Defender for Cloud 映像檔掃描。理由：網路與身分識別的強化移除了預設的後門；掃描可在執行階段前捕捉到已知的 CVE。

7. 密鑰與組態

• 使用具備 Private Endpoint 和 RBAC 的 Key Vault；App Service 和 Functions 使用 Key Vault 參考來取用密鑰，而 AKS 則使用 Secret Store CSI 搭配 Workload Identity。理由：密鑰永遠不會存放在存放庫或應用程式組態中；輪替是集中化且可稽核的。

8. 發布治理

• 透過強制審查與檢查來保護 GitHub 的 main 分支；在部署到生產環境前，要求環境核准並通過安全性閘道（沒有重大的 SAST/SCA/IaC 發現項目）。理由：確保只有經過驗證的安全建置才能繼續進行；對於高風險的變更，仍保留人工監督。

9. 可觀測性健康度管理

• 設定 Application Insights 使用自訂的 Telemetry Processors 來修訂 PII，並將 WAF/APIM 的診斷資料路由到一個安全的 Log Analytics 工作區，該工作區僅授予最低權限的 Reader 存取權。理由：在不暴露敏感資料的情況下保留鑑識價值；存取是可稽核且受限制的。

← Microsoft Sentinel 與安全營運 · 所有領域 · 混合與多雲安全 →

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

瀏覽 Microsoft →