Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O armazenamento imutável para Armazenamento de Blobs do Azure permite armazenar dados críticos para o negócio em um estado WORM (Write Once, Read Many). 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, é 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.
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.
Você pode definir essas políticas juntos. Por exemplo, você pode ter tanto uma política de retenção baseada em tempo quanto uma retenção legal definidas no mesmo nível e ao mesmo tempo. Para que uma operação de gravação seja bem-sucedida, você deve ter o versionamento ativado ou não ter nem um bloqueio legal nem uma política de retenção com base no tempo sobre os dados. Para que a exclusão seja bem-sucedida, não pode haver um bloqueio legal ou uma política de retenção baseada em tempo sobre os dados.
O diagrama a seguir mostra como políticas de retenção baseadas em tempo e retenções legais impedem operações de gravação e exclusão enquanto 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 em nível de contêiner permite definir políticas apenas no nível do contêiner, enquanto o WORM em nível de versão permite definir políticas 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 indústrias relacionadas (especialmente as corretoras) a armazenar dados de forma segura. 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: Armazenamento imutável para blobs permite que você armazene informações sensíveis que são críticas para litígios ou uso comercial em um estado à prova de adulteração pelo tempo desejado até que a retenção seja removida. 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 de imutabilidade do 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 você define uma política de retenção baseada em tempo, 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 podem ser excluídos, mas não substituídos.
Scope
Você pode configurar uma política de retenção baseada em tempo nos seguintes escopos:
- Política WORM em nível de versão: Configure uma política de retenção baseada em tempo na conta, no contêiner ou na versão (o controle de versão deve estar ativado na conta). Se você configurar isso no nível da conta ou do contêiner, todos os blobs na respectiva conta ou contêiner herdam a política. Se houver um bloqueio legal em um contêiner, você não poderá criar um WORM em nível de versão para o mesmo contêiner. Essa restrição existe porque a retenção legal impede a geração das versões.
- 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. Você não pode configurar blobs individuais 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, 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 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 ofereça proteção contra imutabilidade, não recomendamos usar o estado desbloqueado para nada além de testes de curto prazo.
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 de recursos do Azure retêm informações sobre operações de dados. Você é responsável por armazenar esses registros de forma persistente, conforme necessário para fins regulatórios ou outros.
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. Um hold legal armazena dados de blob em formato Write Once, Read Many (WORM) até que o hold seja explicitamente resolvido. 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.
Scope
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 no nível de uma versão individual de blob para o gerenciamento granular de dados sensíveis (o controle de versão deve estar habilitado na conta).
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.
Marcas
Você deve associar uma retenção legal em nível de contêiner a uma ou mais tags alfanuméricas definidas pelo usuário que servem como strings de identificadores. Por exemplo, uma tag pode incluir um ID de caso ou 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 de recursos do Azure retêm informações sobre operações de dados. Você é responsável por armazenar esses registros de forma persistente, conforme necessário para fins regulatórios ou outros.
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 | Configure políticas apenas no nível do container. Cada objeto que você envia para o contêiner herda o conjunto de políticas imutável. | Configure políticas no nível da conta, contêiner ou blob. Se você definir uma política no nível da conta, todos os blobs que você enviar para essa conta herdam a política. A mesma lógica segue com contêineres. Se você definir uma política em múltiplos níveis, a ordem de precedência é sempre Blob -> Container -> Account. |
| Tipos de políticas disponíveis | Defina dois tipos diferentes de políticas no nível do contêiner: políticas de retenção baseadas em tempo e retenções legais. | No nível da conta e do contêiner, defina apenas políticas de retenção baseadas em tempo. No nível do blob, defina tanto políticas de retenção baseadas em tempo quanto bloqueios legais. |
| 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 e contêineres existentes | Ative esse recurso a qualquer momento para contêineres existentes. | Dependendo do nível de granularidade, esse recurso pode não estar ativado para todas as contas e contêineres existentes. |
| Exclusão de conta/contêiner | Depois de bloquear uma política de retenção baseada em tempo em um container, você só pode excluir containers se estiverem vazios. | Depois de ativar o WORM em nível de versão em uma conta ou container, você só pode excluí-los se estiverem vazios. |
| Suporte para o Azure Data Lake Storage (contas de armazenamento que têm um namespace hierárquico habilitado) | Suportar políticas WORM em nível de contêiner em contas que possuem um namespace hierárquico. | Políticas WORM em nível de versão ainda não são suportadas em contas que possuem namespace hierárquico. |
Para saber mais sobre WORM em nível de contêiner, veja políticas de WORM em nível de contêiner. Para saber mais sobre o WORM em nível de versão, veja políticas de WORM em nível de versão.
WORM em nível de contêiner vs. WORM em 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ê quer definir políticas para conjuntos de dados específicos, que podem categorizar 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 você tem uma carga de trabalho mista, de modo que alguns grupos de dados possam ser agrupados 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ê quer definir políticas para todos os dados ou grandes quantidades de dados que possam ser delimitadas 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 não ativar o controle de versão, não poderá manter as edições ou sobrescritas 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. Você pode mudar o nível 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. Configurar uma política de imutabilidade para um blob de página que armazena um disco VHD para uma máquina virtual ativa é desencorajado, pois as gravações no disco são bloqueadas ou, se o versionamento estiver ativado, cada gravação é 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 você configura a exclusão suave de blobs para uma conta de armazenamento, isso se aplica a todos os blobs na conta, independentemente de estar em vigor um bloqueio legal ou uma política de retenção baseada em tempo. 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 blobs e depois configurar uma política de imutabilidade, todos os blobs que já tiverem sido excluídos temporariamente serão excluídos permanentemente quando o período de retenção da exclusão temporária expirar. Você pode restaurar blobs que foram deletados suavemente durante o período de retenção de deleção suave. Um blob ou versão que você ainda não eliminou automaticamente está protegido pela política de imutabilidade e não pode ser deletado manualmente até que a política de retenção baseada em tempo expire ou a retenção legal seja 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 Microsoft 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 Microsoft Azure.
Observação
Você não pode configurar uma política de inventário em uma conta se o suporte à imutabilidade em nível de versão estiver ativado nessa conta, ou se o suporte à imutabilidade em nível de versão estiver ativado no contêiner de destino que você define 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 entre múltiplas contas de armazenamento com base em um conjunto de condições que você define. 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, confira 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 em nível de versão, a conta pode ser maior porque você ativou o versionamento, e há um custo associado ao armazenamento de versões extras. 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 Microsoft Azure.
Criar ou eliminar uma política de retenção baseada em tempo ou uma retenção legal em uma versão de blob resulta em uma taxa de transação de escrita. Modificar uma política de retenção baseada em tempo (seja bloqueando-a ou estendendo-a) resulta em uma cobrança de Outras operações. Para mais informações sobre cobranças de transação, veja Operações e Transferência de Dados.
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
Importante
Esse recurso é Incompatível com a restauração pontual e o último acompanhamento de acesso.
Esse recurso é compatível com failover não planejado gerenciado pelo próprio cliente. No entanto, quaisquer mudanças que você faça na política imutável após o último tempo de sincronização (como bloquear uma política de retenção baseada em tempo ou estendê-la) não sincronizam com a região secundária. Após a conclusão do failover, você pode refazer as alterações na região secundária para garantir que ela esteja atualizada em relação aos 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 na URL, criam um blob e, em seguida, adicionam a ele. Se um contêiner tem uma política ativa de retenção baseada em tempo ou uma retenção legal, esse padrão não tem 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 Microsoft Azure.