Seguridad

Hardening de ERPNext y Frappe Bench: checklist por capas

Sistema operativo, red, Nginx, MariaDB, Redis, Bench y aplicación. La seguridad real de ERPNext en producción depende de las capas que la rodean tanto como del propio producto. Este es el orden en que las endurecemos en proyectos reales, con ejemplos concretos de configuración.

Carlos Martínez·Director Técnico
6 de mayo de 2026
10 min de lectura

Las cuatro capas de hardening

ERPNext es razonablemente seguro de partida, pero la seguridad real en producción depende del entorno que lo rodea. Estas son las cuatro capas que endurecemos en cada instalación.

1. Sistema operativo y red

  • **Distribución Linux estable** (Ubuntu LTS, Debian o Rocky); kernel y librerías al día.
  • **Firewall** (ufw, firewalld) con solo puertos imprescindibles abiertos: 80, 443, SSH no estándar.
  • **Fail2ban activo** en SSH y Nginx con jails personalizadas para ERPNext (login fallido, fuerza bruta sobre /api).
  • **SSH solo con clave** (PermitRootLogin no, PasswordAuthentication no), puerto no estándar y rate-limit.
  • **NTP sincronizado** y logs centralizados (syslog remoto o ELK / Loki).

2. Nginx y TLS

  • **TLS 1.2+** con cifrados modernos (Mozilla intermediate o moderno); deshabilitar TLS 1.0 y 1.1.
  • **HSTS** con includeSubDomains y preload una vez verificado.
  • **OCSP stapling** activo y resolver configurado.
  • **Headers de seguridad**: Content-Security-Policy adaptado, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy restrictiva.
  • **Rate limiting** en Nginx para /api y /method (limit_req_zone).
  • **Acceso a /api/method/frappe.client.get_list vigilado**: usuarios sin rol no deben poder enumerar arbitrariamente.

Content-Security-Policy de partida

Una CSP conservadora para ERPNext debería al menos incluir:

****`

default-src 'self';

img-src 'self' data: https:;

script-src 'self' 'unsafe-inline';

style-src 'self' 'unsafe-inline';

connect-src 'self' wss:;

frame-ancestors 'none';

****`

Si tienes integraciones externas (Stripe, Sentry, herramientas de tracking) hay que añadirlas explícitamente. Audita la consola del navegador en staging antes de aplicar la CSP a producción.

3. MariaDB y Redis

  • **MariaDB bind a localhost** o al socket Unix (no expuesto en Internet ni en red interna no necesaria).
  • **Usuario MariaDB de Frappe sin permisos de superadmin**; permisos solo sobre el schema del site.
  • **Cifrado at-rest** (LUKS o cifrado en MariaDB) si el cumplimiento lo exige (sectores regulados, datos especialmente sensibles).
  • **Redis bind a localhost o socket Unix**; nunca expuesto sin requirepass y con AUTH.
  • **Backups MariaDB diarios + binlog** para PITR; copias offsite cifradas con rotación de claves.
  • **Pruebas mensuales de restore** en entorno aislado.

4. Frappe Bench y aplicación

  • **developer_mode = 0** en producción y **server_script_enabled = 0** salvo necesidad explícita auditada.
  • Logs de Bench rotados con logrotate y retención clara.
  • supervisord con permisos mínimos; bench user sin shell de root.
  • **2FA obligatorio** para System Manager y roles administrativos.
  • **SSO** con SAML/OAuth2 si la organización lo usa (Entra ID, Google Workspace, Keycloak).
  • **Auditoría**: Activity Log activado; revisión mensual de accesos privilegiados.
  • **Política de contraseñas** con longitud mínima 12 y rotación al menos anual para roles críticos.

Cómo hacer una prueba de restore real

Una prueba de restore real, paso a paso:

  • Toma el backup más reciente (DB + private + public).
  • Crea un site nuevo en una máquina aislada (puede ser un container Docker).
  • Restaura DB con **bench --site newsite restore mysite-db.sql.gz**.
  • Restaura private/public files.
  • Inicia el site y verifica que los datos cuadran (cuentas contables, facturas, usuarios).
  • Documenta el tiempo total: **ese es tu RTO real**.

Al menos una prueba de restore al mes; cualquier instalación crítica que no la haga está construyendo un castillo de naipes.

Por dónde empezar

Si tienes una instalación nueva o sin auditar, este es el orden recomendado:

  • **Red y SSH** (si SSH es vulnerable, lo demás no importa).
  • **TLS y headers** en Nginx.
  • **MariaDB y Redis** bind a localhost.
  • **2FA y permisos** en la aplicación.
  • **Backups y prueba de restore**.

Conclusión

El hardening de ERPNext es una serie de pasos relativamente estándar que toda instalación productiva debería tener. ¿Quieres que auditemos la tuya? [Contáctanos](/contacto) — entregamos informe priorizado con plan de remediación.

Empezar · Respuesta en 24h

¿Tienes dudas sobre ERPNext?

Contacta con nosotros para una consulta gratuita. Te ayudamos a evaluar si ERPNext es la solución adecuada para tu empresa.

Demo personalizada
Sin compromiso
Equipo en España