No domínio de armazenamento do AZ-104 (15–20%), o primeiro bloco do guia oficial de habilidades é "configurar o acesso ao armazenamento". Firewalls e redes virtuais, tokens SAS, políticas de acesso armazenadas, chaves de acesso e acesso baseado em identidade para o Azure Files estão todos ali, e no nosso banco de questões as perguntas sobre firewall e permissões de acesso somam quase metade das questões de armazenamento. O difícil é que esses recursos atuam em camadas diferentes. Abra o firewall sem as permissões certas e você recebe um 403; tenha as permissões com o firewall bloqueando e você também não entra.
Este artigo separa os dois filtros que toda solicitação de armazenamento precisa passar: rede e autorização. Vamos ver a configuração de acesso à rede pública e as regras de firewall, os quatro métodos de autorização, os três tipos de SAS e as políticas de acesso armazenadas, a rotação de chaves de acesso e a desativação do Shared Key, o acesso baseado em identidade para o Azure Files e a criptografia em repouso. O básico, como redundância, camadas de acesso e gerenciamento do ciclo de vida, está em Guia Completo de Gerenciamento de Armazenamento.
---
Dois Filtros que Toda Solicitação de Armazenamento Precisa Passar
Para entrar em um prédio comercial você primeiro passa pela segurança da portaria e depois usa o crachá na porta do escritório. Passar pela portaria não significa poder entrar em qualquer escritório, e ter crachá não adianta se a entrada principal estiver fechada. O Azure Storage verifica cada solicitação duas vezes do mesmo jeito.
| Filtro | O que verifica | Onde configurar | |------|------|------| | 1. Rede | De onde vem a solicitação (internet, uma VNet específica, um IP específico, um ponto de extremidade privado) | Conta de armazenamento → Rede | | 2. Autorização | Se quem chama pode fazer esta operação (chave, SAS, Entra ID, anônimo) | Chaves de acesso, SAS, Controle de acesso (IAM), nível de acesso do contêiner |
!Uma solicitação de armazenamento precisa passar pelo filtro de rede e pelo filtro de autorização
Dica para o exame: Se "o token SAS é válido, mas o acesso é negado só a partir de um escritório", suspeite do filtro de rede (regras de firewall), não da autorização. Se "uma regra de VNet foi adicionada, mas as solicitações falham com erro 403 de permissão", verifique a função de dados do RBAC ou as permissões do SAS.
---
O Filtro de Rede: Acesso à Rede Pública e Regras de Firewall
A primeira escolha na página Rede de uma conta de armazenamento é o nível de acesso à rede pública.
| Configuração | Comportamento | |------|------| | Habilitado em todas as redes | Acessível de qualquer lugar da internet (só resta o filtro de autorização) | | Habilitado em redes virtuais e endereços IP selecionados | Só as solicitações que atendem às regras abaixo são permitidas; o resto é bloqueado | | Desabilitado | O ponto de extremidade público é bloqueado; acesso só por pontos de extremidade privados |
Quando você escolhe redes selecionadas, combina regras de permissão.
| Regra | O que permite | O que lembrar | |------|------|------| | Regra de rede virtual | Uma sub-rede específica de uma VNet específica | A sub-rede precisa do ponto de extremidade de serviço Microsoft.Storage (o portal cria automaticamente) | | Regra de rede IP | Endereços ou intervalos de IP públicos | IPs privados (10.x, 172.16–31.x, 192.168.x) não são permitidos; /31 e /32 entram como IPs individuais | | Regra de instância de recurso | Uma instância específica de um recurso do Azure | Recursos do mesmo locatário; o que podem fazer é definido pelas atribuições de função desse recurso | | Exceção de serviços confiáveis | Serviços do Azure da lista de confiáveis | Para serviços que não podem ser isolados por VNet ou IP |
As regras de IP escondem uma pegadinha muito cobrada. Regras de rede IP não têm efeito sobre solicitações vindas da mesma região do Azure que a conta de armazenamento, porque serviços da mesma região se comunicam por endereços IP privados do Azure. Para permitir ou restringir o acesso de VMs da mesma região, é preciso usar regras de rede virtual. Além disso, depois que você habilita um ponto de extremidade de serviço em uma sub-rede, o tráfego dessa sub-rede usa um IP privado como origem, então as regras de IP que permitiam o IP público dessa sub-rede deixam de valer.
Um ponto de extremidade privado dá à conta de armazenamento um IP privado dentro da sua VNet, então, mesmo com o acesso à rede pública Desabilitado, o tráfego que chega pelo ponto de extremidade privado continua passando. Pontos de extremidade de serviço e privados são comparados com um diagrama em VNet, NSG, DNS e Load Balancer Explicados para Iniciantes.
Dica para o exame: "Permitir acesso só a partir do IP público 203.0.113.10 do escritório local" é uma regra de rede IP. "Permitir só a Subnet1 da VNet1 na mesma região" é uma regra de rede virtual mais um ponto de extremidade de serviço. "Bloquear a internet completamente e permitir acesso só por um IP privado da VNet" é um ponto de extremidade privado com o acesso à rede pública desabilitado.
---
O Filtro de Autorização: Quatro Formas de Provar o Acesso
Uma solicitação que passa pelo filtro de rede prova seus direitos de uma destas quatro formas.
| Método | Prova | Características | |------|------|------| | Microsoft Entra ID | Token de um usuário, grupo ou identidade gerenciada + uma função de dados do RBAC | Recomendado pela Microsoft, suporta acesso condicional e auditoria | | Shared Key | Chave de acesso da conta | Uma única chave dá todos os direitos sobre todos os dados da conta | | SAS | Token de URL assinado | Delegação limitada por tempo, permissões e destino | | Leitura anônima | Nenhuma | Só funciona se permitida na conta e depois habilitada no nível do contêiner |
A Microsoft recomenda Entra ID e identidades gerenciadas por padrão, e chaves só quando realmente necessárias. Ler e gravar blobs com o Entra ID exige uma função de dados como Storage Blob Data Reader ou Storage Blob Data Contributor, como explicado em Como Interpretar Atribuições de Função do Azure RBAC no AZ-104.
---
Três Tipos de SAS e Políticas de Acesso Armazenadas
Uma SAS (assinatura de acesso compartilhado) funciona como o cartão de um quarto de hotel. A recepção emite um cartão que abre um quarto específico até uma data específica. O que muda é com o que o cartão foi assinado, e isso gera três tipos.
| Tipo | Assinada com | Destino | Política de acesso armazenada | Se o Shared Key for desativado | |------|------|------|------|------| | SAS de delegação de usuário | Uma chave de delegação de usuário obtida com credenciais do Entra | Blob (incluindo Data Lake), filas, tabelas, Azure Files | Não suportada | Continua funcionando | | SAS de serviço | Chave de acesso da conta | Um único serviço de armazenamento | Suportada | Negada | | SAS de conta | Chave de acesso da conta | Um ou mais serviços, incluindo operações de nível de serviço | Não suportada | Negada |
Quando você precisa de uma SAS, a Microsoft recomenda a SAS de delegação de usuário, porque ela é protegida por credenciais do Entra em vez da chave da conta. Uma chave de delegação de usuário vale por no máximo sete dias, então uma SAS de delegação de usuário também não pode expirar mais de sete dias à frente.
Políticas de Acesso Armazenadas
Uma política de acesso armazenada é uma "regra de emissão de cartões" definida antes em um contêiner, fila, tabela ou compartilhamento de arquivos. Quando uma SAS de serviço faz referência à política, ela herda da política a hora de início, a hora de expiração e as permissões.
Até cinco por contêiner (ou fila, tabela ou compartilhamento) Criar ou alterar uma política pode levar até 30 segundos para valer Excluir a política, renomear seu identificador ou colocar a expiração no passado invalida todas as SAS vinculadas Funciona só com SAS de serviço; SAS de delegação de usuário e de conta só podem ser ad hoc
Formas de Invalidar uma SAS Já Emitida
| Método | Alcance do impacto | |------|------| | Esperar a expiração | Só essa SAS (expiração curta é o padrão mais seguro) | | Excluir ou alterar a política de acesso armazenada | Todas as SAS de serviço que fazem referência à política | | Regenerar a chave da conta usada na assinatura | Todas as SAS de serviço e de conta assinadas com essa chave + todos os aplicativos que usam essa chave | | Revogar as chaves de delegação de usuário | Todas as SAS de delegação de usuário da conta |
Dica para o exame: Para poder "invalidar imediatamente um conjunto de tokens SAS emitidos sem afetar outras SAS ou aplicativos", é preciso emiti-los desde o início como SAS de serviço vinculadas a uma política de acesso armazenada. Regenerar a chave tem o maior alcance e costuma aparecer como resposta errada.
---
Gerenciando as Chaves de Acesso e Desativando o Shared Key
Toda conta de armazenamento nova recebe duas chaves de acesso de 512 bits. São duas para que você possa rotacioná-las sem derrubar os aplicativos.
Se os aplicativos usam a key1, primeiro mude a configuração deles para a key2 Regenere a key1 Mude os aplicativos para a nova key1 e depois regenere a key2
A Microsoft recomenda guardar as chaves no Azure Key Vault e rotacioná-las regularmente. Como uma chave de acesso dá todos os direitos sobre todos os dados da conta e a capacidade de emitir tokens SAS, também é preciso controlar quem recebe funções que conseguem ler as chaves (Owner, Contributor, Storage Account Contributor e outras).
Indo além, se você desativar "Permitir o acesso à chave da conta de armazenamento" (AllowSharedKeyAccess = false), todas as solicitações assinadas com a chave da conta são rejeitadas e só as do Entra ID passam. As SAS de serviço e de conta são bloqueadas junto, e só as SAS de delegação de usuário continuam funcionando. Ferramentas ou serviços antigos que dependem de chaves também podem parar, então verifique o impacto antes.
Dica