Armazene dados de blob críticos para os negócios com armazenamento imutável em um estado de gravação única, leitura múltipla (WORM)
O armazenamento imutável do Armazenamento de Blobs do Azure permite aos utilizadores armazenar dados críticos para a empresa num estado WORM (Write Once, Read Many). Enquanto estiver em um estado WORM, os dados não podem ser modificados ou excluídos para um intervalo especificado pelo usuário. Ao configurar políticas de imutabilidade para dados de blob, você pode proteger seus dados contra substituições e exclusões.
O armazenamento imutável para o Armazenamento de Blobs do Azure dá suporte a dois tipos de políticas de imutabilidade:
Políticas de retenção com base no tempo: com uma política de retenção baseada no tempo, os usuários podem definir políticas para armazenar dados por um intervalo especificado. Quando uma política de retenção baseada no tempo é definida, os objetos podem ser criados e lidos, mas não modificados ou excluídos. Após o período de retenção expirar, os objetos podem ser excluídos, mas não substituídos.
Políticas de retenção legal: uma retenção legal armazena dados imutáveis até que a retenção legal seja explicitamente liberada. Quando uma retenção legal é definida, os objetos podem ser criados e lidos, mas não modificados ou excluídos.
Estas políticas podem ser definidas ao mesmo tempo que as outras. Por exemplo, um usuário pode ter uma política de retenção baseada no tempo e uma retenção legal definida no mesmo nível e ao mesmo tempo. Para que uma gravação seja bem-sucedida, você deve ter o controle de versão habilitado ou não ter uma retenção legal ou uma política de retenção baseada no tempo nos dados. Para que uma exclusão seja bem-sucedida, também não deve haver uma retenção legal ou uma política de retenção baseada no tempo nos dados.
O diagrama a seguir mostra como as políticas de retenção baseadas no tempo e as retenções legais impedem operações de gravação e exclusão enquanto elas estão em vigor.
Há dois recursos sob o guarda-chuva de armazenamento imutável: WORM no nível do contêiner e WORM no nível da versão. O WORM no nível do contêiner permite que as políticas sejam definidas apenas no nível do contêiner, enquanto o WORM no nível da versão permite que as políticas sejam definidas no nível da conta, contêiner ou versão.
Sobre o armazenamento imutável para blobs
O armazenamento imutável ajuda organizações de saúde, instituições financeiras e setores relacionados, especialmente organizações de corretores, a armazenar dados com segurança. O armazenamento imutável pode ser usado em qualquer cenário para proteger dados críticos contra modificação ou exclusão.
As aplicações típicas incluem:
Conformidade regulamentar: o armazenamento imutável para o Armazenamento de Blobs do Azure ajuda as organizações a lidar com as 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, nem mesmo por usuários 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 críticas para litígios ou uso comercial em um estado inviolável pelo período desejado até que a retenção seja removida. Esse recurso não se limita apenas a casos de uso legais, mas também pode ser pensado como uma retenção baseada em eventos ou um bloqueio corporativo, onde a necessidade de proteger dados com base em gatilhos de eventos ou política corporativa é necessária.
Conformidade regulamentar
A Microsoft contratou uma empresa de avaliação independente líder especializada em gerenciamento de registros e governança de informações, a Cohasset Associates, para avaliar o armazenamento imutável para blobs e sua conformidade com 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 da Regra 1.31(c)-(d) da CFTC, da Regra 4511 da FINRA e da Regra 17a-4(f) da SEC. A Microsoft direcionou esse conjunto de regras porque elas representam a orientação mais prescritiva globalmente para a retenção de registros para instituições financeiras.
O relatório Cohasset está disponível na Central de Confiabilidade de Serviços da Microsoft. A Central de Confiabilidade do Azure contém informações detalhadas sobre as certificações de conformidade da Microsoft. Para solicitar uma carta de atestado da Microsoft sobre a conformidade com a imutabilidade do WORM, entre em contato com o Suporte do Azure.
Políticas de retenção baseadas no tempo
Uma política de retenção baseada em tempo armazena dados de blob em um formato WORM por um intervalo especificado. Quando uma política de retenção baseada no tempo é definida, os clientes podem criar e ler blobs, mas não podem modificá-los ou excluí-los. Depois que o intervalo de retenção expirar, os blobs podem ser excluídos, mas não substituídos.
Âmbito
Uma política de retenção baseada em tempo pode ser configurada nos seguintes escopos:
- Política WORM no nível da versão: uma política de retenção baseada no tempo pode ser configurada no nível da conta, do contêiner ou da versão. Se estiver configurado no nível da conta ou do contêiner, ele será herdado por todos os blobs na respetiva conta ou contêiner.
- Política WORM no nível do contêiner: uma política de retenção baseada no tempo configurada no nível do contêiner se aplica a todos os blobs nesse contêiner. Os blobs individuais não podem ser configurados com suas próprias políticas de imutabilidade.
Intervalo de retenção para uma política baseada em tempo
O intervalo de retenção mínimo para uma política de retenção baseada no tempo é de um dia e o máximo é de 146.000 dias (400 anos). Quando você configura uma política de retenção baseada em tempo, os objetos afetados permanecem no estado imutável durante o período de retenção efetivo. O período de retenção efetivo para objetos é igual à diferença entre o tempo de criação do blob e o intervalo de retenção especificado pelo usuário. Como o intervalo de retenção de uma política pode ser estendido, o armazenamento imutável usa o valor mais recente do intervalo de retenção especificado pelo usuário para calcular o período de retenção efetivo.
Por exemplo, suponha que um usuário crie uma política de retenção baseada no tempo com um intervalo de retenção de cinco anos. Um blob existente nesse contêiner, testblob1, foi criado há um ano, portanto, o período de retenção efetivo para testblob1 é de quatro anos. Quando um novo blob, testblob2, é carregado no contêiner, o período de retenção efetivo para testblob2 é de cinco anos a partir do momento de sua criação.
Políticas bloqueadas versus desbloqueadas
Quando você configura pela primeira vez uma política de retenção baseada no tempo, a política é desbloqueada para fins de teste. Ao concluir o teste, você pode bloquear a política para que ela esteja totalmente em conformidade com a SEC 17a-4(f) e outras conformidades regulamentares.
As políticas bloqueadas e desbloqueadas protegem contra exclusões e substituições. No entanto, você pode modificar uma política desbloqueada encurtando ou estendendo o período de retenção. Você também pode excluir uma política desbloqueada. Não é possível excluir uma política de retenção baseada em tempo bloqueada. Você pode estender o período de retenção, mas não pode diminuí-lo. É permitido um máximo de cinco aumentos no período de retenção efetivo ao longo do tempo de vida de uma política bloqueada definida no nível do contêiner. Para uma política configurada para uma versão de blob, não há limite para o número de aumentos para o período efetivo.
Importante
Uma política de retenção baseada no tempo deve ser bloqueada para que o blob esteja em um estado imutável compatível (protegido contra gravação e exclusão) para SEC 17a-4(f) e outra conformidade regulamentar. A Microsoft recomenda que bloqueie a política num período de tempo razoável, normalmente inferior a 24 horas. Embora o estado desbloqueado forneça proteção de imutabilidade, o uso do estado desbloqueado para qualquer finalidade que não seja o teste de curto prazo não é recomendado.
Log de auditoria da política de retenção
Cada contêiner com uma política de retenção baseada no tempo habilitada fornece um log de auditoria de política. O log de auditoria inclui até sete comandos de retenção baseados em tempo para políticas de retenção baseadas em tempo bloqueadas. O registro em log normalmente começa depois que você bloqueia a política. As entradas de log incluem o ID do usuário, o tipo de comando, os carimbos de data/hora e o intervalo de retenção. O log de auditoria é mantido durante o tempo de vida da política de acordo com as diretrizes regulatórias SEC 17a-4(f).
O log de atividades do Azure fornece um log mais abrangente de todas as atividades do serviço de gerenciamento. Os logs de recursos do Azure retêm informações sobre operações de dados. É da responsabilidade do utilizador armazenar esses registos de forma persistente, conforme possa ser necessário para fins regulamentares ou outros.
As alterações nas políticas de retenção baseadas no tempo no nível da versão não são auditadas.
Retenções legais
Uma retenção legal é uma política de imutabilidade temporária que pode ser aplicada para fins de investigação legal ou políticas gerais de proteção. Uma retenção legal armazena dados de blob em um formato Write-Once, Read-Many (WORM) até que a retenção seja explicitamente desmarcada. Quando uma retenção legal está em vigor, os blobs podem ser criados e lidos, mas não modificados ou excluídos. Use uma retenção legal quando o período de tempo em que os dados devem ser mantidos em um estado WORM é desconhecido.
Âmbito
Uma política de retenção legal pode ser configurada em qualquer um dos seguintes escopos:
Política WORM no nível da versão: uma retenção legal pode ser configurada em um nível de versão de blob individual para gerenciamento granular de dados confidenciais.
Política WORM no nível do contêiner: uma retenção legal configurada no nível do contêiner se aplica a todos os blobs nesse contêiner. Os blobs individuais não podem ser configurados com suas próprias políticas de imutabilidade.
Etiquetas
Uma retenção legal no nível do contêiner deve ser associada a uma ou mais tags alfanuméricas definidas pelo usuário que servem como cadeias de caracteres de identificador. Por exemplo, uma tag pode incluir um ID de caso ou nome de evento.
Registo de auditoria
Cada contêiner com uma retenção legal em vigor fornece um log de auditoria de política. O log contém o ID do usuário, tipo de comando, carimbos de data/hora e tags de retenção legal. O log de auditoria é mantido durante o tempo de vida da política de acordo com as diretrizes regulatórias SEC 17a-4(f).
O log de atividades do Azure fornece um log mais abrangente de todas as atividades do serviço de gerenciamento. Os logs de recursos do Azure retêm informações sobre operações de dados. É da responsabilidade do utilizador armazenar esses registos de forma persistente, conforme possa ser necessário para fins regulamentares ou outros.
As alterações nas retenções legais no nível da versão não são auditadas.
Opções de recursos de armazenamento imutáveis
A tabela a seguir mostra um detalhamento das diferenças entre WORM no nível do contêiner e WORM no nível da versão:
| Categoria | WORM no nível do contêiner | WORM de nível de versão |
|---|---|---|
| Nível de granularidade da política | As políticas só podem ser configuradas no nível do contêiner. Cada objeto carregado no contêiner herda o conjunto de políticas imutável. | As políticas podem ser configuradas no nível da conta, contêiner ou blob. Se uma política for definida no nível da conta, todos os blobs carregados nessa conta herdarão a política. A mesma lógica segue com os contêineres. Se uma política for definida em vários níveis, a ordem de precedência será sempre Blob -> Container -> Account. |
| Tipos de apólices disponíveis | Dois tipos diferentes de políticas podem ser definidos no nível do contêiner: políticas de retenção baseadas no tempo e retenções legais. | No nível da conta e do contêiner, apenas políticas de retenção baseadas no tempo podem ser definidas. No nível de blob, tanto as políticas de retenção baseadas no tempo quanto as retenções legais podem ser definidas. |
| Dependências de recursos | Nenhum outro recurso é um pré-requisito ou requisito para que esse recurso funcione. | O controle de versão é um pré-requisito para que esse recurso seja usado. |
| Habilitação para contas/contêiner existentes | Esse recurso pode ser ativado a qualquer momento para contêineres existentes. | Dependendo do nível de granularidade, esse recurso pode não estar habilitado para todas as contas/contêineres existentes. |
| Exclusão de conta/contêiner | Depois que uma política de retenção baseada em tempo é bloqueada em um contêiner, os contêineres só podem ser excluídos se estiverem vazios. | Depois que o WORM no nível da versão estiver habilitado em uma conta ou contêiner, eles só poderão ser excluídos se estiverem vazios. |
| Suporte para o Azure Data Lake Storage Gen2 (contas de armazenamento que têm um namespace hierárquico habilitado) | Há suporte para políticas WORM no nível de contêiner em contas que têm um namespace hierárquico. | As políticas WORM de nível de versão ainda não são suportadas em contas que têm um namespace hierárquico. |
Para saber mais sobre o WORM no nível do contêiner, consulte Políticas do WORM no nível do contêiner. Para saber mais sobre o WORM no nível da versão, visite as políticas do WORM no nível da versão.
WORM de nível de contêiner vs WORM de nível de versão
A tabela a seguir ajuda você a decidir qual tipo de política WORM usar.
| Critérios | Uso do WORM no nível do contêiner | Uso do WORM no nível da versão |
|---|---|---|
| Organização dos dados | Você deseja definir políticas para conjuntos de dados específicos, que podem ser categorizados por contêiner. Todos os dados nesse contêiner precisam ser mantidos em um estado WORM pelo mesmo período de tempo. | Não é possível agrupar objetos por períodos de retenção. Todos os blobs devem ser armazenados com um tempo de retenção individual com base nos cenários desse blob, ou o usuário tem uma carga de trabalho mista para que alguns grupos de dados possam ser agrupados em contêineres enquanto outros não podem. Você também pode querer definir políticas no nível do contêiner e políticas no nível do blob dentro da mesma conta. |
| Quantidade de dados que requer uma política imutável | Não é necessário definir políticas em mais de 10.000 contêineres por conta. | Você deseja definir políticas sobre todos os dados ou grandes quantidades de dados que podem ser delineados por conta. Você sabe que, se usar o WORM no nível do contêiner, terá que exceder o limite de 10.000 contêineres. |
| Interesse em habilitar o controle de versão | Você não quer lidar com a habilitação do controle de versão por causa do custo ou porque a carga de trabalho criaria várias versões extras para lidar. | Você quer usar o controle de versão ou não se importa de usá-lo. Você sabe que, se eles não habilitarem o controle de versão, você não poderá manter edições ou substituições em blobs imutáveis como versões separadas. |
| Local de armazenamento (Blob Storage vs Data Lake Storage Gen2) | Sua carga de trabalho está totalmente focada no Azure Data Lake Storage Gen2. Você não tem interesse imediato ou planeja mudar para usar uma conta que não tenha o recurso de namespace hierárquico habilitado. | Sua carga de trabalho está no Armazenamento de Blobs em uma conta que não tem o recurso de namespace hierárquico habilitado e pode usar o WORM de nível de versão agora, ou você está disposto a esperar que o controle de versão esteja disponível para contas que têm um namespace hierárquico habilitado (Azure Data Lake Storage Gen2). |
Camadas de acesso
Todas as camadas de acesso de blob suportam armazenamento imutável. Você pode alterar a camada de acesso de um blob com a operação Definir Camada de Blob. Para obter mais informações, consulte Camadas de acesso para dados de blob.
Configurações de redundância
Todas as configurações de redundância suportam armazenamento imutável. Para obter mais informações sobre configurações de redundância, consulte Redundância de armazenamento do Azure.
Tipos de blob recomendados
A Microsoft recomenda que você configure políticas de imutabilidade principalmente para blobs de bloco e blobs de acréscimo. A configuração de uma política de imutabilidade para um blob de página que armazena um disco VHD para uma máquina virtual ativa é desencorajada, pois as gravações no disco serão bloqueadas ou, se o controle de versão estiver habilitado, cada gravação será armazenada como uma nova versão. A Microsoft recomenda que você revise cuidadosamente a documentação e teste seus cenários antes de bloquear quaisquer políticas baseadas em tempo.
Armazenamento imutável com exclusão suave de blob
Quando a exclusão suave de blob é configurada para uma conta de armazenamento, ela se aplica a todos os blobs dentro da conta, independentemente de uma retenção legal ou política de retenção baseada no tempo estar em vigor. A Microsoft recomenda ativar a exclusão suave para proteção extra antes que quaisquer políticas de imutabilidade sejam aplicadas.
Se você habilitar a exclusão suave de blob e, em seguida, configurar uma política de imutabilidade, todos os blobs que já foram excluídos suavemente serão excluídos permanentemente quando a política de retenção de exclusão suave expirar. Os blobs excluídos suavemente podem ser restaurados durante o período de retenção de exclusão suave. Um blob ou versão que ainda não foi excluído suavemente é protegido pela política de imutabilidade e não pode ser excluído suavemente até que a política de retenção baseada no tempo expire ou a retenção legal seja removida.
Usar o inventário de blob para controlar políticas de imutabilidade
O inventário de blob do Armazenamento do Azure fornece uma visão geral dos contêineres em suas contas de armazenamento e das versões de blobs, instantâneos e blob dentro deles. Você pode usar o relatório de inventário de blob para entender os atributos de blobs e contêineres, incluindo se um recurso tem uma política de imutabilidade configurada.
Quando você habilita 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 os requisitos de negócios e conformidade.
Para obter mais informações sobre o inventário de blobs, consulte Inventário de blobs do Armazenamento do Azure.
Nota
Não é possível configurar uma política de inventário em uma conta se o suporte para imutabilidade no nível de versão estiver habilitado nessa conta ou se o suporte para imutabilidade no nível de versão estiver habilitado no contêiner de destino definido na política de inventário.
Configurando políticas em escala
Você pode usar uma tarefa de armazenamento para configurar políticas de imutabilidade em escala em várias contas de armazenamento com base em um conjunto de condições que você definir. Uma tarefa de armazenamento é um recurso disponível nas Ações de Armazenamento do Azure, uma estrutura sem servidor que você pode usar para executar operações de dados comuns em milhões de objetos em várias contas de armazenamento. Para saber mais, consulte O que são as Ações de Armazenamento do Azure?.
Preços
Não há cobrança de capacidade extra pelo uso de armazenamento imutável. O preço dos dados imutáveis é igual ao dos dados mutáveis. Se você estiver usando o WORM no nível da versão, a conta pode ser maior porque você habilitou o controle de versão e há um custo associado às versões extras que estão sendo armazenadas. Analise a política de preços de controle de versão para obter mais informações. Para obter detalhes de preços sobre o Armazenamento de Blobs do Azure, consulte a página de preços do Armazenamento do Azure.
Criar, modificar ou excluir uma política de retenção baseada no tempo ou retenção legal em uma versão de blob resulta em uma cobrança de transação de gravação.
Se não pagar a sua fatura e a sua conta tiver uma política de retenção ativa baseada no tempo em vigor, aplicam-se as políticas normais de retenção de dados, conforme estipulado nos termos e condições do seu contrato com a Microsoft. Para obter informações gerais, consulte Gerenciamento de dados na Microsoft.
Suporte de funcionalidades
Este recurso é incompatível com a restauração point-in-time e o rastreamento do último acesso. Esse recurso é compatível com failover não planejado gerenciado pelo cliente, no entanto, quaisquer alterações feitas na política imutável após o último tempo de sincronização (como bloquear uma política de retenção baseada em tempo, estendê-la, etc.) não serão sincronizadas com a região secundária. Quando o failover for concluído, você poderá refazer as alterações na região secundária para garantir que ela esteja atualizada com seus requisitos de imutabilidade. Não há suporte para políticas de imutabilidade em contas que tenham o protocolo NFS (Network File System) 3.0 ou o protocolo SSH File Transfer Protocol (SFTP) habilitado.
Algumas cargas de trabalho, como o Backup SQL para URL, criam um blob e adicionam a ele. Se um contêiner tiver uma política de retenção baseada no tempo ativa ou retenção legal em vigor, esse padrão não terá êxito. Consulte Permitir gravações de blob de acréscimo protegido para obter mais detalhes.
Para obter mais informações, consulte Suporte ao recurso de Armazenamento de Blob em contas de Armazenamento do Azure.