Laboratório Técnico: Configure stored access policies
Questões
Questão 1 — Múltipla Escolha
Uma equipe de desenvolvimento utiliza uma Shared Access Signature (SAS) do tipo service SAS para conceder acesso temporário a um container no Azure Blob Storage. Após a implantação em produção, o time de segurança exige a capacidade de revogar o acesso imediatamente, sem precisar recriar a chave de conta.
Qual modificação resolve esse requisito?
A) Reduzir o tempo de expiração da SAS para 1 hora e regenerá-la periodicamente.
B) Associar a SAS a uma stored access policy definida no container, de forma que a revogação da política invalide a SAS.
C) Migrar para uma account SAS, que suporta revogação direta pelo portal do Azure.
D) Habilitar o Azure Defender for Storage para monitorar e bloquear tokens SAS suspeitos.
Questão 2 — Cenário Técnico
Um administrador criou a seguinte stored access policy em um container chamado relatorios:
az storage container policy create \
--container-name relatorios \
--name "politica-leitura" \
--account-name minha-conta \
--permissions r \
--expiry 2025-12-31
Em seguida, gerou uma SAS vinculada a essa política. Três meses depois, o administrador precisa que o acesso expire imediatamente. Ele executa:
az storage container policy delete \
--container-name relatorios \
--name "politica-leitura" \
--account-name minha-conta
Qual é o comportamento esperado após a exclusão da política?
A) A SAS continua válida até a data 2025-12-31 definida originalmente, pois a expiração é gravada no token no momento da criação.
B) A SAS é invalidada imediatamente, pois sua validade depende da existência e das permissões da stored access policy associada.
C) A SAS passa a operar com permissões de leitura e escrita, pois sem a política associada ela herda as permissões da chave de conta.
D) O Azure retorna erro 403 Forbidden apenas para novas requisições iniciadas após a exclusão, mas completa as requisições em andamento com a política antiga.
Questão 3 — Múltipla Escolha
Ao definir permissões em uma stored access policy, um administrador omite intencionalmente os campos --start e --expiry. Uma SAS é gerada sem datas definidas diretamente no token, vinculada a essa política.
Qual é o comportamento resultante?
A) A SAS é rejeitada pelo Azure, pois toda SAS deve conter datas de início e expiração explícitas no token.
B) A SAS herda as datas de início e expiração da stored access policy; como ambas foram omitidas, a SAS fica válida por 24 horas por padrão.
C) A SAS fica válida indefinidamente até que a stored access policy seja modificada ou excluída, pois nenhuma restrição de tempo foi aplicada.
D) A SAS utiliza a data de criação do container como início e a data de expiração da chave de conta como limite superior.
Questão 4 — Cenário Técnico
Um administrador precisa atualizar as permissões de uma stored access policy existente para adicionar permissão de escrita (w) a uma política que hoje concede apenas leitura (r). Ele executa:
az storage container policy create \
--container-name dados \
--name "politica-rw" \
--account-name minha-conta \
--permissions rw \
--expiry 2026-06-30
Observe que o administrador usou create em vez de update. Considerando que já existe uma política com o nome politica-rw nesse container, qual é o resultado?
A) O comando falha com erro de conflito, pois não é permitido criar uma política com o mesmo nome de outra já existente.
B) O comando sobrescreve a política existente com os novos parâmetros, pois create funciona como upsert para stored access policies.
C) O comando cria uma segunda política com o mesmo nome, resultando em duas entradas com comportamento indefinido.
D) A política existente é preservada e uma nova política temporária é criada com sufixo numérico automático.
Questão 5 — Verdadeiro ou Falso
Um único container no Azure Blob Storage pode ter no máximo 5 stored access policies definidas simultaneamente. Tentar adicionar uma sexta política retorna erro e a operação é recusada.
A afirmação acima é verdadeira ou falsa?
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
Uma SAS vinculada a uma stored access policy não carrega todas as suas restrições embutidas no token de forma autônoma. Ao associar a SAS à política, a validade e as permissões passam a depender da política armazenada no serviço. Revogar ou excluir a política invalida imediatamente todas as SAS que a referenciam, sem necessidade de regenerar a chave de conta.
A alternativa A reduz a janela de exposição, mas não oferece revogação imediata. A alternativa C está incorreta: uma account SAS também não suporta revogação direta sem política associada. A alternativa D descreve um serviço de monitoramento, não um mecanismo de controle de acesso.
O ponto central é que a revogabilidade imediata é a principal razão de existir das stored access policies em relação às SAS ad hoc.
Gabarito — Questão 2
Resposta: B
Quando uma SAS de serviço é vinculada a uma stored access policy, o Azure avalia a validade da SAS consultando a política no momento de cada requisição. Se a política é excluída, a referência que a SAS carrega deixa de existir no serviço, e o Azure rejeita o token imediatamente.
A alternativa A descreve o comportamento de uma SAS ad hoc (sem política associada), cujas restrições ficam embutidas no token e não podem ser revogadas externamente. A alternativa C é tecnicamente incorreta: a ausência da política não expande permissões. A alternativa D mistura conceitos de controle de sessão HTTP com o funcionamento de tokens SAS, que são validados por requisição.
Gabarito — Questão 3
Resposta: C
As stored access policies permitem que campos de data sejam omitidos intencionalmente. Quando --start e --expiry são omitidos da política e também não são definidos diretamente no token SAS, o Azure não aplica nenhuma restrição de tempo à SAS. Ela permanece válida indefinidamente enquanto a política existir e a chave de conta usada na assinatura não for rotacionada.
Não existe valor padrão de 24 horas (alternativa B). O Azure não rejeita SAS sem datas (alternativa A). As datas do container e da chave de conta não são herdadas automaticamente (alternativa D).
Este comportamento exige atenção em ambientes de produção: omitir datas é uma decisão explícita com impacto direto na postura de segurança.
Gabarito — Questão 4
Resposta: B
No contexto das stored access policies, o comando az storage container policy create opera como upsert: se uma política com o nome especificado já existir no container, ela é substituída integralmente pelos novos parâmetros. Não há distinção operacional entre criar e sobrescrever nesse contexto.
A alternativa A reflete um comportamento esperado por quem assume semântica de INSERT OR FAIL, que não se aplica aqui. As alternativas C e D descrevem comportamentos que não existem na implementação do Azure Storage. Este mecanismo de upsert é, na prática, a forma recomendada de atualizar políticas existentes quando não se usa explicitamente update.
Gabarito — Questão 5
Resposta: Verdadeiro
O Azure Storage impõe um limite de 5 stored access policies por container. Esse limite se aplica individualmente a cada recurso: um container, uma fila, uma tabela ou um compartilhamento de arquivo pode ter no máximo 5 políticas simultâneas. Tentar criar uma sexta política retorna erro, e a operação é recusada sem afetar as políticas existentes.
Este limite é relevante em arquiteturas que segmentam acesso por perfil de usuário ou serviço usando políticas distintas. Exceder o limite exige consolidar políticas ou repensar a estratégia de acesso, possivelmente combinando permissões em uma única política mais abrangente.