Proteja o seu Armazenamento de Blobs do Azure

Armazenamento de Blobs do Azure armazena grandes quantidades de dados de objetos não estruturados em contentores. É frequentemente alvo de exfiltração, ransomware e incidentes de exposição pública. Este artigo fornece recomendações de segurança específicas para contentores de blobs, blobs e espaços de nomes hierárquicos do Azure Data Lake Storage.

Note

Este artigo aborda práticas de segurança específicas do Armazenamento de Blobs do Azure. Para orientações de segurança ao nível da conta, consulte Secure your Armazenamento do Azure account.

Segurança de rede

  • Use o Azure Front Door para domínios personalizados, sites estáticos e qualquer conteúdo de blob disponibilizado publicamente: Termine o TLS no Azure Front Door com um certificado gerido, ative o WAF e restrinja o acesso à rede pública da conta de armazenamento para que apenas o Front Door possa aceder à origem. A funcionalidade de domínio personalizado do Armazenamento do Azure não suporta certificados TLS geridos, e o Front Door adiciona proteção contra WAF, limitação de taxa e registo que o acesso anónimo a contentores não tem. Para mais informações, veja Use Azure Front Door with Armazenamento do Azure blobs.

  • Desative o endpoint estático do site quando não estiver a ser utilizado: O $web contentor permanece legível publicamente enquanto a funcionalidade do site estático estiver ativada, mesmo que allowBlobPublicAccess esteja false. Desative a funcionalidade de site estático nas contas que não precisam. Para mais informações, consulte Alojamento estático de sites em Armazenamento do Azure.

Gestão de identidade e acesso

Acesso público anónimo

  • Desativar o acesso de leitura público e anónimo na conta de armazenamento: Defina a propriedade allowBlobPublicAccess para false de modo que nenhum contentor na conta possa ser público, independentemente da configuração definida ao nível do contentor. Para obter mais informações, consulte Visão geral: remediar o acesso de leitura anónimo para dados em blob.

  • Auditar e remediar qualquer acesso anónimo existente: Use as orientações em Remediar o acesso anónimo de leitura a dados blob para encontrar contentores que permitam o acesso público e convertê-los em acesso privado ou partilha explícita baseada em SAS.

SAS e ABAC ao nível do blob

  • Prefira uma SAS de delegação de utilizador em vez de uma SAS de serviço para acesso a blobs: Uma assinatura de acesso partilhado (SAS) de delegação de utilizador é assinada com credenciais do Microsoft Entra. Revogar a chave de delegação do utilizador invalida imediatamente todos os SAS emitidos a partir dela, oferecendo um mecanismo de revogação de que os SAS de serviço e de conta não dispõem. Para obter mais informações, consulte Criar uma SAS de delegação de usuário.

  • Limite o SAS de serviço com políticas de acesso armazenadas para permitir a revogação: Se tiver de usar um SAS de serviço, associe-o a uma política de acesso armazenada no contentor. Pode então modificar ou eliminar a política para revogar todos os SAS que a referenciam. Sem uma política, um SAS de serviço só pode ser revogado mediante a rotação das chaves da conta, o que afeta todos os outros SAS associados à conta. Para obter mais informações, consulte Definir uma política de acesso armazenado.

  • Utilize tags de índice de blob para condicionar o acesso através de ABAC: combine tags de índice de blob com condições de controlo de acesso baseado em atributos (ABAC) para conceder acesso de leitura apenas a blobs com valores de tag específicos — por exemplo, Classification=Public. Esta abordagem permite que uma única atribuição de função sirva muitos chamadores sem conceder acesso a dados digitados sensíveis. Para mais informações, consulte Autorizar acesso a blobs usando condições ABAC.

Proteção de dados

  • Utilize âmbitos de encriptação para blobs para isolar a encriptação de contentores ou blobs específicos: Os âmbitos de encriptação permitem-lhe aplicar diferentes chaves ou políticas de rotação de chaves ao nível do contentor ou do blob numa única conta. Esta funcionalidade é útil para cargas de trabalho multi-inquilino que partilham uma conta, mas necessitam de controlo de chaves por inquilino. Para mais informações, veja Scope de encriptação para Armazenamento de Blobs.

  • Utilize encriptação do lado do cliente para dados de blob que nunca devem aparecer no servidor em texto não encriptado: Encripte o conteúdo do blob no cliente antes do carregamento. O SDK integra-se com Azure Key Vault ou Managed HSM para gestão de chaves. Combine-o com uma CMK gerida pelo serviço para uma proteção por camadas. Para mais informações, veja Encriptação do lado do cliente para blobs.

Imutabilidade e WORM

  • Configure políticas de retenção baseada no tempo para dados regulados: Aplique retenção temporal ao nível do contentor ou da versão para evitar a modificação ou eliminação de blobs por um período fixo. A imutabilidade ao nível da versão proporciona um controlo mais fino e pode ativar ou estendê-la em versões individuais. Para obter mais informações, consulte Armazenar dados de blob cruciais para o negócio com armazenamento imutável.

  • Use retenções legais para retenção indefinida motivadas por necessidades legais ou investigativas: As retenções legais impedem a eliminação até que um utilizador autorizado resolva explicitamente a retenção, sem duração fixa. Para obter mais informações, consulte Armazenar dados de blob cruciais para o negócio com armazenamento imutável.

  • Bloqueie as políticas de retenção para as tornar não modificáveis: Utilizadores com permissões apropriadas podem encurtar ou eliminar uma política de retenção desbloqueada. Bloquear a apólice torna o período de retenção um compromisso unilateral. Bloqueie apenas depois de validar a duração da apólice. Para mais informações, consulte Configurar políticas de imutabilidade para contentores.

Operações de replicação e cópia de objetos

  • Restringa a replicação de objetos a contas fonte que controla: Configure a lista de fonte-conta permitida da conta de destino para que apenas contas de origem conhecidas e confiáveis possam enviar dados. Para mais informações, consulte Configurar replicação de objetos.

  • Prevenir a replicação de objetos entre inquilinos: Proibir políticas de replicação cujas contas de origem e destino estejam em diferentes inquilinos Microsoft Entra. Esta restrição impede um utilizador autorizado de configurar a replicação para um tenant externo. Para obter mais informações, consulte Impedir a replicação de objetos entre locatários do Microsoft Entra.

  • Restringa o âmbito permitido para operações de cópia: Configure a conta para permitir operações de cópia apenas a partir de contas de origem no mesmo tenant ou na mesma subscrição. Esta configuração bloqueia um caminho comum de exfiltração – copiar de uma conta privada para uma conta controlada pelo atacante. Para mais informações, consulte Âmbito permitido para operações de cópia.

Backup e recuperação

  • Ative o controlo de versões de blobs para preservar versões anteriores nas operações de escrita e eliminação: Quando ativa o controlo de versões, cada operação de escrita ou eliminação cria uma nova versão e mantém o estado anterior. Podes endereçar e restaurar versões. Para obter mais informações, consulte Versionamento de Blob.

  • Ativar a eliminação suave para blobs e para contentores: A eliminação suave mantém blobs e contentores eliminados durante um período de retenção definido, para que possa restaurá-los durante esse período. Configure de forma independente o soft delete ao nível do contentor e ao nível do blob, e ative ambos. Para mais informações, consulte Soft delete para blobs e Soft delete para containers.

  • Ativar a restauração pontual no tempo para contas de blocos de blocos: A restauração pontual funciona com versionamento e soft delete para restaurar uma série de blocos de blocos a um carimbo temporal específico do passado. Esta funcionalidade é útil para a recuperação de ransomware. O restauro para um ponto anterior no tempo exige que ative o controlo de versões, a eliminação recuperável de blobs e o feed de alterações. Para obter mais informações, consulte Restauração point-in-time para blobs de bloco.

  • Ativar o feed de alterações para auditoria e perícia: O feed de alterações é um registo ordenado e inalterável de todas as alterações aos blobs na conta. Além de permitir o restauro num ponto específico no tempo, proporciona um registo de auditoria duradouro para efeitos de investigação. Para mais informações, consulte o suporte a Change feed em Armazenamento de Blobs do Azure.

Azure Data Lake Storage

O Data Lake Storage adiciona um namespace hierárquico e listas de controlo de acesso (ACLs) semelhantes a POSIX ao Armazenamento de Blobs. As ACLs e o RBAC funcionam em conjunto — concedem acesso geral através do RBAC e refinam-no no sistema de ficheiros com ACLs.

  • Utilize o RBAC para um controlo de acesso mais abrangente e as ACLs para um controlo de acesso mais granular: Atribua funções RBAC incorporadas para blobs ao nível do contentor ou da conta para conceder um acesso alargado. Depois, usa ACLs em diretórios e ficheiros para restringir o acesso dentro do contentor. Não use apenas ACLs para as permissões que o utilizador precisa em todo um contentor. O RBAC é mais eficiente para avaliar e auditar. Para mais informações, veja Modelo de Controlo de Acesso no Azure Data Lake Storage.

  • Aplicar ACLs por defeito em diretórios para que novos itens subordinados herdem permissões: As ACLs por defeito aplicam-se a ficheiros e diretórios criados depois de definir a ACL. Configure-as ao nível do diretório para evitar gerir ACLs em ficheiros individuais. Para mais informações, consulte listas de controlo de acesso no Azure Data Lake Storage.

  • Ative o namespace hierárquico na criação da conta: Não pode ativar o namespace hierárquico numa conta existente sem migração. Se souber que uma carga de trabalho usa a semântica do Data Lake Storage, ative-a desde o início em vez de migrar mais tarde. Para mais informações, consulte Azure Data Lake Storage hierarchical namespace.

Registo e monitorização

  • Alerta para ocorrências de acesso anónimo depois de desativar o acesso anónimo: Quando definir allowBlobPublicAccess como false, filtre os registos de armazenamento para AuthenticationType == "Anonymous" e crie um alerta para quaisquer ocorrências. Estas ocorrências indicam um cliente mal configurado ou uma tentativa de sondagem. Para obter mais informações, consulte Monitorar o Armazenamento do Azure.

  • Ativar e agir com base nos resultados da análise de malware do Defender for Storage: Ao ativar a análise de malware, configure uma resposta automatizada (eliminação de blobs, etiqueta de quarentena ou supressão do fluxo de trabalho subsequente) para veredictos de MalwareScanningResult, para que os blobs maliciosos identificados não possam ser disponibilizados aos consumidores. Para mais informações, consulte Responder aos resultados de Análise de Malware no Defender for Storage.

  • Monitorize alterações nas etiquetas de índice de blobs para detetar desvios na classificação: Se utilizar etiquetas de índice de blobs para definir condições de acesso ABAC, as alterações a essas etiquetas alteram diretamente quem pode ler o blob. Registar e emitir alertas sobre operações SetBlobTags em contentores sensíveis. Para mais informações, consulte Gerir e localizar dados no Blob Storage do Azure com etiquetas de índice de blobs.

Passos seguintes

  • Última atualização a