Laboratório de Troubleshooting: Configure encryption at host for Azure virtual machines
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador recebe uma solicitação de segurança para habilitar encryption at host em uma VM de produção existente chamada vm-prod-app01, que está na região East US 2 e utiliza o tamanho Standard_D4s_v3. A VM está configurada com dois discos de dados gerenciados e um disco de SO, todos usando SSE com PMK. O Key Vault da assinatura está configurado com soft delete e purge protection habilitados.
O administrador executa o seguinte comando:
az vm update \
--resource-group rg-producao \
--name vm-prod-app01 \
--set securityProfile.encryptionAtHost=true
A saída retornada é:
(BadRequest) EncryptionAtHost is not supported for the VM size Standard_D4s_v3
in this region. Please deallocate the VM and retry with a supported VM size.
Code: BadRequest
O administrador verifica que a feature flag EncryptionAtHost está com status Registered na assinatura e que o provider Microsoft.Compute foi registrado corretamente após o registro da feature. O time de infraestrutura confirma que outra VM na mesma assinatura, com tamanho Standard_E4s_v3, recebeu o encryption at host sem problemas na semana anterior.
Qual é a causa raiz do erro observado?
A) A VM não foi desalocada antes de executar o comando az vm update, o que impede qualquer alteração no perfil de segurança.
B) O tamanho Standard_D4s_v3 não suporta encryption at host na região East US 2, e a causa não está relacionada ao registro da feature nem à configuração do Key Vault.
C) O Key Vault precisa ter uma política de acesso explícita para a identidade gerenciada da VM antes que encryption at host possa ser habilitado.
D) O provider Microsoft.Compute foi registrado, mas a feature flag EncryptionAtHost exige um segundo ciclo de propagação de até 24 horas antes de estar completamente operacional.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que uma VM crítica de banco de dados (vm-sqlprod-01) está operando sem encryption at host habilitado. A causa foi confirmada: a VM nunca teve o recurso habilitado desde sua criação há oito meses. A assinatura já tem a feature flag registrada e o provider atualizado. O tamanho da VM é Standard_M32ms, que consta na lista de SKUs suportados para encryption at host.
O contexto operacional é o seguinte:
| Fator | Detalhe |
|---|---|
| Estado atual da VM | Running |
| Janela de manutenção disponível | Próxima janela em 6 dias |
| Impacto de parada imediata | Interrupção de transações ativas em produção |
| Permissão de desalocação | Requer aprovação do change management |
| Urgência declarada pela segurança | Alta, mas sem prazo de SLA imediato |
Qual é a ação correta a tomar neste momento?
A) Executar az vm update com o parâmetro securityProfile.encryptionAtHost=true imediatamente, pois VMs com disco de SO gerenciado aceitam essa alteração sem desalocação.
B) Desalocar a VM agora sem aprovação formal, pois o risco de segurança declarado como alto justifica contornar o processo de change management.
C) Registrar a necessidade no processo de change management, aguardar aprovação e executar a desalocação e habilitação do encryption at host dentro da janela de manutenção em 6 dias.
D) Habilitar Azure Disk Encryption (ADE) imediatamente como substituto ao encryption at host, pois o ADE pode ser aplicado sem desalocação e cobre o mesmo escopo de proteção.
Cenário 3 — Causa Raiz
Uma VM Windows chamada vm-dev-win01 está configurada com encryption at host habilitado e utiliza um Disk Encryption Set (des-cmk-dev) com chaves gerenciadas pelo cliente armazenadas no Key Vault kv-dev-eastus. A VM foi provisionada há três semanas sem problemas.
Na manhã de hoje, o time de operações relata que não consegue inicializar a VM. O portal do Azure exibe o seguinte status:
Provisioning State: Failed
Status Message: The key vault key used for disk encryption
is currently not accessible. Ensure that the key vault is
not soft-deleted and has not had its access revoked.
O administrador verifica no portal que o Key Vault kv-dev-eastus está visível e ativo. Também confirma que o Disk Encryption Set des-cmk-dev aparece como configurado na VM. Ontem à tarde, um engenheiro de segurança rotacionou as chaves do Key Vault como parte de um processo trimestral de renovação de credenciais. O mesmo engenheiro também desabilitou o acesso de rede público ao Key Vault como medida adicional de hardening, restringindo o acesso apenas via Private Endpoint. O Private Endpoint ainda não foi provisionado.
Qual é a causa raiz da falha ao inicializar a VM?
A) A rotação das chaves no Key Vault invalidou automaticamente a versão anterior da chave referenciada pelo Disk Encryption Set, tornando os discos inacessíveis.
B) O acesso de rede público ao Key Vault foi removido sem que o Private Endpoint estivesse disponível, tornando o Key Vault inacessível pelo plano de controle do Azure Compute.
C) O Disk Encryption Set perdeu sua associação com o Key Vault após a rotação de chaves, exigindo reconfiguração manual da referência de chave.
D) O processo de rotação de chaves corrompeu os metadados de criptografia dos discos gerenciados, exigindo restauração a partir de snapshot.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta: a criação de uma nova VM com encryption at host habilitado está falhando em uma assinatura recentemente provisionada. Ele precisa diagnosticar a causa de forma eficiente.
Os passos de investigação disponíveis são:
- P1: Verificar se o SKU da VM selecionado está na lista de tamanhos que suportam encryption at host na região alvo.
- P2: Executar
az feature show --namespace Microsoft.Compute --name EncryptionAtHostpara verificar o status da feature flag. - P3: Executar
az provider show --namespace Microsoft.Compute --query "registrationState"para verificar o estado do provider após o registro da feature. - P4: Tentar criar a VM novamente com o mesmo parâmetro e capturar a mensagem de erro completa para identificar o código de falha específico.
- P5: Verificar no portal se existe uma Azure Policy atribuída ao escopo da assinatura que nega ou audita a criação de VMs sem encryption at host, pois isso poderia bloquear a operação mesmo com tudo configurado.
Qual sequência de diagnóstico é a mais eficiente e logicamente correta?
A) P4 → P2 → P3 → P1 → P5
B) P2 → P3 → P1 → P4 → P5
C) P1 → P5 → P2 → P4 → P3
D) P5 → P1 → P4 → P2 → P3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro é explícita ao indicar que o tamanho Standard_D4s_v3 não suporta encryption at host na região East US 2. O suporte a encryption at host depende tanto do SKU da VM quanto da disponibilidade regional, e nem todos os tamanhos da família D suportam o recurso em todas as regiões.
A pista confirmatória está na própria saída do comando: o código BadRequest com a descrição EncryptionAtHost is not supported for the VM size Standard_D4s_v3. A informação sobre a VM Standard_E4s_v3 na mesma assinatura reforça que o problema é específico do SKU, não da assinatura nem do ambiente.
A informação sobre o Key Vault com soft delete e purge protection é irrelevante neste cenário. Esses atributos são pré-requisitos para uso de chaves gerenciadas pelo cliente (CMK), mas esta VM está usando PMK, e a falha ocorreu antes de qualquer interação com o Key Vault.
O distrator mais perigoso é o A, que atribui o erro à ausência de desalocação. O erro retornado é BadRequest por incompatibilidade de SKU, não um erro de estado da VM. Agir com base no distrator A faria o administrador desalocar a VM de produção desnecessariamente e ainda assim encontrar o mesmo erro.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é que a desalocação da VM exige aprovação formal de change management e há uma janela de manutenção disponível em 6 dias. A urgência declarada pela segurança é alta, mas sem SLA imediato, o que significa que o risco não justifica contornar controles operacionais estabelecidos.
Habilitar encryption at host em uma VM existente exige desalocação obrigatória. Portanto, qualquer ação que ignore esse requisito resulta em erro, como demonstrado pelo distrator A.
O distrator D representa o erro diagnóstico mais perigoso: ADE e encryption at host não cobrem o mesmo escopo. Habilitar ADE não elimina a lacuna de proteção dos caches de disco no host e não substitui encryption at host. Adotar essa alternativa geraria uma falsa sensação de conformidade sem resolver o problema real.
O distrator B viola o princípio de governança operacional. Mesmo diante de riscos de segurança, contornar o change management em produção sem aprovação pode criar riscos maiores do que o problema que tenta resolver.
Gabarito — Cenário 3
Resposta: B
A causa raiz é o bloqueio de acesso de rede ao Key Vault sem que o Private Endpoint de substituição estivesse provisionado. O plano de controle do Azure Compute precisa acessar o Key Vault para recuperar as chaves de criptografia no momento da inicialização da VM. Sem conectividade de rede com o Key Vault, esse processo falha independentemente de as chaves estarem íntegras.
A pista confirmatória está na sequência de eventos: a falha ocorreu após a mudança de ontem, que incluiu dois eventos simultâneos: rotação de chaves e remoção do acesso público. A rotação de chaves, quando feita corretamente com versionamento no Key Vault e atualização da referência no Disk Encryption Set, não invalida discos existentes. O bloqueio de rede, por outro lado, é imediato e total.
A informação sobre o Disk Encryption Set aparecendo como configurado no portal é irrelevante para o diagnóstico: ela confirma que a associação não foi perdida, o que elimina o distrator C. A visibilidade do Key Vault no portal também é irrelevante, pois o portal acessa o Key Vault via plano de gerenciamento, não pelo mesmo caminho que o Azure Compute usa durante a inicialização da VM.
O distrator mais perigoso é o A. Um administrador que assumir que a rotação de chaves causou o problema pode tentar reverter a rotação ou criar uma nova versão de chave, perdendo tempo enquanto o verdadeiro bloqueio de rede permanece ativo.
Gabarito — Cenário 4
Resposta: A
A sequência correta é P4 → P2 → P3 → P1 → P5.
O primeiro passo deve ser capturar a mensagem de erro completa (P4), pois o código de falha específico direciona toda a investigação subsequente. Sem essa informação, o diagnóstico é cego.
Com o erro em mãos, verifica-se o status da feature flag (P2), pois esse é o pré-requisito mais comum a falhar em assinaturas novas. Em seguida, confirma-se o registro do provider (P3), que é o segundo passo obrigatório frequentemente esquecido. Só depois faz sentido verificar restrições de SKU (P1), pois esse erro tem mensagem própria e distinguível.
P5 (verificação de Azure Policy) é o último passo porque é o menos provável em uma assinatura recém-provisionada, e sua verificação só agrega valor depois que os pré-requisitos básicos foram descartados.
A sequência B parece lógica à primeira vista porque começa pelos pré-requisitos, mas ignora que sem o erro exato (P4), o administrador pode verificar feature flag e provider e concluir erroneamente que tudo está correto, sem identificar que o problema real pode estar no SKU ou em uma policy. Começar pelo sintoma concreto, P4, é a disciplina diagnóstica correta.
Árvore de Troubleshooting: Configure encryption at host for Azure virtual machines
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul médio: pergunta diagnóstica, nó de decisão
- Vermelho: causa identificada que requer correção
- Verde: ação recomendada ou resolução do problema
- Laranja: validação ou verificação intermediária antes de agir
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente, não no que você supõe. Siga o caminho que corresponde ao estado atual do sistema até alcançar um nó vermelho (causa) ou verde (ação). Se o caminho percorrido não corresponder ao sintoma observado, retorne ao último nó de decisão e revise a premissa antes de avançar.