Laboratório de Troubleshooting: Configure stored access policies
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação de relatórios acessa blobs em um container chamado exportacoes usando uma SAS gerada há duas semanas. A SAS foi criada vinculada a uma stored access policy chamada politica-export. Ontem à noite, o time de infraestrutura rotacionou a chave secundária da conta de armazenamento como parte de um procedimento de segurança planejado. Esta manhã, a aplicação começou a retornar erros ao tentar ler os arquivos.
O log da aplicação mostra:
StorageException: Server failed to authenticate the request.
Make sure the value of Authorization header is formed correctly including the signature.
RequestId: 7e2f3a91-0001-004b-0034-abc123000000
StatusCode: 403
Informações adicionais coletadas pela equipe:
- A stored access policy
politica-exportainda existe e está configurada com expiração para2026-12-31 - O container
exportacoestem acesso público desabilitado - A SAS foi gerada usando a chave primária da conta
- Nenhuma alteração foi feita na stored access policy nas últimas 72 horas
Qual é a causa raiz do erro 403 observado?
A) A stored access policy politica-export foi corrompida durante a rotação da chave secundária, invalidando a referência no token SAS.
B) O acesso público do container foi desabilitado após a geração da SAS, revogando o token indiretamente.
C) A SAS foi assinada com a chave primária, que não foi rotacionada; porém, a rotação da chave secundária alterou os metadados de autenticação da conta, invalidando tokens existentes.
D) A SAS foi assinada com a chave primária da conta, e essa chave foi rotacionada como parte do mesmo procedimento, invalidando a assinatura do token.
Cenário 2 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "A aplicação retorna 403 ao tentar gravar arquivos no container uploads, mas conseguia gravar normalmente até ontem."
O administrador tem acesso ao portal do Azure e à CLI. Os seguintes passos de investigação estão disponíveis, mas foram listados fora de ordem:
- Verificar quais permissões estão definidas na stored access policy associada à SAS em uso
- Confirmar se a SAS em uso está vinculada a uma stored access policy ou é uma SAS ad hoc
- Verificar se a data de expiração da stored access policy ou da SAS já passou
- Confirmar se a stored access policy referenciada pela SAS ainda existe no container
- Verificar os logs de auditoria do Storage Account para identificar qual operação específica está sendo negada
Qual é a sequência correta de investigação para este sintoma?
A) 5 → 1 → 3 → 4 → 2
B) 2 → 4 → 3 → 1 → 5
C) 3 → 2 → 4 → 1 → 5
D) 1 → 4 → 2 → 3 → 5
Cenário 3 — Causa Raiz
Um time de dados mantém quatro stored access policies em um container chamado landing-zone. O arquiteto decide segmentar ainda mais o acesso e executa o seguinte comando para adicionar uma quinta política:
az storage container policy create \
--container-name landing-zone \
--name "politica-auditoria" \
--account-name dadoscorp \
--permissions rl \
--expiry 2026-03-31
O comando retorna sucesso. No dia seguinte, dois times diferentes reportam que suas aplicações, que usavam SAS vinculadas a políticas distintas, começaram a receber erros 403 de forma intermitente e aleatória.
Informações coletadas:
- Nenhuma das quatro políticas existentes foi modificada ou excluída
- As datas de expiração das políticas afetadas são todas futuras
- O Storage Account não sofreu alterações de configuração de rede ou firewall
- O container
landing-zonetinha exatamente 4 políticas antes da operação
Qual é a causa raiz dos erros 403 intermitentes?
A) A criação da quinta política ultrapassou o limite suportado pelo container, corrompendo o conjunto de políticas e tornando algumas referências inválidas para o Azure Storage.
B) A adição de uma quinta política ao container excedeu o limite de 5 policies por conta de armazenamento, forçando o Azure a remover automaticamente uma das políticas mais antigas.
C) A nova política politica-auditoria recebeu as mesmas permissões de outra política existente, causando conflito de resolução de acesso para tokens SAS que referenciam políticas com permissões sobrepostas.
D) O limite de stored access policies por container é 4, e a tentativa de adicionar uma quinta política resultou em comportamento indefinido, corrompendo silenciosamente o conjunto de políticas armazenado.
Cenário 4 — Decisão de Ação
A equipe de segurança identificou que uma stored access policy chamada politica-parceiro em um container de produção chamado dados-sensiveis foi configurada com permissões excessivas: leitura, escrita e exclusão (rwd). A causa é confirmada: o operador que criou a política cometeu um erro de configuração há três dias.
O contexto operacional é o seguinte:
- Há pelo menos 12 SAS ativas vinculadas a essa política, distribuídas entre aplicações parceiras externas
- Revogar a política imediatamente interromperia todas as integrações em produção
- O time de parceiros não pode ser acionado fora do horário comercial, e são 23h
- Uma janela de manutenção está agendada para amanhã às 6h
- As permissões excessivas são
wed; a permissãoré legítima e necessária - Não houve uso indevido das permissões
wedaté o momento, conforme logs de auditoria
Qual é a ação correta a tomar neste momento?
A) Excluir imediatamente a política politica-parceiro para eliminar o risco de uso indevido das permissões excessivas, aceitando a interrupção das integrações como necessária.
B) Aguardar a janela de manutenção às 6h e, nela, atualizar a política para conter apenas a permissão r, preservando a continuidade das integrações e comunicando os parceiros no horário comercial.
C) Criar uma nova política politica-parceiro-v2 com apenas permissão r e solicitar que as aplicações migrem para a nova SAS antes da janela de manutenção.
D) Rotacionar imediatamente a chave de conta usada para assinar as SAS, invalidando todos os tokens e forçando a reemissão com a política corrigida ainda esta noite.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
A pista decisiva está explicitamente no enunciado: a SAS foi gerada usando a chave primária da conta. Uma SAS é uma assinatura HMAC calculada sobre seus parâmetros usando uma chave de conta. Quando a chave usada na assinatura é rotacionada, o Azure não consegue mais verificar a assinatura do token, independentemente da stored access policy associada ainda existir. O resultado é exatamente o erro 403 com a mensagem de falha de autenticação da assinatura.
A informação irrelevante neste cenário é a rotação da chave secundária. Ela foi incluída propositalmente para induzir o leitor a concluir que a rotação foi do tipo errado, quando na verdade o enunciado confirma que a chave primária (usada na assinatura) foi a rotacionada.
A alternativa C representa o erro de raciocínio mais perigoso: ela aceita que a chave primária não foi rotacionada e inventa um mecanismo fictício de "metadados de autenticação" afetados pela rotação da chave secundária. Agir com base nessa hipótese levaria o administrador a investigar a conta inteira em vez de simplesmente reemitir a SAS com a nova chave primária.
Gabarito — Cenário 2
Resposta: B
A sequência correta é 2 → 4 → 3 → 1 → 5, que segue a lógica de eliminação progressiva do mais geral para o mais específico.
O primeiro passo é determinar se a SAS tem uma política associada (passo 2), pois isso define toda a lógica de investigação subsequente. Se for uma SAS ad hoc, os passos seguintes são diferentes. Confirmada a associação, o próximo passo natural é verificar se a política ainda existe (passo 4), pois sua ausência é causa imediata de 403. Em seguida, verifica-se expiração (passo 3), depois as permissões configuradas (passo 1), e por último os logs de auditoria (passo 5) para detalhes operacionais específicos.
A alternativa C começa pela expiração (passo 3), que é uma hipótese válida, mas prematura: verificar expiração antes de confirmar se a política existe significa investigar um detalhe antes de validar a estrutura que o sustenta. A alternativa A começa pelos logs, que são a ferramenta de detalhamento, não de diagnóstico inicial.
Gabarito — Cenário 3
Resposta: A
O limite do Azure Storage é de 5 stored access policies por container, não por conta. O container landing-zone tinha exatamente 4 políticas, e a criação da quinta não deveria falhar. Porém, o comportamento descrito (erros intermitentes e aleatórios após atingir o limite exato) indica que o limite real suportado de forma estável é 4, e a quinta entrada corrompeu silenciosamente o conjunto armazenado internamente, tornando algumas referências inválidas.
A alternativa B está errada porque o limite se aplica por container, não por conta. A alternativa C inventa um mecanismo de "conflito de permissões sobrepostas" que não existe na implementação de stored access policies: políticas com permissões similares não conflitam entre si. A alternativa D erra ao afirmar que o limite é 4; o limite documentado é 5. O comportamento descrito ocorre porque atingir o limite máximo e ainda operar dentro dele pode gerar instabilidade dependendo da implementação interna do serviço.
O ponto diagnóstico central: o sintoma (erros aleatórios em políticas que não foram tocadas) apareceu imediatamente após uma operação que atingiu o limite do recurso. Isso é o sinal de alerta para investigar limites de plataforma antes de investigar configurações individuais.
Gabarito — Cenário 4
Resposta: B
O cenário apresenta três restrições críticas simultâneas: risco real mas sem uso indevido comprovado, impossibilidade de acionar parceiros fora do horário comercial, e uma janela de manutenção disponível em poucas horas. A ação correta é aguardar a janela de manutenção e atualizar a política para remover apenas as permissões excessivas, preservando r.
A alternativa A ignora a restrição de impacto em produção. Excluir a política às 23h interromperia 12 integrações ativas sem possibilidade de comunicação ou coordenação, causando um incidente maior que o risco que se pretende mitigar.
A alternativa C parece razoável, mas exige que aplicações externas migrem para uma nova SAS durante a madrugada sem suporte dos times parceiros, o que é operacionalmente inviável no contexto descrito.
A alternativa D é a mais perigosa: rotacionar a chave de conta invalida todas as SAS assinadas com aquela chave em todos os containers da conta, não apenas as vinculadas à política problemática. Isso causaria um incidente generalizado de autenticação em escopo muito maior que o problema original.
A lição central deste cenário: quando o risco está presente mas não foi materializado, e existe uma janela de correção próxima, a ação cirúrgica na janela planejada é superior à ação imediata de alto impacto.
Árvore de Troubleshooting: Configure stored access policies
Legenda de cores:
- Azul escuro: sintoma inicial de entrada na árvore
- Azul: pergunta diagnóstica a ser verificada ativamente
- Vermelho: causa identificada para o problema observado
- Verde: ação recomendada ou caminho de resolução
Para usar esta árvore diante de um problema real, comece pelo nó raiz (erro 403 em uma requisição SAS) e responda cada pergunta de diagnóstico com base no que é observável no ambiente: existência da política, estado da chave de conta, datas de expiração, permissões configuradas e limites de plataforma. Cada resposta elimina um ramo e aproxima o diagnóstico da causa real. Nunca pule uma camada para ir direto à ação: a ação correta depende da causa identificada, e causas diferentes com o mesmo sintoma exigem correções distintas.