Checklist de segurança para VPS antes do primeiro deploy

Antes de publicar uma aplicação, vale responder uma pergunta simples: se alguém descobrir o IP da VPS agora, o que essa pessoa consegue fazer? Todo servidor público recebe varreduras automáticas, tentativas de login e requisições para vulnerabilidades conhecidas. Não é um cenário excepcional; é o ambiente normal da internet.

Este checklist cobre o mínimo que deve estar decidido antes do primeiro deploy. Ele não substitui uma revisão de segurança para ambientes regulados ou de alto risco, mas remove falhas básicas que aparecem repetidamente em servidores novos.

Acesso SSH: identidade, não senha

Use uma chave SSH protegida por senha em vez de depender de uma senha do servidor. Crie um usuário administrativo comum e evite operar diariamente como root. Depois de testar o novo acesso em uma segunda janela de terminal, desabilite o login remoto do root e a autenticação por senha, quando não houver uma razão operacional para mantê-los.

Antes de alterar a configuração do SSH, mantenha a sessão atual aberta. Uma linha incorreta em sshd_config não deveria ser capaz de bloquear seu único caminho de volta ao servidor.

Firewall: comece com uma lista curta

Para uma aplicação web pública, a regra inicial costuma ser permitir SSH, HTTP e HTTPS; todo o resto fica bloqueado. O banco de dados deve estar em uma rede interna, em localhost ou acessível apenas por hosts explicitamente permitidos.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Depois confira as portas realmente em escuta. Docker merece atenção: publicar uma porta no host pode contornar parte das expectativas que você criou no firewall. Prefira expor a aplicação ao Nginx por uma rede interna ou por 127.0.0.1.

Atualizações e reinicialização

Atualize a imagem logo após o provisionamento e defina como acompanhar correções futuras. Atualizações automáticas de segurança podem ser adequadas para servidores simples; em aplicações críticas, uma janela de manutenção controlada pode fazer mais sentido. Em ambos os casos, o importante é não deixar a decisão implícita.

Quando uma atualização exigir reinício, confirme que os serviços voltam sozinhos. Um container sem política de reinício ou uma unit sem enable pode deixar o site indisponível depois da primeira manutenção.

Segredos não pertencem ao repositório

Senhas, tokens, chaves de API e arquivos .env precisam de permissões restritas e não devem ir para Git, imagens Docker ou logs. Use um arquivo de ambiente com permissão 0600, um gerenciador de segredos ou o mecanismo oferecido pela plataforma de deploy.

Também vale separar credenciais por função. Uma chave usada pelo backup deveria ter acesso apenas ao bucket de backup, não à conta inteira do provedor.

HTTPS e cabeçalhos básicos

Não trate HTTPS como decoração. Ele protege credenciais, sessões e dados enviados pelos usuários. Configure certificado válido, redirecione HTTP para HTTPS e confira a renovação automática. Para aplicações web, cabeçalhos como X-Content-Type-Options, Referrer-Policy e uma política de conteúdo compatível com a aplicação são uma segunda camada útil.

Backup só conta quando você restaura

Defina o que precisa ser recuperado: arquivos enviados, banco de dados, configurações, volumes e variáveis essenciais. Mantenha a cópia fora da VPS e faça um teste de restauração. O procedimento precisa sobreviver a uma VPS perdida, não apenas a um arquivo apagado por acidente.

Checklist final

usuário não-root com acesso administrativo validado;
chaves SSH ativas e acesso root remoto revisado;
firewall permite apenas portas necessárias;
aplicação e banco não expõem portas internas por engano;
atualizações e reinício de serviços foram testados;
segredos estão fora do Git e com permissões restritas;
domínio responde por HTTPS;
backup externo e uma restauração foram testados.

O Guia de Configuração de VPS aprofunda cada item, com comandos para Ubuntu, auditoria de portas, templates de Nginx e uma rotina de backup com Restic.