n8n self-hosted seguro: arquitetura de cybersegurança que ninguém te conta no YouTube

Tenho assistido conteúdos brasileiros e americanos sobre n8n self-hosted e tem um padrão preocupante: quase ninguém fala de segurança. O fluxo típico do tutorial é: cria VM na nuvem com IP público, instala n8n, ativa HTTPS básico, "pronto, tá tudo funcionando". Esse setup é exatamente o cenário que hackers procuram com scanners automáticos.

Trabalho com cybersegurança há 18+ anos, atualmente como Senior Cybersecurity Lead na Microsoft, e desenho arquiteturas seguras de aplicações em cloud há quase uma década. Neste post organizo os controles que você precisa implementar antes de colocar tokens reais (OpenAI, Stripe, e-mail corporativo, banco de dados de clientes) no seu n8n.

Por que o setup padrão é um problema?

Quando você sobe uma VM com IP público e instala n8n, três coisas ficam expostas:

1. Porta 22 (SSH) — o ponto de entrada administrativo do Linux
2. Porta 5678 (n8n) — a interface web do n8n
3. Porta 80/443 (web) — qualquer reverse proxy à frente

Um atacante com scanner faz duas coisas em paralelo:

• Brute-force em SSH — tentativas automatizadas com listas de senhas comuns
• Recon do n8n — versão exposta, possíveis CVEs conhecidos, endpoints de autenticação

Se ele entra via SSH, toma controle total da VM. Se entra via n8n, acessa todos os seus workflows com credenciais armazenadas — tokens OpenAI, integração WhatsApp, banco de clientes, e-mail corporativo. O estrago é catastrófico.

A boa notícia: as defesas certas são acessíveis (custam centavos a poucos dólares por mês) e a maioria você implementa em poucas horas.

A arquitetura segura: 6 camadas

Vou descrever cada camada com termos Azure (que é o que uso), mas o conceito se traduz direto para AWS, GCP ou qualquer cloud. Pergunte ao ChatGPT pelo serviço equivalente se for usar outra.

[Sua máquina] → [VPN] → [Subnet] → [App Gateway] → [NSG] → [VM com n8n]
                                       ↑
                  [Entra ID + Conditional Access]
                                       ↑
                  [Defender for Cloud + monitoramento]

Camada 1: VPN para fechar SSH

A regra mais importante: não exponha SSH (porta 22) na internet pública. Em vez disso:

1. Configure uma VPN ponto-a-site entre sua rede local e a VNet da Azure (ou equivalente na AWS/GCP)
2. Configure o NSG da VM para permitir SSH apenas a partir de IPs internos da VNet
3. Para acessar a VM, você primeiro conecta na VPN, ganha um IP interno, e só então o SSH abre

O custo de uma VPN ponto-a-site no Azure é de poucos dólares por mês (paga-se por tráfego de saída, em geral centavos para uso pessoal). Em troca, você fecha o vetor número 1 de ataque em servidores Linux na nuvem.

Camada 2: Subnets e segmentação de rede

Coloque a VM do n8n em uma subnet dedicada, não junto com outros workloads. Por quê? Princípio de menor privilégio de rede: se um outro serviço seu for comprometido em outra subnet, ele não consegue alcançar o n8n facilmente.

Para começar, uma subnet por aplicação já é um avanço grande. Em ambientes corporativos a granularidade pode ir mais longe (uma subnet por VM), mas para uso pessoal/SMB é overkill.

Camada 3: NSG (Network Security Group) — o firewall interno

O NSG é o firewall de camada 4 da Azure. Você define regras como:

Permitir 443 (HTTPS) inbound de: qualquer
Permitir 22 (SSH) inbound de: 10.0.0.0/24 (VNet via VPN)
Negar tudo o resto inbound
Negar 5678 (n8n direto) inbound de: qualquer

A última regra é crítica: bloqueie o acesso direto à porta nativa do n8n. O n8n só deve ser acessado via reverse proxy na 443.

Camada 4: EasyPanel / Caddy como reverse proxy

Se você instalou o n8n via EasyPanel (como mostrei em posts anteriores), você já ganha um benefício: o EasyPanel coloca Caddy como reverse proxy na frente do n8n. Isso faz duas coisas importantes:

1. HTTPS automático via Let's Encrypt
2. Esconde a porta 5678 nativa — o atacante vê apenas a porta 443 padrão

Para setups manuais, configure Nginx ou Caddy você mesmo na frente do n8n.

Camada 5: Application Gateway (Layer 7 firewall, opcional avançado)

Para ambientes corporativos ou multi-cliente, vale colocar um Application Gateway com WAF (Web Application Firewall) à frente da VM:

• Inspeciona requests HTTP
• Bloqueia padrões conhecidos de ataque (SQL injection, XSS, scanners conhecidos)
• Permite balancear carga entre múltiplos n8n para alta disponibilidade
• Esconde completamente o IP da VM (o tráfego termina no App Gateway)

Custo: começa em ~US$ 250/mês na Azure. Não vale para uso pessoal — vale a partir do momento que você está rodando n8n para clientes pagantes.

Camada 6: Entra ID + Conditional Access (versão Enterprise do n8n)

A versão Community do n8n não suporta SSO/SAML. Para isso você precisa da versão Enterprise. Mas se você é Enterprise, ative imediatamente:

1. Single Sign-On com Entra ID — você loga no n8n com sua credencial corporativa
2. Conditional Access policies:
   • Bloquear logins de fora do país onde você opera
   • Exigir MFA sempre
   • Bloquear logins de dispositivos não-registrados
   • Bloquear logins fora do horário comercial

Isso transforma o vetor de ataque "senha vazada" em algo muito mais difícil de explorar.

Monitoramento contínuo: Defender for Cloud + Azure Policy

Duas peças adicionais que valem para qualquer ambiente:

Defender for Cloud

Análise contínua da postura de segurança da sua VM e subscription Azure. Te alerta sobre:

• Portas expostas indevidamente
• VM sem patches de segurança
• Comportamento anômalo na VM
• Tentativas de acesso suspeitas

Custo: começa gratuito (Defender CSPM Free); para alertas avançados, ~US$ 15/VM/mês.

Azure Policy

Define regras "constitucionais" da subscription:

• "Toda VM precisa ter NSG"
• "Nenhuma VM pode ter porta 22 aberta para 0.0.0.0/0"
• "Toda conta de storage precisa ter HTTPS-only"

Se alguém da equipe (ou você mesmo distraído) criar um recurso violando a regra, a Azure bloqueia ou alerta. É prevenção sistêmica de erro humano.

O que a documentação oficial do n8n diz?

Ler o que o time do n8n recomenda é essencial, mas a documentação oficial cobre apenas o mínimo: HTTPS, autenticação básica, SAML (Enterprise). Não menciona nada de VPN, segmentação de rede, WAF, Conditional Access. Tudo isso é responsabilidade sua.

O que estou compartilhando vem da experiência de arquitetar ambientes corporativos de cybersegurança. É o que eu faria (e faço) na minha própria conta n8n.

O que fazer agora — checklist de hardening para n8n self-hosted

Nível 1 — uso pessoal / lab (custo: ~US$ 5-10/mês extra)

• Configure VPN ponto-a-site e feche SSH para a internet
• HTTPS obrigatório com certificado Let's Encrypt (EasyPanel já faz)
• NSG restritivo — bloqueie 5678 direto, permita só 443
• Senha forte e única no n8n + 2FA se disponível
• Atualize n8n regularmente — saiba a versão atual e o changelog de segurança
• Backup automático da VM — Azure Backup é trivial de configurar

Nível 2 — uso comercial / multi-cliente (custo: ~US$ 50-300/mês extra)

Tudo do nível 1 +:

• Subnets dedicadas para n8n e cada componente crítico
• Defender for Cloud Plan 2 com alertas e recomendações
• Azure Policy para impedir criação de recursos inseguros
• Logs centralizados em um workspace Log Analytics
• Application Gateway com WAF se você atende múltiplos clientes

Nível 3 — corporativo / regulado (custo: variável)

Tudo do nível 2 +:

• n8n Enterprise com SSO via Entra ID
• Conditional Access com regras de geografia/device/horário
• SIEM (Microsoft Sentinel ou equivalente) para correlação de logs
• Penetration test anual
• Plano de incident response documentado
• Backup geo-redundante + teste de restore trimestral

Quem está construindo automações para vender como serviço deveria estar pelo menos no Nível 2 antes do primeiro cliente. Quem está em ambiente corporativo deveria estar no Nível 3 — ponto.

Um único token OpenAI vazado pode custar centenas de dólares em um fim de semana. Um workflow comprometido com integração de e-mail pode ser usado para phishing em massa em nome da sua empresa. Cybersegurança em n8n não é detalhe opcional — é o que separa um lab pessoal de um sistema profissional.

Este artigo foi gerado a partir do meu vídeo no YouTube. Assista a versão completa para ver o diagrama completo de arquitetura desenhado ao vivo e detalhes sobre cada camada.