Publicar é decisão de negócio. Sustentar é configuração.
Boa parte dos servidores em operação hoje precisa estar acessível pela internet porque o negócio depende disso: gente trabalhando de fora, cliente entrando no sistema, aplicação que sustenta o faturamento e não pode ficar restrita à rede interna. Tirar isso do ar em nome da segurança não é uma opção real para quem precisa trabalhar.
O risco que vem com isso é conhecido. Um servidor publicado na internet recebe milhares de tentativas de login por dia, vindas de varreduras automáticas que nunca param. Essa é uma condição permanente de quem publica, e é o que torna a hardenização, ou fortalecimento, um pré-requisito: o trabalho de deixar o sistema com a menor superfície possível de ataque, removendo o que não é usado, restringindo quem acessa o quê e ajustando as configurações que vêm abertas por padrão. Quem tem porta aberta não tem margem para deixar item pendente.
O que está em jogo é uma operação parada por dias, dado de cliente exposto, e o tempo que se perde tentando reconstruir o que aconteceu.
Quem opera on-premises sente uma proteção a mais. Servidor no rack da sala dos fundos, rede sem saída externa, nada publicado. Essa confiança costuma ruir pelo mesmo tipo de caminho: uma estação com credencial salva, um acesso de terceiro que ficou ativo, um arquivo baixado de um e-mail de phishing. A configuração do servidor é o que determina se um acesso indevido vira um incidente pequeno ou um problema grande. Isso vale igual em nuvem e em datacenter próprio.
Vale saber com clareza onde cada parte começa. O provedor responde pela estrutura que sustenta o servidor: datacenter, energia, rede física, disponibilidade. Quem contrata responde pelo que roda dentro dele: usuários, senhas, permissões, serviços ativos, atualização.
Poucos incidentes começam com uma técnica sofisticada. Começam com uma senha reaproveitada, um administrador esquecido, um serviço ligado sem necessidade ou um sistema parado em uma versão de meses atrás. As verificações a seguir são as que mais fazem sentido para sustentar um ambiente publicado.
Acesso e identidade
Identidade é o ponto em que a maioria dos comprometimentos nasce, e onde os esforços rendem mais.
Exija segundo fator de autenticação (2FA) em tudo que for administrativo, e sempre que possível também no acesso remoto. Senha forte e individual protege enquanto continua secreta, e credencial vaza com muito mais frequência do que se imagina. O 2FA existe justamente para esse cenário. Com ele, uma senha comprometida vira um alerta em vez de um acesso indevido.
Mantenha uma conta nominal por pessoa. Conta compartilhada elimina a possibilidade de saber quem fez o quê, e essa informação faz falta justamente no dia em que algo der errado. Trabalhe com privilégio mínimo como padrão, porque boa parte de quem tem acesso administrativo hoje não precisa dele para o trabalho do dia a dia. Revise periodicamente, e remova o acesso de quem sai da empresa ainda no mesmo dia.
Dê atenção especial aos usuários de serviço, integrações, rotinas automatizadas e credenciais escritas dentro de scripts. Essas contas sem dono humano passam anos sem revisão, quase sempre com privilégios elevados e senhas que nunca foram alteradas.
A separação entre o que é publicado e o que é administrativo
Existe uma separação simples entre o que o negócio precisa publicar e o que é usado de forma administrativa: manutenção, virtualizador, painel de rede, interfaces de gerência. Esse segundo grupo não precisa estar visível para o usuário final, e quando fica atrás de um caminho controlado, com origem restrita, o que um atacante enxerga diminui de forma considerável sem tirar nada do ar para quem trabalha.
Vale revisar as interfaces de gerência dos equipamentos, que seguem ligadas mesmo com o servidor desligado, e os equipamentos que ainda estão com senha de fábrica.
Os cuidados que os serviços expostos exigem
Desative os serviços que não são usados e limite a publicação de portas, porque cada item exposto é mais uma coisa para manter, corrigir e monitorar.
Toda publicação deve passar por um ponto de entrada que autentica e depois entrega a sessão, com criptografia em trânsito e certificado válido. Um serviço de acesso remoto entregue diretamente, sem essa camada na frente, aceita conexões de qualquer lugar do mundo e registra pouco sobre quem tentou.
Bloqueie a origem das tentativas repetidas de autenticação, e não a conta, para não travar usuários legítimos.
Limite o acesso por país ou por faixa de IP quando souber de onde seus usuários acessam. Tais ações fazem o volume de ruído diminuir e deixam o registro de logs mais legível. Trocar a porta padrão tem efeito parecido: afasta a varredura de bots, e o que sobra no registro fica mais fácil de notar.
Limite quem precisa de conta administrativa e mantenha atualizado todo software publicado. Software de acesso remoto é alvo prioritário, e falha conhecida em serviço exposto costuma ser explorada em escala poucos dias depois de divulgada.
Os itens a seguir são os que mais se repetem em ambientes publicados, independente da distribuição ou da versão.
Hardenização no Linux
- Autenticação por chave, com login por senha desabilitado
- Login direto do usuário root bloqueado, com elevação nominal
- Restrição de quais usuários ou grupos podem abrir sessão remota
- Bloqueio automático da origem após tentativas repetidas de autenticação
- Firewall local ativo, com política padrão de negação
- Revisão dos serviços habilitados no boot
- Atualizações de segurança automatizadas
- Verificação rotineira da integridade dos pacotes instalados
- Auditoria de permissões elevadas e de tarefas agendadas (crontab e temporizadores)
Hardenização no Windows Server
- Acesso remoto entregue por um ponto intermediário com criptografia, com a porta padrão alterada
- Considerar o 2FA antes da abertura de qualquer sessão remota
- Bloqueio automático da origem após tentativas repetidas de autenticação
- Grupo de acesso remoto restrito, sem conta administrativa autorizada a entrar por ele
- Senha de administrador local única por máquina, gerenciada de forma centralizada
- Conta administrativa separada da conta de uso diário, inclusive nas contas de serviço
- Protocolos legados, funções e recursos sem uso desabilitados
- Antivírus corporativo ativo e atualizado em todos os servidores
- Política de atualização definida, com janela de manutenção acordada
As duas listas são longas de propósito, e ninguém implementa tudo de uma vez. O que importa é saber o que já está feito e o que ficou pendente, por decisão ou por falta dela, de quem administra o ambiente. O desenho de cada item muda conforme o sistema, a aplicação e o modelo de contratação.
A maior parte desses itens não exige investimento. São decisões de configuração no que já está contratado: desligar o que não é usado, restringir quem entra, definir política de atualização, ajustar permissão. O custo está no tempo de quem executa e na disciplina de revisar.
Ambientes conteinerizados seguem a mesma lógica: imagens, privilégios, visibilidade de rede. O acesso ao orquestrador é tão sensível quanto um console de virtualização. Serviço publicado a partir de um contêiner continua exigindo entrada autenticada, registro do que acontece e atualização em dia.
Segmentação
Separar camadas é o que impede que um servidor comprometido comprometa um ambiente inteiro. Em ambiente publicado isso pesa ainda mais, porque o servidor que recebe as sessões é, por definição, o mais exposto de todos.
O banco de dados não precisa falar com a internet e cada servidor que atende usuários externos não precisa alcançar toda a rede interna. O ideal é que o banco aceite conexão apenas do servidor de aplicação, e nada além disso. Quando tudo está na mesma rede, um único equipamento comprometido alcança tudo o que existe.
A proteção de borda cuida do que chega, o antivírus cuida do que já está dentro, e a segmentação limita até onde um servidor comprometido consegue chegar. As três são necessárias.
Logs
Log guardado apenas dentro do servidor tem valor limitado, porque quem obtém acesso administrativo consegue alterá-lo. Envie os registros para fora do host, defina um prazo de retenção e mantenha o horário sincronizado em todas as máquinas. Sem relógio consistente, correlacionar eventos entre sistemas diferentes vira suposição.
Em ambiente publicado, o registro de autenticação é o que mais importa. Falha repetida vindo de uma origem nova, sucesso em horário improvável, sessão aberta por uma conta que quase nunca entra. São sinais visíveis, desde que alguém esteja acompanhando. Defina quem faz isso e com que frequência.
Esse registro também é o que sustenta a resposta a um incidente. A LGPD exige comunicação ao titular e à autoridade quando há risco relevante, e sem log preservado não há como dizer o que foi acessado, por quem e quando.
Backup só existe depois do teste
Backup com retenção definida e cópia separada do ambiente principal é a última linha contra ransomware e contra erro humano. O que transforma isso em garantia é o teste de restauração: restaurar de verdade, com periodicidade, e cronometrar quanto demora.
Defina quanto tempo a operação aguenta ficar parada e quanto dado pode ser perdido sem virar problema. Esses dois números orientam a frequência das cópias e o desenho da rotina. Restaure em ambiente separado, confira se a aplicação sobe e se os dados estão íntegros, e registre o tempo que levou. É esse registro que mostra se a rotina atende ao que a operação precisa.
Por onde começar
Se a lista parece longa, três coisas resolvem quase todo o risco com o menor esforço: 2FA em todo acesso administrativo e, sempre que possível, no acesso remoto, entrada intermediada em vez de serviço entregue direto, e atualização em dia.
Depois vêm a revisão de quem é administrador, a segmentação e o teste de restauração. O resto entra como rotina.
E antes de tudo isso, o inventário. Servidor que ninguém sabe que existe não é atualizado, não é monitorado e não aparece em nenhuma dessas listas. É por ele que a entrada acontece.
Hardenização não é um projeto com data de entrega. É o estado em que o ambiente precisa se manter, revisado sempre que algo muda: um servidor novo, um serviço publicado, uma pessoa que entra ou sai. Configuração que foi feita uma vez afrouxa sozinha com o tempo, e é o acompanhamento contínuo que mantém o ambiente previsível.
A decisão de publicar é legítima e o negócio depende dela. O que precisa vir junto é o trabalho que a torna sustentável no tempo. Vale rodar essa lista no próprio ambiente e marcar com honestidade o que está em dia e o que nunca foi feito. O resultado diz mais sobre o risco real da operação do que qualquer ferramenta instalada depois.
Revisar essa lista com alguém que conhece o ambiente rende mais do que revisar sozinho. A OPEN publica conteúdos como este com regularidade e acompanha seus clientes nas decisões de hardenização do dia a dia.