Cómo proteger credenciales y datos sensibles en n8n

Las automatizaciones suelen concentrar acceso a correo, bases de datos, almacenamiento y APIs. Una sola credencial expuesta puede afectar a varios sistemas, por lo que su gestión debe formar parte del diseño del workflow.

Cómo almacena n8n las credenciales

n8n utiliza credenciales para autenticar nodos frente a servicios externos. En una instalación self-hosted, estos datos se cifran antes de almacenarse en la base de datos mediante la clave de cifrado de la instancia.

n8n genera una clave en el primer inicio si no proporcionas una. Definir N8N_ENCRYPTION_KEY permite controlar y respaldar ese secreto de forma explícita. La misma clave será necesaria para utilizar las credenciales después de una restauración.

No escribas secretos dentro del workflow

Una clave API pegada en un nodo de código, una expresión o un campo visible puede terminar en exportaciones JSON, capturas o historiales. Utiliza siempre el tipo de credencial adecuado cuando exista.

Para HTTP Request, configura autenticación mediante credenciales en lugar de construir manualmente cabeceras con tokens escritos en el nodo.

Aplicar el principio de mínimo privilegio

La cuenta conectada a n8n debería disponer únicamente de las operaciones necesarias. Si un workflow solo añade filas a una hoja concreta, no necesita control administrativo sobre toda una organización.

Cuando el proveedor lo permita, crea cuentas de servicio o claves independientes por entorno y proyecto. Esto facilita revocar un acceso sin interrumpir todas las automatizaciones.

• Separa desarrollo y producción.
• Usa una credencial distinta para cada finalidad crítica.
• Evita cuentas personales con permisos globales.
• Revisa periódicamente qué workflows utilizan cada credencial.

Proteger la clave de cifrado y las copias

La clave de cifrado no debe almacenarse únicamente dentro del mismo VPS. Conserva una copia cifrada y controla quién puede acceder a ella. No la publiques en Git ni la incluyas en documentación pública.

Una copia de PostgreSQL y del volumen de n8n debe tratarse como información sensible. Aunque las credenciales estén cifradas, la copia contiene workflows, ejecuciones y posiblemente datos personales.

Controlar ejecuciones y registros

Los datos procesados pueden quedar guardados en el historial de ejecuciones. Configura qué ejecuciones conservar y elimina información que no sea necesaria.

Antes de compartir una captura de un error, revisa cabeceras, cuerpos HTTP, direcciones de correo y valores de nodos. Difuminar una clave parcialmente no siempre es suficiente si otros campos permiten reconstruirla.

Compartir credenciales dentro de un equipo

Compartir acceso no debería significar copiar la contraseña por mensajería. Utiliza las funciones de proyectos y compartición disponibles en tu edición, y revisa los roles asignados.

Cuando una persona abandone el proyecto, elimina su acceso y valora rotar las credenciales que pudo utilizar. La revocación debe estar documentada, no depender de la memoria.

Lista de comprobación

• N8N_ENCRYPTION_KEY está definida y respaldada.
• El archivo .env tiene permisos restrictivos.
• No hay secretos escritos en nodos o notas.
• Las cuentas externas usan mínimo privilegio.
• Las copias están cifradas y se prueban.
• La retención de ejecuciones está configurada.
• Existe un proceso de rotación y revocación.

Fuentes oficiales

• Configurar una clave de cifrado personalizada
• Crear y editar credenciales
• Seguridad en instalaciones self-hosted

Continúa aprendiendo

Consulta la guía introductoria de BreachReel o descubre la formación estructurada para avanzar desde los fundamentos hasta automatizaciones completas.