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.

PaaS 運算：App Service 與 Functions

預設安全的模式可減少 PaaS 的攻擊面。

• Azure App Service：

  • 驗證/授權：啟用 App Service Authentication，將驗證工作卸載到 Microsoft Entra ID 或其他提供者。使用 Easy Auth 處理標準的 OIDC/OAuth2 流程，然後在所有路由上強制登入，以消除未經驗證的曝險。
  • 存取限制：透過 IP/CIDR、服務標籤或經由 private endpoints 的虛擬網路流量來允許或拒絕流量。為 scm 端點和應用程式端點維護獨立的規則，以分別保護您的部署平面。
  • 私人端點 (Private Endpoints)：在您的 VNet 中透過私有 IP 公開應用程式，並可選擇性地停用公用存取。使用私有 DNS 區域，並透過 VNet Integration 和中央輸出防火牆來限制對外相依性。
  • 受控識別 (Managed Identities)：優先使用系統指派或使用者指派的識別來存取 Key Vault、Storage 及其他服務。這能消除內嵌的密碼，並實現集中的角色指派和金鑰輪替。

• Azure Functions：

  • 金鑰管理：Functions 使用函式金鑰、主機金鑰和主要金鑰。定期輪替金鑰，並將外部使用的金鑰儲存在 Key Vault 中，或在可行時用適當的 OAuth 流程取代金鑰。
  • 網路整合：使用 private endpoints 進行對 Function 應用程式的傳入存取，並使用區域性 VNet Integration 進行傳出控制。將 Functions 使用的 Storage 帳戶限制為僅能由選定的網路存取，並將 Function 的 private endpoint 加入允許的網路清單中。
  • 識別：使用受控識別進行服務對服務的驗證，而非使用金鑰或連接字串。透過範圍狹窄的 RBAC 指派來實踐最低權限原則。
  • 部署控制：強制僅使用 FTPS、停用 scm 網站的基本驗證、限制 scm 的 IP，並使用「從套件執行」(Run From Package) 以確保不可變的部署。將 CI/CD 與 workload identity federation 整合，以消除長期存在的密碼。

Kubernetes 與容器安全性

端對端地強化叢集與供應鏈。

• AKS 身分識別與授權：

  • Microsoft Entra 整合：為 AKS 啟用受控 AAD，以使用 Entra token 和群組來驗證 kubectl。這能集中管理使用者生命週期及 MFA/條件式存取。
  • Kubernetes RBAC：將 Entra 使用者/群組對應到 Kubernetes 的 roles 和 role bindings，以實現命名空間範圍的最低權限。
  • 適用於 Kubernetes 的 Azure RBAC：當您希望由 Azure RBAC 直接授權 Kubernetes API 操作時，請使用內建角色（例如 Azure Kubernetes Service RBAC Viewer/Admin）。這能將授權和稽核與 Azure 控制平面統一。

• AKS 網路與隱私：

  • 網路原則：使用 Azure NPM 或 Calico 來強制執行 pod-to-pod 和 pod-to-service 的流量規則。預設拒絕所有流量，並明確允許必要的輸出流量；policy-as-code 可防止橫向移動。
  • 私人叢集：將 API server 設為私有，僅能透過 private endpoints 存取。搭配 Azure Bastion/Private Link 和防火牆輸出策略（NAT Gateway + UDRs），讓管理平面遠離公開網際網路。

• Container Registry (ACR) 安全性：

  • RBAC：將 AcrPull 指派給只需要提取映像檔的工作負載，並將 AcrPush 指派給建置管線；避免使用權限過大的 Owner 角色。AcrPull 和 AcrPush 符合最低權限原則。
  • 內容信任與簽署：使用 cosign 簽署映像檔，並在 pod 啟動前透過 admission control（Gatekeeper + Ratify）強制執行驗證。這能防禦被竄改的映像檔。
  • 映像檔掃描：啟用 Microsoft Defender for Cloud，在推送/匯入映像檔至 ACR 時以及按排程進行掃描。使用 admission policies 來阻止部署含有嚴重未修補 CVE 的映像檔。
  • 隔離模式：將新的映像檔路由到一個隔離的 repo 或標籤，執行掃描和策略檢查，然後在核准後透過重新標記來晉升。
  • 私人存取：停用公用網路存取，並使用 private endpoints 和登錄庫防火牆規則。使用資源層級的角色指派將 AKS 附加到 ACR，而非使用目錄角色。

使用叢集的受控識別將 ACR 附加到 AKS 的簡短範例：

az aks update -g rg-aks -n myAKS --attach-acr myAcrName

• Microsoft Defender for Containers：在 AKS 中部署一個資料平面感應器，監控 Kubernetes 稽核日誌和執行期信號，並與映像檔掃描結果相互關聯。它能偵測到可疑的 pod 內 exec 操作、加密貨幣挖礦、暴露的儀表板以及具風險的控制平面操作。啟用自動佈建，並將警示連接到您的 SIEM/SOAR 進行分類處理。

治理、原則與強制執行

一致性的控管需要在部署時與執行階段套用原則。

• 針對運算與磁碟的 Azure Policy：
  • 拒絕建立沒有 trusted launch 或沒有使用 CMK 進行 SSE 加密的 VM。
  • 使用 DeployIfNotExists 強制安裝端點保護所需的 VM 擴充功能，以自動安裝必要的代理程式。
  • 稽核客體設定的合規性；排程修復設定偏移。

若缺少必要的 VM 擴充功能，可使用以下簡短的原則片段來部署：

"policyRule": {
  "if": { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "name": "MDE.Windows"
    }
  }
}

• Kubernetes 准入控制：
  • 適用於 AKS 的 Azure Policy 附加元件使用 Gatekeeper (OPA) 在准入時評估 pod 的規格。強制執行規則，例如「只能從 ACR 提取」、「禁止特權容器」以及「需要映像簽章」。
  • 為基準（必要）和強化（敏感命名空間）維護不同的計畫 (initiatives)，以實現漸進式強化。

用於限制登錄庫的簡短 Gatekeeper 限制條件：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-acr-only
spec:
  parameters:
    repos:
    - myacr.azurecr.io/

• 維運節奏：
  • 偵測：使用 Defender for Cloud 的建議和工作負載警示作為您的設定偏移與威脅訊號。
  • 決策：根據業務影響和可利用性進行分類；透過標籤指派擁有者。
  • 強制執行：將成功的試行轉換為拒絕原則/准入限制；衡量被封鎖的嘗試以偵測影子 IT。

實務問題情境

Adobe Inc. 正在將一個支付微服務遷移到 Azure。安全性要求規定零公開暴露、僅使用已簽署的映像檔，以及在轉換期間對舊有 VM 的管理員存取權限有時間限制。

1. 將 AKS 控制平面設為私有並鎖定輸出流量。

• 理由：私有的 AKS API 伺服器可將管理平面從網際網路上移除。NAT Gateway 加上具有明確輸出規則的 Azure Firewall，可確保工作負載只能連線到經核准的端點（ACR、Key Vault、Microsoft 套件儲存庫）。

2. 強制使用已簽署的映像檔並限制登錄庫。

• 理由：設定 Gatekeeper 的限制條件，只允許來自 myacr.azurecr.io 的映像檔，並要求使用經由 Ratify 驗證的 cosign 簽章。這可以防止被竄改或不受信任的映像檔執行，從而消除一個重大的供應鏈風險。

3. 使用私有端點和最低權限角色來保護 ACR。

• 理由：停用公用網路存取，並透過 AKS VNet 中的私有端點來公開 ACR。僅授予 AKS 受控識別 AcrPull 權限；授予建置管線 AcrPush 權限。這遵循了最低權限原則，並消除了對網際網路的依賴。

4. 啟用 Defender for Containers 和 ACR 映像檔掃描。

• 理由：推送時的持續映像檔掃描和執行階段威脅偵測提供了分層的保護。警示統一了設定錯誤、已知弱點和可疑行為，以便快速回應。

5. 使用驗證和私有存取來保護基於 App Service 的管理工具。

• 理由：使用 App Service Authentication 搭配 Microsoft Entra ID 來要求 MFA 和條件式存取。為管理應用程式建立一個私有端點，並另外限制 scm 的存取。受控識別移除了存取 Key Vault 所需的密碼。

6. 在轉換期間對舊有主機使用 Just-in-Time (JIT) VM 存取。

• 理由：JIT 預設會關閉 RDP/SSH，僅在核准的請求下於有限時間內開啟。這嚴格限制了暴露的窗口，同時保留了緊急存取權限。

7. 標準化加密選項：磁碟使用 SSE with CMK；VM 使用 Trusted Launch。

• 理由：SSE with CMK 可將維運負載降到最低，並將金鑰生命週期集中在 Key Vault 中管理，而 Trusted Launch/vTPM 則增加了開機完整性和金鑰保護。ADE 僅保留給合約上要求提供基於客體作業系統的加密領域證據的場景。

8. 應用 Azure Policy 和准入控制作為防護欄。

• 理由：Azure Policy 計畫 (initiatives) 強制執行 trusted launch、必要的 VM 擴充功能，並拒絕公用的 ACR/Function 存取。Gatekeeper 限制條件則為 AKS 實作執行階段的准入檢查。兩者共同確保團隊在反覆運算過程中，設定能保持合規。

9. 透過持續的治理進行驗證與維運。

• 理由：將 Defender for Cloud 和 MDE 的警示串接到 Adobe 的 SIEM，衡量原則的效果（拒絕 vs. 稽核），並每月審查例外情況。這將一次性的控制措施轉變為一個持久的安全性維運模型。

← 網路安全架構 · 所有領域 · 資料、儲存與資料庫安全 →

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

瀏覽 Microsoft →