Escrever uma vez no nível do contêiner, ler muitas políticas (WORM) para dados de blob imutáveis
Uma política WORM (write once, read many) 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, consulte Armazenar dados de blob críticos para os negócios com armazenamento imutável em um estado WORM (write once, read many)
Disponibilidade
As políticas WORM (CLW) no nível de contêiner estão disponíveis para todos os contêineres novos e existentes. Essas políticas são suportadas para contas v2 de uso geral, blob de bloco premium, v1 de uso geral (legado) e armazenamento de blob (legado).
Gorjeta
A Microsoft recomenda atualizar contas v1 de uso geral para v2 de uso geral para que você possa aproveitar mais recursos. Para obter informações sobre como atualizar uma conta de armazenamento v1 de uso geral existente, consulte Atualizar uma conta de armazenamento.
Esse recurso é suportado para contas de namespace hierárquico. Se o namespace hierárquico estiver habilitado, você não poderá renomear ou mover um blob quando ele estiver no estado imutável. Tanto o nome do blob quanto a estrutura de diretórios fornecem dados essenciais no nível do contêiner que não podem ser modificados quando a política imutável estiver em vigor.
Não há nenhum processo de habilitação para esse recurso; está automaticamente disponível para todos os contentores. Para saber mais sobre como definir uma política em um contêiner novo ou existente, consulte Configurar políticas de imutabilidade WORM no nível do contêiner.
Eliminação
Um contêiner com um conjunto de políticas WORM no nível do contêiner deve estar vazio antes que o contêiner possa ser excluído. Se houver uma política definida em um contêiner com namespace hierárquico habilitado, um diretório deverá estar vazio antes de poder ser excluído.
Cenários
| Cenário | Operações proibidas | Proteção de blob | Proteção de contentores | Produção de contas |
|---|---|---|---|---|
| Um contêiner é protegido por uma política de retenção ativa baseada em tempo com escopo de contêiner e/ou uma retenção legal está em vigor | Excluir Blob, Colocar Blob1, Definir Metadados de Blob, Colocar Página, Definir Propriedades de Blob, Blob de Instantâneo, Blob de Cópia Incremental, Acrescentar Bloco2 | Todos os blobs no contêiner são imutáveis para conteúdo e metadados do usuário. | A exclusão de contêiner falhará se uma política WORM no 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 no tempo expirada com escopo de contêiner e nenhuma retenção legal está em vigor | Colocar Blob 1, Definir Metadados de Blob, Colocar Página, Definir Propriedades de Blob, Blob de Instantâneo, Blob de Cópia Incremental, Acrescentar Bloco2 | 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 pelo menos um blob existir no contêiner, independentemente de a política estar bloqueada ou desbloqueada. | A exclusão da conta de armazenamento falhará se houver pelo menos um contêiner com uma política de retenção baseada no tempo bloqueada. As políticas desbloqueadas não fornecem proteção contra exclusão. |
1 O Armazenamento do Azure permite que a operação Colocar Blob crie um novo blob. Operações de substituição subsequentes 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 com a propriedade allowProtectedAppendWrites ou allowProtectedAppendWritesAll habilitada.
Permitir gravações de blobs de acréscimo protegidos
Os blobs de acréscimo são compostos por blocos de dados e otimizados para operações de acréscimo de dados exigidas por cenários de auditoria e registro. Por design, os blobs de acréscimo só permitem a adição de novos blocos ao final do blob. Independentemente da imutabilidade, a modificação ou exclusão de blocos existentes em um blob de apêndice não é fundamentalmente permitida. Para saber mais sobre blobs de acréscimo, consulte 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, em seguida, continuar a adicionar novos blocos de dados ao final do blob de acréscimo com a operação Bloco de acréscimo. Apenas novos blocos podem ser adicionados; Os blocos existentes não podem ser modificados ou excluídos. Habilitar essa configuração não afeta o comportamento de imutabilidade de blobs de bloco ou blobs de página.
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 bloco. A API de armazenamento de Blob não fornece uma maneira para os aplicativos fazerem isso diretamente. No entanto, os aplicativos podem fazer isso usando os métodos append e flush disponíveis na API do Data Lake Storage Gen2. Além disso, essa propriedade permite que aplicativos da Microsoft, como o Azure Data Factory, acrescentem blocos de dados usando APIs internas. Se suas cargas de trabalho dependem de qualquer uma dessas ferramentas, você pode usar essa propriedade para evitar erros que podem aparecer quando essas ferramentas tentam 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 apêndice, há uma pequena diferença na forma como o período de retenção é determinado. A retenção efetiva é a diferença entre o tempo 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, logblob1, é criado no contêiner hoje, novos logs continuam a ser adicionados ao blob de apêndice pelos próximos 10 dias, de modo que o período de retenção efetivo para logblob1 é de 100 dias a partir de hoje (o tempo de seu último apêndice + 90 dias).
As políticas de retenção com base no 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 estiver 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 no tempo ou retenção legal) é 10.000.
Para um contêiner, o número máximo de tags de retenção legais de cada vez é 10.
O comprimento mínimo de uma etiqueta de retenção legal é de três caracteres alfanuméricos. O comprimento máximo é de 23 caracteres alfanuméricos.
Para um contêiner, um máximo de 10 logs de auditoria de política de retenção legal são retidos durante a duração da política.