Laboratório Técnico: Create and use shared access signature (SAS) tokens
Questões
Questão 1 — Múltipla Escolha
Você precisa conceder acesso temporário a um único blob em uma conta de armazenamento para um parceiro externo. O acesso deve expirar em 24 horas, ser limitado apenas à operação de leitura e não exigir que o parceiro tenha uma conta no Microsoft Entra ID.
Qual tipo de SAS atende a esses requisitos com o menor escopo de privilégio possível?
A) Account SAS, pois permite definir permissões por serviço e por recurso individualmente.
B) Service SAS sem política de acesso armazenada, pois é emitida diretamente para um recurso específico dentro de um serviço.
C) User Delegation SAS, pois utiliza credenciais do Microsoft Entra ID para assinar o token.
D) Service SAS com política de acesso armazenada, pois a política garante que o acesso seja revogado automaticamente após 24 horas.
Questão 2 — Cenário Técnico
Uma aplicação consome arquivos de um contêiner no Azure Blob Storage usando uma Service SAS assinada com a chave da conta. Após um incidente de segurança, a equipe suspeita que o token SAS foi comprometido. O token ainda está dentro do prazo de validade configurado.
sv=2022-11-02&ss=b&srt=o&sp=r&se=2025-04-01T00:00:00Z
&st=2025-03-01T00:00:00Z&spr=https&sig=<assinatura>
Qual é a forma mais direta de invalidar imediatamente esse token?
A) Alterar as permissões do contêiner para privado no portal do Azure.
B) Regenerar a chave da conta de armazenamento utilizada para assinar o token.
C) Remover o token do código da aplicação e reimplantar o serviço.
D) Reduzir o prazo de expiração do token editando o parâmetro se na URL.
Questão 3 — Verdadeiro ou Falso
Uma User Delegation SAS pode ser emitida para recursos nos serviços Blob, Queue e Table do Azure Storage, desde que o principal do Microsoft Entra ID tenha as permissões necessárias atribuídas via RBAC.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Um desenvolvedor criou uma Service SAS associada a uma Stored Access Policy em um contêiner. Após perceber que as permissões concedidas estavam mais amplas do que o necessário, ele atualizou a política para remover a permissão de escrita. Minutos depois, a aplicação ainda consegue escrever no contêiner usando o token original.
blob_client.upload_blob(data, overwrite=True)
# Operação ainda bem-sucedida após atualização da política
Qual é a causa mais provável desse comportamento?
A) A Service SAS ignora alterações na Stored Access Policy enquanto o token não expirar.
B) O token SAS foi emitido antes da política existir, portanto não está vinculado a ela.
C) A propagação das alterações em Stored Access Policies pode levar até 30 segundos para ser efetivada globalmente.
D) A aplicação está usando uma versão em cache do token que foi resolvida localmente pelo SDK.
Questão 5 — Múltipla Escolha
Ao comparar uma Account SAS com uma Service SAS, qual afirmativa descreve corretamente uma diferença funcional entre os dois tipos?
A) A Account SAS pode conceder acesso a múltiplos serviços de armazenamento em uma única assinatura, enquanto a Service SAS é limitada a um único serviço.
B) A Service SAS suporta delegação via Microsoft Entra ID, enquanto a Account SAS é sempre assinada com a chave da conta.
C) A Account SAS permite definir permissões no nível do objeto, enquanto a Service SAS opera apenas no nível do contêiner.
D) A Service SAS pode ser usada para gerenciar propriedades da conta de armazenamento, enquanto a Account SAS é restrita ao plano de dados.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Uma Service SAS sem política de acesso armazenada é emitida diretamente para um recurso específico dentro de um serviço (neste caso, um blob individual), com permissões, tempo de expiração e escopo definidos no próprio token. Ela não exige que o destinatário tenha identidade no Microsoft Entra ID, atendendo ao requisito do parceiro externo.
A alternativa A está errada porque a Account SAS tem escopo mais amplo, podendo abranger múltiplos serviços e tipos de recurso simultaneamente, o que viola o princípio do menor privilégio para acesso a um único blob.
A alternativa C está errada porque a User Delegation SAS exige que o emissor tenha uma identidade no Microsoft Entra ID com permissões RBAC adequadas. Não é adequada para parceiros externos sem conta Entra.
A alternativa D confunde o papel da Stored Access Policy: ela facilita a revogação e o gerenciamento centralizado, mas não garante expiração automática diferente do que já estaria definido no token.
Gabarito — Questão 2
Resposta: B
Tokens SAS assinados com a chave da conta não podem ser revogados individualmente, pois não há registro central deles no Azure. A única forma de invalidar todos os tokens assinados por uma chave comprometida é regenerar essa chave. Isso invalida imediatamente qualquer SAS que dependia da assinatura gerada pela chave anterior.
A alternativa A está errada porque alterar o nível de acesso do contêiner afeta o acesso anônimo público, não tokens SAS que já possuem permissões embutidas na assinatura.
A alternativa C não invalida o token: remover o token do código impede que a aplicação o use, mas qualquer outro sistema ou agente que já possua a URL pode continuar utilizando-a até a expiração.
A alternativa D é inviável porque o parâmetro se faz parte da string assinada. Alterá-lo na URL invalida a assinatura criptográfica, tornando o token rejeitado pelo serviço, mas isso não é uma ação administrativa controlada.
Gabarito — Questão 3
Resposta: Falso
A User Delegation SAS é suportada apenas para o serviço Blob Storage (incluindo Azure Data Lake Storage Gen2). Ela não pode ser emitida para os serviços Queue ou Table. Essa é uma limitação importante: a autenticação via Microsoft Entra ID para emissão de SAS delegada está disponível exclusivamente no contexto de blobs. Assumir que todos os serviços de armazenamento suportam User Delegation SAS é um equívoco comum que pode causar falhas de design em arquiteturas de acesso delegado.
Gabarito — Questão 4
Resposta: C
Quando uma Service SAS é vinculada a uma Stored Access Policy, alterações nessa política (como remoção de permissões ou modificação do prazo) são propagadas para todos os tokens que a referenciam. No entanto, essa propagação não é instantânea: o Azure pode levar até 30 segundos para que a mudança seja efetivada em todos os nós de armazenamento. O comportamento descrito é esperado e documentado.
A alternativa A está errada e representa o oposto do benefício central das Stored Access Policies: justamente a capacidade de alterar ou revogar tokens sem precisar aguardar a expiração.
A alternativa B descreve uma situação diferente: tokens emitidos antes da criação de uma política e sem referência a ela ficam de fato desvinculados, mas o cenário afirma explicitamente que o token está associado à política.
A alternativa D é plausível, mas o SDK do Azure Blob Storage não realiza cache local de tokens SAS de forma que override respostas de erro 403 retornadas pelo serviço.
Gabarito — Questão 5
Resposta: A
A diferença funcional central entre os dois tipos é o escopo de abrangência: uma Account SAS pode conceder acesso a múltiplos serviços (Blob, Queue, Table, File) em uma única assinatura, com permissões configuráveis por tipo de recurso e operação. Já a Service SAS é sempre restrita a um único serviço de armazenamento.
A alternativa B inverte os fatos: é a User Delegation SAS (não a Service SAS) que utiliza delegação via Microsoft Entra ID. Tanto Account SAS quanto Service SAS são assinadas com a chave da conta ou com a chave de delegação do usuário.
A alternativa C está errada: a Service SAS pode sim operar no nível do objeto (por exemplo, um blob específico), não apenas no nível do contêiner.
A alternativa D está conceitualmente invertida: operações de gerenciamento da conta pertencem ao plano de controle (ARM) e não são acessíveis por nenhum tipo de SAS, que opera exclusivamente no plano de dados.