Hardening de entornos n8n enterprise: el perímetro oculto
Análisis exhaustivo de superficies de ataque en integraciones de automatización en la nube. Configuración segura de webhooks y encriptación de credenciales.
Por qué n8n se convierte en un objetivo de alto valor
Una instancia de n8n productiva acumula credenciales hacia decenas de SaaS: Slack, GitHub, AWS, Stripe, bases de datos, CRM. Comprometer el host equivale a comprometer todo ese set de integraciones a la vez. Y, sin embargo, la mayoría de despliegues que reviso están detrás de un Cloudflare Tunnel sin autenticación adicional, con N8N_ENCRYPTION_KEY en un .env versionado y webhooks públicos sin validación de firma.
Controles mínimos no negociables
Autenticación SSO obligatoria delante de la UI (Cloudflare Access, Authentik o similar), N8N_ENCRYPTION_KEY rotada y custodiada en un secret manager (no en variables de entorno persistidas), base de datos externa con TLS, y ejecución de workflows en modo queue con workers aislados por red del scheduler.
Para webhooks expuestos: firma HMAC obligatoria validada en el primer nodo del workflow, allowlist de IPs cuando el proveedor lo permite, y rate limiting en la capa de ingreso. Un webhook sin firma es una RPC anónima sobre tu infraestructura.
Aislamiento de workflows
El nodo Execute Command y el nodo Code en modo unrestricted son RCE por diseño cuando los usa un operador con acceso a la UI. En entornos multi-equipo desactivo ambos a nivel de instancia y obligo a que cualquier integración custom pase por un nodo HTTP contra un microservicio interno auditado, donde la lógica vive en un repo con revisión de código y firma de imagen.