Laboratório de Troubleshooting: Create and use shared access signature (SAS) tokens
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma aplicação web em produção lê arquivos de um contêiner no Azure Blob Storage usando uma Service SAS gerada programaticamente. A aplicação funcionou corretamente por semanas. Na última segunda-feira às 09h00 (UTC-3), os usuários começaram a relatar erro ao tentar baixar arquivos.
O time de infraestrutura verificou que a conta de armazenamento está ativa, o contêiner existe, os blobs estão presentes e a conectividade de rede não apresenta anomalias. O time de segurança informou que realizou uma rotação de chaves da conta na sexta-feira anterior às 18h00 (UTC-3) como parte do ciclo mensal de governança.
A aplicação registrou o seguinte erro:
StorageErrorCode: AuthenticationFailed
RequestId: 4f2c1a3b-0000-0000-0000-000000000000
StatusCode: 403
ErrorMessage: Server failed to authenticate the request.
Make sure the value of Authorization header is formed correctly
including the signature.
O código de geração do token SAS utiliza a chave da conta recuperada de uma variável de ambiente definida no momento do deploy, sem recarregamento dinâmico.
Qual é a causa raiz do erro de autenticação?
A) O contêiner teve suas permissões de acesso público removidas durante a rotação de chaves, invalidando o acesso via SAS.
B) A assinatura do token SAS foi gerada com a chave antiga e deixou de ser válida após a rotação, pois a variável de ambiente não foi atualizada com a nova chave.
C) O token SAS atingiu seu prazo de expiração natural coincidentemente próximo à rotação de chaves.
D) A rotação de chaves alterou o endpoint da conta de armazenamento, tornando as URLs dos blobs inválidas.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que um token SAS vinculado a uma Stored Access Policy chamada leitura-parceiros foi incluído acidentalmente em um repositório público do GitHub por cerca de 40 minutos antes de ser removido. O token ainda está dentro do prazo de validade. A causa está confirmada: o token foi exposto publicamente.
A conta de armazenamento é compartilhada entre três sistemas em produção, todos ativos neste momento. Dois desses sistemas usam tokens SAS vinculados à mesma política leitura-parceiros. O terceiro sistema usa uma política diferente chamada escrita-interna.
A equipe tem permissão para modificar Stored Access Policies na conta.
Qual é a ação correta a tomar neste momento?
A) Regenerar a chave da conta de armazenamento imediatamente para invalidar todos os tokens SAS ativos.
B) Excluir e recriar a Stored Access Policy leitura-parceiros com um novo identificador, invalidando os tokens vinculados a ela sem afetar o sistema que usa escrita-interna.
C) Aguardar a expiração natural do token exposto, pois ele já foi removido do repositório e o risco de uso indevido é baixo.
D) Alterar o prazo de expiração da Stored Access Policy leitura-parceiros para uma data no passado, invalidando os tokens vinculados.
Cenário 3 — Causa Raiz
Um desenvolvedor criou um script Python para gerar tokens User Delegation SAS para blobs em uma conta de armazenamento. O script autentica via Microsoft Entra ID usando uma service principal com as credenciais corretas. A geração dos tokens funciona sem erros. No entanto, ao tentar usar os tokens gerados para acessar os blobs, a aplicação recebe o seguinte erro:
StorageErrorCode: AuthorizationPermissionMismatch
RequestId: 7a9e4b2c-0000-0000-0000-000000000000
StatusCode: 403
ErrorMessage: This request is not authorized to perform this operation
using this permission.
O desenvolvedor confirmou que:
- A service principal tem a role
Readerna subscription - O token SAS foi gerado com permissão de leitura (
sp=r) - O prazo de validade está correto e dentro do futuro
- A conta de armazenamento não tem firewall habilitado
- O contêiner existe e contém os blobs esperados
Qual é a causa raiz do erro?
A) A service principal não tem uma role RBAC de plano de dados atribuída no escopo da conta de armazenamento ou do contêiner, o que impede a emissão de User Delegation SAS com permissões válidas.
B) A role Reader não permite leitura de blobs via SAS porque é uma role de plano de controle, não de plano de dados.
C) O firewall da conta de armazenamento está bloqueando as requisições, apesar de o desenvolvedor afirmar o contrário.
D) A service principal não pode ser usada para gerar User Delegation SAS; apenas usuários interativos com sessão ativa no Microsoft Entra ID podem solicitar chaves de delegação.
Cenário 4 — Sequência de Diagnóstico
Uma equipe recebe um chamado: uma integração com parceiros externos parou de funcionar. Os parceiros usam uma URL com Service SAS para fazer upload de arquivos para um contêiner. A URL foi gerada há dois dias pela equipe interna e enviada por e-mail aos parceiros.
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar se o token SAS contém a permissão de escrita (
sp=wousp=c) na URL. - Confirmar com os parceiros qual mensagem de erro exata está sendo retornada.
- Verificar a data e hora de expiração do token (
se=) em relação ao horário atual em UTC. - Confirmar se a chave da conta de armazenamento usada para assinar o token foi rotacionada após a geração da URL.
- Verificar se o contêiner de destino ainda existe na conta de armazenamento.
Qual é a sequência correta de investigação para este cenário?
A) 1 → 3 → 5 → 4 → 2
B) 2 → 5 → 3 → 4 → 1
C) 3 → 1 → 4 → 5 → 2
D) 5 → 2 → 1 → 3 → 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois fatos: a variável de ambiente é definida apenas no momento do deploy, sem recarregamento dinâmico, e a rotação de chaves ocorreu após o último deploy. Isso significa que a aplicação continua usando a chave antiga para assinar novos tokens SAS, e a assinatura gerada com uma chave revogada é matematicamente inválida para o Azure Storage, resultando em erro 403 com AuthenticationFailed.
A informação sobre os usuários relatarem o erro na segunda-feira é um detalhe de contexto que não influencia o diagnóstico: o que importa é que a rotação ocorreu antes do início dos erros, sem atualização da variável.
A alternativa A representa um equívoco comum: a rotação de chaves não altera permissões de acesso público do contêiner. São configurações completamente independentes.
A alternativa C é o distrator mais perigoso. A coincidência de tempo entre a rotação e o início dos erros poderia levar ao diagnóstico errado de expiração natural, mas o enunciado não fornece nenhum dado sobre o prazo de validade dos tokens e o padrão de falha é sistemático, não gradual.
A alternativa D é tecnicamente impossível: a rotação de chaves não altera endpoints de armazenamento.
Gabarito — Cenário 2
Resposta: B
O cenário apresenta uma restrição crítica: dois sistemas em produção usam tokens vinculados à política leitura-parceiros, enquanto um terceiro usa escrita-interna. A ação correta é eliminar apenas o vetor de risco sem interromper o terceiro sistema.
Excluir e recriar a Stored Access Policy leitura-parceiros com um novo identificador invalida imediatamente todos os tokens que a referenciam, pois o campo si= no token aponta para um identificador que deixa de existir. O sistema que usa escrita-interna não é afetado.
A alternativa A é o distrator mais perigoso: regenerar a chave da conta invalida todos os tokens SAS de todos os sistemas, incluindo o que usa escrita-interna, causando interrupção desnecessária em produção. Essa ação seria correta apenas se não existisse Stored Access Policy ou se o token fosse assinado diretamente com a chave.
A alternativa C ignora que 40 minutos de exposição pública é tempo suficiente para que o token seja copiado e explorado. Aguardar a expiração não é aceitável diante de uma exposição confirmada.
A alternativa D parece razoável, mas não funciona: alterar apenas o prazo de expiração de uma Stored Access Policy não invalida tokens já emitidos que referenciam aquela política se o identificador da política permanecer o mesmo. A invalidação efetiva exige a exclusão ou substituição da política com novo identificador.
Gabarito — Cenário 3
Resposta: A
A User Delegation SAS é assinada usando uma chave de delegação obtida junto ao Azure Storage. Para que o Storage emita essa chave para uma service principal, ela precisa ter uma role RBAC de plano de dados atribuída no escopo adequado, como Storage Blob Data Reader, Storage Blob Data Contributor ou equivalente. A role Reader é uma role de plano de controle (ARM) e não concede permissões sobre os dados em si.
A pista crítica está no erro AuthorizationPermissionMismatch: o token foi gerado, mas as permissões embutidas nele não são suportadas porque o principal que o emitiu não tem autoridade sobre o plano de dados. O Storage não valida apenas a assinatura, mas também se o principal emissor tinha direito de conceder aquela permissão.
A alternativa B está parcialmente correta ao identificar que Reader é plano de controle, mas erra ao afirmar que isso impede leitura de blobs via SAS. O problema não é a leitura em si, mas a falta de role de plano de dados para emitir a chave de delegação com validade.
A informação sobre o firewall desabilitado e o contêiner existente são detalhes irrelevantes incluídos propositalmente para desviar o diagnóstico para problemas de rede ou de infraestrutura.
A alternativa D é falsa: service principals podem gerar User Delegation SAS normalmente, desde que tenham as permissões RBAC de plano de dados corretas.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 2 → 5 → 3 → 4 → 1.
O diagnóstico deve começar pelo sintoma exato relatado pelo sistema externo (passo 2), pois a mensagem de erro delimita imediatamente o espaço de investigação. A seguir, verifica-se se o recurso de destino existe (passo 5), pois um contêiner deletado tornaria qualquer token inválido independentemente de outros fatores. Depois, examina-se o prazo de expiração (passo 3), que é a causa mais frequente de falha em SAS após o funcionamento inicial. Em seguida, verifica-se se houve rotação de chave após a geração (passo 4), que invalidaria a assinatura. Por fim, confirma-se se as permissões do token cobrem a operação de escrita (passo 1), que seria verificado por último por ser o aspecto mais improvável de ter mudado, já que a URL foi gerada pela equipe interna.
A alternativa A inicia pela inspeção de permissões antes de sequer confirmar o erro, o que é ineficiente. A alternativa C começa pela expiração sem antes confirmar o sintoma exato, arriscando investigar a causa errada. A alternativa D começa pela existência do contêiner sem antes coletar o erro relatado, perdendo a informação mais objetiva disponível.
Árvore de Troubleshooting: Create and use shared access signature (SAS) tokens
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou de estado) |
| Vermelho | Causa identificada |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o tipo de erro recebido. A cada nó de pergunta, responda com base no que é observável diretamente: parâmetros da URL do token, configurações da conta de armazenamento, atribuições de role e estado dos recursos de destino. Avance pelo caminho que corresponde ao estado observado até alcançar um nó de causa identificada. A partir daí, aplique a ação corretiva correspondente antes de reemitir ou reconfigurar o token.