Segurança no N8N

O N8N é uma plataforma de automação de workflows amplamente adotada por equipes técnicas e empresas que precisam integrar sistemas, processar dados sensíveis e orquestrar processos críticos. Por atuar como um hub central de integrações — conectando APIs, bancos de dados, serviços de cloud e aplicações SaaS — a segurança da instância N8N é um aspecto que não pode ser negligenciado.

Este artigo reúne as principais práticas e configurações de segurança disponíveis na plataforma, organizadas de forma didática para equipes que desejam operar o N8N com o nível de proteção adequado ao ambiente corporativo — especialmente em contextos enterprise, onde compliance, governança e rastreabilidade são requisitos essenciais.

Por Que Segurança no N8N é Crítica?

Uma instância N8N mal configurada pode expor credenciais de APIs, tokens OAuth, chaves de banco de dados e dados sensíveis processados em workflows. Considerando que o N8N funciona como um ponto de integração central, uma brecha de segurança pode comprometer múltiplos sistemas simultaneamente.

Superfícies de ataque em uma instância N8N sem hardening:

• Credenciais de API armazenadas sem criptografia adequada

• Acesso irrestrito ao editor via internet sem VPN ou IP allowlist

• Usuários com permissões excessivas além do necessário

• Webhooks sem autenticação expostos publicamente

• Dados sensíveis visíveis nos logs de execução

• Instância desatualizada com vulnerabilidades conhecidas

O N8N, por padrão, prioriza facilidade de uso — o que é ideal para desenvolvimento e prototipagem, mas inadequado para ambientes de produção. As configurações de segurança descritas neste artigo devem ser aplicadas antes de qualquer implantação em ambiente produtivo.

Autenticação: A Primeira Linha de Defesa

Autenticação de Dois Fatores (2FA)

O N8N suporta autenticação de dois fatores via aplicativo autenticador (TOTP), adicionando uma segunda camada de verificação além da senha. Mesmo que uma senha seja comprometida, o acesso à instância permanece bloqueado sem o código gerado pelo autenticador.

Como ativar o 2FA individualmente:

• Acesse Settings > Personal no painel lateral esquerdo

• Clique em Enable 2FA

• Escaneie o QR code com seu aplicativo autenticador (Google Authenticator, Authy etc.)

• Digite o código gerado pelo app para confirmar

• Salve os códigos de recuperação em local seguro — essenciais caso perca o dispositivo

Enforcement de 2FA para Toda a Instância

Administradores de instâncias enterprise podem tornar o 2FA obrigatório para todos os usuários que fazem login com e-mail e senha. Essa funcionalidade está disponível nas configurações de segurança da instância.

Como forçar 2FA para todos os usuários:

• Acesse Settings > Security no painel administrativo

• Na seção Enforce two-factor authentication, ative o toggle

• Usuários sem 2FA configurado serão obrigados a configurá-lo no próximo login

• Para desativar o enforcement, basta desligar o toggle — usuários que já configuraram o 2FA mantêm a funcionalidade ativa

⚠ Importante sobre SSO

• O enforcement de 2FA se aplica apenas a usuários autenticados com e-mail e senha.

• Usuários que fazem login via SSO (SAML ou OIDC) não são afetados — a responsabilidade pelo MFA fica com o provedor de identidade.

Para ambientes self-hosted, é possível desabilitar completamente o 2FA definindo a variável de ambiente N8N_MFA_ENABLED como false — útil em contextos onde o controle de acesso é gerenciado externamente.

Single Sign-On (SSO) com SAML e OIDC

Em ambientes enterprise, o N8N suporta autenticação federada via SAML 2.0 e OpenID Connect (OIDC), permitindo integração com provedores de identidade como Okta, Azure AD e outros IDPs corporativos.

Protocolo	Casos de Uso	Benefícios
SAML 2.0	Ambientes corporativos com Okta, Azure AD, ADFS	Padrão consolidado, ampla compatibilidade
OIDC	Provedores modernos, Google Workspace, Auth0	Mais simples de implementar, token JWT nativo
LDAP	Active Directory, OpenLDAP	Integração direta com diretórios corporativos

A adoção de SSO centraliza o gerenciamento de acesso, garante que políticas de senha e MFA do provedor de identidade sejam aplicadas automaticamente, e simplifica o offboarding — desativar o usuário no IDP remove imediatamente o acesso ao N8N.

Controle de Acesso Baseado em Função (RBAC)

O N8N Enterprise oferece um sistema robusto de controle de acesso baseado em funções (RBAC), permitindo granularidade na definição de quem pode criar, modificar, executar ou apenas visualizar workflows e credenciais.

Tipos de Perfis e Permissões

Perfil	Escopo	Permissões Típicas
Instance Owner	Global	Controle total da instância, configurações de segurança
Admin	Global	Gerenciamento de usuários, projetos e configurações
Project Admin	Projeto	Gestão completa dentro do projeto
Project Editor	Projeto	Criar, editar e executar workflows e credenciais
Project Viewer	Projeto	Somente leitura — visualizar execuções e resultados

O princípio do menor privilégio deve guiar a atribuição de permissões: cada usuário deve receber apenas o acesso mínimo necessário para executar suas funções. Um analista que só precisa monitorar execuções não deve ter permissão de editar workflows.

Projetos como Unidade de Isolamento

O N8N organiza o acesso através de Projetos, que funcionam como espaços isolados para grupos de workflows e credenciais. Cada projeto tem seus próprios membros e permissões, permitindo que equipes diferentes trabalhem com isolamento adequado.

Boas práticas na organização de projetos:

• Crie projetos separados por equipe, cliente ou domínio de negócio

• Evite misturar workflows de produção e desenvolvimento no mesmo projeto

• Atribua Project Admins como responsáveis pela governança de cada projeto

• Revise periodicamente os membros e permissões de cada projeto

• Use o Personal Space apenas para desenvolvimento individual — não compartilhe workflows críticos ali

Políticas de Personal Space

Administradores de instância podem controlar o comportamento dos espaços pessoais dos usuários, definindo se eles podem compartilhar workflows e credenciais do seu Personal Space com outros, e se podem publicar workflows criados nesse espaço.

Configurações disponíveis em Settings > Security > Personal Space Policies:

• Sharing workflows and credentials: controla se usuários podem compartilhar itens do Personal Space

• Publishing workflows: controla se workflows do Personal Space podem ser ativados para execução em produção

Restringir o compartilhamento e publicação a partir do Personal Space é uma prática recomendada em ambientes enterprise, garantindo que toda automação crítica passe por projetos com governança adequada e revisão por pares.

Proteção de Credenciais

As credenciais armazenadas no N8N — chaves de API, tokens OAuth, senhas de banco de dados — são o ativo mais sensível da plataforma. O N8N implementa múltiplas camadas de proteção para esses dados.

Criptografia em Repouso

Todas as credenciais são criptografadas antes de serem armazenadas no banco de dados, usando a chave definida pela variável de ambiente N8N_ENCRYPTION_KEY. Isso garante que mesmo em caso de comprometimento do banco de dados — por exemplo, através de um backup exposto — as credenciais permaneçam ilegíveis.

⚠ Atenção crítica sobre a chave de criptografia:

• Por padrão, o N8N gera uma nova chave a cada restart quando N8N_ENCRYPTION_KEY não está definida.

• Isso significa que todas as credenciais ficam inacessíveis após um reinício da instância em ambientes não configurados corretamente.

• Em produção, sempre defina uma N8N_ENCRYPTION_KEY persistente, forte e armazenada com segurança.

4.2 Compartilhamento Seguro de Credenciais

O modelo de compartilhamento do N8N segue o princípio do menor privilégio: usuários com quem uma credencial é compartilhada podem utilizá-la em seus workflows, mas não conseguem visualizar ou editar o conteúdo da credencial — como a chave de API em si.

Comportamento do compartilhamento de credenciais:

• O proprietário da credencial pode compartilhá-la com usuários específicos

• Usuários que recebem acesso podem usar a credencial, mas não vê-la

• Credenciais criadas dentro de um projeto são acessíveis aos membros conforme sua role

• Project Admins: podem ver, editar, compartilhar e excluir

• Project Editors: podem usar e editar

• Project Viewers: podem apenas usar em workflows existentes

Segredos Externos (External Secrets)

Para ambientes que exigem gerenciamento centralizado de segredos, o N8N Enterprise suporta integração com cofres externos de segredos, eliminando a necessidade de armazenar credenciais sensíveis diretamente no banco de dados do N8N.

Provedor Suportado	Tipo	Observação
HashiCorp Vault	Self-hosted	Suporte a múltiplos vaults por instância (v2.10.0+)
AWS Secrets Manager	Cloud	Integração nativa com ecossistema AWS
Azure Key Vault	Cloud	Ideal para ambientes Azure/Microsoft
GCP Secret Manager	Cloud	Para infraestruturas Google Cloud

A adoção de External Secrets é especialmente recomendada para empresas com políticas rigorosas de compliance e auditoria, pois centraliza o controle de segredos e facilita a rotação de credenciais sem necessidade de atualizar múltiplas configurações no N8N.

Segurança na Infraestrutura Self-Hosted

Para equipes que operam instâncias N8N self-hosted, a responsabilidade pela segurança da infraestrutura é integralmente da organização. Abaixo estão as configurações e práticas mais críticas.

HTTPS e TLS Obrigatórios

Nunca exponha o N8N via HTTP em ambiente de produção. Use um reverse proxy (NGINX, Traefik, Caddy) para terminar TLS e encaminhar o tráfego para a instância. Isso garante que credenciais e tokens transmitidos durante o login e as chamadas de API não sejam interceptáveis.

Restrição de Acesso ao Editor

O editor N8N — onde workflows são criados e credenciais configuradas — não deve ser exposto diretamente à internet. Implemente uma das seguintes estratégias:

VPN corporativa: usuários acessam o editor apenas através da VPN
IP Allowlist: restrinja o acesso ao endpoint do editor a faixas de IP específicas via firewall ou security group
Autenticação no proxy: configure autenticação adicional no reverse proxy antes de chegar ao N8N

Proteção contra SSRF

Workflows N8N podem fazer requisições HTTP para serviços externos. Para evitar ataques de Server-Side Request Forgery (SSRF) — onde um workflow malicioso poderia acessar recursos internos da rede — configure os controles de hosts e faixas de IP permitidas.

Variáveis de ambiente para proteção SSRF:

• N8N_BLOCK_ENV_ACCESS_IN_NODE: impede acesso a variáveis de ambiente dentro de nodes

• Configure allowlists de hosts que os workflows podem alcançar

• Bloqueie faixas de IP privadas (10.x, 172.16.x, 192.168.x) para evitar acesso à rede interna

Nodes de Alto Risco

O node Execute Command permite executar comandos arbitrários no sistema operacional onde o N8N está rodando. Se essa funcionalidade não for necessária, desative-o e outros nodes de alto risco usando a variável de ambiente N8N_NODES_DENYLIST.

⚠ Nodes que devem ser avaliados para desativação:

• Execute Command: execução de comandos no servidor

• Read/Write Files from Disk: acesso ao sistema de arquivos

• SSH: conexões SSH a partir de workflows

• Avalie o contexto de uso antes de desativar — alguns workflows legítimos podem depender dessas capacidades

Retenção de Dados de Execução

Os logs de execução do N8N armazenam inputs e outputs de cada node — o que pode incluir dados sensíveis como tokens, números de documentos ou informações pessoais. Configure a retenção automática para limitar a janela de exposição.

Configurações recomendadas de retenção:

• EXECUTIONS_DATA_MAX_AGE: defina entre 30 e 60 dias para ambientes de produção

• Use a funcionalidade de Redação de Dados de Execução para mascarar campos sensíveis nos logs

• Avalie quais dados realmente precisam ser persistidos para debugging vs. dados que devem ser efêmeros

6. Segurança de Webhooks

Webhooks são um dos pontos de entrada mais comuns em automações N8N — e também uma superfície de ataque se não forem adequadamente protegidos. Qualquer endpoint de webhook exposto publicamente sem autenticação pode ser invocado por qualquer pessoa que conheça a URL.

Autenticação em Webhooks

O N8N permite configurar autenticação nos nós de Webhook, exigindo que as requisições incluam credenciais válidas. Utilize uma das opções disponíveis:

Basic Auth: usuário e senha incluídos no header Authorization
Header Auth: token customizado em um header específico
JWT: validação de tokens JWT assinados
None: apenas para webhooks internos em redes privadas, nunca em produção pública

Randomização de Caminhos de Webhook

Evite usar caminhos de webhook previsíveis ou baseados em nomes de projetos. Utilize UUIDs ou strings aleatórias nos caminhos, dificultando a descoberta por varredura automatizada. O N8N gera automaticamente caminhos únicos por padrão — evite substituí-los por valores mais simples.

Proteção do Endpoint /rest

A API pública do N8N (endpoint /rest) deve ser desativada ou protegida se não estiver em uso externo. Caso não precise expor a API do N8N a sistemas externos, bloqueie esse endpoint no nível do proxy ou firewall para reduzir a superfície de ataque.

Auditoria e Rastreabilidade

Log Streaming

Em ambientes enterprise, o N8N suporta streaming de logs para sistemas externos de observabilidade e SIEM (Security Information and Event Management). Isso permite auditoria centralizada de quem fez o quê, quando e em qual workflow.

Destinos suportados para Log Streaming:

• Syslog: integração com coletores de log tradicionais

• Webhook: envio de eventos para sistemas customizados

• Loki: stack de observabilidade Grafana

• Sentry: rastreamento de erros e eventos

Histórico de Workflows

O N8N mantém histórico de versões de workflows, permitindo rastrear mudanças ao longo do tempo. Em conjunto com o Source Control (integração com Git), é possível manter rastreabilidade completa de alterações, com autoria e timestamp de cada modificação.

Source Control e Ambientes

O recurso de Source Control do N8N Enterprise integra a plataforma a repositórios Git, permitindo que workflows sejam versionados, revisados em pull requests e promovidos entre ambientes (desenvolvimento, homologação, produção) de forma controlada e auditável.

Segurança no N8N Cloud

Para organizações que utilizam o N8N Cloud (SaaS gerenciado), parte da responsabilidade de segurança é absorvida pela infraestrutura da plataforma:

Aspecto	N8N Cloud	Self-Hosted
Infraestrutura	Azure EU, gerenciado pela n8n	Responsabilidade da organização
Atualizações de segurança	Automáticas, última versão estável	Manual — requer processo de atualização
Backups	Automatizados e inclusos	Responsabilidade da organização
Criptografia em repouso	Azure SSE (Server Side Encryption)	Depende da configuração N8N_ENCRYPTION_KEY
Rede privada	Isolamento gerenciado pela n8n	Responsabilidade de configurar VPC/firewall
RBAC Enterprise	Disponível em planos pagos	Requer licença enterprise

No N8N Cloud, os dados e o hardware são hospedados na União Europeia via Microsoft Azure, que gerencia os controles físicos e de rede da infraestrutura, incluindo isolamento em rede privada inacessível à internet pública.

Checklist de Segurança N8N Enterprise

Use este checklist como referência para avaliar o nível de segurança da sua instância N8N antes de qualquer deploy em produção:

Item	Prioridade	Status
2FA habilitado para todos os usuários	🔴 Crítico
N8N_ENCRYPTION_KEY persistente e segura configurada	🔴 Crítico
HTTPS/TLS via reverse proxy ativo	🔴 Crítico
Editor não exposto diretamente à internet	🔴 Crítico
RBAC configurado com menor privilégio	🟡 Alto
SSO/SAML integrado ao IDP corporativo	🟡 Alto
Webhooks com autenticação configurada	🟡 Alto
Retenção de execuções configurada (30-60 dias)	🟡 Alto
Nodes de alto risco avaliados e desativados se não usados	🟡 Alto
External Secrets integrado para credenciais críticas	🟢 Recomendado
Log Streaming para SIEM configurado	🟢 Recomendado
Source Control (Git) ativo para versionamento	🟢 Recomendado
Personal Space Policies restritivas configuradas	🟢 Recomendado
Proteção SSRF configurada	🟢 Recomendado
Instância atualizada para última versão estável	🟢 Recomendado

Conclusão

A segurança de uma instância N8N é uma responsabilidade compartilhada entre a plataforma, a equipe técnica e os processos organizacionais. Enquanto o N8N Enterprise fornece as ferramentas adequadas — 2FA enforcement, RBAC, External Secrets, Log Streaming, SSO — cabe às equipes de TI e segurança configurá-las corretamente e mantê-las atualizadas.

A abordagem de defesa em profundidade é a mais eficaz: empilhar múltiplas camadas de controle (autenticação forte + menor privilégio + criptografia + monitoramento + rede segura) garante que a falha em um ponto não comprometa todo o sistema.

Para organizações que utilizam o N8N como plataforma central de automação — especialmente em contextos de integração com sistemas financeiros, dados pessoais (LGPD/GDPR) ou infraestruturas críticas — a implementação completa das práticas descritas neste artigo é não apenas recomendada, mas obrigatória.