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

Quando você configura 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. Quando 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 baseada em tempo bloqueada. 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 no número de aumento 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 (versão prévia): 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 um contêiner, que será aplicada por padrão a todos os blobs carregados 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 (versão prévia)

Para configurar políticas de retenção no nível da versão, você deve primeiro habilitar a imutabilidade no nível de versão 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 de versão em um contêiner.

Você pode habilitar o suporte para a imutabilidade no nível de versão no momento em que você cria um 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. 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 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.

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 detalhes sobre as configurações de política de imutabilidade com suporte com base no escopo, consulte Escopo da política de imutabilidade.

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

Importante

As políticas de retenção baseadas em tempo no nível de versão estão atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral. Pode levar até 30 segundos após a habilitação da imutabilidade no nível da versão antes que você possa configurar políticas de retenção baseadas em tempo no nível da versão

Configurar uma política na versão atual

Depois de habilitar o suporte para a imutabilidade no nível de versão para um contêiner, você tem a opção de configurar uma política de retenção baseada em tempo padrão para o contêiner. Quando você configura uma política de retenção baseada em tempo padrão para o contêiner 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 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 permaneça desbloqueada.

Se a política de retenção baseada em tempo padrão para o contêiner for desbloqueada, a versão atual de um blob que herde 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 um contêiner, 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 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 no 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 no 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 no 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
Sem política padrão 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.

Somente as políticas de retenção baseadas em tempo têm uma configuração de propriedade AllowProtectedAppendWrites que 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 Bloco de Acréscimo. Somente novos blocos podem ser adicionados; quaisquer blocos existentes não podem ser modificados ou excluídos. A proteção de imutabilidade de retenção bseada em tempo ainda se aplica, o que impede a exclusão do blob de acréscimo até que o período de retenção efetivo tenha se esgotado. A habilitação dessa configuração não afeta o comportamento de imutabilidade dos blobs de blocos ou de páginas.

Como essa configuração faz parte de uma política de retenção baseada em tempo, 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 baseadas em tempo desbloqueadas permitem que a configuração da propriedade AllowProtectedAppendWrites seja habilitada e desabilitada a qualquer momento. Quando a política de retenção baseada em tempo está bloqueada, a configuração da propriedade AllowProtectedAppendWrites não pode ser alterada.

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 o 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