Microsoft AZ-500: Segurança de Computação, Contêiner e Endpoint — 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

Esta seção fornece uma referência operacional para proteger computação, contêineres e endpoints do Azure em IaaS e PaaS. Ela foca em como configurar as proteções, por que elas são importantes e como aplicá-las de forma consistente com os controles nativos do Azure.

Segurança de Computação e Endpoint

As proteções da plataforma de VMs do Azure e as opções de criptografia são fundamentais.

• Secure Boot, vTPM e Trusted Launch: O Trusted Launch reforça a segurança de VMs de Geração 2 ao habilitar o UEFI Secure Boot e um TPM virtual (vTPM). O Secure Boot impede bootloaders/rootkits não assinados. O vTPM fornece um armazenamento resistente a adulterações para chaves (por exemplo, BitLocker) e suporta a inicialização medida (measured boot) para que a plataforma possa atestar a cadeia de inicialização do SO. Operacionalmente, habilite o Trusted Launch no momento da implantação e imponha-o com políticas para garantir que todas as novas VMs obtenham verificações de integridade baseadas em hardware, sem que os administradores precisem lidar com configurações estáticas de BIOS/UEFI.

• VMs Confidenciais: Use séries de VMs confidenciais baseadas em AMD SEV-SNP ou Intel TDX (por exemplo, DCasv5/DCadsv5) para criptografar a memória da VM e fornecer atestado (attestation). Isso protege as cargas de trabalho contra um host/hypervisor mal-intencionado e ataques de canal lateral (side-channel attacks). Operacionalmente, selecione SKUs confidenciais para cenários de dados em uso altamente sensíveis, integre o atestado em seu pipeline de implantação e prefira discos de SO efêmeros quando precisar de reimplantações rápidas sem persistência de dados.

• Opções de Criptografia de Disco:

  • Azure Disk Encryption (ADE): BitLocker (Windows) ou DM-Crypt (Linux) dentro do sistema operacional convidado (guest), com chaves no Key Vault (BEK/KEK). Útil quando você precisa de domínios de criptografia baseados no guest, verificações de conformidade dentro do SO ou para aproveitar o BitLocker vinculado ao vTPM. Requer agente e operações de ciclo de vida para a saúde da extensão.
  • Server-Side Encryption (SSE) com Chaves Gerenciadas pelo Cliente (CMK): Criptografia no nível de armazenamento para discos gerenciados usando chaves no Key Vault ou Managed HSM. Sem agentes no guest, cobertura completa da plataforma (discos, snapshots, imagens), sobrecarga operacional mínima. Padrão recomendado para a maioria dos casos de uso; combine com Trusted Launch ou Confidential VMs para uma defesa em profundidade mais forte.

• Microsoft Defender for Servers:

  • Plano 1: Microsoft Defender for Endpoint (MDE) para EDR/proteção de endpoint em servidores. Escolha este plano quando você já possui ferramentas maduras de gerenciamento de vulnerabilidades e configuração e precisa principalmente de EDR.
  • Plano 2: Adiciona avaliação de vulnerabilidades baseada em agente ou sem agente, acesso just-in-time (JIT) a VMs, controles adaptativos de aplicativos, fortalecimento adaptativo de rede e monitoramento de integridade de arquivos (FIM). Escolha quando desejar uma redução de exposição orientada pela plataforma e governança em ação sem precisar integrar várias ferramentas.
  • Proteção de endpoint: Implante o MDE por meio de extensões de VM ou do Arc para servidores não-Azure para padronizar telemetria, proteção contra adulteração e playbooks de resposta em ambientes híbridos.
  • Avaliação de vulnerabilidades: Use o sinal do MDE Threat & Vulnerability Management ou o scanner integrado (por exemplo, Qualys) para inventariar CVEs, priorizar por explorabilidade e orquestrar a aplicação de patches. Operacionalmente, estabeleça uma linha de base (baseline) primeiro para os servidores críticos expostos à internet; vincule a remediação às janelas de mudança.
  • Monitoramento de Integridade de Arquivos: Rastreie alterações em arquivos/chaves de registro sensíveis para detectar adulterações suspeitas e atender a requisitos de conformidade. Configure caminhos de monitoramento com escopo definido para evitar ruído e encaminhe os alertas para o seu SIEM.

• Redução de exposição com o Defender for Cloud:

  • Acesso Just-in-Time a VMs: Fecha o tráfego de entrada RDP/SSH. Os administradores solicitam acesso por tempo limitado; o Defender abre a regra no NSG ou no Azure Firewall e registra a atividade. O resultado é uma superfície de ataque drasticamente reduzida com exceções auditáveis.
  • Controles Adaptativos de Aplicativos: Aprende os processos normais e cria listas de permissões (allowlists) (AppLocker no Windows, regras de auditoria para Linux). Isso bloqueia binários e scripts não aprovados — particularmente eficaz contra ataques sem arquivo (fileless) ou LOLBin.
  • Fortalecimento Adaptativo de Rede: Usa análise de tráfego e inteligência de ameaças para propor o enrijecimento de regras de NSG. Adote uma cadência de revisar e aplicar para restringir iterativamente a exposição, evitando interrupções.
  • Configuração de Convidado (Guest Configuration): Azure Policy para auditoria/remediação dentro do sistema operacional convidado (Windows e Linux) por meio de um agente ou do Azure Arc. Use-o para impor baselines de SO, políticas de senha e configurações alinhadas ao CIS quando você precisar de um estado de configuração comprovável, e não apenas da postura da plataforma.

Computação PaaS: App Service e Functions

Padrões seguros por padrão reduzem a superfície de ataque de PaaS.

• Azure App Service:

  • Autenticação/Autorização: Habilite a Autenticação do App Service para delegar a autenticação ao Microsoft Entra ID ou a outros provedores. Use o Easy Auth para fluxos padrão OIDC/OAuth2 e, em seguida, imponha o login em todas as rotas para remover a exposição não autenticada.
  • Restrições de Acesso: Permita ou negue tráfego por IP/CIDR, tags de serviço ou tráfego de rede virtual por meio de pontos de extremidade privados. Mantenha regras separadas para o ponto de extremidade scm e o ponto de extremidade do aplicativo para proteger seu plano de implantação de forma independente.
  • Pontos de Extremidade Privados (Private Endpoints): Exponha o aplicativo por meio de um IP privado em sua VNet e, opcionalmente, desabilite o acesso público. Use zonas de DNS privado e restrinja as dependências de saída com a Integração VNet e um firewall de egresso central.
  • Identidades Gerenciadas (Managed Identities): Prefira identidades atribuídas pelo sistema ou pelo usuário para acessar o Key Vault, o Storage e outros serviços. Isso elimina segredos incorporados e permite a atribuição centralizada de funções e a rotação de chaves.

• Azure Functions:

  • Gerenciamento de Chaves: As Functions usam chaves de função, chaves de host e a chave mestra. Rotacione as chaves regularmente e armazene as chaves consumidas externamente no Key Vault, ou substitua as chaves por fluxos OAuth adequados, se viável.
  • Integração de Rede: Use pontos de extremidade privados para acesso de entrada ao aplicativo de Função e a Integração VNet regional para controles de saída. Restrinja a conta de Storage usada pelas Functions apenas a redes selecionadas e adicione o ponto de extremidade privado da Função às redes permitidas.
  • Identidades: Use identidades gerenciadas para autenticação de serviço a serviço em vez de chaves ou strings de conexão. Aplique o princípio do menor privilégio com atribuições RBAC de escopo restrito.
  • Controles de Implantação: Imponha o uso exclusivo de FTPS, desabilite a autenticação básica para o site scm, restrinja os IPs do scm e use o “Run From Package” para garantir implantações imutáveis. Integre o CI/CD com a federação de identidade de carga de trabalho para eliminar segredos de longa duração.

Segurança de Kubernetes e Contêineres

Fortaleça os clusters e as cadeias de suprimentos de ponta a ponta.

• Identidade e autorização do AKS:

  • Integração com o Microsoft Entra: Habilite o AAD gerenciado para o AKS para autenticar o kubectl usando tokens e grupos do Entra. Isso centraliza o ciclo de vida do usuário e o MFA/Acesso Condicional.
  • RBAC do Kubernetes: Mapeie usuários/grupos do Entra para funções (roles) e vínculos de função (role bindings) do Kubernetes para aplicar o princípio do menor privilégio no escopo do namespace.
  • Azure RBAC para Kubernetes: Use funções internas (por exemplo, Azure Kubernetes Service RBAC Viewer/Admin) quando desejar que o Azure RBAC autorize diretamente as ações da API do Kubernetes. Isso unifica a autorização e a auditoria com o plano de controle do Azure.

• Rede e privacidade do AKS:

  • Políticas de Rede (Network policies): Imponha o tráfego de pod para pod e de pod para serviço com o Azure NPM ou o Calico. Negue por padrão e permita explicitamente o egresso necessário; a política como código (policy-as-code) impede o movimento lateral.
  • Clusters Privados: Torne o servidor da API privado, acessível apenas por meio de pontos de extremidade privados. Combine com o Azure Bastion/Private Link e uma estratégia de egresso com firewall (NAT Gateway + UDRs) para manter o plano de gerenciamento fora da internet.

• Segurança do Container Registry (ACR):

  • RBAC: Atribua a função AcrPull a cargas de trabalho que precisam apenas baixar imagens e AcrPush a pipelines de build; evite a função superprivilegiada de Proprietário (Owner). AcrPull e AcrPush estão alinhadas com o princípio do menor privilégio.
  • Confiança e assinatura de conteúdo: Assine imagens com o cosign e imponha a verificação com o controle de admissão (Gatekeeper + Ratify) antes que os pods iniciem. Isso protege contra imagens adulteradas.
  • Verificação de Imagens: Habilite o Microsoft Defender for Cloud para verificar o ACR no push/importação e de forma agendada. Bloqueie a implantação de imagens com CVEs críticos não corrigidos usando políticas de admissão.
  • Padrão de quarentena: Roteie novas imagens para um repositório ou tag em quarentena, execute verificações e checagens de política e, em seguida, promova-as por meio de uma nova marcação após a aprovação.
  • Acesso privado: Desabilite o acesso à rede pública e use pontos de extremidade privados e regras de firewall do registro. Anexe o AKS ao ACR usando uma atribuição de função no nível do recurso em vez de uma função de diretório.

Exemplo rápido para anexar o ACR ao AKS usando a identidade gerenciada do cluster:

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

• Microsoft Defender for Containers: Implanta um sensor de plano de dados no AKS, monitora os logs de auditoria e os sinais de tempo de execução do Kubernetes e os correlaciona com os resultados da verificação de imagens. Ele detecta execuções suspeitas em pods, mineração de criptomoedas, dashboards expostos e operações arriscadas no plano de controle. Habilite o provisionamento automático e conecte os alertas ao seu SIEM/SOAR para triagem.

Governança, Política e Aplicação

O controle consistente exige políticas na implantação e em tempo de execução.

• Azure Policy para computação e discos:
  • Negar a criação de VMs sem trusted launch ou sem SSE com CMK.
  • Impor extensões de VM para proteção de endpoint usando DeployIfNotExists para instalar automaticamente os agentes necessários.
  • Auditar a conformidade da configuração do convidado; remediar desvios de configuração (drift) de forma agendada.

Pequeno trecho de política para implantar uma extensão de VM necessária, caso esteja ausente:

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

• Controles de admissão do Kubernetes:
  • O add-on do Azure Policy para AKS usa o Gatekeeper (OPA) para avaliar as especificações dos pods no momento da admissão. Impor regras como “fazer pull somente do ACR”, “não permitir contêineres privilegiados” e “exigir assinaturas de imagem”.
  • Manter iniciativas separadas para a linha de base (obrigatórias) e reforçadas (para namespaces sensíveis) para permitir o fortalecimento progressivo (progressive hardening).

Pequena restrição (constraint) do Gatekeeper para restringir registros:

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

• Cadência operacional:
  • Detectar: Use as recomendações do Defender for Cloud e os alertas de workload como seus sinais de desvio de configuração (drift) e ameaças.
  • Decidir: Faça a triagem por impacto no negócio e explorabilidade; atribua proprietários por meio de tags.
  • Aplicar: Converta projetos-piloto bem-sucedidos em políticas de negação (deny policies)/restrições de admissão; meça as tentativas bloqueadas para detectar shadow IT.

Cenário de Problema Prático

A Adobe Inc. está migrando um microsserviço de pagamentos para o Azure. Os requisitos de segurança exigem exposição pública zero, apenas imagens assinadas e acesso administrativo com tempo limitado a VMs legadas durante a transição (cutover).

1. Tornar o plano de controle do AKS privado e bloquear o tráfego de saída (egress).

• Justificativa: Um servidor de API do AKS privado remove o plano de gerenciamento da internet. Um NAT Gateway junto com o Azure Firewall com regras de saída explícitas garante que as cargas de trabalho acessem apenas endpoints aprovados (ACR, Key Vault, repositórios de pacotes da Microsoft).

2. Impor o uso de imagens assinadas e restringir os registros.

• Justificativa: Configure o Gatekeeper com restrições (constraints) que permitem apenas imagens de myacr.azurecr.io e exigem assinaturas cosign validadas pelo Ratify. Isso impede que imagens adulteradas ou não confiáveis sejam executadas, mitigando um grande risco na cadeia de suprimentos (supply chain).

3. Proteger o ACR com private endpoints e funções de privilégio mínimo.

• Justificativa: Desabilite o acesso da rede pública e exponha o ACR por meio de um private endpoint na VNet do AKS. Conceda à identidade gerenciada do AKS apenas a função AcrPull; conceda ao pipeline de build a função AcrPush. Isso segue o princípio do privilégio mínimo e elimina a dependência da internet.

4. Habilitar o Defender for Containers e a varredura de imagens do ACR.

• Justificativa: A varredura contínua de imagens no momento do push e a detecção de ameaças em tempo de execução fornecem cobertura em camadas. Os alertas unificam configurações incorretas, vulnerabilidades conhecidas e comportamentos suspeitos para uma resposta rápida.

5. Proteger ferramentas administrativas baseadas no App Service com autenticação e acesso privado.

• Justificativa: Use o App Service Authentication com o Microsoft Entra ID para exigir MFA e Acesso Condicional (Conditional Access). Crie um private endpoint para o aplicativo de administração e restrinja o acesso ao scm separadamente. As identidades gerenciadas (Managed identities) eliminam a necessidade de segredos para o acesso ao Key Vault.

6. Usar o acesso Just-in-Time (JIT) a VMs para hosts legados durante a transição (cutover).

• Justificativa: O JIT fecha as portas RDP/SSH por padrão e as abre apenas mediante solicitações aprovadas por durações limitadas. Isso limita estritamente as janelas de exposição, preservando o acesso de emergência.

7. Padronizar as escolhas de criptografia: SSE com CMK para discos; Trusted Launch para VMs.

• Justificativa: O SSE com CMK minimiza a carga operacional e centraliza o ciclo de vida das chaves no Key Vault, enquanto o Trusted Launch/vTPM adiciona integridade de inicialização (boot) e proteção de chaves. O ADE é reservado apenas para casos em que a evidência de um domínio de criptografia baseado no sistema operacional convidado é contratualmente exigida.

8. Aplicar o Azure Policy e o controle de admissão como barreiras de proteção (guardrails).

• Justificativa: As iniciativas do Azure Policy impõem o uso de trusted launch, extensões de VM obrigatórias e negam o acesso público ao ACR/Function. As restrições (constraints) do Gatekeeper implementam verificações de admissão em tempo de execução para o AKS. Juntos, eles garantem que as configurações permaneçam em conformidade à medida que as equipes iteram.

9. Validar e operar com governança contínua.

• Justificativa: Integre os alertas do Defender for Cloud e do MDE ao SIEM da Adobe, meça o efeito da política (deny vs. audit) e revise as exceções mensalmente. Isso transforma controles pontuais em um modelo operacional de segurança duradouro.

← Arquitetura de Segurança de Rede · Todos os domínios · Segurança de Dados →

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

Navegar Microsoft →