LGPD em servidor dedicado: o que é responsabilidade de quem hospeda os dados

LGPD em servidor dedicado: quem é controlador, o que fazer na infraestrutura e como agir em incidente com dados pessoais (prazo de 3 dias úteis).

Para que serve

Quem guarda dados pessoais de clientes, pacientes ou funcionários em um servidor dedicado precisa cumprir a LGPD (Lei nº 13.709/2018). Este artigo explica, de forma prática, quais obrigações da LGPD em servidor dedicado ficam com você, o que configurar no servidor para demonstrar segurança e o que fazer se houver um vazamento. Ele não substitui orientação jurídica: use-o como roteiro técnico e valide os pontos legais com o seu advogado ou encarregado (DPO).

Pré-requisitos

• Saber quais sistemas do servidor tratam dados pessoais (ERP, CRM, banco de dados, e-mail, sites com formulário, backups).
• Acesso administrativo ao servidor e às VMs.
• Alguém na empresa responsável pelo tema (encarregado ou, em empresas pequenas, um canal de contato definido).

Quem é quem na LGPD quando você usa um servidor dedicado

A LGPD separa dois papéis principais:

• Controlador: quem toma as decisões sobre o tratamento (por que coletar, quais dados, por quanto tempo guardar). Se a sua empresa roda o próprio ERP no servidor, ela é a controladora.
• Operador: quem trata dados em nome do controlador, seguindo as instruções dele. Se você é um MSP ou software house e hospeda sistemas dos seus clientes, normalmente é operador em relação a eles, e eles são os controladores.

Na prática, quem tem a senha de root, define os usuários do banco e escolhe onde fica o backup é quem responde pelas medidas técnicas daquele ambiente. O contrato com seus próprios clientes deve deixar claros esses papéis.

LGPD em servidor dedicado: o que a lei exige na parte técnica

O artigo 46 pede medidas de segurança, técnicas e administrativas, capazes de proteger os dados contra acessos não autorizados e situações acidentais ou ilícitas de destruição, perda, alteração ou vazamento. A lei não lista ferramentas, então a forma de mostrar que você cumpriu é ter controles implantados e documentados. Para um servidor dedicado, isso significa:

1. Mapeie os dados. Monte uma planilha simples com: sistema, VM onde roda, tipos de dados pessoais (nome, CPF, saúde, financeiro), finalidade, quem acessa, onde fica o backup e por quanto tempo é guardado. Esse inventário atende boa parte do registro das operações exigido pelo artigo 37.
2. Controle o acesso. Usuários nominais (nada de conta compartilhada), privilégio mínimo e autenticação em dois fatores no Proxmox, no SSH, no RDP e nos painéis. Veja os artigos sobre autenticação em dois fatores e privilégio mínimo desta categoria.
3. Feche o que não precisa estar exposto. Banco de dados, painel do Proxmox (8006), SSH e RDP não devem ficar abertos para a internet. Veja o artigo sobre fechar o acesso e liberar só pela VPN.
4. Criptografe em trânsito e em repouso. HTTPS com TLS 1.2 ou 1.3 nos sistemas web, conexões ao banco por TLS quando saírem da VM e backups criptografados (o Proxmox Backup Server, por exemplo, permite criptografia no cliente).
5. Faça e teste backup fora do servidor. A perda de dados também é incidente de segurança. Guarde ao menos uma cópia em outro local e teste a restauração periodicamente.
6. Registre e guarde logs. Logins, alterações de permissão e acessos administrativos ajudam a responder a pergunta mais difícil de um incidente: "o que foi acessado?". Centralize logs fora da máquina que eles descrevem.
7. Apague o que não precisa mais. Dados antigos, dumps de banco esquecidos em /root ou /tmp e VMs de teste com cópia da produção são vazamentos esperando para acontecer. Para procurar dumps esquecidos:

   sudo find / -xdev \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.dump" -o -name "*.bak" \) -size +1M -mtime +30 2>/dev/null

8. Documente. Uma página interna dizendo quais controles existem, quem é responsável e quando foram revisados vale muito em uma fiscalização.

Incidente com dados pessoais: o que fazer

A Resolução CD/ANPD nº 15/2024 regulamenta a comunicação de incidentes. Os pontos centrais são:

• O controlador deve comunicar à ANPD e aos titulares afetados o incidente que possa gerar risco ou dano relevante, no prazo de 3 dias úteis contados de quando soube que dados pessoais foram afetados. Agentes de pequeno porte têm prazo em dobro.
• A comunicação é feita pelo peticionamento eletrônico da ANPD (SEI!ANPD), com informações como natureza dos dados, titulares afetados, medidas de segurança adotadas, riscos e ações de mitigação.
• O controlador deve manter registro de todos os incidentes, inclusive os que não foram comunicados, por no mínimo cinco anos.
• Se você é operador, a sua obrigação principal é avisar o controlador rapidamente e entregar as informações técnicas que ele precisa para comunicar.

Do lado técnico, os primeiros passos são:

1. Preserve evidências antes de limpar. Faça snapshot da VM afetada no Proxmox e copie os logs para fora do servidor.
2. Contenha. Isole a VM (remova a placa de rede ou bloqueie no firewall do Proxmox), troque senhas e revogue chaves e tokens expostos.
3. Descubra o alcance. Quais tabelas, arquivos e períodos foram acessados. Isso define se há risco relevante.
4. Registre tudo com data e hora. O registro do incidente é obrigatório mesmo quando não houver comunicação.
5. Notifique quem atacou a partir de outra rede, se for o caso. O CERT.br publica recomendações e modelos de notificação de incidentes para redes de origem.

Como saber se você está em dia

• Existe um inventário de dados pessoais por sistema e por VM, atualizado nos últimos 12 meses.
• Todos os acessos administrativos são nominais, com 2FA, e as portas de administração não respondem na internet.
• Há backup criptografado fora do servidor com teste de restauração registrado.
• Existe um procedimento escrito de resposta a incidentes com o prazo de 3 dias úteis e o responsável por comunicar.

Problemas comuns

• "O provedor é responsável pela segurança dos meus dados": a segurança física e a rede do datacenter são do provedor; tudo que roda dentro do seu sistema operacional, sem Gerenciamento contratado, é seu.
• Banco de dados exposto na internet: MySQL (3306), PostgreSQL (5432) e SQL Server (1433) abertos são uma das causas mais comuns de vazamento. Restrinja ao IP da aplicação ou à VPN.
• Dados de produção em ambiente de teste: use dados anonimizados ou mascarados nas VMs de homologação.
• Backup sem criptografia em serviço de terceiros: o backup carrega os mesmos dados pessoais da produção e precisa da mesma proteção.

Perguntas frequentes

A LGPD vale para empresa pequena?

Sim. Microempresas e empresas de pequeno porte podem ter regras simplificadas (como prazos em dobro e dispensa de nomear encarregado, desde que mantenham um canal de contato), mas continuam obrigadas a proteger os dados.

Preciso criptografar o disco do servidor?

A lei não obriga uma técnica específica. Criptografia de disco protege principalmente contra perda física do hardware; contra invasão remota, o que mais pesa é controle de acesso, atualizações e backup criptografado.

Quanto tempo tenho para comunicar um vazamento?

Três dias úteis a partir do momento em que o controlador sabe que dados pessoais foram afetados, conforme a Resolução CD/ANPD nº 15/2024. Agentes de pequeno porte têm o prazo em dobro.

Logs com IP e usuário são dados pessoais?

Podem ser, quando permitem identificar uma pessoa. Defina por quanto tempo guarda os logs e proteja o acesso a eles.

Leitura complementar

• Lei nº 13.709/2018 (LGPD), texto oficial
• ANPD: comunicação de incidente de segurança
• CERT.br: recomendações para notificações de incidentes

Precisa de ajuda?

Se precisar de informações sobre a infraestrutura física do seu servidor para documentar a conformidade, ou se suspeitar de um incidente e precisar de acesso ao console IPMI/iLO, abra um ticket ou chame o suporte 24/7.