Laboratório de Troubleshooting: Manage Access Keys
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação web hospedada em um Azure App Service consome arquivos de uma storage account do tipo GPv2. A aplicação funciona normalmente há semanas. Na tarde de uma sexta-feira, o time de operações executa uma rotina de manutenção de segurança e, horas depois, a aplicação começa a retornar erros 403 em todas as requisições que tentam ler blobs.
O administrador verifica o App Service e confirma que ele está em execução. Verifica também o firewall da storage account e constata que o IP do App Service está na lista de permissões. O log de diagnóstico da storage account exibe o seguinte:
2026-03-26T18:42:11Z AuthenticationFailed
StorageErrorCode: AuthenticationFailed
AuthenticationType: SharedKey
CallerIP: 20.x.x.x
StatusCode: 403
ErrorMessage: Server failed to authenticate the request.
Make sure the value of Authorization header is formed
correctly including the signature.
A string de conexão da aplicação está armazenada nas Application Settings do App Service e não foi alterada desde a implantação original, há três meses.
Qual é a causa raiz do erro 403 observado?
A) O firewall da storage account está bloqueando o IP do App Service apesar de ele constar na lista.
B) A access key referenciada na string de conexão foi regenerada durante a manutenção, tornando-a inválida.
C) O App Service perdeu conectividade com o endpoint da storage account por instabilidade de rede.
D) A storage account atingiu o limite de requisições por segundo e está retornando erros temporários de throttling.
Cenário 2 — Decisão de Ação
A causa de um incidente foi identificada: a key1 da storage account de produção foi regenerada por engano por um membro do time que confundiu o ambiente de produção com o de homologação. A key2 permanece com o valor original e é desconhecida para a aplicação em produção, que usa apenas a key1 via string de conexão armazenada no Azure Key Vault.
O incidente está ativo. A aplicação está fora do ar há 12 minutos. O time possui as seguintes informações confirmadas:
| Item | Estado |
|---|---|
| key2 (valor original) | Intacta, disponível no portal |
| String de conexão no Key Vault | Referencia key1, desatualizada |
| Permissão para regenerar key1 | Disponível |
| Janela de manutenção | Não está aberta |
| SLA de disponibilidade | 99,9% mensal, já em risco |
Qual é a ação correta a tomar neste momento para restaurar o serviço o mais rápido possível?
A) Regenerar a key1 novamente, atualizar a string de conexão no Key Vault com o novo valor e reiniciar a aplicação.
B) Atualizar a string de conexão no Key Vault para referenciar a key2 e aguardar o reload automático da aplicação.
C) Abrir uma janela de manutenção formal, atualizar a string de conexão no Key Vault para referenciar a key2 e reiniciar a aplicação manualmente.
D) Reverter a regeneração da key1 pelo Azure Monitor Activity Log para restaurar o valor original.
Cenário 3 — Causa Raiz
Um script de automação em Python executa backups noturnos de blobs entre duas storage accounts. O script roda em uma VM e tem funcionado sem falhas por dois meses. Na manhã de uma segunda-feira, o administrador recebe um alerta indicando que o backup de domingo falhou.
Ao examinar o log do script, ele encontra:
[2026-03-23 02:14:33] Starting backup job...
[2026-03-23 02:14:33] Source account: backupsource01
[2026-03-23 02:14:33] Destination account: backupdest01
[2026-03-23 02:14:35] ERROR: azure.core.exceptions.HttpResponseError:
(AuthorizationFailure) This request is not authorized to perform
this operation using this permission.
RequestId: a3f2...
StatusCode: 403
[2026-03-23 02:14:35] Backup job failed after 2 seconds.
O administrador verifica o portal e confirma que:
- A VM está ligada e com conectividade de rede normal
- A storage account
backupsource01tem o firewall desabilitado - A storage account
backupdest01foi migrada para uma nova subscription na sexta-feira anterior - O script usa uma SAS token gerada há 65 dias, com validade original de 60 dias
- A região da VM e das storage accounts não sofreu nenhum incidente reportado
Qual é a causa raiz da falha no backup?
A) A migração da storage account backupdest01 para outra subscription alterou seu endpoint, invalidando as referências no script.
B) A SAS token usada pelo script expirou antes da execução do backup de domingo.
C) O firewall da storage account backupsource01 bloqueou a requisição originada da VM durante a janela noturna.
D) A migração da storage account backupdest01 para outra subscription revogou automaticamente todas as SAS tokens associadas a ela.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um chamado: uma aplicação está falhando ao acessar uma storage account com erros de autenticação intermitentes. Ele tem acesso ao portal do Azure, ao Azure Monitor e ao código da aplicação.
Os passos de investigação disponíveis são:
- Passo P: Verificar no Activity Log se houve operação
listKeysou regeneração de chave recente na storage account - Passo Q: Verificar no código da aplicação qual mecanismo de autenticação está sendo usado (access key, SAS ou Managed Identity)
- Passo R: Confirmar se a opção "Disable storage account key access" está habilitada na storage account
- Passo S: Verificar se a string de conexão ou a chave referenciada na aplicação corresponde ao valor atual da access key no portal
- Passo T: Verificar no log de diagnóstico da storage account o
AuthenticationTypee oStatusCoderetornados nas requisições com falha
Qual é a sequência de diagnóstico mais eficiente, partindo do sintoma para a causa?
A) T, Q, R, P, S
B) Q, T, R, S, P
C) P, S, R, Q, T
D) R, P, T, Q, S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
Explicação:
- O log mostra
AuthenticationType: SharedKeyeAuthenticationFailedcom a mensagem de que a assinatura da requisição está incorreta. Isso indica que a chave usada para assinar a requisição não corresponde à chave armazenada no servidor, o que é o comportamento exato após uma regeneração de chave. - A pista decisiva no enunciado é que a "manutenção de segurança" ocorreu horas antes do início dos erros, e que a string de conexão "não foi alterada desde a implantação original". A chave foi trocada no servidor, mas a aplicação ainda apresenta o valor antigo.
- A informação sobre o firewall e o IP do App Service é deliberadamente irrelevante: erros de firewall resultam em timeouts ou rejeições de conexão TCP, nunca em
AuthenticationFailedcom StatusCode 403 e mensagem de assinatura inválida. - Os distractores A e C representam o erro clássico de focar no elemento visível (firewall, rede) em vez de ler o tipo exato do erro de autenticação. O distrator D é descartável porque erros de throttling retornam StatusCode 503 ou 429, não 403.
- Agir com base no distrator A, tentando ajustar regras de firewall, atrasaria a resolução sem nenhum efeito, prolongando o incidente.
Gabarito — Cenário 2
Resposta: B
Explicação:
- A key2 está intacta e disponível. Atualizar a string de conexão no Key Vault para referenciar a key2 é a ação que restaura o serviço com a menor quantidade de passos e sem depender de nenhuma regeneração adicional.
- A alternativa A é tecnicamente válida em outro contexto, mas exige regenerar a key1, atualizar o Key Vault e reiniciar a aplicação: três passos onde dois já são suficientes com a alternativa B.
- A alternativa C representa uma ação correta aplicada no momento errado. Exigir abertura de janela de manutenção quando o SLA já está em risco e existe uma solução imediata disponível é uma decisão equivocada de governança.
- A alternativa D é o distrator mais perigoso: o Activity Log registra que a operação de regeneração ocorreu, mas não armazena o valor anterior da chave. Não existe mecanismo de reversão de access key no Azure. Agir com base nessa alternativa consumiria tempo crítico de incidente sem resultado possível.
- A pista de que a key2 está "intacta e disponível" é o elemento central do enunciado que deve guiar a decisão.
Gabarito — Cenário 3
Resposta: B
Explicação:
- O enunciado informa explicitamente que a SAS token foi gerada há 65 dias com validade original de 60 dias. Portanto, ela expirou 5 dias antes da execução do backup de domingo. Uma SAS token expirada resulta exatamente no erro
AuthorizationFailurecom StatusCode 403 que o log apresenta. - A migração da
backupdest01para outra subscription é a informação irrelevante inserida propositalmente. Migrações de subscription no Azure não alteram o endpoint da storage account nem invalidam SAS tokens existentes, ao contrário do que o distrator D sugere. - O distrator A é plausível superficialmente, mas incorreto: o endpoint de uma storage account não é alterado por uma mudança de subscription.
- O distrator C é descartável porque o enunciado afirma explicitamente que o firewall da
backupsource01está desabilitado, e o erro ocorre na operação sobre abackupdest01. - O distrator D representa um equívoco técnico real e comum: SAS tokens são derivadas de access keys no momento da geração, mas a migração de subscription não as invalida retroativamente. Acreditar nisso levaria o administrador a regenerar chaves desnecessariamente em vez de simplesmente recriar a SAS token.
Gabarito — Cenário 4
Resposta: B
Explicação:
- A sequência correta é Q, T, R, S, P porque segue a lógica de diagnóstico progressivo: primeiro entender o mecanismo de autenticação em uso (Q), depois observar o que o sistema está retornando para aquele mecanismo (T), em seguida verificar se o acesso por chave está habilitado na storage account (R), comparar o valor referenciado na aplicação com o valor atual (S) e, por último, investigar se houve evento recente que possa ter causado a divergência (P).
- Começar por P (Activity Log) sem saber sequer qual mecanismo de autenticação está em uso é prematuro: o log seria analisado sem contexto suficiente para interpretar os eventos relevantes.
- A alternativa A inverte as prioridades ao começar pela telemetria (T) antes de entender o contexto da aplicação (Q), o que pode levar a interpretações incorretas do log.
- A alternativa C começa pela causa hipotética (P) em vez do sintoma observável, violando o princípio de diagnóstico progressivo.
- A alternativa D começa por R, que só faz sentido depois de confirmar que o mecanismo em uso é SharedKey; verificar essa configuração para uma aplicação que usa Managed Identity seria uma etapa irrelevante.
Árvore de Troubleshooting: Manage Access Keys
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Nó raiz: sintoma ou falha inicial |
| Azul médio | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de um erro 403 em uma storage account, comece pelo nó raiz e leia o AuthenticationType presente no log de diagnóstico para escolher o caminho inicial. Se o tipo for SharedKey, verifique se o acesso por chave está desabilitado antes de comparar valores de chave. Se for SAS, valide a vigência do token. Se for autenticação via Microsoft Entra ID, investigue as atribuições de papel no RBAC. Em cada caminho, percorra as perguntas diagnósticas até alcançar um nó de causa (vermelho), aplique a ação correspondente (verde) e, ao final, valide a recuperação pelo nó laranja antes de encerrar o incidente.