Microsoft AZ-500: Gerenciamento de Chaves, Criptografia e Certificados — 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

O gerenciamento de chaves no Azure se concentra no Azure Key Vault e no Azure Managed HSM. Esses serviços fornecem armazenamento seguro de material criptográfico, APIs consistentes e operações auditáveis que sustentam a criptografia em repouso, em trânsito e na camada de aplicação. O objetivo operacional é separar a custódia das chaves do tempo de execução da aplicação, minimizar o raio de impacto (blast radius) com autorização e rede com escopo definido, e impor a recuperabilidade e a rotação para reduzir o risco de segredos de longa duração.

Arquitetura e Autorização do Azure Key Vault e Managed HSM

Arquitetura do Azure Key Vault

• Composição do serviço: front-ends multilocatários (multi-tenant), partições regionais para o plano de dados, isolamento por locatário (per-tenant) e autenticação baseada no Azure AD. As chaves são protegidas por software (camada Standard) ou por HSM (camada Premium). Segredos e certificados são sempre protegidos por software.
• Camadas: Standard (chaves de software) para uso geral e eficiência de custos; Premium (chaves baseadas em HSM) quando é necessária proteção equivalente a FIPS 140-2 Nível 2/3 ou um limite de HSM dedicado para o material da chave. Escolha a camada Premium para requisitos regulatórios ou ao usar chaves com “RSA-HSM” ou “EC-HSM”.
• Exclusão reversível (soft delete) e proteção contra limpeza (purge protection): A exclusão reversível está sempre ativa com uma retenção configurável (7 a 90 dias, comumente 90). A proteção contra limpeza, quando habilitada, impede a exclusão permanente do cofre ou de objetos até que o período de retenção termine, mesmo por usuários com privilégios elevados. Raciocínio operacional: habilite a proteção contra limpeza em qualquer cofre que suporte chaves gerenciadas pelo cliente (CMK). Sem ela, uma limpeza acidental ou mal-intencionada poderia tornar os dados dependentes (por exemplo, armazenamento ou bancos de dados criptografados com essa chave) irrecuperáveis.
• Recuperação: Objetos excluídos do cofre podem ser listados e recuperados; a recuperação no nível do cofre é suportada. Os backups produzem blobs criptografados que podem ser restaurados em cofres compatíveis na mesma região e nuvem do Azure. Raciocínio: exporte backups de chaves periodicamente e proteja-os separadamente; teste as restaurações para validar o RTO.

Modelo de autorização

• Modelos de permissão: Políticas de acesso do cofre (legado) vs. Azure RBAC (recomendado).
  • Políticas de acesso: definidas por cofre; concedem permissões granulares para chaves, segredos e certificados. Ideal para quando você precisa de direitos de tempo de execução muito restritos e específicos por tipo de objeto para um pequeno conjunto de principais (principals).
  • Azure RBAC: defina o Modelo de Permissão do cofre como Controle de acesso baseado em função do Azure para usar as funções do plano de dados do RBAC. Vantagens: escopo na assinatura/grupo de recursos/cofre; atribuições elegíveis para PIM; governança e auditoria centralizadas. Recomendado para novas implantações e para operações administrativas.
• Funções internas do cofre (exemplos): Key Vault Administrator (gerenciamento completo), Key Vault Crypto Officer (gerenciamento de chaves, mas não de políticas de acesso), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Orientação operacional:
  • Use o RBAC (por exemplo, Key Vault Administrator) ao delegar a configuração de modelos de acesso e ACLs de rede.
  • Use uma política de acesso ou uma função RBAC do plano de dados, como Key Vault Certificates Officer, para inserção/exclusão de certificados com o menor privilégio em um único cofre.
• Design de escopo: Prefira atribuir o RBAC no escopo do cofre para evitar privilégios excessivos. Use o escopo do grupo de recursos somente quando vários cofres compartilharem equipes de operadores idênticas; evite atribuições no escopo da assinatura para acesso em tempo de execução.

Managed HSM

• Arquitetura e domínios de segurança: O Managed HSM é um cluster de HSM validado como FIPS 140-2 Nível 3, de locatário único (single-tenant) por cliente. Um domínio de segurança protege a portabilidade do material de chave do cluster; o backup/restauração entre clusters requer um quórum de chaves privadas do domínio de segurança. Raciocínio: gere e deposite (escrow) as chaves de domínio entre custodiantes distintos; teste a restauração para um HSM de DR.
• Modelo de função: Integrado com o Azure RBAC. As funções incluem Managed HSM Administrator, Crypto Officer, Crypto User e Reader. Separação de responsabilidades: administradores gerenciam o cluster; crypto officers gerenciam as chaves; crypto users usam as chaves para operações.
• Alta disponibilidade: Redundante regionalmente com múltiplas partições de HSM e um serviço com suporte de SLA; a redundância de zona está disponível nas regiões suportadas. Para recuperação de desastres entre regiões, dependa de backups + domínio de segurança.
• Casos de uso: Processamento de pagamentos, assinatura de código (code signing), encapsulamento de chaves (key wrapping) para criptografia de envelope e cargas de trabalho regulamentadas que exigem limites de HSM de Nível 3.

Objetos e Ciclo de Vida: Chaves, Segredos, Certificados e Rotação

Chaves, segredos, certificados

• Chaves: Para operações criptográficas (assinar, verificar, encapsular/desencapsular, criptografar/descriptografar). Escolha o tipo/tamanho da chave com base na força do algoritmo e no desempenho (ex: RSA 3072/4096 para conformidade, ou ECC P-256/P-384 para desempenho).
• Segredos: Bytes/strings arbitrários como senhas, strings de conexão e tokens de API. Não são usados para operações criptográficas.
• Certificados: X.509 com chaves privadas. Armazenados como um objeto de certificado e um segredo correspondente (PFX/PEM). Úteis para ciclos de vida de TLS/MTLS e assinatura de código.

Operações de ciclo de vida e rotação

• Versionamento: Cada definição ou importação gera uma versão imutável. As aplicações devem referenciar segredos versionados para comportamento determinístico ou URIs sem versão para obter automaticamente a versão mais recente, dependendo das necessidades de gerenciamento de mudanças.
• Estratégias de rotação:
  • Chaves: Prefira URIs de chave sem versão para serviços do Azure que os suportam (ex: Storage, SQL TDE, segredos gerenciados pelo AKV). Rotacione adicionando uma nova versão; os serviços se reconectam automaticamente quando suportado. Se um serviço exigir uma versão fixa (pinned), automatize uma etapa de reconfiguração. Imponha a rotação com políticas de rotação do AKV e alertas.
  • Segredos: Rotacione via Azure Automation, Functions ou Logic Apps acionados por notificações do Event Grid, ou use a rotação nativa do provedor (ex: rotação de SAS ou senhas de banco de dados). Evite segredos estáticos de longa duração, substituindo-os por identidades gerenciadas sempre que possível.
  • Certificados: Defina políticas de certificado com “ações de tempo de vida” (lifetime actions) para renovação automática antes da expiração; use emissores integrados para renovação sem intervenção manual.

Gerenciamento de certificados

• Importação/geração: Importe PFX/PEM existentes (com chave privada) ou gere um CSR e faça com que o Key Vault conclua a emissão com uma CA configurada.
• Renovação automática e emissores: Configure emissores como DigiCert, GlobalSign ou uma CA corporativa da Microsoft via Key Vault. Habilite a renovação automática com limites de notificação e renovação.
• Integração de aplicações:
  • App Service e Functions: use referências do Key Vault com identidade gerenciada; a plataforma sincroniza automaticamente os segredos rotacionados.
  • Application Gateway/WAF: referencie o ID do segredo do certificado do Key Vault; o Gateway obtém novas versões automaticamente.
  • AKS: monte certificados via driver CSI do Secrets Store e provedor do Azure Key Vault.

Exemplo de atribuição de RBAC para operações de certificado com privilégio mínimo:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Segurança de Rede e Integração de Serviços

Rede do Key Vault

• Regras de firewall: Defina como ‘Redes selecionadas’ (Selected networks) para restringir a fontes aprovadas. Justificativa: impede o tráfego originado da internet, mesmo com tokens válidos.
• Endpoints de serviço de rede virtual: Permitem tráfego de sub-redes específicas sem IPs privados. Simples de habilitar e reduz a exposição. Use quando precisar de isolamento rápido e não exigir alterações de DNS.
• Endpoints privados: Atribua um IP privado ao cofre em sua VNet para conectividade verdadeiramente privada. Bloqueie o acesso da rede pública. Justificativa: controle de exfiltração mais forte, exigido em ambientes de alta confiança e quando a saída para a internet é restrita.
• Serviços confiáveis: A opção “Permitir que serviços confiáveis da Microsoft…” (Allow trusted Microsoft services) permite que serviços específicos do Azure acessem o cofre apesar das restrições de rede. Necessário para cenários como a verificação de chaves de criptografia do Storage durante a rotação. Habilite de forma restrita e documente as dependências.

Chaves gerenciadas pelo cliente (CMK) e URIs de chave

• Serviços suportados: Azure Storage, SQL Database (TDE), Synapse, Databricks, criptografia de segredos em repouso do AKS, App Configuration, Event Hubs, Service Bus e Managed Disks via Disk Encryption Set.
• Estratégia de URI de chave:
  • URIs sem versão: Prefira quando o serviço suporta reconexão automática a novas versões da chave; permite rotação transparente sem atualizações no serviço.
  • URIs com versão: Exigidos por alguns serviços; automatize uma atualização da configuração do serviço vinculada a eventos de rotação.
• Padrões de rotação:
  • Rotação escalonada: Crie uma nova versão da chave; valide se o serviço consegue acessá-la; monitore erros; depois, opcionalmente, desabilite as versões mais antigas após um período seguro.
  • Orientada a eventos: Use o Event Grid em eventos de nova versão de chave para acionar fluxos de trabalho de validação ou reconfiguração de serviço.

Integração de criptografia de envelope

• Os serviços do Azure usam uma chave de criptografia de dados (DEK) localmente (ex: AES-256) e uma chave de criptografia de chave (KEK) no Key Vault/HSM para encapsular a DEK. Operacionalmente, garanta a disponibilidade da KEK e o acesso à rede, pois a perda ou o bloqueio do acesso pode paralisar as operações do serviço.

Exemplo: encapsular uma DEK com uma chave do AKV

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Criptografia, Opções para Dados em Repouso e Higiene de Segredos

Conceitos essenciais de criptografia

• Criptografia simétrica: Uma única chave usada para criptografar/descriptografar (ex: AES-GCM/CTR). Rápida; ideal para grandes volumes de dados.
• Criptografia assimétrica: Pares de chaves pública/privada (RSA/ECC) usados para troca de chaves e assinaturas. Mais lenta; ideal para estabelecer confiança e encapsular (wrapping) DEKs.
• Hashing: Digest de mão única (ex: SHA-256). Para integridade; não é criptografia.
• Assinatura: A chave privada produz a assinatura; a chave pública a verifica. Não repúdio e integridade.
• Criptografia de envelope: Combina uma KEK assimétrica com uma DEK simétrica para desempenho e isolamento da custódia da chave.

Azure Disk Encryption e criptografia de armazenamento

• Criptografia padrão de Managed Disks: Criptografia no lado do servidor (SSE) com chaves gerenciadas pela plataforma (PMK). Sobrecarga operacional mínima.
• CMK com Disk Encryption Set (DES): Use um DES que referencie uma chave do Key Vault ou Managed HSM para discos, snapshots e imagens. Justificativa: controle centralizado do ciclo de vida e revogação da chave; atende à conformidade para controle do cliente.
• ADE (Azure Disk Encryption): BitLocker (Windows) ou dm-crypt (Linux) dentro do sistema operacional convidado (in-guest). Use quando precisar de uma postura de criptografia no nível do SO, protetores de chave no nível do disco vinculados ao domínio ou mandatos de conformidade existentes. Contrapartida operacional: maior complexidade, gerenciamento de extensões e potencial impacto no provisionamento da VM.
• Criptografia dupla:
  • Discos: Combine SSE com PMK na camada de infraestrutura mais CMK via DES para obter duas camadas de criptografia independentes.
  • Contas de armazenamento: Use escopos de criptografia com CMKs separadas por contêiner/carga de trabalho; combine com a criptografia de infraestrutura onde disponível para obter duas camadas.
• Escopos de criptografia (Azure Storage): Defina escopos por contêiner ou por blob com CMKs distintas para isolar o risco do locatário/carga de trabalho e permitir a rotação direcionada sem um impacto amplo.

Higiene de segredos e práticas operacionais

• Identidades gerenciadas: Use identidades gerenciadas atribuídas pelo sistema ou pelo usuário para recursos do Azure para obter tokens para o Key Vault e outros serviços, eliminando credenciais incorporadas (embedded). Defina escopos restritos para o RBAC ou políticas de acesso.
• Verificação de segredos (Secret scanning): Habilite o Microsoft Defender for DevOps, a verificação de segredos do GitHub Advanced Security e as proteções de repositório. Integre com pull requests para bloquear padrões de credenciais conhecidos.
• Pipelines e IaC: Use integrações de tarefas do Key Vault no Azure Pipelines e credenciais federadas baseadas em OIDC do GitHub Actions para evitar segredos persistidos. Não imprima segredos em logs; mascare as saídas. Rotacione qualquer material vazado imediatamente.
• Design de aplicativos: Prefira referências sem versão onde for seguro; faça cache minimamente e trate erros 401/403 readquirindo tokens e buscando novamente os segredos para dar suporte a eventos de rotação.

Aprofundamento em Gerenciamento de Certificados

• Emissão orientada por políticas: Defina o assunto, SANs, uso da chave, EKUs, tipo/tamanho da chave e configurações de reutilização de chave em uma política de certificado do Key Vault. Justificativa: postura TLS consistente em todos os ambientes.
• Integração com emissores: Configure um perfil de CA no Key Vault. Para PKI privada, integre com o Microsoft ADCS através de um emissor personalizado ou use o Certificate Connector do Azure Key Vault. CAs públicas permitem renovação automatizada sem expor chaves privadas fora do AKV.
• Operações de renovação automática: Use ações de ciclo de vida (ex: renovar 60 dias antes da expiração; notificar com 90 dias de antecedência). Operacionalmente, alinhe as janelas de renovação com os congelamentos de mudanças (change freezes) e garanta que os serviços dependentes se sincronizem automaticamente.
• Consumo pela aplicação: Recupere como um segredo (PFX/PEM) ou vincule por referência em serviços da plataforma. Prefira vinculações nativas da plataforma (App Service, Application Gateway) para uma transição (rollover) sem tempo de inatividade para novas versões. Para o Kubernetes, monte via CSI para acionar reinicializações contínuas (rolling restarts) na rotação.

Cenário de Problema Prático

A Siemens AG precisa proteger a telemetria de IoT no Azure, impor uma custódia de chaves robusta para dados em repouso e automatizar a rotação de certificados e segredos em uma frota distribuída globalmente.

1. Estabelecer limites de cofres e HSMs

• Criar Key Vaults Premium regionais para segredos/certificados de aplicação e um Managed HSM para operações de KEK.
• Justificativa: Cofres Premium permitem chaves respaldadas por HSM quando necessário; o Managed HSM fornece garantia de Nível 3 e custódia de chaves independente para operações de empacotamento (wrapping).

2. Impor recuperabilidade e barreiras de proteção (guardrails)

• Habilitar a proteção contra exclusão definitiva (purge protection) em todos os cofres e no Managed HSM; definir a retenção de exclusão reversível (soft-delete) para 90 dias. Aplicar o Azure Policy para auditar/negar cofres sem proteção contra exclusão definitiva.
• Justificativa: Previne a perda catastrófica de dados por exclusões definitivas; a política garante que desvios de configuração (drift) não ocorram.

3. Centralizar a autorização usando RBAC

• Definir os cofres para o modelo de permissão do Azure RBAC. Atribuir a função Key Vault Administrator a uma pequena equipe de plataforma via PIM; atribuir Key Vault Secrets Officer às equipes de aplicação no escopo do cofre; atribuir Managed HSM Crypto Officer aos engenheiros de segurança.
• Justificativa: RBAC + PIM resulta em privilégio mínimo, elevação com limite de tempo e auditoria consistente. A separação de funções impede que administradores usem as chaves.

4. Bloquear o acesso à rede com private endpoints

• Criar private endpoints em VNets hub; desabilitar o acesso à rede pública. Habilitar “serviços confiáveis” (trusted services) apenas para contas de Storage que usam CMK.
• Justificativa: Private endpoints eliminam a exposição pública e bloqueiam caminhos de exfiltração de dados, preservando os fluxos necessários entre serviços e o cofre.

5. Implementar CMK e estratégia de criptografia

• Para o Storage, definir escopos de criptografia (encryption scopes) por carga de trabalho com URIs de KEK sem versão no cofre Premium; para Managed Disks, usar Disk Encryption Sets com CMK do HSM. Habilitar a criptografia no nível da infraestrutura para criptografia dupla.
• Justificativa: Chaves por carga de trabalho reduzem o raio de impacto (blast radius); URIs sem versão permitem rotação transparente; a criptografia dupla atende a requisitos de conformidade rigorosos.

6. Automatizar a rotação de chaves e segredos

• Configurar políticas de rotação de chaves do AKV (ex: expiração anual, rotacionar com 9 meses) e notificações do Event Grid que acionam trabalhos de validação. Usar identidades gerenciadas (managed identities) nos serviços; remover credenciais estáticas.
• Justificativa: A rotação previsível e automatizada reduz o risco de chaves e segredos de longa duração; identidades gerenciadas substituem segredos compartilhados frágeis.

7. Operacionalizar certificados

• Usar políticas de certificado do Key Vault com integração do emissor DigiCert; definir a renovação automática para 60 dias antes da expiração. Vincular certificados por referência no Application Gateway e no App Service.
• Justificativa: A renovação automatizada previne interrupções e evita o manuseio manual de chaves; as vinculações da plataforma captam novas versões sem a necessidade de reimplantar.

8. Validar e monitorar

• Habilitar logs de diagnóstico do Key Vault e do Managed HSM para o Log Analytics; alertar sobre tentativas não autorizadas, negações de firewall e eventos de proximidade da expiração. Executar testes de restauração trimestrais para backups de cofres e HSM usando o quórum do domínio de segurança.
• Justificativa: O monitoramento contínuo detecta configurações incorretas ou ataques prontamente; o teste de restauração garante a recuperabilidade sob pressão.

← Segurança de Dados · Todos os domínios · Gerenciamento da Postura de Segurança e Governança →

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

Navegar Microsoft →