# Infraestrutura Defensável: Segurança Não É Hardening, É Controle de Blast Radius

A maior ilusão em segurança de infraestrutura é achar que um servidor “hardeningado” está seguro. Segurança real não nasce de um checklist. Nasce de arquitetura: identidade forte, superfície mínima, segmentação honesta, telemetria útil e capacidade de recuperação.

Infra segura é infra onde uma credencial vazada não vira domínio total. Onde uma CVE crítica não vira movimento lateral livre. Onde um container comprometido não enxerga segredo, metadata, socket Docker, rede interna e banco de dados ao mesmo tempo.

O objetivo não é impedir todo ataque. É reduzir confiança implícita e encurtar o tempo entre comprometimento, detecção, contenção e recuperação.

1. O Perímetro Morreu, Mas A Rede Ainda Importa

Zero Trust não significa “comprar VPN bonita”. Significa parar de tratar rede interna como zona confiável.

Em uma infra decente:

• SSH não fica aberto para o mundo.
• Acesso administrativo exige MFA forte ou chave curta com controle central.
• Banco não escuta em interface pública.
• Serviço interno não confia em IP privado como identidade.
• Cada workload tem identidade própria.
• Cada conexão precisa ter motivo para existir.

O modelo correto é: todo recurso é uma fronteira de confiança.

Se uma aplicação precisa falar com PostgreSQL, ela fala só com PostgreSQL, só na porta necessária, só com credencial limitada, só a partir da identidade esperada.

2. Identidade É O Novo Firewall

A maioria dos incidentes modernos começa como problema de identidade: token vazado, chave SSH antiga, conta sem MFA, service account poderosa demais, segredo esquecido em .env, CI/CD com permissão absurda.

Infra madura trata identidade como plano crítico.

Boas práticas reais:

• Chaves SSH por pessoa, nunca compartilhadas.
• Root login desativado quando possível.
• MFA phishing-resistant para painéis críticos.
• Service accounts com escopo mínimo.
• Segredos rotacionáveis e auditáveis.
• Tokens de CI/CD separados por ambiente.
• Nenhuma credencial de produção em máquina de dev.

O teste simples: se uma chave vazar hoje, qual é o raio da explosão?

Se a resposta for “acesso total”, a infra não está segura. Está esperando dar merda.

3. Superfície De Ataque Tem Que Ser Pequena E Observável

Toda porta aberta é uma promessa que você precisa cumprir: patch, log, autenticação, rate limit, monitoramento e resposta.

Em VPS, cloud ou Kubernetes, o mínimo saudável é:

• Expor só 80/443 publicamente.
• Administração por Tailscale, WireGuard, SSM, Teleport ou equivalente.
• Nginx/Caddy como borda, app atrás em 127.0.0.1 ou rede interna.
• Firewall default-deny.
• Logs de acesso e erro persistidos.
• Alertas para restart inesperado, spike de 5xx, variação de tráfego e alteração de binários críticos.

Não basta “funcionar”. Tem que ser investigável.

4. Containers Não São Sandbox Mágica

Container é empacotamento e isolamento parcial. Não é VM, não é limite absoluto de segurança.

Erros clássicos:

• Rodar container como root.
• Montar /var/run/docker.sock.
• Usar imagem gigante sem necessidade.
• Não fixar versão de imagem.
• Passar segredos por variável de ambiente sem controle.
• Container com rede ampla demais.
• Capability Linux sobrando.
• Filesystem gravável sem motivo.

Um workload bem desenhado roda com usuário sem privilégio, filesystem read-only quando possível, capabilities mínimas, secrets montados por mecanismo controlado, imagem pequena e SBOM/vulnerability scanning no pipeline.

5. Patch Management É Logística, Não Heroísmo

Atualizar pacote manualmente quando lembra não é estratégia. É loteria.

O que funciona:

• Inventário de assets.
• Janela de update definida.
• Reboot planejado para kernel.
• Ambientes reproduzíveis.
• Backup antes de mudança crítica.
• Rollback documentado.
• Priorização por exposição real.

CVE crítica em serviço não exposto pode esperar mais que CVE média em painel público sem MFA. Risco é contexto, não só CVSS.

6. Logs Bons São Logs Que Respondem Perguntas

Log inútil é ruído caro. Log bom responde:

• Quem autenticou?
• De onde?
• Com qual identidade?
• Qual recurso acessou?
• O que mudou?
• Qual processo abriu conexão externa?
• Qual deploy introduziu o comportamento?
• Qual segredo foi lido?
• Qual container reiniciou?
• Qual rota começou a retornar erro?

Sem isso, incidente vira arqueologia.

O stack não precisa ser enorme. Para infra pequena: journald, Nginx logs, auditd, fail2ban com cuidado, Prometheus, Grafana, Loki ou equivalente já resolvem muita coisa. Para ambientes maiores: SIEM, EDR, tracing, detections versionadas e resposta automatizada.

7. Backup É Controle De Segurança

Ransomware ensinou uma coisa óbvia: backup que o atacante consegue apagar não é backup, é placebo.

Backup sério tem:

• Cópia offline ou imutável.
• Credencial separada da produção.
• Teste periódico de restore.
• Retenção definida.
• Criptografia.
• Procedimento escrito.
• Métrica de RPO/RTO.

A pergunta não é “tem backup?”. A pergunta é: quanto tempo leva para voltar e quanto dado você perde?

8. IA Na Segurança De Infra: Útil, Mas Só Com Evidência

IA ajuda muito em revisão de configuração, threat modeling, análise de logs, detecção de padrões e validação de hipóteses. Mas IA sem evidência vira teatro.

Use IA para:

• revisar Nginx, SSH, systemd, Docker, Kubernetes e Terraform;
• gerar threat model;
• procurar caminhos de ataque;
• explicar logs;
• sugerir detections;
• revisar permissões;
• criar checklist de hardening;
• comparar estado atual contra baseline.

Não use IA como autoridade final. Use como multiplicador de análise. A regra é simples: sem log, sem diff, sem config, sem evidência, é palpite bonito.

Checklist Final

Uma infra defensável precisa responder “sim” para isto:

• Sei tudo que está exposto publicamente.
• Admin não depende de senha simples.
• Segredos não estão espalhados.
• Cada serviço tem privilégio mínimo.
• Banco não está público.
• Logs sobrevivem ao restart.
• Backup foi restaurado recentemente em teste.
• Kernel e pacotes têm rotina de update.
• Deploy é reproduzível.
• Incidente tem plano de contenção.
• Uma credencial vazada não derruba tudo.

Segurança de infraestrutura não é sobre parecer sofisticado. É sobre controlar falha. Sistema bom assume que algo vai vazar, quebrar ou ser explorado, e mesmo assim continua limitado, observável e recuperável.