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 (mTLS) 或托管身份保护后端服务。将机密存储为由 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 中创建应用注册/服务主体，然后添加一个联合凭据，将存储库、分支和工作流/环境绑定到该身份。这样可以生成短期令牌，无需存储机密，并通过 Azure RBAC 支持最小权限范围。
• 锁定管道权限：要求批准才能使用服务连接，将管道限制在受保护的分支上，并禁用“允许脚本访问 OAuth 令牌”选项（除非需要）。使用带有掩码的变量组和机密；通过日志记录命令禁止回显机密。在 GitHub 中，优先使用环境和组织机密而不是存储库机密以实现集中控制，并在适用的情况下在托管运行器中使用“防止日志中出现机密”的设置。
• 应用环境防护规则：必需的审阅者、检查（例如，变更管理工单、测试通过）和基于时间的批准。

使用 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 的基础设施即代码 (IaC) 错误配置（例如，公共存储、宽松的 NSG），并提供策略驱动的治理和漂移跟踪。 发现结果会连同存储库和管道的上下文一起汇总到 Defender for Cloud 中，以便确定优先级。根据严重性阈值对发布进行门控，以阻止不安全的部署。

机密管理与平台集成

Key Vault 提供集中的机密、密钥和证书管理，并带有全面的控制措施：

• 强制启用清除保护和软删除，以防止破坏性丢失。优先使用 RBAC 而非访问策略进行统一授权；在可行的情况下启用 Private Endpoints 并禁用公共网络访问；启用日志记录到安全的工作区。
• App Service 和 Functions 使用托管身份，在应用设置中通过 Key Vault 引用来使用机密；无需重新部署即可透明地轮换机密。
• AKS 在运行时通过 Secrets Store CSI Driver 和 Azure Key Vault 提供程序来检索机密，并使用 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

管道应在作业运行时获取机密：

• Azure DevOps：使用由托管身份支持的服务连接来运行 Key Vault 任务；将机密下载限制在最少的阶段。
• GitHub Actions：使用 azure/login 进行 OIDC 身份验证，并使用 azure/keyvault 拉取所需名称的机密。

安全 SDLC、容器、日志记录和发布

安全 SDLC 实践可在部署前降低风险：

• 早期使用 STRIDE 或等效方法进行威胁建模，确保身份验证、授权和数据流得到明确验证。随着架构的演变更新模型。
• 在每个 PR 上运行 SAST；对于高严重性问题，中断构建并明确责任人。DAST 在部署到具有安全测试数据的暂存槽/环境后执行。
• SCA 持续监控软件包；强制要求固定版本和许可证合规性。
• 通过分支策略进行严格的代码审查：要求有审查者、关联的工作项、构建验证和签名提交。

容器镜像安全是供应链完整性的基础：

• 在构建过程中生成并存储 SBOM（SPDX 或 CycloneDX），并作为 OCI 工件与镜像一同发布，以实现可追溯性。
• 使用 Defender for Cloud 的容器扫描功能，在推送前和在注册中心静态存储时扫描镜像；根据严重发现对晋级进行门控。
• 使用 cosign 通过 Notary v2/OCI 工件签署镜像和证明。在准入时强制执行签名验证（例如，使用 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 权限），并在导出到 Storage 时使用不可变存储（基于时间的保留锁定）。
• 在可用时使用 Private Link 保护遥测数据引入和查询终结点。将检测连接字符串存储在 Key Vault 中并定期轮换。

安全发布实践强制执行受控的晋级：

• Azure DevOps Environments 或 GitHub Environments 中的审批门要求指定的审查者、通过质量检查和变更工单。为高风险部署自动化暂停窗口。
• 对服务连接和代理应用最小权限原则；按环境将其范围限定在资源组或订阅。使用具有狭窄范围角色的托管标识。
• 在开发、测试和生产环境之间进行环境隔离，使用独立的订阅、VNet、Key Vault 和 ACR；禁止跨环境的横向移动，并在每个环境中使用不同的机密/密钥。

实践问题场景

Fabrikam 公司正在向互联网发布一个多租户 SaaS API。要求：阻止 OWASP Top 10 攻击，按操作验证 OAuth 范围，防止机密出现在存储库中，限制滥用客户端，并确保只有签名的容器镜像能在生产环境中运行。

1. 前端和 WAF

• 部署 Azure Front Door Standard，并配置一个 WAF 策略，该策略在“阻止”模式下使用最新的 OWASP 托管规则集，外加自定义的速率限制规则和地理封锁。理由：集中的全局边缘强制执行可减少攻击面，并在 L7 攻击到达源站之前将其吸收。

2. API 网关策略

• 将 Azure API Management 置于 Front Door 之后；实施 validate-jwt 策略，按操作进行颁发者/受众/范围检查，并使用带有配额的产品级订阅密钥。理由：APIM 提供身份感知强制执行和租户隔离；密钥加 OAuth 提供分层防御和精确的流量限制。

3. 身份和许可

• 在 Entra ID 中注册 SPA 和守护程序应用，为用户流配置委托范围，为守护程序配置应用程序角色；将用户许可限制为已验证的发布者，并要求对应用权限进行管理员同意。为守护程序使用证书凭据。理由：消除了弱机密，强制执行最小权限，并减少了许可钓鱼的风险。

4. 使用 OIDC 的 DevSecOps

• 配置 GitHub Actions，使其通过 OIDC 联合连接到一个 Azure 服务主体，该主体在构建时范围限定于非生产订阅，在发布时范围限定于生产订阅的服务主体，每个主体都具有最小角色（构建时为 AcrPush，发布时为限定于生产资源组的 Contributor）。理由：无需存储机密；每个环境的爆炸半径都最小化。

5. 容器供应链

• 通过 ACR Tasks 构建镜像，生成 SBOM (CycloneDX) 并使用 cosign 签署镜像；将证明存储为 OCI 工件。配置 AKS 准入策略，要求有效的签名。理由：来源和完整性在部署时可验证，从而阻止被篡改的镜像。

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 诊断信息路由到具有最小权限 Reader 访问权限的安全 Log Analytics 工作区。理由：在不暴露敏感数据的情况下保留取证价值；访问是可审计和受限的。

← Microsoft Sentinel 和安全运营 · 所有领域 · 混合云和多云安全 →

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

浏览 Microsoft →