Lista de seguridad de n8n para una instancia compartida y autoalojada
Lista de seguridad de n8n para managers: base de la instancia, clave de cifrado, exposición de webhooks, accesos con ejemplos de rbac y límites de funciones.
Comprobado con la documentación de n8n el .
Qué cubre esta lista de seguridad de n8n
Esta lista de seguridad de n8n está escrita para el momento en que una instancia autoalojada deja de ser el sandbox de una sola persona y pasa a ser infraestructura compartida. Cubre cinco áreas: la base de la instancia, las credenciales y la clave de cifrado, la exposición de webhooks, el acceso de usuarios y los roles, y las restricciones de funciones que limitan lo que un flujo puede leer.
Todo lo factual que aparece aquí proviene de la propia documentación de producto de n8n. No se aportaron datos de benchmarks, encuestas ni incidentes, así que trata las comprobaciones como controles documentados y no como protección medida, y confirma la disponibilidad del plan y los valores por defecto en tu propia versión antes de comprometerte con un plan de despliegue.
"Hecho" significa lo mismo en cada sección: una persona responsable con nombre ha verificado el ajuste en la instancia en producción, ha escrito el valor esperado en algún lugar que tu equipo pueda encontrar y ha fijado una fecha para volver a revisarlo. n8n documenta una visión general de seguridad para autoalojamiento que cubre la ejecución de una auditoría de seguridad, la configuración de SSL y SSO, la restricción de nodos y de la API pública y la redacción de datos de ejecución, además de la autenticación en dos pasos para los usuarios.
La auditoría en sí puede ejecutarse de tres formas: la línea de comandos, la API pública autenticada como propietario de la instancia, o el nodo n8n. Su informe de instancia señala webhooks sin proteger, ajustes de seguridad ausentes y una instancia desactualizada.
Sources: Security | Deploy | n8n Docs, Run security audits | Deploy | n8n Docs
Base de la instancia e higiene de la clave de cifrado
Empieza por el transporte. Para TLS, n8n recomienda terminarlo delante de la instancia con un proxy inverso como Traefik o un balanceador de carga de red, en lugar de exponer n8n directamente.
Después, la clave de cifrado. n8n cifra las credenciales con una clave que se genera automáticamente en el directorio .n8n del home en el primer arranque, y puedes sobrescribirla con la variable de entorno N8N_ENCRYPTION_KEY. Un estándar de equipo sugerido: defínela explícitamente y guárdala en tu gestor de secretos, para que la clave no exista únicamente en un disco. Si ejecutas el modo cola, la documentación es explícita: la variable de entorno de la clave de cifrado debe estar definida en cada worker.
La autenticación en dos pasos puede imponerse a todos los usuarios con N8N_MFA_ENFORCED_ENABLED, cuyo valor por defecto es false. Ten en cuenta que, cuando esta política se gestiona mediante variables de entorno, los controles equivalentes de la interfaz quedan bloqueados.
El inicio de sesión único con SAML u OIDC es una función de pago: Cloud Enterprise, y Business o Enterprise en autoalojado. Configurar SSO con variables de entorno está disponible desde n8n 2.18.0; las instancias más antiguas lo configuran en la interfaz.
Sources: Security | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs, Set a custom encryption key | Deploy | n8n Docs, Security | Deploy | n8n Docs, Configure SSO | Deploy | n8n Docs
Comprobaciones de exposición de webhooks
Los webhooks son el primer punto por donde se filtra una instancia compartida, porque una URL de producción es accesible para cualquiera que la descubra. El nodo Webhook admite Basic auth, Header auth o JWT auth, y también None, que deja la URL abierta. Si el campo de lista de IP permitidas se deja vacío, cualquier dirección puede invocar la URL de producción del webhook.
| Opción | Qué comprueba | Deja abierto |
|---|---|---|
| Basic auth | Usuario y contraseña en la petición | Nada más documentado |
| Header auth | El valor de una cabecera concreta | Nada más documentado |
| JWT auth | Un token firmado en la petición | Nada más documentado |
| None | Ninguna verificación del emisor | Cualquiera que tenga la URL |
| Lista de IP permitidas vacía | Ninguna restricción de origen | Todas las direcciones IP |
Un estándar de equipo razonable, ofrecido como sugerencia y no como requisito documentado: todo webhook de producción recibe un método de autenticación y una lista de IP permitidas, y ambos se comprueban durante la revisión del flujo junto con la nomenclatura y la gestión de errores. Esta es la parte de la seguridad de n8n que más a menudo se descuida cuando varias personas publican flujos.
Vale la pena conocer un comportamiento específico de versión antes de actualizar. Desde n8n 1.103.0, las respuestas HTML de los webhooks se envuelven automáticamente en iframes en sandbox como mecanismo de protección, lo que puede romper flujos que dependían del comportamiento anterior.
Sources: Webhook | Nodes | n8n Docs
Acceso de usuarios, roles y ejemplos de rbac
El control de acceso en n8n funciona a nivel de instancia con los roles integrados Owner, Admin y Member, y también puedes crear roles de instancia personalizados. El objetivo de los roles personalizados, según la documentación, es que un usuario obtenga solo las capacidades que necesita en lugar de acceso completo de Admin. Los roles personalizados, tanto de instancia como de proyecto, requieren Enterprise tanto en Cloud como en autoalojado, así que comprueba el nivel antes de diseñar en torno a ellos.
Los proyectos agrupan flujos y credenciales, y los administradores de proyecto añaden y quitan usuarios dentro de su proyecto. Ejemplos prácticos de rbac para una instancia compartida: las nuevas incorporaciones entran como Member por defecto; un grupo pequeño y nombrado tiene Admin; cada departamento tiene un proyecto para que sus credenciales no sean visibles para todos; y un administrador de proyecto se responsabiliza de las altas y bajas de ese proyecto.
Una trampa operativa que debe formar parte de tu proceso de cambios. Mover un flujo o una credencial entre proyectos o usuarios elimina todo el uso compartido existente y puede afectar a otros flujos, así que anuncia los movimientos con antelación en lugar de hacerlos discretamente un viernes.
Si tu equipo guarda los flujos de n8n en un repositorio de GitHub, una adición sugerida a esta revisión: decide quién puede acceder a ese repositorio al mismo tiempo que revisas los roles de la instancia. La documentación de n8n aportada no cubre el control de versiones, así que fija ese estándar por tu cuenta.
Sources: Set permissions and roles (RBAC) | Administer | n8n Docs, Organize work in projects | Administer | n8n Docs, Custom roles | Administer | n8n Docs
Restricciones de funciones y una cadencia de revisión
La última capa limita lo que un flujo puede alcanzar incluso cuando se ejecuta correctamente. N8N_BLOCK_ENV_ACCESS_IN_NODE controla si los usuarios pueden leer variables de entorno desde las expresiones y el nodo Code, y los valores por defecto pueden variar según la versión, así que lee el valor en tu instancia en lugar de suponerlo. La misma visión general apunta a restringir nodos y la API pública y a redactar los datos de ejecución, algo que importa sobre todo cuando muchas personas pueden abrir el historial de ejecuciones de otra.
Delimita tu revisión con honestidad. Ninguna fuente aportada cubre en profundidad las copias de seguridad, el aislamiento de red, los gestores de secretos externos o la monitorización de logs, así que eso necesita su propio trabajo fuera de esta lista.
Una cadencia viable, sugerida y no prescrita: ejecuta la auditoría cada mes, revisa los roles y la pertenencia a proyectos cuando alguien entra o sale, y vuelve a leer los ajustes de autenticación de los webhooks cada vez que un flujo pase a producción. Terminar no es un visto bueno único; es un repaso corto y recurrente del que alguien se responsabiliza.
Un repaso recurrente de seguridad en n8n
- Auditar: Ejecuta la auditoría de seguridad y lee el informe de instancia.
- Priorizar: Trata los webhooks sin proteger y una instancia desactualizada como bloqueantes.
- Accesos: Revisa Owner, Admin y la pertenencia a proyectos frente al equipo actual.
- Webhooks: Confirma la autenticación y las listas de IP permitidas en los webhooks de producción.
- Registrar: Anota los valores esperados y fija la próxima fecha de revisión.
Ese repaso recurrente es lo que mantiene la seguridad de n8n como algo real y no aspiracional en una instancia compartida.
Sources: Security | Deploy | n8n Docs, Security | Deploy | n8n Docs
