Azure Storage Accounts são serviços fundamentais na Microsoft Azure que fornecem armazenamento em nuvem escalável, seguro e altamente disponível para vários tipos de dados, incluindo blobs (binary large objects), files, queues e tables. Eles funcionam como contêineres que agrupam esses diferentes serviços de storage sob um único namespace para facilitar a gestão.
Principais opções de configuração:
Cada storage account deve ter um nome único em todo o Azure.
Cada storage account é implantada em uma região ou em uma zona estendida do Azure.
É possível selecionar a versão premium da storage account para melhor desempenho.
É possível escolher entre 4 tipos de redundância para proteger contra falhas em racks, discos e datacenters.
Opções de configuração de segurança:
Require secure transfer for REST API operations: Exige TLS em qualquer comunicação com o storage.
Allows enabling anonymous access on individual containers: Se desativado, não será possível habilitar acesso anônimo no futuro.
Enable storage account key access: Se desativado, o acesso com Shared Keys será proibido.
Minimum TLS version
Permitted scope for copy operations: Permitir de qualquer storage account, de qualquer storage account do mesmo Entra tenant ou de storage accounts com private endpoints na mesma virtual network.
Opções de Blob Storage:
Allow cross-tenant replication
Access tier: Hot (dados acessados com frequência), Cool e Cold (dados raramente acessados)
Opções de rede:
Network access:
Allow from all networks
Allow from selected virtual networks and IP addresses
Disable public access and use private access
Private endpoints: Permite uma conexão privada à storage account a partir de uma virtual network
Opções de proteção de dados:
Point-in-time restore for containers: Permite restaurar containers para um estado anterior.
Requer que versioning, change feed e blob soft delete estejam ativados.
Enable soft delete for blobs: Habilita um período de retenção (em dias) para blobs deletados (mesmo sobrescritos).
Enable soft delete for containers: Habilita um período de retenção (em dias) para containers deletados.
Enable soft delete for file shares: Habilita um período de retenção (em dias) para file shares deletados.
Enable versioning for blobs: Mantém versões anteriores dos seus blobs.
Enable blob change feed: Mantém logs de criação, modificação e deleção de blobs.
Enable version-level immutability support: Permite definir uma política de retenção baseada em tempo no nível da conta que se aplicará a todas as versões de blob.
Version-level immutability support e point-in-time restore for containers não podem ser habilitados simultaneamente.
Opções de configuração de criptografia:
Encryption type: É possível usar Microsoft-managed keys (MMK) ou Customer-managed keys (CMK).
Enable infrastructure encryption: Permite uma dupla criptografia dos dados “para mais segurança”.
Static websites são servidos a partir do contêiner especial $web através de um endpoint específico da região, por exemplo https://<account>.z13.web.core.windows.net/.
O contêiner $web pode reportar publicAccess: null via a blob API, mas os arquivos ainda são alcançáveis através do static site endpoint, então deixar artifacts de config/IaC lá pode leak secrets.
Quick audit workflow:
# Identify storage accounts with static website hosting enabled
az storage blob service-properties show --account-name <acc-name> --auth-mode login
# Enumerate containers (including $web) and their public flags
az storage container list --account-name <acc-name> --auth-mode login
# List files served by the static site even when publicAccess is null
az storage blob list --container-name '$web' --account-name <acc-name> --auth-mode login
# Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login
Locate storage accounts que podem expor dados: az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'. Se allowBlobPublicAccess for false você não pode tornar containers públicos.
Inspect risky accounts para confirmar a flag e outras configurações fracas: az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'.
Enumerate container-level exposure onde a flag está habilitada:
az storage container list --account-name <acc> \
--query '[].{name:name, access:properties.publicAccess}'
"Blob": leituras anônimas permitidas apenas quando o nome do blob é conhecido (sem listagem).
"Container": listagem + leitura anônimas de todos os blobs.
null: privado; autenticação necessária.
Comprove acesso sem credenciais:
Se publicAccess estiver definido como Container, a listagem anônima funciona: curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list".
Para ambos Blob e Container, o download anônimo do blob funciona quando o nome é conhecido:
az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
# or via raw HTTP
curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
É possível gerar Shared Keys assinadas com as chaves de acesso para autorizar o acesso a certos recursos através de um URL assinado.
Note
Note que a parte CanonicalizedResource representa o recurso do serviço de armazenamento (URI). E se qualquer parte no URL estiver codificada, também deverá estar codificada dentro do CanonicalizedResource.
Note
Isto é usado por padrão pelo az cli para autenticar solicitações. Para que utilize as credenciais do principal Entra ID indique o parâmetro --auth-mode login.
É possível gerar uma shared key para os serviços blob, queue e file assinando a seguinte informação:
Shared Access Signatures (SAS) são URLs seguras e por tempo limitado que concedem permissões específicas para acessar recursos em uma conta do Azure Storage sem expor as chaves de acesso da conta. Enquanto as chaves de acesso fornecem acesso administrativo total a todos os recursos, o SAS permite controle granular especificando permissões (como read ou write) e definindo um tempo de expiração.
User delegation SAS: Isso é criado a partir de um Entra ID principal que vai assinar o SAS e delegar as permissões do usuário para o SAS. Só pode ser usado com blob and data lake storage (docs). É possível revogar todos os SAS delegados de usuário gerados.
Mesmo que seja possível gerar um delegation SAS com “mais” permissões do que as que o usuário possui. Contudo, se o principal não as tiver, não funcionará (no privesc).
Service SAS: É assinado usando uma das access keys da storage account. Pode ser usado para conceder acesso a recursos específicos em um único serviço de storage. Se a key for renovada, o SAS deixará de funcionar.
Account SAS: Também é assinado com uma das access keys da storage account. Concede acesso a recursos através dos serviços de uma storage account (Blob, Queue, Table, File) e pode incluir operações a nível de serviço.
Ao gerar um SAS é necessário indicar as permissões que ele deve conceder. Dependendo do objeto sobre o qual o SAS está sendo gerado, diferentes permissões podem ser incluídas. Por exemplo:
Azure Blob Storage agora suporta o SSH File Transfer Protocol (SFTP), permitindo transferência segura de arquivos e gerenciamento diretamente no Blob Storage sem exigir soluções customizadas ou produtos de terceiros.
Protocol Support: SFTP funciona com storage accounts configuradas com hierarchical namespace (HNS). Isso organiza blobs em diretórios e subdiretórios para facilitar a navegação.
Security: SFTP usa identidades de usuários locais para autenticação e não se integra com RBAC ou ABAC. Cada usuário local pode autenticar via:
Azure-generated passwords
Public-private SSH key pairs
Granular Permissions: Permissões como Read, Write, Delete e List podem ser atribuídas a usuários locais para até 100 containers.
Networking Considerations: Conexões SFTP são feitas pela porta 22. A Azure suporta configurações de rede como firewalls, private endpoints ou virtual networks para proteger o tráfego SFTP.
Hierarchical Namespace: HNS deve estar habilitado ao criar a storage account.
Supported Encryption: Requer algoritmos criptográficos aprovados pelo Microsoft Security Development Lifecycle (SDL) (ex.: rsa-sha2-256, ecdsa-sha2-nistp256).
SFTP Configuration:
Habilitar SFTP na storage account.
Criar identidades de usuários locais com permissões apropriadas.
Configurar home directories para os usuários definirem sua localização inicial dentro do container.
az storage blob show –account-name –container-name –sas-token ‘se=2024-12-31T23%3A59%3A00Z&sp=racwdxyltfmei&sv=2022-11-02&sr=c&sig=ym%2Bu%2BQp5qqrPotIK5/rrm7EMMxZRwF/hMWLfK1VWy6E%3D’ –name ‘asd.txt’