Armazene dados de blob comercialmente críticos com armazenamento imutável em um estado WORM (gravar uma vez, reproduzir várias)
O armazenamento imutável para o Armazenamento de Blobs do Azure habilita os usuários a armazenar dados comercialmente críticos em um estado WORM (gravar uma vez, ler várias vezes). Durante o estado de WORM, os dados não podem ser modificados nem excluídos em um intervalo especificado pelo usuário. Ao configurar políticas de imutabilidade para dados de blob, você protege seus 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.
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.
Essas políticas podem ser definidas ao mesmo tempo que umas às outras. Por exemplo, um usuário pode ter uma política de retenção baseada em tempo e um conjunto de retenção legal 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 em tempo nos dados. Para que uma exclusão seja bem-sucedida, não deve haver uma retenção legal ou uma política de retenção baseada em tempo nos dados também.
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.
Há dois recursos sob o guarda-chuva do armazenamento imutável: WORM no nível do contêiner e WORMno 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, do contêiner ou da versã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. Ele pode ser usado 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.
Políticas de retenção baseadas em tempo
A política de retenção baseadas em tempo armazena dados de blob em um formato WORM para um intervalo especificado. Quando uma política de retenção baseada em tempo é definida, os clientes podem criar e ler blobs, mas não podem modificá-los ou excluí-los. Após a expiração do intervalo de retenção, os blobs poderão ser excluídos, mas não substituídos.
Escopo
Uma política de retenção baseada em tempo pode ser configurada em um dos seguintes escopos:
- Política WORM no nível da versão: uma política de retenção baseada em tempo pode ser configurada no nível da conta, contêiner ou versão. Se ela estiver configurada no nível da conta ou do contêiner, será herdada por todos os blobs na respectiva conta ou contêiner. Se houver uma retenção legal em um contêiner, o WORM no nível da versão não poderá ser criado para o mesmo contêiner. Isso ocorre porque as versões não podem ser geradas devido à retenção legal.
- Política WORM de nível de contêiner: uma política de retenção baseada em tempo configurada no nível do contêiner se aplica a todos os objetos nesse contêiner. 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 mínimo de retenção para uma política de retenção baseada em tempo é de um dia, e o máximo é de 146.000 dias (400 anos). Ao configurar 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 os 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 da 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 em tempo com um intervalo de retenção de cinco anos. Um blob existente nesse contêiner, o testblob1, foi criado um ano atrás; portanto, o período de retenção efetivo para testblob1 é de quatro anos. Se um novo blob, o testblob2, for carregado no contêiner, o período de retenção efetivo para o testblob2 será de cinco anos a partir do momento da criação.
Políticas bloqueadas versus desbloqueadas
Quando você configura pela primeira vez uma política de retenção baseada em tempo, ela é desbloqueada para fins de teste. Ao terminar o teste, você poderá bloquear a política para que ela esteja em total conformidade com a SEC 17a-4(f) e outras conformidades regulatórias.
As políticas bloqueadas e desbloqueadas protegem contra exclusões e substituições. No entanto, você pode modificar uma política desbloqueada reduzindo 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 bloqueada baseada em tempo. Você pode estender o período de retenção, mas não pode diminuí-lo. É permitido um máximo de cinco aumentos para o período de retenção efetivo durante o tempo de vida de uma política bloqueada que esteja 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 em tempo deve ser bloqueada para que o blob seja colocado em um estado imutável (proteção contra gravação e exclusão) segundo a SEC 17a-4(f) e outras normas de conformidade. A Microsoft recomenda bloquear a política em um período de tempo razoável, geralmente, menos de 24 horas. Embora o estado desbloqueado forneça proteção de imutabilidade, o uso do estado desbloqueado para qualquer finalidade diferente de testes de curto prazo não é recomendado.
Log de auditoria de política de retenção
Cada contêiner com uma política de retenção baseada em tempo habilitada fornece um log de auditoria da 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. Normalmente, o registro em log é iniciado depois que você bloqueia a política. As entradas do log incluem a ID de usuário, o tipo de comando, os carimbos de data/hora e o intervalo de retenção. Este log de auditoria é retido por todo o tempo de vida da política, de acordo com as diretrizes regulatórias da 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 dos recursos do Azure retêm informações sobre operações de dados. É responsabilidade do usuário armazenar esses logs de forma persistente, conforme seja necessário para regulamentações ou outros fins.
As alterações nas políticas de retenção baseadas em tempo no nível de 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 de proteção geral. Uma retenção legal armazena dados de blob em um formato WORM (grava uma vez, lê muitas) até que ela seja explicitamente limpo. Quando uma retenção legal está em vigor, 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 de WORM for desconhecido.
Escopo
Uma política de retenção legal pode ser configurada em qualquer um dos seguintes escopos:
Política WORM de nível de versão: uma retenção legal pode ser configurada em um nível de versão de blob individual para o gerenciamento granular de dados confidenciais.
Política WORM de nível de contêiner: uma retenção legal configurada no nível de contêiner se aplica a todos os blobs nesse contêiner. Blobs individuais não podem ser configurados com suas próprias políticas de imutabilidade.
Marcações
Uma retenção legal de nível de 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 uma ID do caso ou um nome de evento.
Log de auditoria
Cada contêiner com uma retenção legal em vigor fornece um log de auditoria de política. O log contém a ID de usuário, o tipo de comando, carimbos de hora e marcas de retenção legal. Este log de auditoria é retido por todo o tempo de vida da política, de acordo com as diretrizes regulatórias da 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 dos recursos do Azure retêm informações sobre operações de dados. É responsabilidade do usuário armazenar esses logs de forma persistente, conforme seja necessário para regulamentações ou outros fins.
As alterações nas retenções legais no nível da versão não são auditadas.
Opções de recurso de armazenamento imutável
A tabela a seguir mostra um detalhamento das diferenças entre o WORM no nível do contêiner e o WORM no nível da versão:
| Categoria | WORM no nível do contêiner | WORM no nível da 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 de 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 contêineres. Se uma política for definida em vários níveis, a ordem de precedência será sempre Blob –> Contêiner –> Conta. |
| Tipos de políticas disponíveis | Dois tipos diferentes de políticas podem ser definidos no nível do contêiner: políticas de retenção baseadas em tempo e retenção legal. | No nível da conta e do contêiner, somente as políticas de retenção baseadas em tempo podem ser definidas. No nível do blob, as políticas de retenção baseadas em tempo e as retenções legais podem ser definidas. |
| Dependências de recurso | 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 habilitado 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 for bloqueada em um contêiner, os contêineres só poderão ser excluídos se estiverem vazios. | Depois que o WORM no nível de versão estiver habilitado em uma conta ou nível de contêiner, eles só poderão ser excluídos se estiverem vazios. |
| Suporte para o Azure Data Lake Storage (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 no nível da versão ainda não têm suporte em contas que têm um namespace hierárquico. |
Para saber mais sobre o WORM no nível do contêiner, consulte as políticas WORM no nível do contêiner. Para saber mais sobre o WORM no nível da versão, visite políticas WORM no nível de versão.
Nível de contêiner versus WORM no nível de versão
A tabela a seguir ajuda você a decidir qual tipo de política WORM usar.
| Critérios | Uso de WORM no nível do contêiner | Uso de WORM no nível de versão |
|---|---|---|
| Organização de 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 tempo. | Você não pode 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 clusterizados em contêineres, enquanto outros blobs não podem. Talvez você também queira definir políticas de nível de contêiner e políticas no nível de blob na mesma conta. |
| Quantidade de dados que exige uma política imutável | Você não precisa definir políticas em mais de 10.000 contêineres por conta. | Você deseja definir políticas em todos os dados ou grandes quantidades de dados que podem ser delineadas por conta. Você sabe que, se usar o WORM no nível do contêiner, precisará exceder o limite de 10.000 contêineres. |
| Interesse em habilitar o controle de versão | Você não deseja lidar com a habilitação do controle de versão devido ao 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 em 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 (Armazenamento de Blobs versus Data Lake Storage) | Sua carga de trabalho está totalmente focada no Azure Data Lake Storage. 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 no nível da versão agora ou você está disposto a esperar que o controle de versão esteja disponível para contas que tenham um namespace hierárquico habilitado (Azure Data Lake Storage). |
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 saber mais, confira Camadas de acesso 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 mais informações sobre as opções de redundância, confira Redundância do Armazenamento do Microsoft Azure.
Tipos de blob recomendados
A Microsoft recomenda configurar políticas de imutabilidade principalmente para blobs de blocos e de acréscimo. A configuração de uma política de imutabilidade para um blob de páginas 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 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 temporária como forma de proteção extra antes de aplicar qualquer política de imutabilidade.
Se você habilitar a exclusão temporária de blob e, em seguida, configurar uma política de imutabilidade, todos os blobs que já foram excluídos de forma temporária serão excluídos permanentemente após a expiração da política de retenção de exclusão temporária. 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 temporária está protegido pela política de imutabilidade e não pode ser excluído de forma temporária 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.
Observação
Você não poderá 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.
Configuração de 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 conta de armazenamento é um recurso disponível em 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á nenhum custo adicional de capacidade para usar o armazenamento imutável. Os dados imutáveis são cobrados da mesma maneira que os dados mutáveis. Se você estiver usando o WORM no nível de versão, a fatura poderá ser maior porque você habilitou o controle de versão e há um custo associado a versões extras sendo armazenadas. Examine a política de preços de controle de versão para obter mais informações. Para obter detalhes de preço do Armazenamento de Blobs do Azure, confira a Página de preços do Armazenamento do 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
Esse recurso é incompatível com a restauração pontual e o último rastreamento de 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 a última hora de sincronização (como bloqueio de uma política de retenção baseada em tempo, extensão 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 têm o protocolo NFS (Network File System) 3.0 ou o protocolo SFTP (SSH File Transfer Protocol) habilitado.
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. Para saber mais, confira Permitir gravações de blob de acréscimo protegidas.
Para obter mais informações, consulte o suporte a recursos de Armazenamento de Blobs em contas de Armazenamento do Azure.