Explore a recuperação, a retenção e a eliminação de dados

Concluído

Depois que os dados de uma organização são examinados e classificados, a próxima decisão a ser tomada é por quanto tempo manter os dados. A recuperação e o descarte de dados são um aspecto essencial do gerenciamento de ativos de dados. Uma política de retenção de dados define os princípios para recuperação e eliminação de dados e é imposta da mesma forma que a reclassificação de dados. As funções de custódia e administração geralmente desempenham essas tarefas de forma colaborativa.

A falha em manter uma política de retenção de dados pode ocasionar a perda de dados ou o descumprimento de requisitos de descoberta legais e regulatórios. A maioria das organizações que não possui uma política de retenção de dados claramente definida tende a usar uma política de retenção padrão de manter tudo. No entanto, isso representa um risco maior em cenários de serviços de nuvem. Por exemplo, uma política de retenção de dados para provedores de serviços de nuvem pode ser considerada pela duração da assinatura, ou seja, enquanto o serviço for pago, os dados serão retidos. Esse contrato de pagamento para retenção talvez não lide com políticas de retenção corporativas ou regulatórias.

A definição de uma política para dados confidenciais pode garantir que os dados sejam armazenados e removidos com base nas melhores práticas. Além disso, é possível criar uma política de arquivamento para formalizar um entendimento sobre quais dados devem ser descartados e quando.

Diagram showing multiple years of data being disposed.

Uma política de retenção de dados deve tratar dos requisitos regulatórios e de conformidade necessários, bem como dos requisitos corporativos de retenção legal. Os dados classificados corretamente devem influenciar as decisões tomadas sobre a duração da retenção. As regras de classificação de dados que pertencem à retenção de dados devem ser abordadas ao migrar para a nuvem. As tecnologias de proteção de dados, como criptografia, gerenciamento de direitos e soluções de prevenção contra perda de dados estão disponíveis na nuvem e podem ajudar a reduzir os riscos de divulgação.

Armazenamento imutável e retenção de dados

O armazenamento imutável para o Armazenamento de Blobs do Azure permite que os usuários armazenem dados comercialmente críticos em um estado WORM (Write Once, Read Many). Esse estado torna os dados não apagáveis e não modificáveis para um intervalo especificado pelo usuário. Os blobs podem ser criados e lidos, mas não modificados ou excluídos durante o intervalo de retenção.

O armazenamento imutável permite:

  • Suporte à política de retenção baseada em tempo: os usuários definem políticas para armazenar dados em um intervalo especificado.
  • Suporte à política de retenção legal: Quando o intervalo de retenção não é conhecido, os usuários podem definir retenções legais para armazenar dados de forma imutável até que a retenção legal seja removida. Quando uma retenção legal é definida, blobs podem ser criados e lidos, mas não modificados ou excluídos. Cada retenção legal é associada a uma marca alfanumérica, definida pelo usuário, que é usada como uma cadeia de caracteres do identificador (como uma ID do caso).
  • Suporte para todos as camadas de blob: as políticas WORM são independentes da camada de Armazenamento de Blobs do Azure e se aplicam a todas as camadas: frequente, esporádica e de arquivos. Os usuários podem fazer a transição dos dados de suas cargas de trabalho para o nível de custo mais otimizado, mantendo a imutabilidade dos dados.
  • Configuração no nível do contêiner: os usuários podem configurar políticas de retenção com base no tempo e marcas de retenção legal no nível do contêiner. Ao usar configurações simples no nível do contêiner, os usuários podem criar e bloquear políticas de retenção baseadas em tempo, estender intervalos de retenção, definir e limpar retenção legal, entre outros. Essas políticas se aplicam a todos os blobs no contêiner, existentes e novos.
  • Suporte a log de auditoria: cada contêiner inclui um log de auditoria, que exibe até cinco comandos de retenção baseados em tempo para políticas de retenção baseadas em tempo bloqueadas. No entanto, o log tem um máximo de três logs para extensões de intervalo de retenção ou retenção baseada em tempo. O log contém a ID de usuário, o tipo de comando, os carimbos de data/hora e o intervalo de retenção. Para retenções legais, o log contém as marcações de ID de usuário, tipo de comando, carimbos de data/hora e retenção legal.

Esse log de auditoria é mantido durante o tempo de vida do contêiner, de acordo com as diretrizes regulamentares da SEC 17a-4 (f). O Log de Atividades do Azure mostra um log mais abrangente de todas as atividades do painel de controle. É responsabilidade do usuário armazenar esses logs de forma persistente, conforme seja necessário para regulamentações ou outros fins.

O armazenamento imutável para Armazenamento de Blobs do Azure é compatível com dois tipos de políticas WORM ou imutáveis: retenção baseada em tempo e retenções legais.

Quando uma política de retenção baseada em tempo ou retenção legal é aplicada em um contêiner, todos os blobs existentes são movidos para o estado imutável (gravação e exclusão protegidas). Todos os novos blobs carregados no contêiner também passam para o estado imutável.

Quando uma política de retenção baseada em tempo é aplicada em um contêiner, todos os blobs no contêiner permanecem no estado imutável durante o período de retenção efetivo. O período de retenção efetivo de blobs existentes é igual ao intervalo de retenção especificado pelo usuário menos o tempo decorrido desde a hora de criação do blob.

Para novos blobs, o período de retenção efetivo é igual ao intervalo de retenção especificado pelo usuário. Como os usuários podem estender o intervalo de retenção, 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, o usuário cria uma política de retenção baseada em tempo com um intervalo de retenção de cinco anos. O blob existente nesse contêiner, testblob1, foi criado um ano atrás. O período de retenção efetivo para testblob1 é de quatro anos. Um novo blob, testblob2, agora é carregado no contêiner. O período de retenção para esse novo blob é de cinco anos.

Quando existe uma expectativa razoável de litígio, as organizações são obrigadas a preservar as ESI (informações armazenadas eletronicamente). Essa expectativa geralmente existe antes de as especificidades do caso serem conhecidas e a preservação geralmente é ampla. Quando você define uma retenção legal, todos os blobs novos e existentes permanecem em um estado imutável até que a retenção legal seja apagada.

Um contêiner pode ter uma retenção legal e uma política de retenção baseada em tempo ao mesmo tempo. Todos os blobs nesse contêiner permanecem no estado imutável até que todas as retenções legais sejam removidas, mesmo que seu período de retenção efetivo expire. Por outro lado, um blob permanece em um estado imutável até que o período de retenção efetivo expire, mesmo que todas as retenções legais tenham sido apagadas.