Laboratório de Troubleshooting: Configure storage account encryption
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que uma conta de armazenamento crítica parou de responder a qualquer operação de leitura e escrita há aproximadamente 40 minutos. Nenhuma alteração de rede ou firewall foi feita na conta. A conta usa customer-managed keys (CMK) com o Azure Key Vault há seis meses sem problemas.
O administrador executa uma verificação e obtém a seguinte saída:
az storage account show \
--name prodstorageacct01 \
--query "encryption" \
--output json
{
"keySource": "Microsoft.Keyvault",
"keyVaultProperties": {
"keyName": "storage-cmk-key",
"keyVaultUri": "https://prodkv01.vault.azure.net/",
"keyVersion": "a3f1c2e4d5b6...",
"currentVersionedKeyExpirationTimestamp": "2025-03-15T00:00:00Z",
"lastKeyRotationTimestamp": "2024-09-15T10:22:00Z"
}
}
O administrador também verifica que:
- O Azure Key Vault está na mesma região da conta de armazenamento
- O firewall do Key Vault permite acesso de serviços confiáveis da Microsoft
- A conta de armazenamento tem redundância ZRS configurada
- O soft-delete do Key Vault está habilitado com período de retenção de 90 dias
Qual é a causa raiz da falha observada?
A. O firewall do Key Vault está bloqueando o acesso da conta de armazenamento por uma mudança de configuração não documentada
B. A chave CMK expirou, pois o campo currentVersionedKeyExpirationTimestamp indica uma data no passado
C. A redundância ZRS entrou em conflito com a configuração de CMK durante uma falha zonal, causando perda temporária de acesso
D. O soft-delete do Key Vault foi ativado com um período de retenção incompatível com a política de rotação de chave
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que uma conta de armazenamento de produção está configurada para usar customer-managed keys (CMK), mas a identidade gerenciada atribuída ao sistema da conta perdeu a permissão get na política de acesso do Key Vault após uma reorganização de permissões realizada ontem.
A causa foi confirmada: a role assignment da identidade gerenciada no Key Vault foi removida por engano. Os dados da conta de armazenamento estão inacessíveis e o impacto em produção é ativo. O Key Vault utiliza o modelo de Azure RBAC para controle de acesso, não políticas de acesso legadas.
As seguintes restrições se aplicam:
- A equipe de segurança ainda está auditando todas as permissões modificadas ontem e solicita que nenhuma nova permissão seja atribuída sem aprovação formal
- O administrador de armazenamento tem permissão de Contributor na conta de armazenamento
- O incidente está classificado como P1 com SLA de restauração de 2 horas
- O administrador tem acesso de Key Vault Administrator no Key Vault afetado
Qual é a ação correta a tomar neste momento?
A. Atribuir imediatamente a role Key Vault Crypto Service Encryption User à identidade gerenciada da conta de armazenamento no Key Vault, sem aguardar aprovação, dado o impacto ativo em produção
B. Alterar a configuração de criptografia da conta de armazenamento para chaves gerenciadas pela Microsoft (MMK) temporariamente, restaurando o acesso enquanto aguarda a aprovação formal
C. Abrir o processo de aprovação formal com a equipe de segurança, documentando a causa raiz e a role específica a ser restaurada, e aguardar a aprovação antes de qualquer atribuição de permissão
D. Criar uma nova identidade gerenciada atribuída pelo usuário com a permissão correta no Key Vault e reatribuí-la à conta de armazenamento para contornar a restrição de aprovação
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que blobs carregados para o container raw-data em uma conta de armazenamento não estão sendo criptografados com o escopo de criptografia scope-raw, que deveria ser o padrão para esse container. Os blobs aparecem criptografados, mas quando verificados, usam o escopo padrão da conta (scope-account-default).
O administrador verifica o estado atual com os seguintes comandos:
az storage account show \
--name analytics01 \
--query "encryption.defaultToOAuthAuthentication"
true
az storage container show \
--account-name analytics01 \
--name raw-data \
--query "{defaultScope:encryptionScope,preventOverride:denyEncryptionScopeOverride}"
{
"defaultScope": "scope-raw",
"preventOverride": false
}
O administrador também confirma que:
- O escopo
scope-rawexiste e está habilitado na conta - A conta de armazenamento tem blob versioning ativado
- O container foi criado há 3 semanas
- Os uploads são feitos via SDK com autenticação OAuth e sem especificar escopo explícito
Qual é a causa raiz do comportamento observado?
A. O blob versioning ativo interfere com a aplicação de escopos de criptografia por container, forçando o uso do escopo padrão da conta
B. O campo preventOverride está definido como false, permitindo que o SDK sobrescreva o escopo do container com o escopo padrão da conta durante o upload
C. A autenticação OAuth (defaultToOAuthAuthentication: true) impede que o escopo de criptografia do container seja aplicado corretamente quando o escopo não é especificado explicitamente na operação
D. O SDK está especificando explicitamente o escopo scope-account-default durante o upload, sobrescrevendo a configuração do container, pois preventOverride está como false
Cenário 4 — Impacto Colateral
Uma empresa mantém uma conta de armazenamento com customer-managed keys (CMK) usando uma chave no Azure Key Vault. Para atender a um novo requisito de conformidade, o administrador decide habilitar infrastructure encryption na conta de armazenamento existente.
O administrador acessa o portal do Azure, navega até a seção de criptografia da conta de armazenamento e constata que a opção de infrastructure encryption está desabilitada e acinzentada, sem possibilidade de edição. Sem investigar mais, ele decide recriar a conta de armazenamento com a opção habilitada e migrar os dados via AzCopy.
A recriação e migração são concluídas com sucesso. A nova conta tem infrastructure encryption habilitada e CMK configurado corretamente.
Qual consequência secundária essa ação pode causar?
A. Os dados migrados via AzCopy perdem a associação com o escopo de criptografia original, sendo reencriptados com o escopo padrão da nova conta
B. Todas as shared access signatures (SAS) geradas com base na conta original e ainda dentro do prazo de validade deixam de funcionar imediatamente
C. A nova conta de armazenamento não consegue usar CMK se infrastructure encryption estiver habilitada, pois as duas configurações são mutuamente exclusivas
D. O AzCopy recria os blobs com novos timestamps de criação e modificação, o que pode afetar sistemas dependentes de metadados temporais dos objetos
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está no campo currentVersionedKeyExpirationTimestamp, que exibe o valor 2025-03-15T00:00:00Z. Considerando que o laboratório se situa em março de 2025 e a falha ocorreu aproximadamente 40 minutos antes da verificação, essa data indica que a chave expirou recentemente. Quando uma chave CMK expira no Key Vault, o Azure Storage perde a capacidade de decriptar as chaves de envelope, bloqueando completamente leitura e escrita.
A informação sobre o firewall do Key Vault permitir serviços confiáveis da Microsoft é propositalmente irrelevante: esse detalhe descreve uma configuração correta que não tem relação com o sintoma. O objetivo de incluí-la é induzir o leitor a investigar conectividade quando o problema está no ciclo de vida da chave.
A redundância ZRS não tem nenhuma interação com CMK e não causa bloqueio de acesso. O soft-delete também não interfere na acessibilidade de chaves ativas; ele protege contra exclusão acidental, não afeta expiração.
O distrator mais perigoso é A: o administrador poderia gastar tempo investigando regras de firewall do Key Vault enquanto o real problema, a chave expirada, permanece sem correção, prolongando o impacto em produção.
Gabarito — Cenário 2
Resposta: C
A restrição crítica do cenário é explícita: a equipe de segurança está em auditoria ativa e solicitou formalmente que nenhuma nova permissão seja atribuída sem aprovação. Essa restrição não pode ser contornada mesmo diante de um P1, pois fazê-lo criaria um risco de segurança adicional durante um momento de revisão de permissões comprometidas.
A ação correta é iniciar imediatamente o processo de aprovação formal, documentando com precisão a role a ser restaurada (Key Vault Crypto Service Encryption User) e a identidade gerenciada afetada, para que a equipe de segurança possa aprovar com agilidade dentro do SLA de 2 horas.
A alternativa A é tecnicamente correta quanto à role, mas viola a restrição de processo estabelecida pela equipe de segurança. A alternativa B parece pragmática, mas alterar a configuração de criptografia de uma conta de produção de CMK para MMK é uma operação de alto risco que pode causar janela de inacessibilidade durante a transição e também exigiria aprovação em um ambiente com controles formais. A alternativa D contorna a restrição de forma ainda mais grave, criando uma nova identidade com permissões não auditadas.
O distrator mais perigoso é A: um administrador sob pressão de P1 poderia justificar a atribuição direta como resposta a incidente, mas isso contradiz diretamente a restrição estabelecida e potencialmente agrava a situação de auditoria.
Gabarito — Cenário 3
Resposta: D
O container raw-data está corretamente configurado: defaultScope aponta para scope-raw e a verificação confirma que o escopo existe e está habilitado. O problema está em preventOverride: false. Com essa configuração, qualquer cliente, incluindo o SDK, pode sobrescrever o escopo definido no container durante o upload.
O comportamento observado, blobs sendo gravados com scope-account-default em vez de scope-raw, é consistente com o SDK omitindo o escopo explícito e o Azure aplicando o escopo padrão da conta no lugar do escopo do container, porque preventOverride não está aplicando a restrição necessária.
O defaultToOAuthAuthentication é a informação irrelevante inserida propositalmente. Ele controla o método de autenticação padrão para requisições anônimas via portal e ferramentas, mas não interfere na lógica de aplicação de escopos de criptografia.
O blob versioning também é irrelevante para o comportamento de escopos de criptografia.
O distrator mais perigoso é B: o leitor poderia interpretar preventOverride: false como a causa de forma correta, mas atribuir a sobrescrita ao SDK agindo por conta própria em vez de entender que o SDK está especificando explicitamente o escopo padrão da conta, que tem precedência quando preventOverride não bloqueia a substituição.
Gabarito — Cenário 4
Resposta: B
Quando uma conta de armazenamento é recriada com um novo nome ou nova instância, todas as shared access signatures (SAS) que foram geradas com base na conta original são invalidadas imediatamente, mesmo que ainda estejam dentro do prazo de validade configurado. SAS tokens são derivados das chaves de conta ou de uma user delegation key vinculada à identidade e à conta específica. Ao recriar a conta, esses vínculos se rompem.
A alternativa A é incorreta: o AzCopy transfere os dados com os escopos de criptografia definidos no destino. Os escopos da nova conta são aplicados corretamente conforme configuração.
A alternativa C é falsa: infrastructure encryption e CMK são compatíveis e frequentemente usados juntos para atender a requisitos de conformidade mais rigorosos.
A alternativa D descreve um comportamento real do AzCopy em relação a timestamps, mas o impacto é geralmente aceito em migrações e não constitui uma consequência crítica de segurança ou disponibilidade comparável à invalidação de SAS.
O ponto mais importante deste cenário é que a recriação de uma conta de armazenamento não é uma operação transparente para os consumidores da conta: qualquer SAS em circulação, links de acesso temporário ou integrações baseadas na identidade da conta original precisam ser reavaliados antes da migração.
Árvore de Troubleshooting: Configure storage account encryption
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o sintoma é de inacessibilidade completa ou de escopo de criptografia incorreto. Siga as perguntas de diagnóstico respondendo sim ou não com base no que é observável diretamente: estado da chave no Key Vault, permissões da identidade gerenciada, configuração do container. Cada caminho leva a uma causa nomeada com a ação correspondente, evitando investigações em paralelo que consomem tempo sem critério.