Como adequar uma VPS à LGPD em 7 controles

Resposta direta

Adequar uma VPS à LGPD exige combinar governança de dados com controles técnicos verificáveis. A empresa deve saber quais dados pessoais estão no servidor, por que são tratados, quem pode acessá-los, por quanto tempo serão mantidos e como serão eliminados. Na infraestrutura, isso se traduz em acesso SSH por chave, autenticação multifator no painel, firewall, atualizações, criptografia, backups testados, logs protegidos e um plano de resposta a incidentes. A localização da VPS também entra na análise, mas a LGPD não exige, de forma geral, que todo dado permaneça no Brasil. Se houver armazenamento, suporte ou replicação no exterior, a transferência internacional precisa ser identificada e enquadrada nos mecanismos legais aplicáveis.

Nenhuma configuração isolada torna uma VPS compatível com a LGPD. Um disco criptografado não corrige coleta excessiva, assim como um datacenter brasileiro não substitui controle de acesso, contrato com fornecedores ou política de retenção. A conformidade nasce da ligação entre finalidade jurídica, arquitetura e rotina operacional.

Na prática, comece por um inventário simples. Registre aplicações, bancos, buckets, volumes, filas, backups, logs e serviços externos. Depois associe cada ativo a um responsável, uma finalidade, uma categoria de dados, um prazo de retenção e um procedimento de exclusão. Esse documento orientará as decisões técnicas e ajudará a demonstrar por que cada controle existe.

A LGPD envolve análise jurídica e organizacional. Este artigo oferece orientação técnica e editorial, não substitui aconselhamento jurídico, atuação do encarregado nem avaliação específica de risco. Organizações que tratam dados sensíveis, informações de crianças ou grandes volumes devem considerar um Relatório de Impacto à Proteção de Dados Pessoais e revisão especializada.

Resumo rápido

• A LGPD não certifica VPS nem cria uma configuração única aplicável a todas as empresas.
• O primeiro passo é mapear dados pessoais, finalidades, sistemas, responsáveis e fornecedores.
• Hospedagem no Brasil pode simplificar alguns fluxos, mas não elimina outras obrigações legais.
• SSH por chave, MFA, privilégio mínimo, firewall e atualizações reduzem acessos indevidos.
• Criptografia precisa proteger conexões, discos, backups e chaves de maneira separada.
• Retenção e exclusão devem alcançar produção, réplicas, logs e ciclos de backup.
• Logs e alertas precisam permitir investigação sem registrar senhas, tokens ou conteúdo excessivo.

Transformar esses pontos em um projeto executável requer evidências. Em vez de escrever apenas que o servidor é seguro, registre a data da última atualização, as regras de firewall aprovadas, os administradores autorizados, os testes de restauração e o resultado dos exercícios de incidente. Uma planilha controlada pode funcionar em um projeto pequeno. Equipes maiores tendem a precisar de inventário de ativos, gestão de identidades, centralização de logs e processos formais de mudança.

Também convém separar três camadas. A aplicação decide quais dados coleta e apresenta. O sistema operacional controla usuários, processos, rede e armazenamento. O provedor administra a virtualização, o hardware e determinados serviços de plataforma. Essa divisão evita a expectativa equivocada de que contratar uma VPS transfere toda a responsabilidade ao fornecedor.

Um exemplo ajuda: uma loja pode hospedar WordPress e banco de dados em São Paulo, enviar e-mails por um serviço estrangeiro e copiar backups para outra região. Embora o servidor principal esteja no Brasil, o fluxo completo inclui terceiros e uma possível transferência internacional. O inventário precisa refletir o caminho real dos dados, não apenas o endereço do painel da VPS.

Comece pelo fluxo de dados e pelas responsabilidades

Mapeie dados, finalidades e sistemas

Antes de alterar o firewall, descubra o que a VPS processa. Liste tabelas de clientes, arquivos enviados, endereços IP, logs de acesso, tickets, registros financeiros e identificadores usados por ferramentas de análise. Classifique cada conjunto como dado pessoal comum, dado pessoal sensível ou informação que não identifica uma pessoa no contexto disponível. Em seguida, associe finalidade, hipótese legal, origem, destinatários, prazo de retenção e método de descarte.

Uma API de cadastro, por exemplo, pode guardar nome e e-mail no PostgreSQL, enviar eventos para uma fila Redis e registrar o identificador do usuário no log do Nginx. Se um dump diário do banco for enviado para armazenamento externo, ele também faz parte do fluxo. Já uma clínica pode armazenar documentos e informações de saúde, o que eleva o impacto potencial de acesso indevido e exige controles proporcionais.

Evite copiar dados reais para desenvolvimento sem necessidade. Uma equipe que precisa reproduzir erros pode gerar uma base sintética com 10 mil registros ou anonimizar campos antes da exportação. Remover apenas o nome não basta quando CPF, telefone, endereço ou combinações de atributos continuam permitindo identificação. O processo deve reduzir de forma efetiva a possibilidade de associação a uma pessoa.

Defina controlador, operador e fornecedores

O controlador toma as decisões principais sobre o tratamento. O operador realiza o tratamento em nome do controlador, conforme as instruções recebidas. Um provedor de VPS pode atuar como operador ou fornecedor de infraestrutura dentro dessa cadeia, mas a classificação depende do serviço e do contrato. Serviços de suporte, monitoramento, e-mail, CDN e backup também precisam entrar na avaliação.

Documente quem aprova acessos, quem aplica atualizações, quem recebe alertas e quem decide sobre comunicação de incidentes. Em uma agência, o cliente pode ser controlador, a agência pode operar a aplicação e o provedor sustentar a infraestrutura. Sem essa divisão, um alerta crítico chega a três empresas e nenhuma sabe quem deve agir.

O contrato deve tratar de segurança, confidencialidade, subprocessadores, localização, suporte a direitos dos titulares, devolução ou eliminação de dados e comunicação de incidentes. Não aceite termos genéricos como prova suficiente. Confirme se o serviço contratado permite exportar logs, remover volumes, revogar usuários e obter informações necessárias para auditoria. Guarde versões dos termos, anexos e registros de aceite, pois recursos e condições podem mudar.

Escolha a localização da VPS com critério jurídico

Servidor no Brasil não é uma obrigação geral

A LGPD não determina que todos os dados pessoais fiquem hospedados fisicamente no Brasil. A localização continua relevante porque altera o fluxo internacional, a latência, a jurisdição contratual e as opções de suporte. A decisão deve considerar o Capítulo V da LGPD, a regulamentação da Autoridade Nacional de Proteção de Dados e os mecanismos aplicáveis à transferência internacional.

Se usuários, administradores, suporte técnico, réplicas ou backups acessarem dados a partir de outro país, olhar apenas para a região principal é insuficiente. Uma VPS em São Paulo pode usar CDN global, monitoramento hospedado nos Estados Unidos e backup em uma região europeia. Da mesma forma, uma instância em Miami pode atender brasileiros com boa conectividade, mas ainda exige análise da transferência e das salvaguardas adotadas.

O artigo sobre VPS no Brasil ou no exterior aprofunda latência, localização e diferenças operacionais. Use esses critérios em conjunto com a avaliação jurídica. Latência menor melhora a experiência, mas não comprova conformidade. Localização nacional simplifica alguns desenhos de arquitetura, porém não corrige coleta sem finalidade, permissões excessivas ou ausência de descarte.

Transferências e cópias precisam entrar no mapa

Solicite ao provedor informações sobre região contratada, locais de suporte, subprocessadores, replicação, snapshots, telemetria e encerramento da conta. Esses dados são variáveis e devem ser confirmados nas páginas oficiais e nos contratos na data da contratação. Não presuma que backup e volume principal permanecem na mesma jurisdição.

Arquitetura	Fluxo de dados	Ponto de verificação	Uso mais comum
VPS e backup no Brasil	Produção e cópia mantidas em regiões nacionais confirmadas	Subprocessadores, acesso remoto e suporte	Sistemas focados no público brasileiro
VPS no Brasil e backup no exterior	Produção local com cópia internacional	Mecanismo de transferência, contrato e retenção	Continuidade regional e recuperação de desastre
VPS no exterior	Tratamento principal fora do Brasil	Transferência internacional, jurisdição e latência	SaaS global e equipes distribuídas
Arquitetura multirregião	Réplicas e serviços em vários países	Inventário completo, roteamento e eliminação	Plataformas globais com alta disponibilidade

Registre a decisão em linguagem clara. Um exemplo seria: produção em região brasileira, backup criptografado em região estrangeira, retenção de 30 dias, acesso restrito ao time de infraestrutura e transferência respaldada pelo mecanismo jurídico aprovado. Se a região ou o contrato mudar, a análise também precisa ser atualizada.

Proteja acesso, rede e criptografia

Acesso administrativo com privilégio mínimo

A conta administrativa da VPS merece tratamento separado das contas da aplicação. Use chaves SSH individuais, desative login direto de root e bloqueie autenticação por senha depois de testar o acesso por chave em outra sessão. Nunca compartilhe uma chave privada por e-mail ou chat. O painel do provedor deve usar autenticação multifator, usuários nominativos e permissões compatíveis com a função de cada pessoa.

Em distribuições que utilizam OpenSSH, uma configuração inicial pode conter:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

Teste a sintaxe com sshd -t antes de recarregar o serviço. Mantenha uma sessão aberta durante a mudança para evitar bloqueio acidental. Em vez de entregar acesso total a um desenvolvedor que só precisa publicar a aplicação, crie uma conta de deploy limitada ao diretório necessário. Administradores podem usar sudo, com registro dos comandos e revisão periódica do grupo autorizado.

Feche portas que não tenham uma finalidade documentada. Um servidor web costuma expor TCP 80 e 443, enquanto SSH pode ser limitado a uma VPN ou a endereços administrativos conhecidos. Bancos como PostgreSQL e MySQL não devem ficar acessíveis pela internet quando a aplicação roda na mesma rede privada. Nosso conteúdo sobre firewall e hardening de VPS detalha essa camada sem tratar o firewall como solução única.

Criptografia em trânsito e em repouso

Use TLS atualizado no site, nas APIs e nas conexões administrativas. Certificados automáticos reduzem expiração acidental, mas a renovação precisa ser monitorada. Entre aplicação e banco em hosts diferentes, habilite TLS e valide o certificado, em vez de aceitar qualquer endpoint criptografado sem verificar sua identidade.

A criptografia em repouso pode existir no volume do provedor, no sistema operacional, no banco ou na aplicação. Cada camada protege contra riscos diferentes. Para campos muito sensíveis, considere criptografia na aplicação com chaves fora do banco. Segredos não devem ficar no repositório Git nem em imagens Docker. Use um gerenciador de segredos ou arquivos protegidos, com permissões 600, rotação e acesso restrito ao processo necessário.

Aplique atualizações de segurança em uma janela definida. Uma pequena API pode usar atualização semanal e correções críticas em até 24 ou 48 horas, conforme o risco. Uma plataforma crítica pode testar pacotes em homologação antes da produção. Em ambos os casos, registre versão, data, responsável e resultado. Varredura de vulnerabilidades ajuda a priorizar, mas não substitui a correção nem a revisão da arquitetura.

Conecte retenção, exclusão e backups

Retenção precisa de prazo e justificativa

Guardar tudo por tempo indeterminado aumenta custo, superfície de ataque e dificuldade para atender direitos dos titulares. Defina prazos por categoria, não um número único para toda a VPS. Contas ativas podem permanecer enquanto durar a relação contratual. Logs de segurança talvez precisem de 90 ou 180 dias, conforme risco e finalidade. Arquivos temporários de importação podem ser removidos em 24 horas. Obrigações legais e regulatórias podem justificar períodos diferentes.

Implemente os prazos no sistema. Uma política que depende de limpeza manual tende a falhar. Em PostgreSQL, uma rotina agendada pode selecionar registros expirados em lotes de mil, registrar a quantidade removida e evitar bloqueios longos. Em armazenamento de objetos, regras de ciclo de vida podem excluir versões após o período aprovado. Filas de mensagens devem ter TTL e limite de tamanho, pois também podem conter dados pessoais.

A exclusão exige atenção às dependências. Apagar o cadastro principal e manter nome, e-mail e endereço em tabelas de auditoria não atende necessariamente ao objetivo. Em alguns contextos, pode ser adequado anonimizar eventos estatísticos e preservar apenas dados necessários para obrigação legal ou defesa de direitos. A decisão precisa ser documentada e aplicada de maneira consistente.

Backup compatível com RPO, RTO e descarte

Backup protege disponibilidade, não serve como arquivo eterno. Defina RPO, que representa a perda máxima de dados tolerada, e RTO, que representa o tempo esperado para restaurar o serviço. Uma loja pequena pode aceitar RPO de 24 horas e RTO de 8 horas. Um SaaS transacional talvez precise de RPO de 15 minutos e RTO de 2 horas. Esses números afetam frequência, tecnologia e custo.

Mantenha cópias criptografadas, separadas da credencial administrativa da VPS e protegidas contra exclusão imediata. O padrão 3-2-1, com três cópias, dois meios ou domínios de falha e uma cópia externa, é uma referência operacional, não uma exigência literal da LGPD. Para aprofundar frequência e restauração, consulte o artigo sobre backup automático em VPS.

Teste restaurações. Um dump diário sem teste pode estar incompleto, corrompido ou depender de uma chave perdida. Faça uma restauração mensal em ambiente isolado, valide contagens, permissões e inicialização da aplicação, depois destrua o ambiente de teste. Registre duração e falhas encontradas.

A eliminação em backups costuma seguir o ciclo de retenção, desde que as cópias sejam protegidas, não retornem ao uso normal e expirem no prazo definido. Se uma cópia antiga for restaurada durante um incidente, execute novamente as rotinas de exclusão e atualização antes de reabrir o sistema. Para casos de alto risco, a destruição de chaves criptográficas pode complementar o descarte, desde que a arquitetura tenha sido planejada para isso.

Prepare logs e resposta a incidentes

Registre o necessário sem criar outro risco

Logs permitem investigar acessos, falhas e mudanças, mas também podem virar um repositório descontrolado de dados pessoais. Não registre senhas, tokens, cookies de sessão, chaves de API, documentos completos ou corpos de requisição por padrão. Prefira identificadores internos, horário sincronizado, origem, ação, recurso afetado e resultado. Quando o IP for necessário para segurança, defina finalidade, acesso e retenção.

Centralize registros relevantes fora da VPS ou em um serviço separado. Se um invasor obtiver root, poderá tentar apagar os arquivos locais. Configure rotação para impedir que o disco fique cheio. Um exemplo inicial seria manter logs operacionais detalhados por 30 dias e eventos de segurança por 180 dias, desde que esses prazos tenham justificativa. Os valores não são universais e devem acompanhar o risco da organização.

Crie alertas acionáveis. Dez tentativas SSH falhas em cinco minutos, alteração inesperada no grupo sudo, tráfego de saída muito acima da média e criação de um usuário administrativo são eventos úteis. Um alerta de CPU em 90% pode indicar carga legítima, ataque ou processo defeituoso. A equipe precisa de contexto para diferenciar esses cenários.

Teste o plano antes de precisar dele

O plano de resposta deve informar quem recebe o alerta, como isolar a VPS, quem preserva evidências, quem avalia impacto aos titulares e quem conduz eventuais comunicações. A Resolução CD/ANPD nº 15/2024 disciplina a comunicação de incidentes de segurança. Os prazos e requisitos devem ser conferidos na norma oficial durante cada revisão do plano, principalmente se houver legislação setorial aplicável.

Em um comprometimento por credencial, a sequência pode incluir bloquear o acesso, capturar evidências, revogar sessões, rotacionar chaves, verificar persistência, restaurar de imagem confiável e monitorar novas tentativas. Reinstalar rapidamente sem preservar registros pode apagar informações necessárias para entender o alcance. Manter uma máquina comprometida conectada, por outro motivo, pode ampliar a exposição. A decisão deve ser liderada por responsáveis definidos previamente.

Faça exercícios semestrais. Um cenário pode simular um bucket de backup exposto por duas horas. Outro pode partir de uma chave SSH de ex-colaborador ainda ativa. Meça tempo de detecção, contenção, identificação dos dados afetados e acionamento das áreas jurídica, técnica e executiva. O relatório do exercício deve gerar tarefas com responsáveis e prazos, não apenas uma ata.

Sincronize relógios com NTP, limite acesso aos logs e preserve trilhas de auditoria. Documente data, fato observado, ação tomada e evidência relacionada. Essa disciplina ajuda tanto na investigação quanto na demonstração de que a empresa adotou medidas proporcionais ao risco.

Recomendações por perfil

A configuração adequada depende do volume, da criticidade e das categorias de dados. CPU e RAM influenciam capacidade, mas não determinam conformidade. Os exemplos abaixo são pontos de partida técnicos e precisam ser ajustados com métricas de uso, arquitetura, contrato e análise de risco.

Desenvolvedor solo e projeto pequeno

Para um site institucional com formulário ou uma aplicação inicial, 2 vCPUs, 2 a 4 GB de RAM e 40 a 80 GB de SSD podem atender, desde que o consumo seja medido. Restrinja SSH à chave individual, ative MFA no provedor, use firewall com apenas 22, 80 e 443 quando necessário e não exponha o banco. Mantenha backup diário criptografado com retenção de 14 a 30 dias e faça um teste de restauração mensal. Documente quais campos são coletados e apague cadastros de teste. Mesmo trabalhando sozinho, mantenha contatos definidos para suporte técnico, avaliação jurídica e comunicação de incidentes.

Equipe de produto ou agência

Uma equipe com vários desenvolvedores deve abandonar credenciais compartilhadas. Use contas nominativas, grupos por função, cofre de segredos e processo de entrada e saída de colaboradores. Uma base de 4 vCPUs, 8 GB de RAM e 100 GB de SSD pode servir a aplicações moderadas, mas a escolha final depende de consultas, filas e tráfego. Separe produção, homologação e desenvolvimento. Dados reais não devem ser copiados para homologação sem anonimização e autorização. Centralize logs, retenha eventos conforme política e revise acessos a cada trimestre. Contratos com clientes e provedores devem explicar papéis, subprocessadores, localização e atendimento a solicitações de titulares.

Produção crítica e dados sensíveis

Sistemas financeiros, de saúde ou que tratam grande volume pedem segregação mais forte. Considere aplicação e banco em instâncias separadas, rede privada, bastion host ou VPN, criptografia por volume e por campo, gestão centralizada de chaves e monitoramento contínuo. Uma arquitetura inicial pode usar 4 a 8 vCPUs e 16 GB de RAM no banco, réplicas e backup com RPO de 15 minutos, mas somente testes de carga sustentam esse dimensionamento. Acesso emergencial deve ser temporário, aprovado e auditado. Realize testes de restauração, exercícios de incidente e revisão de fornecedores. Alterações em região, subprocessadores ou mecanismo de backup devem disparar nova avaliação jurídica e técnica.