Laboratório Técnico: Configure storage account encryption
Questões
Questão 1 — Múltipla Escolha
Uma equipe de segurança exige que todas as chaves de criptografia usadas em contas de armazenamento do Azure sejam rotacionadas manualmente pela organização, sem nenhuma dependência de chaves gerenciadas pela Microsoft. Qual configuração atende a esse requisito?
A. Habilitar infrastructure encryption com chaves gerenciadas pela Microsoft (MMK)
B. Usar customer-managed keys (CMK) armazenadas no Azure Key Vault com rotação manual configurada
C. Ativar blob versioning combinado com chaves gerenciadas pela Microsoft
D. Configurar immutability policies na conta de armazenamento com escopo de criptografia
Questão 2 — Cenário Técnico
Um administrador criou um escopo de criptografia em uma conta de armazenamento com a seguinte configuração:
az storage account encryption-scope create \
--account-name mystorageaccount \
--name myencryptionscope \
--key-source Microsoft.Storage
Posteriormente, a equipe de segurança solicita que esse escopo passe a usar uma chave armazenada no Azure Key Vault. O administrador executa um segundo comando para atualizar o escopo com --key-source Microsoft.KeyVault e a URI da chave.
Após a atualização, o que acontece com os blobs já existentes que foram criptografados com o escopo anterior?
A. Os blobs precisam ser reencriptados manualmente, pois a troca de key source não é retroativa
B. Os blobs são automaticamente reencriptados em segundo plano com a nova chave do Key Vault
C. Os blobs permanecem acessíveis e são reencriptados de forma transparente somente na próxima operação de leitura
D. O Azure bloqueia a atualização do escopo enquanto houver blobs associados a ele
Questão 3 — Verdadeiro ou Falso
Quando infrastructure encryption está habilitada em uma conta de armazenamento do Azure, os dados são criptografados duas vezes em repouso: uma vez na camada de serviço e uma segunda vez na camada de infraestrutura, usando algoritmos e chaves independentes.
- Verdadeiro
- Falso
Questão 4 — Múltipla Escolha
Uma empresa utiliza customer-managed keys (CMK) com o Azure Key Vault para criptografar uma conta de armazenamento. O administrador do Key Vault, sem avisar a equipe de armazenamento, desabilita temporariamente a chave no cofre.
Qual é o comportamento imediato da conta de armazenamento após a chave ser desabilitada?
A. A conta de armazenamento reverte automaticamente para chaves gerenciadas pela Microsoft até a chave ser reabilitada
B. As operações de leitura continuam funcionando, mas operações de escrita são bloqueadas
C. A conta de armazenamento se torna inacessível para leitura e escrita até a chave ser restaurada
D. O Azure gera uma nova versão da chave automaticamente no Key Vault para manter a disponibilidade
Questão 5 — Cenário Técnico
Um desenvolvedor relata que ao fazer upload de blobs para um container específico, os arquivos não estão sendo criptografados com o escopo de criptografia padrão configurado na conta de armazenamento. Ele usa o seguinte comando:
az storage blob upload \
--account-name mystorageaccount \
--container-name mycontainer \
--name myfile.txt \
--file ./myfile.txt
O escopo de criptografia padrão foi definido na conta, mas o container não tem nenhuma configuração de escopo. Qual é a causa mais provável do comportamento relatado?
A. O comando az storage blob upload ignora escopos de criptografia por padrão e usa sempre a chave gerenciada pela Microsoft
B. O escopo de criptografia padrão da conta só se aplica a blobs carregados via portal do Azure, não via CLI
C. O container não herdou o escopo padrão da conta porque a configuração --default-encryption-scope não foi aplicada ao container no momento de sua criação ou atualização
D. O escopo de criptografia padrão da conta é aplicado apenas a novos containers criados após a sua definição, e blobs em containers existentes exigem que o escopo seja especificado explicitamente no upload
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Customer-managed keys (CMK) armazenadas no Azure Key Vault são o mecanismo correto quando a organização precisa controle total sobre o ciclo de vida das chaves, incluindo rotação manual. O administrador define quando e como a chave é rotacionada, sem dependência da Microsoft.
A alternativa A descreve exatamente o oposto do requisito: MMK são gerenciadas pela Microsoft. A alternativa C combina blob versioning com MMK, o que não resolve o requisito de controle de chave. A alternativa D confunde imutabilidade com criptografia, que são controles distintos com finalidades diferentes.
O equívoco central dos distratores é associar "mais segurança" a mais funcionalidades, quando o requisito é especificamente sobre propriedade da chave.
Gabarito — Questão 2
Resposta: B
Quando um escopo de criptografia é atualizado para usar uma nova key source ou nova chave, o Azure reencripta automaticamente em segundo plano todos os dados associados a esse escopo. O processo é transparente e não exige intervenção manual nem causa indisponibilidade.
A alternativa A representa um equívoco comum: assumir que a criptografia no Azure funciona como sistemas on-premises onde a troca de chave exige reprocessamento manual. A alternativa C é plausível mas incorreta: a reencriptação não ocorre somente na leitura, ela é proativa. A alternativa D contradiz o comportamento real do Azure, que permite atualização do escopo mesmo com blobs existentes.
Entender que a reencriptação é automática e assíncrona é essencial para planejar migrações de CMK sem impacto operacional.
Gabarito — Questão 3
Resposta: Verdadeiro
Infrastructure encryption adiciona uma segunda camada de criptografia em repouso, operando abaixo da camada de serviço. As duas camadas usam AES-256, mas com chaves independentes: a camada de serviço usa as chaves configuradas pelo administrador (gerenciadas pela Microsoft ou pelo cliente), enquanto a camada de infraestrutura usa chaves gerenciadas pela Microsoft em nível de plataforma.
Essa configuração é habilitada no momento da criação da conta de armazenamento e não pode ser ativada em contas existentes. O principal risco de marcar como falso é confundir a dupla criptografia com redundância sem valor, quando na prática ela atende requisitos de conformidade que exigem criptografia em múltiplas camadas independentes.
Gabarito — Questão 4
Resposta: C
Quando a chave CMK no Key Vault é desabilitada ou excluída, o Azure Storage perde acesso ao material criptográfico necessário para decriptar as chaves de envelope que protegem os dados. O resultado é bloqueio completo: nem leitura nem escrita funcionam até que a chave seja restaurada e acessível novamente.
A alternativa A representa um comportamento desejável mas inexistente: o Azure não faz fallback automático para MMK, pois isso violaria o modelo de soberania de chave que o CMK se propõe a garantir. A alternativa B é um equívoco que subestima o impacto: leituras também dependem da chave. A alternativa D descreve um comportamento que jamais ocorre, pois o Azure nunca gera chaves no cofre do cliente sem autorização explícita.
Esse cenário reforça a necessidade de políticas de acesso ao Key Vault com monitoramento e alertas adequados quando CMK está em uso.
Gabarito — Questão 5
Resposta: C
O escopo de criptografia padrão definido na conta de armazenamento não é propagado automaticamente para containers existentes. Para que um container use um escopo padrão, ele deve ser explicitamente configurado com --default-encryption-scope durante a criação ou por meio de uma atualização posterior com az storage container set. Sem essa configuração no container, os blobs carregados sem especificar um escopo na operação de upload usam o comportamento padrão da conta, que pode diferir do escopo esperado.
A alternativa A é falsa: a CLI respeita escopos de criptografia normalmente. A alternativa B é falsa: não há distinção de comportamento entre portal e CLI para escopos. A alternativa D é plausível mas incorreta: o escopo padrão da conta se aplica a containers sem configuração própria, exceto quando o container tem sua própria configuração de escopo definida, o que não é o caso descrito.
O erro mais comum aqui é assumir que configurações de conta se propagam automaticamente para todos os recursos filhos, quando na prática containers têm configuração independente de escopo de criptografia.