Microsoft AZ-500: Segurança de Aplicações e DevSecOps — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Security Engineer Associate AZ-500 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A Segurança de Aplicações e o DevSecOps no Azure focam em prevenir o uso indevido de identidades, proteger o ingresso (ingress) e as APIs, deslocar a segurança para a esquerda (shift-left) nos pipelines, proteger segredos em repouso e em trânsito, e impor uma governança de lançamento robusta. Designs eficazes eliminam segredos de longa duração, usam o princípio do privilégio mínimo, validam cada chamador e institucionalizam a detecção e remediação contínuas em código, dependências, infraestrutura e tempo de execução (runtime).

Identidade Segura de Aplicação, Ingresso e Proteção de API

A identidade segura de aplicação no Microsoft Entra ID (Azure AD) começa com um registro de aplicativo (app registration) com escopo bem definido e o fluxo OAuth 2.0 correto:

Permissões delegadas se aplicam quando um usuário está conectado e o consentimento pode ser restrito apenas a aplicativos de fornecedores verificados ou a escopos aprovados pelo administrador. Permissões de aplicativo (somente aplicativo) sempre exigem consentimento do administrador porque autorizam daemons ou serviços em segundo plano que agem sem um usuário.
Aplique o princípio do privilégio mínimo concedendo apenas os escopos ou funções de aplicativo (application roles) mínimos necessários e exigindo a revisão do administrador para solicitações de consentimento. Desabilite o consentimento do usuário final ou permita-o apenas para fornecedores verificados e de baixo risco para reduzir o phishing de consentimento.
Prefira credenciais de certificado ou identidades federadas em vez de segredos de cliente (client secrets). Certificados oferecem maior garantia e rotação previsível. Configure tempos de vida curtos e automatize a rotação. Bloqueie fluxos de cliente público, a menos que seja necessário.
Para serviços do Azure, use identidades gerenciadas (managed identities) em vez de segredos de aplicativo. Atribua funções do plano de dados (data-plane), como Key Vault Secrets User ou Storage Blob Data Reader, e restrinja o acesso à rede usando Private Endpoints, quando aplicável.

O Application Gateway WAF v2 e o Azure Front Door WAF protegem o ingresso público contra as ameaças do Top 10 da OWASP:

Habilite o Core Rule Set da OWASP mais recente gerenciado pela Microsoft e execute no modo de Prevenção (Prevention) após o ajuste fino (tuning). Use a pontuação de anomalia (anomaly scoring) inicialmente para reduzir falsos positivos durante o período de aprendizado.
Configure regras personalizadas para geofencing, bloqueios de reputação de IP, imposição de cabeçalhos (header) e limites de tamanho de solicitação. Para o Front Door, adicione regras de limite de taxa (rate-limit) por IP de cliente para mitigar ataques de credential stuffing e DoS básicos da Camada 7 (L7).
Termine o TLS com conjuntos de cifras (cipher suites) e políticas fortes; use TLS de ponta a ponta (end-to-end) até a origem. Para cenários que exigem mTLS, configure a validação de certificado de cliente nos listeners do Application Gateway.
Anexe políticas de WAF a listeners/rotas com precisão; use exclusões de regras somente quando entender completamente o falso positivo. Transmita (stream) os logs do WAF para o Log Analytics para engenharia de detecção e resposta a incidentes.

O API Management (APIM) impõe uma postura de segurança multicamadas:

Valide tokens OAuth no gateway com verificações rigorosas de emissor (issuer), público (audience) e escopo (scope). Exija HTTPS em todos os lugares e imponha mTLS quando o limite de confiança do cliente (client trust boundary) o exigir.
Combine chaves de assinatura (subscription keys) com OAuth para defesa em profundidade (defense-in-depth) e para limitação de taxa (throttling) por identidade. Use chaves de assinatura no nível do produto para particionar os consumidores e rotacionar chaves sem afetar outros.
Aplique limitação de taxa (rate limiting) e cotas com granularidade por consumidor, por escopo ou por assinatura. Use filtragem de IP para adicionar redes de parceiros a uma lista de permissões (allowlist), quando apropriado.
Proteja os serviços de backend usando TLS mútuo ou identidades gerenciadas. Armazene segredos como Valores Nomeados (Named Values) referenciando o Key Vault para evitar texto simples (plaintext) na configuração.

Exemplo de política do APIM para imposição de escopo JWT e limitação de taxa (throttling):

<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>

Fortalecimento (Hardening) do Pipeline de DevSecOps e Defender for DevOps

O Azure DevOps e o GitHub Actions devem se autenticar no Azure sem segredos de longa duração:

Use a federação de identidade de carga de trabalho (workload identity federation) (OIDC) para conexões de serviço (service connections). Crie um registro de aplicativo/entidade de serviço (service principal) no Entra ID e, em seguida, adicione uma credencial federada que vincule o repositório, a branch e o workflow/ambiente à identidade. Isso gera tokens de curta duração sem segredos armazenados e suporta o escopo de privilégio mínimo via Azure RBAC.
Restrinja as permissões do pipeline: exija aprovações para usar conexões de serviço, restrinja o pipeline a branches protegidas e desabilite a opção “Permitir que scripts acessem o token OAuth” a menos que seja necessário. Use grupos de variáveis e segredos com mascaramento; não permita a exibição de segredos (secret echo) por meio de comandos de log. No GitHub, prefira segredos de ambiente e de organização em vez de segredos de repositório para controle centralizado e use as configurações de “prevenir segredos em logs” em executores hospedados (hosted runners), quando aplicável.
Aplique regras de proteção de ambiente: revisores obrigatórios, verificações (ex: tickets de gerenciamento de mudanças, aprovação em testes) e aprovações baseadas em tempo.

Crie uma credencial federada com a Azure CLI (exemplo de OIDC do GitHub):

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"]
  }'

O Microsoft Defender for DevOps se integra com o Azure Repos e o GitHub para expor:

Resultados de segurança de código (SAST) em linguagens comuns; anotações em pull requests destacam novos problemas para prevenir regressões.
Risco de dependência (SCA) usando inteligência de vulnerabilidade para bibliotecas OSS com orientação de remediação e versões corrigidas.
Detecção de exposição de segredos e rotações recomendadas para tokens/chaves vazados.
Configurações incorretas de Infraestrutura como Código (Infrastructure-as-Code) em ARM/Bicep/Terraform (ex: armazenamento público, NSGs permissivos) com governança orientada por políticas e rastreamento de desvios (drift). Os resultados são consolidados no Defender for Cloud com o contexto do repositório e do pipeline para priorização. Bloqueie (gate) os lançamentos com base em limites de severidade para impedir implantações inseguras.

Gerenciamento de Segredos e Integração com a Plataforma

O Key Vault oferece gerenciamento centralizado de segredos, chaves e certificados com controles abrangentes:

Imponha a proteção contra exclusão definitiva (purge protection) e a exclusão reversível (soft delete) para evitar perdas destrutivas. Prefira o RBAC em vez de políticas de acesso para autorização unificada; habilite Private Endpoints e desabilite o acesso à rede pública sempre que possível; habilite o registro de logs em um workspace seguro.
O App Service e o Functions usam referências do Key Vault nas configurações do aplicativo com identidades gerenciadas (managed identities); rotacione segredos de forma transparente, sem necessidade de reimplantar.
O AKS recupera segredos em tempo de execução através do Secrets Store CSI Driver com o provedor do Azure Key Vault, autenticado pelo Azure AD Workload Identity (recomendado). Evite colocar segredos em texto plano (plaintext) em objetos Secret do Kubernetes.

Exemplo de referência do Key Vault no App Service:

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

SecretProviderClass do AKS (abreviado):

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

Os pipelines devem buscar segredos durante a execução do job:

Azure DevOps: tarefa do Key Vault com uma conexão de serviço (service connection) baseada em identidade gerenciada; restrinja o download de segredos ao menor número de estágios possível.
GitHub Actions: azure/login para OIDC e azure/keyvault para buscar apenas os nomes necessários.

SDLC Seguro, Contêineres, Logs e Releases

Práticas de SDLC seguro reduzem o risco antes do deployment:

A modelagem de ameaças (threat modeling) no início do ciclo com STRIDE ou equivalente garante que a autenticação, a autorização e os fluxos de dados sejam explicitamente validados. Atualize os modelos conforme a arquitetura evolui.
O SAST é executado em cada PR; quebre os builds em caso de problemas de alta gravidade com responsabilidade clara. O DAST é executado após o deploy em um slot/ambiente de staging com dados de teste seguros.
O SCA monitora pacotes continuamente; exige versões fixas e conformidade de licença.
Revisão de código rigorosa com políticas de branch (branch policies): revisores obrigatórios, itens de trabalho vinculados, validação de build e commits assinados.

A segurança de imagens de contêiner é fundamental para a integridade da cadeia de suprimentos (supply chain):

Gere e armazene SBOMs (SPDX ou CycloneDX) durante os builds, publique-os junto com as imagens como artefatos OCI para rastreabilidade.
Verifique as imagens antes do push (pre-push) e em repouso (at-rest) nos registros usando a verificação de contêineres do Defender for Cloud; bloqueie a promoção com base em descobertas críticas.
Assine imagens e atestados (attestations) usando artefatos Notary v2/OCI com o cosign. Imponha a verificação de assinatura na admissão (ex: Gatekeeper/OPA ou AKS Policy para Kubernetes).
Controles de registro no Azure Container Registry (ACR): desabilite o usuário administrador, restrinja a rede via Private Endpoints, habilite chaves gerenciadas pelo cliente (customer-managed keys), use tokens com escopo de repositório para acesso refinado e aplique padrões de retenção e quarentena. Conceda apenas a permissão AcrPull para os runtimes e AcrPush para o CI. Para o AKS, anexe o ACR com o comando suportado para criar a atribuição correta em vez da configuração manual de função.
Se os contêineres precisarem usar VNet service endpoints a partir de um host de VM, instale um plugin CNI compatível para que o tráfego de cada contêiner seja originado da sub-rede.

Os logs da aplicação não devem vazar segredos ou PII:

Configure o Application Insights para redigir ou descartar campos sensíveis com Telemetry Processors; evite registrar cabeçalhos (headers), tokens ou payloads brutos que contenham segredos ou PII. Limite os campos de dados à necessidade do negócio e habilite a amostragem (sampling) para reduzir a exposição.
Direcione os diagnósticos para um Log Analytics workspace dedicado com RBAC estrito (privilégio mínimo de Log Analytics Reader) e armazenamento imutável ao exportar para o Storage (travas de retenção baseadas em tempo).
Proteja os endpoints de ingestão e consulta de telemetria com o Private Link, onde disponível. Armazene as strings de conexão de instrumentação no Key Vault e rotacione-as regularmente.

Práticas de release seguro impõem uma promoção controlada:

Gates de aprovação em Azure DevOps Environments ou GitHub Environments exigem revisores designados, aprovação em verificações de qualidade e tickets de mudança. Automatize janelas de contenção (hold-back windows) para deployments de alto risco.
Aplique o princípio do menor privilégio (least privilege) às conexões de serviço e agentes; defina o escopo para grupos de recursos ou assinaturas por ambiente. Use identidades gerenciadas (managed identities) com funções de escopo restrito.
Segregação de ambientes entre Dev, Test e Prod com assinaturas, VNets, Key Vaults e ACRs separados; não permita movimento lateral entre ambientes e use segredos/chaves diferentes em cada ambiente.

Cenário de Problema Prático

A Fabrikam, Inc. está publicando uma API SaaS multitenant na internet. Requisitos: bloquear ataques do Top 10 da OWASP, validar escopos OAuth por operação, impedir segredos em repositórios, limitar (fazer throttling de) clientes abusivos e garantir que apenas imagens de contêiner assinadas sejam executadas em produção.

Front-end e WAF

Faça o deploy do Azure Front Door Standard com uma política de WAF usando o conjunto de regras gerenciado (managed rule set) mais recente da OWASP em modo de Prevenção (Prevention), além de regras personalizadas de limitação de taxa (rate-limit) e bloqueio geográfico (geo blocking). Justificativa: a aplicação centralizada na borda global (edge) reduz a superfície de ataque e absorve ataques L7 antes que cheguem à origem.

Política de API Gateway

Posicione o Azure API Management atrás do Front Door; implemente a política

<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>

com verificações de emissor/público/escopo (issuer/audience/scope) por operação e chaves de inscrição no nível do produto com cotas. Justificativa: o APIM fornece aplicação ciente da identidade e isolamento de tenants; chaves mais OAuth oferecem defesa em camadas e throttling preciso.

Identidade e Consentimento

Registre os aplicativos SPA e daemon no Entra ID com escopos delegados para fluxos de usuário e funções de aplicativo (application roles) para o daemon; restrinja o consentimento do usuário a publishers verificados e exija o consentimento do administrador para permissões de aplicativo. Use credenciais de certificado para o daemon. Justificativa: elimina segredos fracos, impõe o menor privilégio e reduz a exposição a phishing de consentimento.

DevSecOps com OIDC

Configure o GitHub Actions para usar federação OIDC com um service principal do Azure com escopo em uma assinatura de não produção para o build e em um principal com escopo de produção para o release, cada um com funções mínimas (AcrPush para o build, Contributor limitado a um RG de produção para o release). Justificativa: sem segredos armazenados; raio de impacto (blast radius) minimizado por ambiente.

Cadeia de Suprimentos de Contêineres

Construa imagens via ACR Tasks, gere SBOMs (CycloneDX) e assine as imagens com o cosign; armazene os atestados (attestations) como artefatos OCI. Configure a admissão do AKS com uma política para exigir assinaturas válidas. Justificativa: a procedência e a integridade são verificáveis no momento do deploy, bloqueando imagens adulteradas.

Controles de Registro e de Tempo de Execução

Desabilite o usuário administrador do ACR, habilite o Private Endpoint, atribua a permissão AcrPull à identidade do kubelet do AKS através do fluxo

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"]
  }'

suportado e habilite a verificação de imagens do Defender for Cloud. Justificativa: o fortalecimento (hardening) da rede e da identidade remove backdoors padrão; a verificação detecta CVEs conhecidos antes do tempo de execução.

Segredos e Configuração

Use o Key Vault com Private Endpoint e RBAC; o App Service e o Functions consomem referências do Key Vault, e o AKS usa o Secret Store CSI com Workload Identity. Justificativa: os segredos nunca residem em repositórios ou em configurações de aplicativo; a rotação é centralizada e auditável.

Governança de Release

Proteja a branch

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

do GitHub com revisões e verificações obrigatórias; exija aprovações de ambiente e passagem pelos gates de segurança (sem achados críticos de SAST/SCA/IaC) antes do deploy em produção. Justificativa: garante que apenas builds validados e seguros progridam; a supervisão humana permanece para mudanças de alto risco.

Higiene de Observabilidade

Configure o Application Insights para redigir PII com Telemetry Processors personalizados e direcione os diagnósticos do WAF/APIM para um Log Analytics workspace protegido com acesso de Leitor (Reader) de menor privilégio. Justificativa: preserva o valor forense sem expor dados sensíveis; o acesso é auditável e restrito.

← Microsoft Sentinel e Operações de Segurança · Todos os domínios · Segurança Híbrida e Multi-Cloud →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →