Laboratório de Troubleshooting: Create and configure a container in Azure Blob Storage
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de dados publicou um container chamado datasets em uma conta de armazenamento de uso geral v2. O container foi configurado com acesso público definido como Blob. Os cientistas de dados confirmam que conseguem fazer upload e download normalmente usando as chaves da conta.
No entanto, um parceiro externo relata que ao tentar acessar um blob diretamente pela URL pública, recebe o seguinte erro:
HTTP 409 - PublicAccessNotPermitted
The public access is not permitted on this storage account.
A equipe verifica o container e confirma que o nível de acesso está corretamente definido como Blob. A conta de armazenamento foi criada há três semanas. O parceiro está acessando de fora da rede corporativa, sem VPN. A conta não possui regras de firewall configuradas. O SKU da conta é Standard_LRS.
Qual é a causa raiz do erro recebido pelo parceiro externo?
A) O nível de acesso Blob não permite acesso por URL direta sem autenticação; é necessário usar Container
B) A opção "Allow Blob public access" está desabilitada no nível da conta de armazenamento
C) A ausência de regras de firewall impede requisições vindas de fora da rede corporativa
D) O SKU Standard_LRS não suporta acesso público a blobs; é necessário usar Standard_GRS
Cenário 2 — Decisão de Ação
A equipe de segurança de uma empresa identificou a causa de um incidente: um container chamado backups foi criado com acesso público Container por engano, expondo nomes e metadados de arquivos de backup para qualquer usuário anônimo na internet. A causa está confirmada e documentada.
O container está em produção ativa. Uma aplicação interna faz upload de novos backups a cada 15 minutos usando uma Shared Access Signature (SAS) com permissões de escrita. Uma segunda aplicação faz leitura dos backups usando a chave de acesso da conta. O gerente de segurança exige correção imediata.
Qual é a ação correta a tomar neste momento?
A) Excluir e recriar o container com acesso Private, pois alterar o acesso em um container existente não é suportado pelo Azure
B) Alterar o nível de acesso do container de Container para Private diretamente nas propriedades do container, sem interromper as aplicações
C) Revogar imediatamente todas as SAS ativas e regenerar as chaves da conta antes de alterar o acesso do container
D) Desabilitar a opção "Allow Blob public access" na conta de armazenamento e depois alterar o container para Private
Cenário 3 — Causa Raiz
Um desenvolvedor executa o seguinte comando para criar um container e imediatamente tenta verificar sua existência:
az storage container create \
--name relatorios \
--account-name corpstorageeast \
--auth-mode login
az storage container show \
--name relatorios \
--account-name corpstorageeast \
--auth-mode login
O segundo comando retorna:
(AuthorizationPermissionMismatch) This request is not authorized to perform
this operation using this permission.
RequestId: 4f8a1c23-...
Time: 2026-03-26T10:14:32.0000000Z
O desenvolvedor confirma que está autenticado via az login com sua conta corporativa. A conta de armazenamento existe e está acessível. O grupo de recursos está na região East US. A conta de armazenamento não possui firewall habilitado. O container relatorios foi criado com sucesso, conforme confirmado pelo retorno do primeiro comando.
Qual é a causa raiz da falha no segundo comando?
A) O parâmetro --auth-mode login não é compatível com o comando show; é necessário usar --auth-mode key
B) O usuário autenticado não possui uma atribuição de role RBAC no plano de dados que autorize a operação de leitura de metadados do container
C) Há um atraso de replicação entre as regiões que impede a leitura imediata após a criação do container
D) O nome relatorios contém caracteres fora do padrão ASCII e causa falha de autenticação no segundo comando
Cenário 4 — Impacto Colateral
Um administrador identifica que a conta de armazenamento corpdata01 tem a opção "Allow Blob public access" habilitada e que vários containers foram criados com acesso Blob ou Container ao longo do tempo. Para remediar o risco de exposição, o administrador desabilita a opção "Allow Blob public access" diretamente nas configurações da conta de armazenamento.
A ação resolve o problema de exposição imediatamente.
Qual consequência secundária essa ação pode causar?
A) Os containers existentes com acesso Blob ou Container terão seus metadados alterados automaticamente para Private no banco de dados interno do Azure
B) Aplicações que dependem de URLs públicas de blobs para funcionar corretamente passarão a receber erros de autorização, sem que nenhuma configuração dessas aplicações tenha sido alterada
C) A regeneração das chaves de acesso da conta será exigida automaticamente pelo Azure como medida de segurança complementar
D) Todos os blobs existentes serão movidos para a camada Archive como proteção adicional contra acesso não autorizado
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no código de erro: PublicAccessNotPermitted. Esse erro específico não indica problema de rede nem de nível de acesso do container; ele indica que a conta de armazenamento tem o acesso público bloqueado no nível da conta. Quando a configuração "Allow Blob public access" está desabilitada na conta, o Azure rejeita qualquer requisição anônima independentemente do que estiver configurado nos containers individuais.
A informação sobre ausência de regras de firewall é irrelevante e foi incluída propositalmente para desviar o raciocínio para a alternativa C. Firewall bloqueado resultaria em um erro de conectividade de rede, não no código 409 - PublicAccessNotPermitted. O SKU Standard_LRS (alternativa D) não tem qualquer relação com suporte a acesso público. A alternativa A está errada porque o nível Blob é exatamente o nível adequado para acesso anônimo por URL direta sem listagem.
O distrator mais perigoso é C, pois a ausência de firewall parece ser uma pista relevante, mas o código de erro 409 elimina essa hipótese antes de qualquer outra investigação.
Gabarito — Cenário 2
Resposta: B
O nível de acesso público de um container existente pode ser alterado diretamente, sem necessidade de recriar o container. A alteração de Container para Private não interrompe aplicações que usam SAS ou chave de acesso, pois essas formas de autenticação operam no plano de dados de forma independente do controle de acesso anônimo.
A alternativa A é factualmente incorreta: o Azure permite alterar o nível de acesso de containers existentes. A alternativa C ignora a restrição de urgência e causaria interrupção imediata das duas aplicações em produção antes de qualquer correção real do problema. A alternativa D é tecnicamente válida como medida de segurança mais ampla, mas vai além do necessário neste momento e poderia ter efeitos colaterais em outros containers da mesma conta que dependem de acesso público legítimo. Dado que a causa está confirmada e a correção é cirúrgica e não disruptiva, a alternativa B é a ação correta.
O distrator mais perigoso é D, pois parece ser uma solução mais segura, mas interfere potencialmente em outros serviços da conta sem que isso tenha sido avaliado.
Gabarito — Cenário 3
Resposta: B
Quando --auth-mode login é usado, o Azure CLI delega a autorização ao plano de dados via RBAC, não via chave. Para executar az storage container show, o usuário precisa de uma role que conceda permissão de leitura no plano de dados do Blob Storage, como Storage Blob Data Reader ou superior. Sem essa atribuição, o Azure retorna AuthorizationPermissionMismatch mesmo que o usuário tenha criado o container, porque a criação pode ter sido autorizada por uma role de plano de gerenciamento que não se estende ao plano de dados.
A informação sobre localização East US e ausência de firewall é irrelevante. O atraso de replicação (alternativa C) não se aplica aqui porque a conta usa Standard_LRS, que é localmente redundante sem replicação entre regiões. A alternativa D é incorreta porque relatorios contém apenas caracteres ASCII válidos para nomes de container. A alternativa A está errada porque --auth-mode login é compatível com show; o problema é de permissão, não de compatibilidade de parâmetro.
O erro de raciocínio mais comum neste cenário é concluir que o primeiro comando funcionou porque o usuário tem permissão suficiente para tudo, sem perceber que criar e ler no plano de dados são permissões distintas no RBAC.
Gabarito — Cenário 4
Resposta: B
Desabilitar "Allow Blob public access" na conta bloqueia imediatamente todas as requisições anônimas a qualquer container da conta, independentemente do nível de acesso configurado em cada container. Aplicações que utilizam URLs públicas de blobs para exibir imagens, servir arquivos estáticos ou integrar com serviços externos passarão a receber erros de autorização sem que nenhuma configuração dessas aplicações tenha sido modificada. O impacto é silencioso do ponto de vista das aplicações: elas não foram alteradas, mas param de funcionar.
A alternativa A está errada: o Azure não altera automaticamente os metadados de configuração dos containers; eles continuam registrados como Blob ou Container, mas o efeito prático é bloqueado pela conta. A alternativa C é incorreta porque a regeneração de chaves não é acionada automaticamente por essa configuração. A alternativa D é incorreta porque nenhuma movimentação de camada de armazenamento ocorre em resposta a mudanças de configuração de acesso público.
Árvore de Troubleshooting: Create and configure a container in Azure Blob Storage
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa diretamente no ambiente: o tipo de erro retornado, o método de autenticação em uso e as configurações visíveis no portal ou via CLI. Siga o caminho correspondente à sua resposta em cada bifurcação até alcançar um nó vermelho com a causa identificada, depois avance para o nó verde com a ação recomendada. Se após aplicar a correção o problema persistir, retorne ao nó de validação laranja e percorra novamente a árvore com as novas informações disponíveis.