- Guarde segredos fora do workflow: prefira variáveis de ambiente e políticas de acesso
- Garanta que a chave de criptografia de credenciais seja estável e bem protegida
- Controle quem pode ver credenciais (UI, banco, backups, logs e métricas)
- Planeje rotação: dupla escrita, janela de transição e rollback
Mapeie onde os segredos aparecem hoje
Liste todos os pontos onde dados sensíveis podem estar: credenciais do n8n (UI), variáveis de ambiente do container/VM, banco de dados, arquivos de workflow exportados, logs, ferramentas de observabilidade e backups. Se você não consegue apontar todos os lugares, a rotação e o controle de acesso vão falhar.
Defina a regra: secrets só em variáveis de ambiente (quando fizer sentido)
Para tokens, chaves de API e segredos que mudam com frequência, use variáveis de ambiente no runtime (Docker/Kubernetes/VM). Isso evita que o segredo fique “enterrado” em nós de workflow, exportações ou prints. Quando precisar usar credenciais nativas do n8n (por conector), trate como item de segurança: acesso mínimo e auditoria.
Garanta criptografia de credenciais com uma chave controlada
O n8n criptografa credenciais no banco usando uma chave de criptografia. Na prática operacional: essa chave precisa ser estável (não pode mudar a cada deploy) e deve ser guardada como segredo de infraestrutura (secret do cluster, vault, variáveis protegidas do CI/CD). Se ela for perdida, você pode ficar sem conseguir descriptografar credenciais existentes.
Trave o acesso: UI, banco, host e rede
Restrinja quem acessa o painel do n8n e quem acessa o banco diretamente. Use segmentação de rede (ex.: banco só acessível pela rede privada), permissões mínimas no host e controle de autenticação forte no n8n. Onde dá ruim de verdade: acesso ao banco + acesso ao backup = exfiltração silenciosa.
Reduza o risco de vazamento em logs e execuções
Revise workflows para não registrar payloads completos contendo PII/tokens. Evite nós que “logam tudo” ou salvam respostas integrais quando não é necessário. Em incidentes reais, o vazamento não acontece pelo cofre: acontece por log, export, print e JSON colado em ticket.
Projete rotação sem quebrar produção
Rotação de segredo exige janela de transição: (1) aceite o segredo antigo e o novo por um período (quando o sistema permitir), (2) atualize credenciais/variáveis, (3) valide fluxos críticos, (4) revogue o segredo antigo. Tenha um plano de rollback documentado, porque o erro típico é girar a chave e descobrir no dia seguinte que um fluxo noturno parou.
Audite backups e exportações
Backups podem carregar credenciais criptografadas e dados sensíveis de execuções (dependendo da configuração e do que você armazena). Trate backup como dado sensível: criptografia em repouso, controle de acesso, retenção mínima, e testes de restauração. Exportar workflow para “passar pro colega” é um dos jeitos mais comuns de vazar contexto e dados.
O que é “secret” vs “credential” no n8n (na prática)
No dia a dia, dá para separar assim: secret é qualquer valor que não pode vazar (token, API key, senha, client secret). Credential é o “objeto” dentro do n8n que guarda (de forma criptografada) as informações para um conector (Google, SMTP, banco, etc.).
O erro comum é tratar tudo como credential dentro da UI e depois descobrir que o segredo foi parar em exportação, log, print de debug ou no histórico do chat interno.
| Item | Onde fica | Risco típico | Boa prática |
|---|---|---|---|
| Variável de ambiente (secret) | Runtime do n8n (container/VM) | Vaza em pipeline/CI, compose compartilhado, print de diagnóstico | Gerenciar em secret store e restringir acesso ao deploy |
| Credencial do n8n | Banco do n8n (criptografada) | Quem acessa UI/banco/backup pode exfiltrar | RBAC/controle de acesso e backups com criptografia e acesso mínimo |
| Dados sensíveis no workflow | Nós, parâmetros, JSON colado | Vaza em export, versionamento, screenshot | Evitar hardcode; preferir referência indireta (env/credentials) e mascarar dados |
| Logs e execuções | Logs do app e histórico de execução | PII/tokens em payloads gravados | Registrar só o necessário; sanitização e retenção curta |
Checklist rápido: sinais de que você está “vazando sem perceber”
Se você marcar 2 ou mais itens abaixo, vale parar e arrumar antes de escalar a automação.
- Workflows com tokens/senhas hardcoded em campos de texto
- Exports de workflow circulando por e-mail/WhatsApp/drive sem controle
- Logs guardando payload completo de webhooks (com CPF, e-mail, telefone, tokens)
- Backup do banco acessível por muita gente (ou sem criptografia)
- Mesmo usuário admin usado por todo mundo no n8n
- Ambiente de homologação usando as mesmas chaves do ambiente de produção
Rotação de secrets: um roteiro que evita o “girou e caiu”
Rotação falha quando é tratada como ato único (“troca a chave e pronto”). Em automação, rotação é um processo com transição e validação.
Quando o provedor permite múltiplas chaves ativas, use isso a seu favor: ative a nova, atualize o n8n, valide fluxos, e só depois revogue a antiga. Quando não permite, faça a troca em janela controlada e monitore erros (429/401/403) e quedas de execução.
- 1) Inventário: quais workflows dependem desse segredo e com que criticidade
- 2) Janela: escolha período de baixo impacto e combine critérios de sucesso
- 3) Transição: habilite segredo novo sem invalidar o antigo (se possível)
- 4) Atualização: mude env/credenciais e replique para todos os nós/instâncias
- 5) Validação: rode fluxos críticos e verifique erros/autenticação
- 6) Revogação: remova o segredo antigo e documente a mudança
LGPD: onde secrets encontram dados pessoais
Mesmo que o seu segredo esteja protegido, a automação pode vazar dados pessoais em logs, execuções e integrações. Em geral, a superfície de risco é maior no “rastro operacional” (histórico de execuções e payloads) do que no segredo em si.
Se você lida com WhatsApp, e-commerce, CRM ou financeiro, trate o histórico de execução como dado sensível: retenção mínima, acesso restrito e monitoramento. Quando não houver dado exato do seu caso, a regra segura é: guardar menos por menos tempo.
Perguntas frequentes
Se eu perder a chave de criptografia de credenciais do n8n, o que acontece?
É melhor usar variáveis de ambiente ou credenciais do n8n?
Backups do n8n podem conter dados sensíveis?
Como evitar que tokens apareçam em logs e histórico de execução?
Leia também
Como colocar o n8n em produção: checklist de segurança, monitoramento e backup (sem susto)
Guia prático para subir n8n em produção com HTTPS, credenciais, filas/retry, logs, alertas e backup/restauração. Focado em cenários comuns no Brasil e em operação estável.
Ler →
Como fazer backup do n8n self-hosted e restaurar sem perder workflows
Guia prático de backup e restauração do n8n self-hosted: exportar workflows e credenciais via CLI, dump do PostgreSQL, a chave de criptografia que não pode faltar e como automatizar tudo.
Ler →
Observabilidade no n8n self-hosted: como montar métricas, logs e alertas (sem adivinhação)
Guia prático para monitorar n8n self-hosted com logs, métricas e alertas. O que medir, como estruturar correlação por execução e como evitar “apagão” quando um fluxo falha.
Ler →
n8n self-hosted e LGPD: onde ficam seus dados e como ficar em conformidade
Rodar o n8n no seu próprio servidor não deixa você em conformidade com a LGPD sozinho. Veja onde os dados ficam, o que a ANPD exige e como configurar retenção, chave e transferência internacional.
Ler →