Você consegue eliminar dados quando precisa? Um checklist de retenção e eliminação para aplicações auto-hospedadas

Porque a eliminação é um requisito de seleção da aplicação, e não apenas uma tarefa da política de privacidade

Uma aplicação pode ser fácil de implementar, exportar e incluir em cópias de segurança, mas continuar difícil de governar quando é necessário remover informação. A questão prática não é apenas saber se a interface tem um botão «Eliminar». É saber se a sua equipa consegue localizar os dados relevantes, aplicar a regra de retenção correta, preservar exceções justificadas e apresentar evidências do que aconteceu.

Isto é importante para dados pessoais, mas também é uma preocupação operacional relativamente a registos de clientes, dados de colaboradores, ficheiros carregados, comentários, credenciais, materiais de projeto e informação de diagnóstico. As [orientações da Comissão Europeia sobre o RGPD](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) descrevem a limitação da conservação como manter dados pessoais apenas durante o tempo necessário e estabelecer prazos para os apagar ou rever. Este é um princípio operacional útil, mesmo quando o RGPD não é o único enquadramento aplicável à sua organização.

Trate a capacidade de eliminação como um critério de adoção. Avalie-a durante uma fase de teste ou prova de conceito, quando ainda pode escolher uma aplicação diferente ou conceber controlos compensatórios. Não presuma que o autoalojamento torna a eliminação simples: os dados podem estar distribuídos pela base de dados da aplicação, armazenamento persistente, cópias de segurança, logs e serviços ligados.

• Torne a retenção e a eliminação num critério de aceitação documentado, a par do controlo de acesso, exportações, cópias de segurança e restauro.
• Avalie os componentes da implementação real, não apenas a documentação do produto ou os rótulos da interface.
• Exija um teste repetível com dados de exemplo antes de colocar informação de produção no sistema.
• Encaminhe questões legais, contratuais e de retenção específicas do setor para os consultores internos ou externos adequados.

Comece por um inventário de dados: registos, ficheiros, comentários, perfis de utilizador, eventos de auditoria, logs, exportações e dados derivados

Não é possível eliminar informação de forma fiável se não a tiver mapeado. Crie um inventário com base em tipos de dados e cópias, em vez de depender de uma única categoria, como «dados de clientes». Comece pelo que os utilizadores conseguem ver e, depois, siga os percursos técnicos que processam, replicam ou retêm esses dados.

Para cada categoria, registe a localização no sistema, o responsável pelos dados, a finalidade, a regra de retenção, o método de eliminação, as funções com acesso, as integrações, o tratamento em cópias de segurança e a fonte de evidência. As [orientações do NIST sobre gestão de logs](https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-92.pdf) recordam de forma útil que a retenção e a eliminação se aplicam tanto às camadas de sistema como de infraestrutura; os dados da aplicação, por si só, não constituem o inventário completo.

Inclua cópias derivadas e operacionais. Um nome ou identificador pode surgir num comentário, nome de ficheiro de anexo, folha de cálculo exportada, notificação, índice de pesquisa, entrada de cache ou metadados de logs. A [documentação do Docker sobre configuração de logs](https://docs.docker.com/engine/logging/configure/) também indica que alguns controladores de logs podem acrescentar aos registos valores de variáveis de ambiente e etiquetas de contentores; por isso, reveja o que a sua implementação coloca nesses campos.

• Registos principais: contactos, transações, projetos, pedidos, conteúdos, formulários e objetos de negócio.
• Dados relacionados com utilizadores: perfis, identificadores de autenticação, funções, preferências e estado da conta.
• Material gerado por utilizadores: carregamentos, anexos, comentários, revisões, imagens e documentos incorporados.
• Dados operacionais: eventos de auditoria, logs da aplicação, logs de contentores, logs da base de dados, relatórios de erros e métricas, quando relevante.
• Cópias derivadas: exportações, relatórios, índices de pesquisa, caches, pré-visualizações, notificações e cargas de tarefas em segundo plano.
• Cópias de armazenamento e resiliência: dumps de base de dados, volumes persistentes, snapshots do armazenamento de ficheiros e arquivos de cópias de segurança.
• Cópias externas: fornecedores de e-mail, fornecedores de identidade, destinatários de webhooks, plataformas de análise, ferramentas de automatização e armazenamento de objetos.

Defina os eventos que desencadeiam retenção, eliminação, anonimização ou obrigação de preservação

Um calendário de retenção deve ser orientado por eventos. «Conservar durante dois anos» está incompleto se ninguém souber quando o prazo começa, o que o termina, quem aprova uma exceção e como a regra é executada. Entre os eventos desencadeadores comuns estão o encerramento de conta, o fim de contrato, a conclusão de projeto, a retirada de consentimento, a conclusão de trabalho de apoio e um pedido de eliminação aprovado.

Separe eliminação de anonimização. A eliminação visa remover os dados identificados dentro do âmbito definido do sistema. A anonimização pode permitir que um registo continue útil para relatórios apenas se já não identificar uma pessoa no contexto relevante. Não chame anonimização a uma simples remoção do nome apresentado sem avaliar os campos restantes e a possibilidade de associação.

Defina também procedimentos de obrigação de preservação antes de surgir um caso urgente. O [artigo 17.º do RGPD](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679) estabelece um direito ao apagamento em circunstâncias específicas, mas esse direito é condicional e não absoluto. As [orientações do NIST sobre gestão de logs](https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-92.pdf) apelam igualmente a que os pedidos de preservação especifiquem como os registos de logs afetados são marcados, armazenados e protegidos. O seu fluxo de trabalho precisa de uma forma documentada de suspender a destruição de rotina quando se aplica uma obrigação válida, limitando a preservação à informação afetada e revendo-a periodicamente.

• Para cada classe de dados, defina: evento desencadeador, período de retenção ou intervalo de revisão, ação, aprovador, via de exceção e evidência conservada.
• Indique se a ação é eliminação permanente, arquivo, retenção restrita, anonimização ou pseudonimização.
• Registe o âmbito de uma obrigação de preservação: assuntos afetados, fontes de dados, data de início, responsável pela guarda, restrições de acesso e data de revisão.
• Registe o motivo quando um pedido de eliminação é recusado, adiado ou cumprido apenas parcialmente.
• Defina como termina uma preservação e como é retomado o processamento normal do ciclo de vida depois disso.

Teste o que significa «eliminar» na aplicação: eliminação lógica, apagamento permanente, arquivo e desativação de conta

Os termos numa interface não são garantias técnicas. «Eliminar», «remover», «arquivar», «desativar» e «inativar» podem produzir resultados muito diferentes. Um item eliminado pode ficar oculto para utilizadores normais, mas continuar disponível para administradores; uma conta pode ficar impedida de iniciar sessão enquanto o seu perfil e conteúdo permanecem intactos; um arquivo pode reter intencionalmente o registo completo.

Execute um teste controlado com dados sintéticos e identificáveis de forma única. Crie um registo, comentários relacionados, um anexo e uma conta de utilizador, quando a aplicação o permitir. Depois, execute cada ação disponível e inspecione os resultados esperados para utilizadores e administradores. Teste os limites das funções: utilizadores comuns, gestores, administradores e clientes de API ainda conseguem encontrar ou obter o conteúdo?

Se a aplicação utiliza PostgreSQL, distinga a visibilidade ao nível da aplicação da remoção física imediata de versões antigas de linhas. A [documentação do PostgreSQL sobre vacuuming](https://www.postgresql.org/docs/current/routine-vacuuming.html) explica que, sob MVCC, um DELETE ou UPDATE não remove imediatamente a versão antiga da linha; o VACUUM recupera mais tarde o espaço para reutilização. O VACUUM normal geralmente torna o espaço reutilizável, em vez de o devolver ao sistema operativo, enquanto o VACUUM FULL reescreve uma tabela para a compactar. Isto é um facto de manutenção de bases de dados, não uma razão para contornar controlos da aplicação ou fazer alegações não suportadas sobre recuperabilidade. Estabeleça o padrão de verificação adequado ao seu caso de utilização com as partes interessadas técnicas e de conformidade qualificadas.

• O item está ausente de vistas normais, pesquisas, APIs e ecrãs administrativos?
• Um administrador consegue restaurá-lo? Em caso afirmativo, com que função e durante quanto tempo?
• A eliminação é propagada para registos subordinados, comentários, anexos e revisões?
• A eliminação de uma conta é diferente da desativação ou revogação de acesso?
• A aplicação fornece uma exportação ou registo de auditoria da ação sem reter conteúdo desnecessário?
• Estão disponíveis eliminação em massa e ações de retenção automatizadas, ou o processamento manual é a única via?

Siga os dados relacionados: anexos, revisões, índices de pesquisa, notificações, caches e dados de tarefas em segundo plano

Um teste de eliminação bem-sucedido segue relações, e não apenas o registo principal. Comece por um marcador conhecido no seu registo sintético e procure-o em conteúdo relacionado. Reveja tabelas de base de dados apenas quando estiver autorizado e for competente para o fazer; caso contrário, peça ao responsável pela manutenção da aplicação que explique o modelo de dados e forneça evidências suportadas.

Os anexos exigem atenção especial porque podem estar numa base de dados, num diretório persistente local ou em armazenamento externo de objetos. Revisões e pré-visualizações de documentos podem sobreviver à versão atual. Índices de pesquisa e caches podem manter-se temporariamente desatualizados. Notificações por e-mail e tarefas em segundo plano em fila podem já conter valores copiados. Decida que atraso, se algum, é aceitável para cada componente e como irá verificar a remoção posterior.

A configuração do armazenamento de objetos pode alterar o significado de eliminar. A [AWS documenta para o S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html) que, num bucket com controlo de versões ativado, um pedido de eliminação sem um ID de versão acrescenta um marcador de eliminação em vez de apagar permanentemente o objeto. A eliminação permanente exige a eliminação das versões retidas especificadas. Se uma aplicação utiliza armazenamento de objetos com versões ou um serviço compatível, teste o comportamento exato do armazenamento e a sua capacidade de identificar todas as versões relevantes.

• Registe a localização dos anexos e se os ficheiros são copiados, transformados ou pré-visualizados.
• Verifique revisões, histórico, funcionalidades de lixo ou reciclagem e as respetivas definições de expiração.
• Procure o marcador de teste antes e depois da eliminação através das pesquisas e APIs suportadas pela aplicação.
• Identifique o comportamento de atualização de cache e índice, incluindo quaisquer tarefas assíncronas.
• Inspecione modelos de notificações, percursos de entrega de e-mail e filas de tarefas para detetar conteúdo copiado.
• Para armazenamento externo de objetos, verifique controlo de versões, marcadores de eliminação, regras de ciclo de vida e evidências de eliminação.

Verifique os sistemas ligados: fornecedores de identidade, serviços de e-mail, webhooks, análises, ferramentas de automatização e armazenamento externo

As integrações tornam os dados da aplicação mais úteis, mas alargam o perímetro da eliminação. Uma aplicação pode remover um registo local enquanto um fornecedor de e-mail retém uma notificação, um fluxo de automatização armazena a sua carga, um destino de webhook recebe uma cópia ou um fornecedor de identidade conserva atributos de conta de acordo com as suas próprias regras de ciclo de vida.

Documente cada ligação de saída e de entrada. Para fluxos de saída, identifique que campos são transmitidos, se é enviada uma carga completa ou um identificador, se novas tentativas ou processamento de mensagens não entregues retêm dados e se o destinatário os consegue eliminar. Para fluxos de entrada, identifique se o sistema externo pode recriar um registo após a eliminação.

Este é também um ponto de decisão. Se uma integração crítica não consegue suportar os seus requisitos de retenção e não existe uma alternativa arquitetural aceitável, não trate um botão local «Eliminar» da aplicação como suficiente. Escolha uma conceção de integração ou aplicação diferente.

• Identidade: identificadores de conta, atributos de perfil, processo de desprovisionamento e regras de fonte de verdade.
• E-mail: conteúdo das mensagens, anexos, logs de entrega, listas de supressão e controlos de retenção.
• Webhooks e automatização: conteúdo das cargas, novas tentativas, históricos de fluxos de trabalho, logs de execução e destinatários subsequentes.
• Análises: campos de eventos, identificadores, dados relacionados com IP quando relevante e interface de eliminação.
• Armazenamento externo: ciclo de vida dos objetos, controlo de versões, réplicas, controlos de acesso e registos de auditoria.
• Documente um contacto ou responsável por cada sistema ligado e cada percurso de eliminação.

Separe a eliminação de dados ativos da retenção de cópias de segurança e dos procedimentos de restauro

A eliminação de dados ativos e a expiração de cópias de segurança resolvem problemas diferentes. Remover informação da aplicação de produção não a remove automaticamente de arquivos de cópias de segurança já criados. Inversamente, expirar cópias de segurança não prova que a aplicação ativa eliminou um registo. Documente ambos os ciclos de vida de forma explícita.

O [Docker indica](https://docs.docker.com/engine/storage/volumes/) que um volume de dados persiste após o contentor ser eliminado. Por isso, eliminar ou recriar um contentor não é evidência de que os dados subjacentes da aplicação foram removidos. O Docker também documenta procedimentos para criar cópias de segurança dos conteúdos de volumes e restaurá-los no mesmo volume de contentor ou noutro, motivo pelo qual os percursos de restauro devem integrar a avaliação.

Numa aplicação gerida pela Airbip, as instâncias são executadas como cargas de trabalho Docker em servidores cloud da Airbip, e a Airbip inclui cópias de segurança diárias, semanais e mensais configuráveis. Confirme no website ativo da Airbip quais as opções de frequência e retenção disponíveis e como se alinham com as suas regras de eliminação ao nível da aplicação. A gestão da infraestrutura não altera as responsabilidades da sua organização quanto à retenção, ao acesso, às obrigações de preservação e ao âmbito da eliminação.

Teste o restauro em segurança. Restaure uma cópia de segurança para um ambiente isolado e com acesso controlado, quando permitido, verifique que os dados históricos esperados estão presentes e confirme que não podem ser confundidos com dados atuais de produção. Defina quem pode autorizar um restauro, que controlos se aplicam após o restauro e como são tratados os dados restaurados após o fim do teste ou incidente.

• Crie um calendário de retenção separado para dados de produção, cópias de segurança, snapshots e arquivos exportados.
• Identifique todas as localizações, frequências, janelas de retenção, mecanismos de encriptação e autoridades de restauro das cópias de segurança no seu ambiente documentado.
• Indique se os pedidos de eliminação afetam apenas cópias de segurança futuras e durante quanto tempo as cópias históricas podem permanecer segundo o calendário de cópias de segurança.
• Teste um procedimento de restauro sem substituir dados de produção.
• Defina controlos para impedir que o restauro de uma cópia de segurança obsoleta reintroduza dados silenciosamente em produção.
• Não equipare remoção de contentor, remoção de volume, expiração de cópia de segurança e sanitização de suporte; são controlos distintos.

Avalie as evidências administrativas: logs de eliminação, trilhos de auditoria, relatórios exportáveis e limites documentados

Um processo de eliminação é mais fácil de defender e operar quando produz evidências proporcionais. No mínimo, deverá conseguir identificar o pedido ou evento desencadeador, a decisão, o operador ou processo automatizado, a data, os sistemas abrangidos, as exceções e o estado de conclusão. Evite criar um trilho de auditoria que reproduza desnecessariamente os dados que pretendia eliminar.

Verifique se a aplicação oferece eventos de auditoria, relatórios administrativos ou APIs suportadas capazes de produzir essas evidências. Se as evidências estiverem incompletas, avalie se um registo operacional documentado pode colmatar a lacuna. Um registo manual pode ser aceitável para atividades de baixo volume, mas torna-se frágil quando estão envolvidos muitos utilizadores, integrações ou localizações de armazenamento.

Os logs precisam dos seus próprios controlos. O [NIST recomenda](https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-92.pdf) que as organizações tratem da retenção, eliminação, preservação e responsabilidade pela infraestrutura de gestão de logs. O [Docker suporta vários controladores e destinos de logs](https://docs.docker.com/engine/logging/configure/). Também indica que alterar a configuração predefinida de logs aplica-se a contentores criados posteriormente, enquanto os contentores existentes mantêm a configuração atual até serem recriados. Verifique a configuração implementada, em vez de assumir que uma alteração de política já alterou todas as cargas de trabalho.

• Consegue exportar um relatório de eliminação que apresente estado e carimbos de data e hora sem expor conteúdo sensível desnecessário?
• O trilho de auditoria distingue uma ação de utilizador, uma ação de administrador e uma tarefa de retenção automatizada?
• Consegue documentar uma conclusão parcial, uma obrigação de preservação ou uma recusa justificada?
• Para onde vão os logs de contentores, plataforma e aplicação, e quem é responsável pelas respetivas definições de retenção e eliminação?
• As alterações de configuração exigem a recriação da carga de trabalho antes de produzirem efeito?
• Os registos de evidência têm controlo de acesso e são retidos apenas durante o tempo necessário?