Compreendendo a criptografia de dados no armazenamento Azure

O Azure Storage é a espinha dorsal de inúmeras aplicações nativas na nuvem, lagos de dados, soluções de backup e cargas de trabalho empresariais. Com esse papel central vem uma responsabilidade inegável: proteger dados onde quer que ele resida. A criptografia é a base dessa proteção, garantindo que informações confidenciais permaneçam confidenciais, mesmo que atacantes bypass controles de rede ou segurança física. O Microsoft Azure fornece uma estrutura de criptografia em camadas que cobre dados tanto em repouso quanto em trânsito, com opções que vão desde criptografia totalmente gerenciada e fornecida por plataforma até hierarquias-chave controladas pelo cliente.

Este artigo expande os recursos de criptografia do núcleo dentro do Azure Storage, incluindo o Azure Blob Storage, Azure Files, Fila Storage e Tables Storage. Nós percorremos cada camada de criptografia, como configurá-lo e as decisões que importam para conformidade, desempenho e controle operacional.

Criptografia em repouso

A criptografia em repouso protege os dados quando é escrita para mídia física dentro dos data centers do Azure. Isto inclui tudo, desde os blocos de disco bruto usados por máquinas virtuais até os níveis de armazenamento de objetos no Blob Storage. O Azure implementa a criptografia em repouso usando uma combinação de criptografia transparente do lado de armazenamento, criptografia de nível de infraestrutura e criptografia opcional do lado do cliente. A criptografia padrão de camada-Azure Storage Service (SSE) funciona automaticamente, mas a flexibilidade para trazer suas próprias chaves ou implementar criptografia de nível de host dá aos arquitetos o controle que eles precisam para ambientes regulatórios.

Criptografia do serviço de armazenamento Azure (SSE)

O SSE é o mecanismo de criptografia padrão para todas as contas de armazenamento Azure novas e existentes. Ele criptografa os dados na camada de serviço de armazenamento antes de escrever no disco e descriptografa- os quando lidos. Este processo é totalmente transparente para aplicativos; não são necessárias alterações de código, nenhuma configuração e nenhuma sintonia de desempenho. O SSE usa 256- bits Advanced Encryption Standard (AES-256)[, um dos algoritmos de criptografia simétrica mais fortes disponíveis. As chaves de criptografia são gerenciadas pela Microsoft e giradas internamente de forma regular. Porque o SSE é ativado por padrão, cada conta de armazenamento – incluindo as criadas através do portal Azure, CLI ou ARM – já protege os dados em repouso, a menos que explicitamente desactivados, o que não é possível para novas contas.

O SSE cobre todos os serviços de Armazenamento Azure: Armazenamento de Blocos (blobs de bloco, blobs de apêndice e blobs de página), Arquivos Azure (incluindo compartilhamentos de arquivos), Armazenamento de Filas e Armazenamento de Mesas. Para os Discos Azure Gerenciados, que armazenam máquinas virtuais, a criptografia é tratada separadamente pela criptografia de disco Azure ou criptografia do lado do servidor (chaves gerenciadas por plataforma SSE +). A tomada crítica: O SSE é uma rede de segurança sem configuração que garante criptografia de base em repouso em toda a família de serviços de Armazenamento.

Criptografia de Infra- Estrutura

Além da SSE, o Azure Storage oferece criptografia de infraestrutura , que adiciona uma segunda camada de criptografia no nível da infraestrutura de armazenamento. Enquanto o SSE protege dados nos discos físicos, a criptografia de infraestrutura criptografa dados novamente antes de ser escrita na rede interna do cluster de armazenamento e camadas de cache. Isto é particularmente relevante para os clientes sujeitos a rigorosos regimes de conformidade que exigem criptografia dupla em todos os meios de armazenamento.

A criptografia de infraestrutura está habilitada no nível da conta de armazenamento e usa chaves gerenciadas pela plataforma. Ela não necessita de alterações em aplicativos ou código do cliente. O trade-off é uma pequena sobrecarga de execução (normalmente insignificante para a maioria das cargas de trabalho) e que não pode ser desabilitada uma vez habilitada. Sua organização deve avaliar se uma segunda camada de criptografia é necessária com base em políticas internas, orientações regulatórias ou requisitos contratuais.

Chaves geridas pelo cliente (CMK)

Para organizações que precisam controlar suas próprias chaves de criptografia – seja para cumprir os mandatos de conformidade, implementar agendas de rotação de chaves ou integrar com sistemas de gerenciamento de chaves existentes – o Armazenamento Azul suporta Chaves gerenciadas pelo cliente (CMK)] armazenadas no Vault de Chave Azure. Quando o CMK está habilitado, a chave raiz usada para embrulhar as chaves de criptografia de dados é armazenada em sua própria instância de Vault de Chave. Isso significa que a Microsoft não pode descriptografar os dados sem acesso à sua chave, e você pode revogar o acesso a qualquer momento, desabilitando ou apagando a chave.

O CMK opera no topo do SSE. O serviço de armazenamento ainda criptografa dados usando o AES-256, mas a chave de criptografia (KEK) que protege as chaves de criptografia de dados (DEKs) é gerenciada por você. Você pode escolher entre uma chave Key Vault-managed (protegida por software ou apoiada por HSM) ou uma chave Key Vault Managed HSM[] para conformidade com o FIPS 140-2 Level 3. A rotação de chaves pode ser manual ou automatizada usando a política de rotação de chaves do Key Vault.

Considerações importantes para o CMK:

  • Se você desativar ou excluir a chave no Key Vault, o Azure Storage não acessará os dados. Isso efetivamente torna a conta de armazenamento inacessível e pode levar à perda permanente de dados se não for cuidadosamente gerenciada.
  • CMK está disponível para armazenamento Blob, arquivos Azure, armazenamento em fila, armazenamento de mesa e armazenamento de lago de dados Azure Gen2.
  • CMK não suporta Azure Managed Disks diretamente; esse cenário usa criptografia do lado do servidor com chaves gerenciadas pelo cliente (SSE + CMK).
  • Monitorar as operações chave através de registros de auditoria Key Vault e Azure Monitor é essencial para detectar tentativas de acesso não autorizadas ou expiração chave.

Chaves fornecidas pelo cliente (CPK)

Para o Armazenamento Blob, existe uma terceira opção de chave chamada ]Cliente-Provided Keys (CPK). O CPK permite que um cliente forneça uma chave de criptografia no momento de cada solicitação, em vez de armazenar a chave no Vault de Chave. A chave é usada para essa operação de leitura ou gravação única e não é mantida pelo Azure. Isto é útil para cenários onde você deseja evitar o gerenciamento de chaves inteiramente no nível da plataforma – por exemplo, quando processa dados altamente sensíveis que não podem compartilhar um cofre de chaves com outras cargas de trabalho. O CPK é suportado tanto para blobs de bloco e blobs de página e trabalha com o Azure PowerShell, .NET SDK, Java SDK e REST API chama.

Criptografia em Trânsito

A criptografia em trânsito protege os dados ao se mover em redes, protegendo-os de interceptações, ataques de homem no meio e escutas. O Azure Storage fornece vários mecanismos – desde a execução obrigatória do HTTPS até a criptografia SMB para compartilhamentos de arquivos – para garantir que os dados nunca sejam transmitidos em texto simples.

Aplicação HTTPS

Todos os endpoints do Armazenamento Azure suportam HTTPS (HTTP sobre TLS 1.2 ou superior). Por padrão, tanto HTTP quanto HTTPS são aceitos, mas a melhor prática é enforce a transferência segura] no nível da conta de armazenamento. Esta configuração rejeita qualquer solicitação feita sobre HTTP, bloqueando conexões de clientes mal configurados ou aplicativos legados que não suportam TLS. Habilitar transferência segura é uma alteração de um clique no portal Azure ou pode ser configurada através da Política Azure para fazer cumprir em todas as assinaturas.

Ao construir aplicações que consomem o Armazenamento Azure, use sempre o esquema URI em cadeias de ligação. Para o desenvolvimento e teste, assegure que não são usados endpoints HTTP em pipelines de produção. Os Azure SDKs obrigam HTTPS por padrão ao usar strings de conexão que incluem o sufixo de endpoint padrão.

Requisitos de versão TLS

O Azure Storage suporta TLS 1.0, 1.1 e 1.2 do lado do cliente. No entanto, a Microsoft aconselha fortemente a desativar TLS 1.0 e 1.1 para atender aos padrões de segurança modernos. A partir do Azure Storage REST API versão 2021-06-08, você pode definir uma versão mínima TLS exigência no nível da conta de armazenamento. Este é o lado do servidor forçado: qualquer cliente que tente se conectar com uma versão TLS mais antiga recebe uma resposta 403 Proibida.

Para configurar a versão mínima do TLS:

  • Vai para a conta de armazenamento no portal Azure.
  • Selecione Configuração sob a seção Segurança + rede.
  • Define a versão do TLS mínimo para 1.2.

Esta configuração aplica-se a todos os pontos de avaliação, incluindo o armazenamento Blob, File, Fila e Tabela. Audite para quaisquer aplicações anteriores que possam depender do TLS 1.0 ou 1.1 antes de executar a atualização.

Criptografia SMB para arquivos Azure

Os Arquivos Azure usam o protocolo Bloco de Mensagem do Servidor (SMB) para acesso a partilha de arquivos. O SMB 3.0 e, posteriormente, incluem criptografia incorporada que protege dados em trânsito entre o cliente e o compartilhamento de arquivos. Quando você acessa um compartilhamento de arquivos Azure de um cliente suportado (Windows 8/Server 2012 ou posterior, Linux com cliente do kernel CIFS 4.0+), a conexão é criptografada automaticamente pela rede. Os Arquivos Azure requerem SMB 3.0 ou superior com criptografia para todas as conexões externas; versões anteriores do SMB são bloqueadas.

Para clientes no local que se conectam via VPN ou ExpressRoute, a criptografia SMB garante que os dados que atravessam a internet pública (se aplicável) permaneçam confidenciais. Em redes internas Azure, a criptografia ainda é recomendada para proteger contra ataques de movimento lateral potenciais dentro do datacenter.

Pontos de Finalidade Privados e Pontos de Serviço

Enquanto a criptografia protege dados em trânsito, controles de nível de rede reduzem ainda mais a exposição. Azure Private Endpoints atribui um endereço IP privado à conta de armazenamento da sua rede virtual, efetivamente trazendo o serviço de armazenamento dentro de sua VNet. O tráfego entre sua rede virtual e a conta de armazenamento viaja pela rede de backbone da Microsoft, e não pela internet pública. Mesmo com endpoints privados, a criptografia HTTPS permanece ativa, fornecendo defesa em profundidade.

Os endpoints de serviço fornecem um benefício similar no nível da sub-rede, mas sem um IP privado. Ambas as opções se integram perfeitamente com as configurações de criptografia em trânsito e SSE.

Gestão de Chaves e Rotação

A criptografia eficaz depende de práticas de gerenciamento de chaves fortes. Mesmo com a SSE usando chaves gerenciadas por plataformas, sua organização mantém a propriedade dos dados e a responsabilidade legal pela sua proteção. Chaves devem ser giradas periodicamente para limitar o impacto de um compromisso chave potencial ou para satisfazer os requisitos de conformidade, como PCI DSS, HIPAA ou SOC 2.

Para contas de armazenamento usando o CMK, a rotação é gerenciada através do Azure Key Vault. Você pode configurar uma rotação automática definindo uma política de rotação na chave – por exemplo, a cada 90 dias. O Azure Storage capta a nova versão chave e recripta as chaves de criptografia de dados com a chave mais recente. Nenhuma intervenção manual ou inatividade é necessária. Para chaves gerenciadas por plataforma (SSE padrão), a Microsoft gira internamente as chaves sem visibilidade do cliente.

A utilização da chave de auditoria é simples com os registos de diagnóstico do Key Vault. Exportar os registos para um espaço de trabalho Log Analytics ou o Armazenamento Azure e configurar alertas para operações como , , ou . Qualquer padrão de acesso inesperado à chave pode indicar uma tentativa de descriptografia não autorizada.

Traga sua própria chave (BYOK) com HSM

Para organizações em indústrias altamente regulamentadas, o Azure Key Vault Managed HSM oferece um módulo de segurança de hardware validado para o FIPS 140-2 Level 3 (HSM) para armazenar chaves de criptografia. Você pode gerar a chave no local e transferi-la com segurança para o HSM usando um processo chamado Traga sua própria chave (BYOK)[. Isso garante que a Microsoft nunca tem acesso ao material chave bruto. O BYOK é suportado tanto para cenários CMK quanto para CPK.

Conformidade e alinhamento regulamentar

Criptografia em Azure Storage mapeia diretamente para os requisitos de conformidade em todos os principais frameworks. O SSE satisfaz os mandatos de criptografia em repouso em ISO 27001, SOC 2 e FedRAMP Moderate. A criptografia de infraestrutura se alinha com os requisitos de criptografia em dupla camada vistos em padrões federais específicos. O CMK fornece a separação de chaves necessária para os dados CJIS (Criminal Justice Information Services) e IRS 1075, onde o CSP não deve ter acesso independente a chaves de decodificação.

É sua responsabilidade verificar se sua configuração de criptografia escolhida atende aos controles específicos em seu escopo de conformidade. Azure fornece documentação de conformidade e relatórios de auditoria através da página Microsoft Compliance Offerings. Use a Política Azure para impor configurações de criptografia em toda sua organização, como exigir CMK para todas as contas de armazenamento contendo dados de produção ou mandar uma versão mínima de TLS de 1.2.

Considerações sobre o desempenho

A criptografia no Armazenamento Azure introduz uma sobrecarga mínima. O SSE opera no nível do nó de armazenamento e é otimizado para a transferência. Na maioria dos benchmarks, o custo da criptografia AES-256 está muito abaixo da latência da rede I/O. A criptografia de infraestrutura adiciona um pequeno custo de amplificação de gravação, mas para cargas de trabalho típicas (contas de armazenamento GPv2, blobs de bloco de uso geral), o impacto é bem inferior a 5% para cargas de trabalho sequenciais. Para I/O aleatório ou cargas de trabalho com objetos muito pequenos (menos de 4 KB), a sobrecarga pode ser ligeiramente maior, mas ainda aceitável para o uso da produção.

O CMK adiciona latência de rede para operações de desembrulhamento de chaves porque o serviço de armazenamento deve chamar o Key Vault para descodificar o DEK em cada montagem ou busca. Esta latência é tipicamente inferior a 10 ms por chamada, e o resultado é em cache, de modo que as solicitações subsequentes dentro da mesma sessão não incorrem na sobrecarga. Para a maioria das aplicações, isto é imperceptível.

Resumo das Melhores Práticas

A implementação da criptografia no Armazenamento Azure requer planejamento, mas não complexidade. As seguintes práticas ajudarão você a construir uma postura robusta de criptografia:

  • Verify SSE está habilitado. Está ligado por padrão, mas audite contas existentes criadas com versões ou ferramentas de gerenciamento mais antigas da API do Azure Storage para garantir que nenhuma conta tenha criptografia desabilitada.
  • Ativar a execução segura da transferência em cada conta de armazenamento para garantir uma comunicação HTTPS-only.
  • ]Defina a versão mínima do TLS para 1.2 em todas as contas de armazenamento de produção. Teste a compatibilidade do cliente legado antes da execução.
  • Use chaves geridas pelo cliente para cargas de trabalho sujeitas a requisitos de conformidade que exijam o controle ou a separação de funções.
  • Implementar criptografia de infraestrutura se sua estrutura de conformidade requer explicitamente criptografia de dupla camada.
  • Rota as teclas regularmente–rotação automática usando as políticas do Key Vault para evitar erros manuais.
  • Operações de criptografia de monitor através de Azure Monitor e diagnósticos Key Vault. Defina alertas para deleções de chaves, desabilitando ou falhas de acesso.
  • Use a Política Azure para fazer cumprir os requisitos de criptografia, como exigir CMK para determinados grupos de recursos ou bloquear o acesso HTTP.
  • Considere criptografia do lado do cliente para dados ultrasensíveis que devem ser criptografados antes de atingir o Armazenamento Azure. As bibliotecas do cliente do Armazenamento Azure suportam isso, mas adiciona complexidade e deve ser reservado para cenários excepcionais.
  • Teste seu plano de recuperação de desastres com chaves CMK. Se o seu Key Vault está em uma região diferente e falhar, sua conta de armazenamento ainda pode ser acessada? Use replicação de chave multi-região ou um Cofre de chave de backup.

Ao criar uma encriptação em camadas em repouso, encriptação em trânsito e gestão de chaves fortes, você pode alcançar uma postura de segurança que atenda às exigências de conformidade empresarial moderna sem sacrificar o desempenho ou simplicidade operacional. Para mais detalhes, consulte a documentação de criptografia Azure Storage Service e o guia de transferência segura .