Armazenar dados de blob comercialmente críticos com armazenamento imutável

O armazenamento imutável para o Armazenamento de Blobs do Azure permite que os usuários armazenem dados críticos aos negócios em um estado WORM (gravar uma vez, reproduzir várias). No estado WORM, os dados não podem ser modificados ou excluídos por um intervalo especificado pelo usuário. Ao configurar políticas de imutabilidade para dados de blob, é possível proteger os dados contra substituições e exclusões.

O armazenamento imutável para o Armazenamento de Blobs do Azure fornece suporte a dois tipos de políticas de imutabilidade:

  • Política de retenção baseada em tempo: os usuários definem políticas para armazenar dados em um intervalo especificado. Quando uma política de retenção baseada em tempo é definida, os objetos podem ser criados e lidos, mas não modificados ou excluídos. Depois que o período de retenção expira, os objetos podem ser excluídos, mas não substituídos. Para saber mais sobre as políticas de retenção baseadas em tempo, veja Políticas de retenção baseadas em tempo para dados de blobs imutáveis.

  • Políticas de retenção legal: uma retenção legal armazena dados imutáveis até ser liberada explicitamente. Quando uma retenção legal é definida, os objetos podem ser criados e lidos, mas não modificados ou excluídos. Para saber mais sobre as políticas de retenção legal, veja Retenções legais para dados de blobs imutáveis.

O diagrama a seguir mostra como as políticas de retenção baseadas em tempo e as retenções legais evitam as operações de gravação e exclusão enquanto elas estão em vigor.

Diagrama mostrando como as políticas de retenção e os controles legais impedem operações de gravação e exclusão

Sobre o armazenamento imutável para blobs

O armazenamento imutável ajuda organizações de saúde, instituições financeiras e indústrias relacionadas, —especialmente organizações de corretoras—, a armazenar dados com segurança. O armazenamento imutável pode ser utilizado em qualquer cenário para proteger dados críticos contra modificação ou exclusão.

Os aplicativos típicos incluem:

  • Conformidade regulatória: armazenamento imutável para armazenamento de Blobs do Azure ajuda as organizações a atender às regulamentações SEC 17a-4 (f), CFTC 1.31 (d), FINRA e outras.

  • Retenção segura de documentos: o armazenamento imutável para blobs garante que os dados não possam ser modificados ou excluídos por nenhum usuário, incluindo aqueles com privilégios administrativos de conta.

  • Retenção legal: o armazenamento imutável para blobs permite que os usuários armazenem informações confidenciais que são essenciais para litígios ou uso comercial em um estado à prova de violação durante a duração desejada até a remoção da retenção. Esse recurso não é limitado apenas a casos de uso jurídico, mas também pode ser considerado como uma retenção baseada em evento ou um bloqueio corporativo, em que a necessidade de proteger os dados com base em gatilhos de evento ou políticas corporativas é necessária.

Conformidade normativa

A Microsoft contratou uma empresa de avaliação independente líder no mercado e especializada em gerenciamento de registros e governança de informações, a Cohasset Associates, para avaliar o armazenamento imutável para blobs e a conformidade dele com os requisitos específicos do setor de serviços financeiros. A Cohasset validou que o armazenamento imutável, quando usado para reter blobs em um estado WORM, atende aos requisitos de armazenamento relevantes dos regulamentos 1.31(c)-(d) do CFTC, 4511 do FINRA e 17a-4(f) do SEC. A Microsoft focou nesse conjunto de regras porque elas representam a orientação mais prescritiva globalmente para retenção de registros em instituições financeiras.

O relatório Cohasset está disponível na Central de Confiança do Serviço da Microsoft. A Central de Confiabilidade do Azure contém informações detalhadas sobre certificações de conformidade. Para solicitar uma carta de atestado da Microsoft sobre a conformidade da imutabilidade de WORM, entre em contato com o Suporte do Azure.

Escopo da política de imutabilidade

As políticas de imutabilidade podem ser definidas para uma versão de blob (versão prévia) ou para um contêiner. A forma como um objeto se comporta em uma política de imutabilidade depende do escopo da política. Para obter mais informações sobre o escopo de cada tipo de política de imutabilidade, veja as seguintes seções:

Dependendo do escopo, é possível configurar uma política de retenção baseada em tempo e uma retenção legal para um recurso (versão de blob ou contêiner). A tabela a seguir resume quais políticas de imutabilidade têm suporte para cada escopo de recurso:

Escopo O contêiner dá suporte a políticas de imutabilidade de nível de versão O contêiner não dá suporte a políticas de imutabilidade de nível de versão
Contêiner Fornece suporte a uma política de imutabilidade de nível de versão padrão. A política padrão se aplica a todas as novas versões criadas no contêiner depois que ele é configurado.

Não fornece suporte à retenção legal.
Fornece suporte a uma política de imutabilidade de nível de contêiner e a uma retenção legal. Uma política em uma versão de blob pode substituir uma política padrão especificada no contêiner.
Versão do blob Fornece suporte a uma política de imutabilidade de nível de versão e a uma retenção legal. N/D

Sobre a visualização

A versão prévia das políticas de imutabilidade de nível de versão está disponível nas seguintes regiões:

  • Canadá Central
  • Leste do Canadá
  • França Central
  • Sul da França

Importante

As políticas de imutabilidade de nível de versão estão atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

Resumo de cenários de imutabilidade

A proteção conferida por uma política de imutabilidade depende do escopo dessa política e, no caso de uma política de retenção baseada em tempo, de sua situação quanto ao bloqueio e à expiração.

Cenários com escopo de nível de versão

A tabela a seguir fornece um resumo das proteções fornecidas pelas políticas de imutabilidade de nível de versão.

Cenário Operações proibidas Proteção de blob Proteção de contêiner Proteção de conta
Uma versão de blob é protegida por uma política de retenção ativa e/ou uma retenção legal está em vigor Delete Blob, Set Blob Metadata, Put Page e Append Block1 A versão de blob não pode ser excluída. Os metadados do usuário não podem ser gravados.

Substituir um blob com Put Blob, Put Block List ou Copy Blob cria uma nova versão.2
A exclusão do contêiner falhará se houver pelo menos um blob no contêiner, independentemente do bloqueio ou não da política. A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner com o armazenamento imutável de nível de versão habilitado.
Uma versão de blob é protegida por uma política de retenção expirada e nenhuma retenção legal está em vigor Set Blob Metadata, Put Page e Append Block1 A versão de blob pode ser excluída. Os metadados do usuário não podem ser gravados.

Substituir um blob com Put Blob, Put Block List ou Copy Blob cria uma nova versão2.
A exclusão do contêiner falhará se houver pelo menos um blob no contêiner, independentemente do bloqueio ou não da política. A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner que contém uma versão de blob com uma política de retenção baseada em tempo bloqueada.

As políticas desbloqueadas não fornecem proteção contra exclusão.

1 A operação Append Block só é permitida para políticas de retenção baseadas em tempo com a propriedade allowProtectedAppendWrites habilitada. Para saber mais, veja Permitir gravações de blobs de acréscimo protegidas. 2 As versões de blob são sempre imutáveis ​​para o conteúdo. Se o controle de versão estiver habilitado para a conta de armazenamento, uma operação de gravação em um blob de bloco criará uma nova versão, com exceção da operação Put Block.

Cenários com escopo de nível de contêiner

A tabela a seguir fornece um resumo das proteções fornecidas pelas políticas de imutabilidade de nível de contêiner.

Cenário Operações proibidas Proteção de blob Proteção de contêiner Proteção de conta
Um contêiner é protegido por uma política de retenção baseada em tempo ativa com o escopo de contêiner e/ou uma retenção legal está em vigor Delete Blob, Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob e Append Block2 Todos os blobs no contêiner são imutáveis ​​para o conteúdo e os metadados do usuário A exclusão do contêiner falhará se uma política de nível de contêiner estiver em vigor. A exclusão da conta de armazenamento falhará se houver um contêiner com pelo menos um blob presente.
Um contêiner é protegido por uma política de retenção baseada em tempo expirada com escopo de contêiner e nenhuma retenção legal está em vigor Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob e Append Block2 Operações de exclusão são permitidas. Operações de substituição não são permitidas. A exclusão do contêiner falhará se houver pelo menos um blob no contêiner, independentemente do bloqueio ou não da política. A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner com uma política de retenção baseada em tempo bloqueada.

As políticas desbloqueadas não fornecem proteção contra exclusão.

1 O Armazenamento do Azure permite que a operação Put Blob crie um novo blob. As operações de substituição seguintes em um caminho de blob existente em um contêiner imutável não são permitidas.

2 A operação Append Block é permitida somente para políticas de retenção baseadas em tempo com a propriedade allowProtectedAppendWrites habilitada. Para saber mais, veja Permitir gravações de blobs de acréscimo protegidas.

Observação

Algumas cargas de trabalho, como o Backup do SQL para URL, criam um blob e o adicionam. Se um contêiner tiver uma política de retenção baseada em tempo ativa ou uma retenção legal em vigor, esse padrão não terá sucesso.

Configurações de conta com suporte

As políticas de imutabilidade têm suporte em contas de armazenamento novas e existentes. A tabela a seguir mostra quais tipos de contas de armazenamento são compatíveis com cada tipo de política:

Tipo de política de imutabilidade Escopo da política Tipos de contas de armazenamento com suporte Dá suporte a namespace hierárquico (versão prévia)
Política de retenção baseada em tempo Escopo de nível de versão (versão prévia) Uso geral v2
Blob de blocos Premium
No
Política de retenção baseada em tempo Escopo de nível de contêiner Uso geral v2
Blob de blocos Premium
v1 de uso geral (herdado)1
Armazenamento de blobs (herdado)
Sim
Retenção legal Escopo de nível de versão (versão prévia) Uso geral v2
Blob de blocos Premium
No
Retenção legal Escopo de nível de contêiner Uso geral v2
Blob de blocos Premium
v1 de uso geral (herdado)1
Armazenamento de blobs (herdado)
Sim

1 A Microsoft recomenda atualizar contas v1 de uso geral para v2 de uso geral para aproveitar mais recursos. Para obter informações sobre como atualizar uma conta de armazenamento v1 de uso geral existente, confira Atualizar uma conta de armazenamento.

Níveis de acesso

Todas as camadas de acesso a blob são compatíveis com o armazenamento imutável. É possível alterar a camada de acesso de um blob com a operação Set Blob Tier. Para obter mais informações, confira Camadas de acesso quente, frio e de arquivos para dados de blob.

Configurações de redundância

Todas as configurações de redundância são compatíveis com o armazenamento imutável. Para configurações com redundância geográfica, o failover gerenciado pelo cliente não tem suporte. Para mais informações sobre as opções de redundância, confira Redundância do Armazenamento do Microsoft Azure.

Suporte a namespace hierárquico

O suporte do armazenamento imutável para contas com um namespace hierárquico está em versão prévia. Para se inscrever, veja Recursos de versão prévia no Azure Data Lake Storage.

Lembre-se de que não é possível renomear ou mover um blob quando ele está no estado imutável e a conta tem um namespace hierárquico habilitado. Tanto o nome do blob quanto a estrutura do diretório fornecem dados essenciais de nível de contêiner que não podem ser modificados depois que a política imutável está em vigor.

Importante

O armazenamento imutável para o Armazenamento de Blobs do Azure em contas com o recurso de namespace hierárquico habilitado está atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

A Microsoft recomenda configurar políticas de imutabilidade principalmente para blobs de blocos e de acréscimo. Não é recomendado configurar uma política de imutabilidade para um blob de página que armazena um disco VHD para uma máquina virtual ativa, pois as gravações no disco serão bloqueadas. A Microsoft recomenda analisar completamente a documentação e testar seus cenários antes de bloquear qualquer política baseada em tempo.

Armazenamento imutável com exclusão reversível de blob

Quando a exclusão reversível de blob é configurada para uma conta de armazenamento, ela se aplica a todos os blobs da conta, independentemente de uma retenção legal ou uma política de retenção baseada em tempo estarem em vigor. A Microsoft recomenda habilitar a exclusão reversível como forma de proteção adicional antes de aplicar qualquer política de imutabilidade.

Se você habilitar a exclusão reversível de blob e, em seguida, configurar uma política de imutabilidade, todos os blobs que já foram excluídos de forma reversível serão excluídos permanentemente após a expiração da política de retenção de exclusão reversível. Blobs com exclusão reversível podem ser restaurados durante o período de retenção de exclusão reversível. Um blob ou versão que ainda não foi excluído de forma reversível está protegido pela política de imutabilidade e não pode ser excluído de forma reversível até que a política de retenção baseada em tempo tenha expirado ou a retenção legal tenha sido removida.

Usar o inventário de blobs para acompanhar políticas de imutabilidade

O inventário de blobs do Armazenamento do Azure fornece uma visão geral dos contêineres em suas contas de armazenamento e os blobs, instantâneos e versões de blob dentro deles. É possível usar o relatório de inventário de blobs para entender os atributos dos blobs e dos contêineres, como se um recurso tem uma política de imutabilidade configurada.

Ao habilitar o inventário de blobs, o Armazenamento do Azure gera um relatório de inventário diariamente. O relatório fornece uma visão geral dos seus dados para que eles atendam aos requisitos de negócios e de conformidade.

Para saber mais sobre o inventário de blobs, veja Inventário de blobs do Armazenamento do Azure (versão prévia).

Preços

Não há nenhum custo de capacidade adicional ao usar o armazenamento imutável. Os dados imutáveis são cobrados da mesma maneira que os dados mutáveis. Para obter detalhes de preço do armazenamento de blobs do Azure, confira a Página de preços do Armazenamento do Microsoft Azure.

Criar, modificar ou excluir uma política de retenção baseada em tempo ou uma retenção legal em uma versão de blob gera um encargo de transação de gravação.

Se você deixar de pagar sua fatura e sua conta tiver uma política de retenção baseada em tempo ativa em vigor, as políticas normais de retenção de dados serão aplicadas, conforme estipulado nos termos e condições de seu contrato com a Microsoft. Para obter informações gerais, confira Gerenciamento de dados na Microsoft.

Suporte a recursos

Esta tabela mostra como a sua conta dá suporte a esse recurso e o impacto no suporte quando você habilita determinadas funcionalidades.

Tipo de conta de armazenamento Armazenamento de Blobs (suporte padrão) Data Lake Storage Gen2 1 NFS 3.0 1
Uso geral v2 Standard Sim Sim 2 Sim 2
Blobs de blocos Premium Sim Sim 2 Sim 2

1 O Data Lake Storage Gen2 e o protocolo NFS (Network File System) 3.0 exigem uma conta de armazenamento com um namespace hierárquico habilitado.

2 Há suporte para o recurso no nível de versão prévia.

Próximas etapas