Políticas WORM no nível do contêiner para dados de blob imutáveis
Uma política WORM no nível do contêiner é um tipo de política de imutabilidade que pode ser definida no nível do contêiner. Para saber mais sobre o armazenamento imutável para o Armazenamento de Blobs do Azure, confira Armazenar dados de blob críticos para os negócios com o armazenamento imutável em um estado WORM
Disponibilidade
As políticas WORM em nível de contêiner (CLW) estão disponíveis para todos os contêineres novos e atuais. Essas políticas têm suporte para contas de uso geral v2, de blob de blocos Premium, de uso geral v1 (herdadas) e de armazenamento de blobs (herdadas).
Dica
A Microsoft recomenda atualizar as contas de uso geral v1 para serem de uso geral v2 a fim de 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.
Este recurso tem suporte em contas de namespace hierárquico. Se o namespace hierárquico estiver habilitado, não será possível renomear ou mover um blob quando ele estiver no estado imutável. Tanto o nome do blob quanto a estrutura de diretório fornecem dados essenciais no nível do contêiner que não podem ser modificados depois da aplicação da política imutável.
Não há processo de habilitação para esse recurso. Ele está automaticamente disponível para todos os contêineres. Para saber como definir uma política em um contêiner novo ou atual, confira Configurar políticas de imutabilidade WORM em nível de contêiner.
Exclusão
Um contêiner com um conjunto de políticas WORM em nível de contêiner deve estar vazio para que seja possível excluí-lo. Se houver uma política definida em um contêiner com o namespace hierárquico habilitado, um diretório deverá estar vazio para que seja possível excluí-lo.
Cenários
| 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 com relação ao conteúdo e aos metadados do usuário. | A exclusão do contêiner falhará se uma política WORM no nível do contêiner estiver em vigor. | A exclusão da conta de armazenamento falhará se houver um contêiner com pelo menos um blob. |
| 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. As 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 oferecem proteção contra exclusão. |
1 O Armazenamento do Azure permite que a operação Put Blob crie um novo blob. Não são permitidas operações de substituição subsequentes em um caminho de blob atual de um contêiner imutável.
2 A operação Append Block é permitida somente para políticas com a propriedade allowProtectedAppendWrites ou allowProtectedAppendWritesAll habilitada.
Permitir gravações em blobs de acréscimo protegidos
Os blobs de acréscimo são compostos por blocos de dados e otimizados para as operações de acréscimo de dados exigidas pelos cenários de auditoria e registro em log. Por design, os blobs de acréscimo permitem apenas a adição de novos blocos no final do blob. Independentemente da imutabilidade, a modificação ou a exclusão de blocos existentes em um blob de acréscimo não é essencialmente permitida. Para saber mais sobre blobs de acréscimo, confira Sobre blobs de acréscimo.
A configuração da propriedade allowProtectedAppendWrites permite gravar novos blocos em um blob de acréscimo, mantendo a proteção e a conformidade da imutabilidade. Se essa configuração estiver habilitada, você poderá criar um blob de acréscimo diretamente no contêiner protegido por política e continuar a adicionar novos blocos de dados no final dos blobs de acréscimo com a operação Bloco de Acréscimo. Somente novos blocos podem ser adicionados, quaisquer blocos existentes não podem ser modificados ou excluídos. A habilitação dessa configuração não afeta o comportamento de imutabilidade dos blobs de blocos ou de páginas.
A configuração da propriedade AllowProtectedAppendWritesAll fornece as mesmas permissões que a propriedade AllowProtectedAppendWrites e adiciona a capacidade de gravar novos blocos em um blob de blocos. A API de Armazenamento de Blobs não fornece uma maneira de os aplicativos fazerem isso diretamente. No entanto, os aplicativos podem fazer isso usando métodos de acréscimo e liberação disponíveis na API do Data Lake Storage Gen2. Além disso, essa propriedade permite que aplicativos da Microsoft, como Azure Data Factory, acrescentem blocos de dados usando as APIs internas. Se suas cargas de trabalho dependerem de qualquer uma dessas ferramentas, você poderá usar essa propriedade para evitar erros que possam aparecer quando essas ferramentas tentarem acrescentar dados a blobs.
Os blobs de acréscimo permanecem no estado imutável durante o período de retenção efetivo. Como novos dados podem ser acrescentados além da criação inicial do blob de acréscimo, há uma pequena diferença na maneira como o período de retenção é determinado. A retenção efetiva é a diferença entre a hora da última modificação do blob de acréscimo e o intervalo de retenção especificado pelo usuário. Da mesma forma, quando o intervalo de retenção é 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 a propriedade allowProtectedAppendWrites habilitada e um intervalo de retenção de 90 dias. Um blob de acréscimo, o logblob1, é criado no contêiner hoje, e novos logs continuam a ser adicionados ao blob de acréscimo pelos próximos 10 dias. Então, o período de retenção efetivo para logblob1 é de 100 dias a partir de hoje (a hora do último acréscimo +90 dias).
As políticas de retenção baseadas em tempo desbloqueadas permitem que as configurações das propriedades allowProtectedAppendWrites e AllowProtectedAppendWritesAll sejam habilitadas e desabilitadas a qualquer momento. Depois que a política de retenção baseada em tempo for bloqueada, as configurações das propriedades allowProtectedAppendWrites e AllowProtectedAppendWritesAll não poderão ser alteradas.
Limites
Para uma conta de armazenamento, o número máximo de contêineres com uma política imutável (retenção baseada em tempo ou retenção legal) é 10.000.
Para um contêiner, o número máximo de marcas de retenção legal por vez é 10.
O comprimento máximo de uma tag de retenção legal é 23 caracteres alfanuméricos. O comprimento máximo de uma tag de retenção legal é 23 caracteres alfanuméricos.
Para um contêiner, são retidos no máximo 10 logs de auditoria de política de retenção legal durante a duração da política.