Contas de Armazenamento do Azure

Uma Azure Storage Account é o recurso fundamental que fornece acesso aos principais serviços de armazenamento do Azure: Blob Storage (armazenamento de objetos), Azure Files (compartilhamentos de arquivos gerenciados), Queue Storage (filas de mensagens), Table Storage (armazenamento de chave-valor NoSQL) e Azure Data Lake Storage Gen2 (namespace hierárquico para análise). Uma única conta de armazenamento pode hospedar todos esses serviços simultaneamente e fornece um namespace exclusivo no Azure — o nome da conta torna-se parte da URL de cada objeto que ela contém.

O Azure oferece vários tipos de contas de armazenamento: Standard general-purpose v2 (GPv2) — o tipo recomendado para a maioria dos cenários; oferece suporte a todos os serviços de armazenamento e opções de redundância com desempenho Standard. Premium block blobs — armazenamento baseado em SSD para cenários que exigem latência muito baixa nas operações do Blob Storage. Premium file shares — compartilhamentos do Azure Files baseados em SSD para cargas de trabalho com alto número de IOPS, como bancos de dados ou diretórios pessoais. Premium page blobs — armazenamento SSD para discos de sistema operacional e de dados de VMs do Azure (Managed Disks usa esse armazenamento internamente). Para a maioria dos casos de uso, comece com uma conta Standard GPv2.

O Azure replica seus dados automaticamente para proteção contra falhas de hardware. As quatro opções de redundância são: LRS (Locally Redundant Storage) — três cópias síncronas em um único centro de dados. ZRS (Zone-Redundant Storage) — três cópias síncronas distribuídas por três zonas de disponibilidade em uma região. GRS (Geo-Redundant Storage) — LRS na região primária + replicação assíncrona para uma região secundária (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS na região primária + replicação assíncrona para uma região secundária. Maior redundância significa maior durabilidade e custo.

Escolha o nível de redundância com base nos seus requisitos de RTO, RPO e orçamento: LRS — mais barato, durabilidade de 11 noves, sem proteção contra falhas do centro de dados. Use para desenvolvimento/teste ou dados que podem ser recriados. ZRS — protege contra falhas do centro de dados, sendo adequado para dados de produção em uma única região. GRS/GZRS — protege contra a indisponibilidade de uma região inteira do Azure; os dados são replicados de forma assíncrona para a região emparelhada. Para dados empresariais críticos que precisam sobreviver a um desastre regional, GRS ou GZRS é a escolha adequada, apesar do custo adicional.

O Azure Storage oferece dois níveis de desempenho: Standard — baseado em unidades de disco rígido (HDD), adequado para a maioria das cargas de trabalho com menor custo por GB. Premium — baseado em unidades de estado sólido (SSD), desenvolvido para cenários sensíveis à latência que exigem E/S em milissegundos de um único dígito. O armazenamento Standard é cobrado por GB armazenado; o Premium é mais caro por GB, mas oferece desempenho consistente e previsível. Para recursos da web, backups, logs e arquivamento, o Standard é adequado. Para VMs com bancos de dados que fazem uso intenso de E/S ou compartilhamentos de arquivos acessados por usuários de desktop, o Premium é a melhor escolha.

Os nomes das contas de armazenamento devem ser exclusivos globalmente em todo o Azure (porque formam parte de um nome DNS público, como mystorageacct.blob.core.windows.net). Os nomes devem ter de 3 a 24 caracteres e conter apenas letras minúsculas e números — sem hífens, sublinhados ou letras maiúsculas. Como os nomes devem ser exclusivos globalmente, palavras comuns e nomes de marcas já estão ocupados. Uma boa prática é combinar um prefixo da empresa, o ambiente (prod/dev) e a finalidade (store/media), acrescentando um sufixo aleatório, se necessário: por exemplo, contosoprodmedia7x2.

Cada conta de armazenamento tem duas chaves de acesso de 512 bits que concedem acesso administrativo total a tudo na conta. Essas chaves devem ser tratadas como senhas — armazenadas no Azure Key Vault, e não no código ou em arquivos de configuração. O Azure gera duas chaves para que você possa realizar a rotação de chaves sem tempo de inatividade: atualize seus aplicativos para usar a Chave 2, gere novamente a Chave 1, alterne os aplicativos para a Chave 1 e, em seguida, gere novamente a Chave 2. Para um controle de acesso mais granular, use Shared Access Signatures (SAS) ou Azure RBAC em vez de compartilhar as chaves mestras.

Azure RBAC (Role-Based Access Control) é a forma recomendada de autorizar o acesso aos dados de armazenamento sem compartilhar chaves. Atribua a função Storage Blob Data Reader para permitir acesso somente leitura ao Blob Storage ou Storage Blob Data Contributor para permitir leitura e gravação. Essas funções são atribuídas a usuários, grupos ou identidades gerenciadas do Entra ID, de modo que o acesso fica vinculado a uma identidade autenticada, e não a um segredo compartilhado. A autorização RBAC para armazenamento está disponível nos serviços Blob, Queue e Table (não no File — esse serviço usa os protocolos SMB/NFS com seus próprios controles de acesso).

Por padrão, as contas de armazenamento aceitam conexões de qualquer rede. Para obter segurança em produção, restrinja o acesso usando o Storage Account Firewall: permita apenas intervalos específicos de IPs públicos ou sub-redes de redes virtuais. Para obter o mais alto nível de segurança, desabilite totalmente o acesso à Internet pública e use um Private Endpoint — um endereço IP privado dentro da sua VNet que encaminha o tráfego para a conta de armazenamento pela rede privada principal do Azure, sem jamais expô-la à Internet pública. Os Private Endpoints são a abordagem recomendada para contas de armazenamento que contêm dados confidenciais ou regulamentados.

O Azure Storage oferece recursos integrados de proteção de dados contra exclusões acidentais: Blob soft delete — os blobs e as versões excluídos são mantidos por um período configurável (de 1 a 365 dias) e podem ser recuperados sem restauração a partir de um backup. Blob versioning — cada substituição cria uma nova versão, permitindo restaurar qualquer versão anterior de um blob. Container soft delete — os contêineres excluídos acidentalmente podem ser recuperados. Esses recursos são desabilitados por padrão e devem ser habilitados para contas de armazenamento de produção que contenham dados importantes não protegidos por backup em outro local.

O Azure Monitor coleta automaticamente métricas de cada conta de armazenamento: capacidade total utilizada, número de transações, bytes de entrada e saída e latência de ponta a ponta. Você pode visualizá-las no painel Insights do portal do Azure para sua conta de armazenamento, que fornece gráficos prontos para capacidade, disponibilidade e desempenho. Para auditoria detalhada de acesso, habilite os Storage Diagnostic Logs para registrar cada operação de leitura, gravação e exclusão em um destino de log — algo útil para investigações de segurança e relatórios de conformidade.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que: uma conta de armazenamento é o recurso raiz de todos os serviços de armazenamento do Azure, identificada por um nome exclusivo globalmente, as opções de redundância — LRS, ZRS, GRS e GZRS — fornecem níveis crescentes de durabilidade a um custo crescente e o acesso deve ser controlado por meio de RBAC e pontos de extremidade privados, em vez do compartilhamento de chaves de acesso mestras. A seguir, vamos nos aprofundar no Blob Storage — o armazenamento de objetos do Azure para dados não estruturados.