Backups antigos do Moodle guardando dados de quem já saiu

Caso real de produção, contado sem identificar o cliente. Numa revisão de segurança e dados, encontramos um problema que quase ninguém olha até ser tarde: backups antigos que ainda guardavam dados pessoais e credenciais de professores que há muito não usavam a plataforma. Contas de gente já desligada, preservadas indefinidamente dentro de arquivos de backup que se acumulavam sem prazo para sumir.

Ninguém tinha feito nada de errado de propósito. É o cenário mais comum: o backup foi feito "por segurança", ninguém definiu por quanto tempo guardar, e o tempo foi empilhando arquivos. O detalhe é que, do ponto de vista da LGPD, isso é justamente o que não se deve fazer.

Por que isso é um problema (mesmo sem ter havido vazamento)

Um backup que inclui usuários carrega dados pessoais, nome, e-mail, campos de perfil, e informações de conta. A LGPD trabalha com dois princípios simples de entender e fáceis de furar:

• Minimização: guardar só o dado necessário.
• Retenção por prazo: não manter dado pessoal por mais tempo do que se justifica.

Backups eternos, com dados de pessoas que nem estão mais na instituição, quebram os dois. E há o agravante prático: quanto mais dado parado guardado, maior a superfície de risco. Se um arquivo mal protegido cai em mãos erradas, o estrago é proporcional ao que estava guardado sem uso. Dado que não deveria mais existir não pode vazar.

O diagnóstico

O trabalho começou por um inventário, sem chute: quantos backups existiam, onde estavam, o que continham e quem ali já não era usuário ativo. Ficou claro o padrão: ausência de política de retenção, backups incluindo dados de usuários por padrão, e nenhuma rotina de revisão de contas inativas. O dado não estava "exposto" por uma falha exótica; estava exposto por ficar guardado a mais, sem necessidade e sem prazo.

A solução

A correção é de governança, não de heroísmo técnico:

• Política de retenção: definir por quanto tempo cada backup vive e descartar o que passou do prazo.
• Separar os propósitos: um backup técnico, protegido e com prazo, para conseguir restaurar a plataforma, não um arquivo permanente de dados pessoais.
• Tratar as contas inativas: desativar, anonimizar ou remover usuários que já não pertencem à plataforma, conforme a regra do negócio.
• Proteger o armazenamento: acesso restrito a quem realmente precisa dos backups.

O resultado

Superfície de exposição reduzida, backups que continuam servindo para o que existem, restaurar, sem virar um depósito eterno de dados de quem já saiu, e a operação alinhada ao que a LGPD espera. O que antes era um passivo silencioso virou um processo com prazo e responsável.

A lição do caso: backup não é só "ter uma cópia". É decidir o que guardar, por quanto tempo e com que proteção. Sobre fazer isso direito, veja como fazer backup do Moodle (e restaurar sem susto); e sobre a parte de conformidade, o checklist de LGPD no treinamento corporativo cobre os pontos que decidem se o seu projeto é tranquilo ou uma dor de cabeça.

Perguntas frequentes

Leia também

SegurançaBackup exposto + Moodle sem suporte + senha repetida: a cadeia de um vazamentoCaso técnicoUma falha do WordPress que chegou ao banco do MoodleCaso técnicoArquivos infectados chegando ao Moodle: como o monitoramento detectou