Self-Hosted Hardening: O n8n é seguro para rodar no seu ambiente corporativo?

Se você olhar friamente para o que o n8n faz, ele é o sonho de qualquer desenvolvedor e o pesadelo de qualquer profissional de segurança (InfoSec).

Essencialmente, o n8n é um servidor que permite a execução arbitrária de código JavaScript (via Code Node) e comandos de terminal (via Execute Command) dentro da sua infraestrutura. Se mal configurado, ele não é apenas uma ferramenta de automação; ele é uma plataforma de RCE (Remote Code Execution) esperando para ser explorada.

Muitas empresas instalam o n8n via Docker, abrem a porta, colocam atrás de um firewall e assumem que estão seguras. "Só quem está na VPN acessa", dizem.

Mas o que acontece quando um funcionário importa um workflow JSON malicioso da internet? Ou quando um atacante explora uma vulnerabilidade SSRF (Server-Side Request Forgery) usando o nó HTTP Request para escanear sua rede interna?

Segurança em ambientes corporativos exige profundidade. Aqui está o que separa uma instalação amadora de um ambiente hardened (blindado).

1. O Princípio do Menor Privilégio (No Root)

A imagem Docker oficial do n8n, por padrão, é segura e roda com o usuário node. Porém, vemos muitas implementações customizadas onde, por conveniência de permissões de volume, os times forçam a execução como root.

A regra é clara: O container do n8n jamais deve rodar como root. Se um atacante conseguir escapar do container (container breakout), ele terá acesso administrativo ao seu host ou cluster Kubernetes.

No Kubernetes, aplicamos SecurityContext estritos:

• runAsUser: 1000
• runAsNonRoot: true
• allowPrivilegeEscalation: false

2. Bloqueando o Sistema de Arquivos e Módulos

Você quer que seus desenvolvedores leiam o /etc/passwd do servidor? Provavelmente não.

O n8n possui variáveis de ambiente críticas para limitar o alcance dos nós de código. Em ambientes de produção que gerenciamos, configuramos estritamente:

• NODE_FUNCTION_ALLOW_EXTERNAL: npm: Restringe quais bibliotecas externas podem ser importadas.
• N8N_BLOCK_ENV_ACCESS_IN_NODE: true: Impede que um workflow leia as variáveis de ambiente do servidor (onde muitas vezes vivem chaves da AWS ou do banco de dados).

3. Ameaça Interna e SSRF

O nó HTTP Request é poderoso. Ele pode bater em qualquer API. Inclusive na API interna da sua cloud (ex: http://169.254.169.254 na AWS) para roubar metadados e credenciais da instância.

Para evitar isso, um ambiente hardened utiliza Network Policies (no Kubernetes) ou regras de Egress estritas. O pod do n8n deve ter permissão para falar com a internet (para acessar APIs SaaS), mas deve ser explicitamente bloqueado de falar com faixas de IP da rede interna (LAN) ou endpoints sensíveis de metadados da nuvem.

4. Sanitização de Inputs e Secrets

Nunca, jamais, coloque senhas hardcoded dentro dos nós. O n8n possui um gerenciador de credenciais seguro. Use-o.

Para empresas com requisitos de conformidade elevados (SOC2, ISO 27001), integramos o n8n com cofres externos como HashiCorp Vault ou AWS Secrets Manager. Isso garante que as credenciais sejam injetadas apenas em tempo de execução e rotacionadas automaticamente, sem que o desenvolvedor do workflow precise ver a senha real.

Conclusão: Segurança não é um "Feature", é um Processo

O n8n é seguro? Sim, se for tratado com o respeito que uma ferramenta de infraestrutura crítica merece.

Rodar uma ferramenta que executa código exige responsabilidade. Se sua empresa está lidando com dados sensíveis (PII, dados financeiros) e você está rodando o n8n com as configurações padrão "out-of-the-box", você tem um ponto cego na sua segurança.

Na n8nscale, nossos blueprints de deployment já vêm com essas camadas de segurança ativadas por padrão. Nós protegemos a ferramenta para que você possa focar na automação sem medo de expor sua empresa.