Políticas de retenção baseadas em tempo para dados de blob imutáveis

A política de retenção baseadas em tempo armazena dados de blob em um formato WORM (Grave uma vez, Leia várias) 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.

Para obter mais informações sobre políticas de imutabilidade para Armazenamento de Blobs, veja Armazenar dados de blob comercialmente críticos com armazenamento imutável.

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 permanecerão 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.

Escopo da política de retenção baseada em tempo

Uma política de retenção baseada em tempo pode ser configurada em qualquer um dos seguintes escopos:

  • Política de nível de versão: uma política de retenção baseada em tempo pode ser configurada para ser aplicada a uma versão de blob para gerenciamento granular de dados confidenciais. Você pode aplicar a política a uma versão individual ou configurar uma política padrão para uma conta de armazenamento ou um contêiner individual, que será aplicada por padrão a todos os blobs carregados nesse conta ou nesse contêiner.
  • Política 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. Objetos individuais não podem ser configurados com suas próprias políticas de imutabilidade.

Os logs de auditoria estão disponíveis no contêiner para políticas de retenção baseadas em tempo tanto no nível da versão quanto no nível do contêiner. Os logs de auditoria não estão disponíveis para uma política com escopo para uma versão de blob.

Escopo da política no nível da versão

Para configurar políticas de retenção no nível da versão, primeiro você precisa habilitar a imutabilidade no nível de versão na conta de armazenamento ou no contêiner pai. A imutabilidade no nível de versão não pode ser desabilitada depois de ser habilitada, embora as políticas desbloqueadas possam ser excluídas. Para obter mais informações, consulte Habilitar suporte para a imutabilidade no nível da versão.

A imutabilidade no nível da versão na conta de armazenamento deve estar habilitada ao criar a conta. Ao habilitar a imutabilidade no nível da versão para uma nova conta de armazenamento, todos os contêineres criados posteriormente nessa conta dão suporte automaticamente à imutabilidade no nível da versão. Não é possível desabilitar o suporte para a imutabilidade no nível da versão em uma conta de armazenamento depois de habilitada, nem é possível criar um contêiner sem suporte para imutabilidade no nível da versão quando ela está habilitada para a conta.

Se você não habilitou o suporte para imutabilidade no nível da versão na conta de armazenamento, pode habilitá-lo em um contêiner individual no momento em que criar o contêiner. Os contêineres existentes também podem dar suporte à imutabilidade no nível da versão, mas devem primeiro passar por um processo de migração. Esse processo pode levar algum tempo e não é reversível. Você pode migrar dez contêineres de cada vez por conta de armazenamento. Para obter mais informações sobre como migrar um contêiner para dar suporte à imutabilidade no nível de versão, consulte Migrar um contêiner existente para dar suporte à imutabilidade no nível de versão.

As políticas de retenção baseadas em tempo no nível de versão exigem que o controle de versão de blob esteja habilitado para a conta de armazenamento. Para saber como habilitar o controle de versão de blobs, confira Habilitar e gerenciar o controle de versão de blobs. Tenha em mente que a habilitação do controle de versão pode ter um impacto nos valores de cobrança. Para obter mais informações, confira a seção Preços e cobrança em Controle de versão de blob.

Depois que o controle de versão estiver habilitado, quando um blob for carregado pela primeira vez, essa versão do blob será a versão atual. Sempre que o blob for substituído, uma nova versão será criada e armazenará o estado anterior do blob. Quando você exclui a versão atual de um blob, a versão atual se torna uma versão anterior e será mantida até ser explicitamente excluída. Uma versão de blob anterior possui a política de retenção baseada em tempo que estava em vigor quando a versão atual se tornou uma versão anterior.

Se uma política padrão estiver em vigor para a conta de armazenamento ou o contêiner, quando uma operação de substituição criar uma versão anterior, a nova versão atual herdará a política padrão para o contêiner ou a conta.

Cada versão pode ter configurada apenas uma política de retenção baseada em tempo. Uma versão também pode ter um controle legal configurado. Para obter mais informações sobre as configurações de política de imutabilidade com suporte baseada no escopo, consulte Escopo da política de imutabilidade.

Para saber como configurar políticas de retenção baseadas em tempo no nível da versão, consulte Configurar políticas de imutabilidade para versões de blob.

Configurar uma política na versão atual

Depois de habilitar o suporte para a imutabilidade no nível da versão para um contêiner ou conta de armazenamento, você tem a opção de configurar uma política de retenção baseada em tempo padrão para o contêiner ou a conta. Quando você configura uma política de retenção baseada em tempo padrão para o contêiner ou a conta e, em seguida, carrega um blob, o blob herda essa política por padrão. Você também pode optar por substituir a política padrão para qualquer blob em upload configurando uma política personalizada para esse blob.

Se a política de retenção baseada em tempo padrão para o contêiner ou a conta for desbloqueada, a versão atual de um blob que herda a política padrão também terá uma política desbloqueada. Depois que um blob individual é carregado, você pode reduzir ou estender o período de retenção para a política na versão atual do blob, ou excluir a versão atual. Você também pode bloquear a política para a versão atual, mesmo que a política padrão no contêiner ou na conta permaneça desbloqueada.

Se a política de retenção baseada em tempo padrão para o contêiner ou a conta for desbloqueada, a versão atual de um blob que herda a política padrão também terá uma política desbloqueada. No entanto, se você substituir a política padrão ao carregar um blob definindo uma política somente para esse blob, a política dele permanecerá desbloqueada até que você a bloqueie explicitamente. Quando a política na versão atual estiver bloqueada, você poderá estender o intervalo de retenção, mas não poderá excluir a política nem reduzir o intervalo de retenção.

Se não houver nenhuma política padrão configurada para o contêiner ou a conta de armazenamento, você poderá carregar um blob com uma política personalizada ou sem nenhuma política.

Se a política padrão em um contêiner ou conta de armazenamento for modificada, as políticas nos objetos dentro desse contêiner permanecerão inalteradas, mesmo se elas tiverem sido herdadas da política padrão.

A tabela a seguir mostra as várias opções disponíveis para definir uma política de retenção baseada em tempo em um blob em upload:

Status da política padrão na conta ou contêiner Carregar um blob com a política padrão Carregar um blob com uma política personalizada Carregar um blob sem política
Política padrão na conta ou contêiner (desbloqueado) O blob é carregado com a política desbloqueada padrão O blob é carregado com a política desbloqueada personalizada O blob é carregado sem política
Política padrão na conta ou contêiner (bloqueado) O blob é carregado com a política bloqueada padrão O blob é carregado com a política desbloqueada personalizada O blob é carregado sem política
Nenhuma política padrão na conta ou no contêiner N/D O blob é carregado com a política desbloqueada personalizada O blob é carregado sem política

Configurar uma política em uma versão anterior

Quando o controle de versão estiver habilitado, uma operação de gravação ou exclusão em um blob cria uma nova versão anterior desse blob que salva o estado do blob antes da operação. Por padrão, uma versão anterior possui a política de retenção baseada em tempo que estava em vigor na versão atual, se ela existir, quando a versão atual se tornou uma versão anterior. A nova versão atual herda a política no contêiner, se houver uma.

Se a política herdada por uma versão anterior for desbloqueada, o intervalo de retenção poderá ser reduzido ou prolongado, ou a política poderá ser excluída. A política em uma versão anterior também pode ser bloqueada para essa versão, mesmo que a política na versão atual esteja desbloqueada.

Se a política herdada por uma versão anterior estiver bloqueada, o intervalo de retenção poderá ser prolongado. A política não pode ser excluída, nem o intervalo de retenção pode ser reduzido.

Se não houver nenhuma política configurada na versão atual, a versão anterior não herdará nenhuma política. Você pode configurar uma política personalizada para a versão.

Se a política em uma versão atual for modificada, as políticas nas versões anteriores existentes permanecerão inalteradas, mesmo que a política tenha sido herdada de uma versão atual.

Escopo da política no nível do contêiner

Uma política de retenção baseada no tempo no nível do contêiner se aplica a todos os objetos em um contêiner, tanto nos novos quanto nos já existentes. Para uma conta com um namespace hierárquico, uma política no nível do contêiner também se aplica a todos os diretórios no contêiner.

Quando uma política de retenção baseada em tempo é aplicada a um contêiner, todos os blobs existentes são movidos para um estado WORM imutável em menos de 30 segundos. Todos os novos blobs que forem carregados nesse contêiner de política protegido também serão movidos para um estado imutável. Quando todos os blobs estiverem em um estado imutável, as operações de substituição ou exclusão no contêiner imutável não serão permitidas. No caso de uma conta com namespace hierárquico, os blobs não podem ser renomeados ou movidos para um diretório diferente.

Os seguintes limites se aplicam às políticas de retenção no nível do contêiner:

  • Para uma conta de armazenamento, o número máximo de contêineres com políticas imutáveis baseadas em tempo bloqueadas é de 10.000.
  • Para um contêiner, o número máximo de edições para estender um intervalo de retenção para políticas baseadas em tempo bloqueadas é de cinco.
  • Para um contêiner, no máximo sete logs de auditorias de políticas de retenção baseadas em tempo são mantidos para uma política bloqueada.

Para saber como configurar uma política de retenção baseada em tempo em um contêiner, consulte Configurar políticas de imutabilidade para contêineres.

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 de propriedade AllowProtectedAppendWrites permite a gravação de novos blocos em um blob de acréscimo, mantendo a proteção contra imutabilidade e a conformidade. 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 de 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.

Observação

Essa propriedade está disponível apenas para políticas de nível de contêiner. Essa propriedade não está disponível para políticas de nível de versão.

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 uma 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).

Políticas de retenção desbloqueadas baseadas em tempo permitem que a configuração da propriedade 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 de propriedade AllowProtectedAppendWrites e AllowProtectedAppendWritesAll não poderão ser alteradas.

Log de auditoria

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. 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 do contêiner, 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.

Próximas etapas