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.

概述

本节为保护 IaaS 和 PaaS 中的 Azure 计算、容器和端点提供操作参考。它重点介绍如何配置保护措施、其重要性，以及如何使用 Azure 原生控件来一致地强制执行这些措施。

计算和端点安全

Azure VM 平台保护和加密选项是基础。

安全启动、vTPM 和可信启动：可信启动通过启用 UEFI 安全启动和虚拟 TPM (vTPM) 来强化 Gen2 VM。安全启动可防止未签名的引导加载程序/rootkit。vTPM 为密钥（例如 BitLocker）提供了一个防篡改的存储，并支持度量启动，以便平台可以证明操作系统引导链的完整性。在操作上，应在部署时启用可信启动，并通过策略强制执行，以确保所有新 VM 都能获得基于硬件的完整性检查，而无需管理员处理静态 BIOS/UEFI 设置。
机密 VM：使用基于 AMD SEV-SNP 或 Intel TDX 的机密 VM 系列（例如 DCasv5/DCadsv5）来加密 VM 内存并提供证明。这可以保护工作负载免受恶意主机/虚拟机监控程序和旁道攻击。在操作上，应为高度敏感的“使用中数据”场景选择机密 SKU，在部署管道中集成证明，并在需要快速重新部署而无需数据持久化时，优先选择临时 OS 磁盘。
磁盘加密选项：
- Azure Disk Encryption (ADE)：客户机内部的 BitLocker (Windows) 或 DM-Crypt (Linux)，密钥存储在 Key Vault 中 (BEK/KEK)。当您需要基于客户机的加密域、操作系统内部的合规性检查或利用与 vTPM 绑定的 BitLocker 时，此选项非常有用。它需要代理和用于扩展运行状况的生命周期操作。
- 使用客户管理的密钥 (CMK) 的服务器端加密 (SSE)：使用 Key Vault 或 Managed HSM 中的密钥对托管磁盘进行存储级加密。无需客户机代理，可完全覆盖平台（磁盘、快照、映像），运维开销极小。推荐作为大多数用例的默认选项；与可信启动或机密 VM 结合使用可实现更强的深度防御。
Microsoft Defender for Servers：
- 计划 1：用于服务器 EDR/端点保护的 Microsoft Defender for Endpoint (MDE)。当您已经拥有成熟的漏洞和配置管理工具，且主要需要 EDR 时，请选择此计划。
- 计划 2：增加了基于代理/无代理的漏洞评估、即时 (JIT) VM 访问、自适应应用程序控制、自适应网络强化和文件完整性监视 (FIM)。当您希望通过平台驱动的方式减少风险暴露面并实现有效的治理，而无需整合多个工具时，请选择此计划。
- 端点保护：通过 VM 扩展或为非 Azure 服务器部署 Arc 来部署 MDE，以在混合云环境中标准化遥测、防篡改和响应 playbook。
- 漏洞评估：使用 MDE 威胁和漏洞管理信号或集成扫描器（例如 Qualys）来清点 CVE，按可利用性排定优先级，并协调补丁安装。在操作上，首先为面向互联网的关键服务器建立基线；将修复工作与变更窗口期挂钩。
- 文件完整性监视：跟踪对敏感文件/注册表项的更改，以检测可疑篡改并满足合规性要求。配置有范围限定的监视路径以避免噪音，并将警报转发到您的 SIEM。
使用 Defender for Cloud 减少风险暴露面：
- 即时 (JIT) VM 访问：关闭入站 RDP/SSH。管理员请求有时间限制的访问；Defender 会打开 NSG 或 Azure Firewall 规则并记录活动。其结果是攻击面大幅缩小，并带有可审计的例外情况。
- 自适应应用程序控制：学习正常进程并创建允许列表（Windows 上的 AppLocker，Linux 的审核规则）。这可以阻止未经批准的二进制文件和脚本——对于防御无文件或 LOLBin 攻击尤其有效。
- 自适应网络强化：使用流量分析和威胁情报来建议收紧 NSG 规则。采用“审查并应用”的节奏，在避免服务中断的同时，迭代地限制风险暴露面。
- 来宾配置：通过代理或 Azure Arc 在客户机内部（Windows 和 Linux）进行审核/修复的 Azure Policy。当您需要可证明的配置状态而不仅仅是平台态势时，可使用它来强制执行操作系统基线、密码策略和符合 CIS 标准的设置。

PaaS 计算：App Service 和 Functions

默认安全的模式可减少 PaaS 的攻击面。

Azure App Service:
- 身份验证/授权：启用 App Service 身份验证，将身份验证工作卸载到 Microsoft Entra ID 或其他提供商。对标准 OIDC/OAuth2 流程使用 Easy Auth，然后在所有路由上强制执行登录，以消除未经身份验证的暴露。
- 访问限制：通过 IP/CIDR、服务标签或专用终结点允许或拒绝虚拟网络流量。为 scm 终结点和应用终结点维护独立的规则，以独立保护您的部署平面。
- 专用终结点：通过 VNet 中的私有 IP 暴露应用，并可选择禁用公共访问。使用私有 DNS 区域，并通过 VNet 集成和中央出口防火墙限制出站依赖。
- 托管标识：优先使用系统分配或用户分配的标识来访问 Key Vault、Storage 和其他服务。这消除了嵌入式密钥，并实现了集中的角色分配和密钥轮换。
Azure Functions:
- 密钥管理：Functions 使用函数密钥、主机密钥和主密钥。定期轮换密钥，并将外部使用的密钥存储在 Key Vault 中，或者在可行的情况下用适当的 OAuth 流程替换密钥。
- 网络集成：对 Function 应用的入站访问使用专用终结点，对出站控制使用区域性 VNet 集成。将 Functions 使用的 Storage 帐户限制为仅限选定网络，并将 Function 的专用终结点添加到允许的网络中。
- 标识：使用托管标识进行服务到服务的身份验证，而不是使用密钥或连接字符串。通过范围狭窄的 RBAC 分配来推动最小权限原则。
- 部署控制：强制仅使用 FTPS，禁用 scm 站点的基本身份验证，限制 scm IP，并使用“从包运行”(Run From Package) 来确保不可变部署。将 CI/CD 与工作负载身份联合集成，以消除长期存在的密钥。

Kubernetes 和容器安全

端到端地加固集群和供应链。

AKS 身份和授权：
- Microsoft Entra 集成：为 AKS 启用托管 AAD，以使用 Entra 令牌和组对 kubectl 进行身份验证。这可以集中管理用户生命周期和 MFA/条件访问。
- Kubernetes RBAC：将 Entra 用户/组映射到 Kubernetes 角色和角色绑定，以实现命名空间范围的最小权限。
- 用于 Kubernetes 的 Azure RBAC：当您希望 Azure RBAC 直接授权 Kubernetes API 操作时，请使用内置角色（例如，Azure Kubernetes Service RBAC Viewer/Admin）。这将授权和审计与 Azure 控制平面统一起来。
AKS 网络和隐私：
- 网络策略：使用 Azure NPM 或 Calico 强制执行 pod 到 pod 以及 pod 到服务的流量策略。默认拒绝，并明确允许所需的出口流量；策略即代码 (policy-as-code) 可防止横向移动。
- 私有集群：将 API 服务器设为私有，仅通过专用终结点访问。与 Azure Bastion/Private Link 和防火墙出口策略（NAT Gateway + UDRs）配合使用，使管理平面脱离公共互联网。
容器注册表 (ACR) 安全：
- RBAC：将 AcrPull 角色分配给仅需拉取镜像的工作负载，将 AcrPush 分配给构建管道；避免使用权限过高的 Owner 角色。AcrPull 和 AcrPush 符合最小权限原则。
- 内容信任和签名：使用 cosign 对镜像进行签名，并在 pod 启动前通过准入控制（Gatekeeper + Ratify）强制执行验证。这可以防御被篡改的镜像。
- 镜像扫描：启用 Microsoft Defender for Cloud，在推送/导入时以及按计划扫描 ACR。使用准入策略阻止部署带有严重未修复 CVE 的镜像。
- 隔离模式：将新镜像路由到隔离的存储库或标签，运行扫描和策略检查，然后在批准后通过重新打标签来提升镜像。
- 私有访问：禁用公共网络访问，并使用专用终结点和注册表防火墙规则。使用资源级别的角色分配将 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 加密的虚拟机。
- 使用 DeployIfNotExists 策略强制为虚拟机安装端点保护扩展，以自动安装所需代理。
- 审核来宾配置合规性；按计划修复配置漂移。

在缺少所需虚拟机扩展时进行部署的简短策略片段：

"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 公司正在将一个支付微服务迁移到 Azure。安全要求规定零公共暴露、只使用签名镜像，以及在切换期间对旧版虚拟机进行有时间限制的管理员访问。

将 AKS 控制平面设为私有并锁定出口流量。

理由：私有的 AKS API 服务器可将管理平面从互联网上移除。通过 NAT Gateway 加上带有明确出站规则的 Azure Firewall，可以确保工作负载只能访问经批准的端点（ACR、Key Vault、Microsoft 软件包仓库）。

强制使用签名镜像并限制镜像仓库。

理由：配置 Gatekeeper 约束，只允许来自 myacr.azurecr.io 的镜像，并要求使用由 Ratify 验证的 cosign 签名。这可以防止被篡改或不受信任的镜像运行，从而消除一个重大的供应链风险。

使用私有端点和最小权限角色保护 ACR。

理由：禁用公共网络访问，并通过 AKS VNet 中的私有端点暴露 ACR。仅授予 AKS 托管身份 AcrPull 权限；授予构建管道 AcrPush 权限。这遵循了最小权限原则，并消除了对互联网的依赖。

启用 Defender for Containers 和 ACR 镜像扫描。

理由：推送时持续进行镜像扫描和运行时威胁检测提供了分层覆盖。警报统一了配置错误、已知漏洞和可疑行为，以便快速响应。

通过身份验证和私有访问保护基于 App Service 的管理工具。

理由：使用 App Service Authentication 与 Microsoft Entra ID 来要求 MFA 和条件访问。为管理应用创建私有端点，并单独限制 scm 访问。使用托管身份访问 Key Vault，从而移除密钥。

在切换期间对旧版主机使用 Just-in-Time (JIT) VM 访问。

理由：JIT 默认关闭 RDP/SSH 端口，仅在收到批准的请求后才在有限时间内开放。这严格限制了暴露窗口，同时保留了紧急访问权限。

标准化加密选项：磁盘使用带 CMK 的 SSE；虚拟机使用受信任启动 (Trusted Launch)。

理由：带 CMK 的 SSE 最大限度地减少了操作负担，并将密钥生命周期集中在 Key Vault 中管理，而受信任启动 (Trusted Launch)/vTPM 则增加了启动完整性和密钥保护。ADE 仅保留给那些合同要求提供基于来宾的加密域证据的场景。

应用 Azure Policy 和准入控制作为护栏。

理由：Azure Policy 计划强制执行受信任启动、必要的虚拟机扩展，并拒绝公共的 ACR/Function 访问。Gatekeeper 约束为 AKS 实施运行时准入检查。它们共同确保团队在迭代开发过程中配置保持合规。

通过持续治理进行验证和运营。

理由：将 Defender for Cloud 和 MDE 的警报接入 Adobe 的 SIEM 系统，衡量策略效果（拒绝 vs. 审核），并每月审查例外情况。这将一次性的控制措施转变为一个持久的安全运营模型。

← 网络安全架构 · 所有领域 · 数据、存储和数据库安全 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通过考试 →

浏览 Microsoft →