Hardening de ERPNext y Frappe Bench: checklist

Este artículo desarrolla la capa de servidor dentro de nuestra serie sobre seguridad en ERPNext. Si todavía no tienes el panorama completo (producto, cumplimiento y entorno), empieza por la guía de seguridad de ERPNext y vuelve aquí para el detalle de sistemas.

Las cuatro capas de hardening

ERPNext es razonablemente seguro de partida, pero la seguridad real en producción depende del entorno que lo rodea, no solo del producto. Estas son las cuatro capas que endurecemos en cada instalación, en el orden en que conviene revisarlas: sistema operativo y red, Nginx y TLS, MariaDB y Redis, y por último Frappe Bench.

1. Sistema operativo y red

En esta capa se juega si el resto de la seguridad tiene sentido: una distribución Linux estable y al día, un firewall con solo los puertos imprescindibles abiertos, fail2ban activo contra fuerza bruta, acceso SSH solo por clave y los relojes del sistema sincronizados con logs centralizados.

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

Nginx es la puerta de entrada, así que aquí se concentra buena parte del blindaje visible desde fuera: TLS 1.2 en adelante con cifrados modernos, HSTS con preload, OCSP stapling, cabeceras de seguridad completas y límites de tasa en las rutas /api y /method para frenar abusos automatizados.

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

Base de datos y caché no deben ser accesibles desde fuera del propio servidor bajo ningún concepto: MariaDB y Redis atados a localhost o socket Unix, el usuario de Frappe sin permisos de superadministrador, cifrado en reposo si el cumplimiento lo exige, y copias diarias con binlog probadas cada mes.

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

En la capa de aplicación se cierra lo que el sistema operativo y la red no pueden proteger por sí solos: modo desarrollador desactivado en producción, logs rotados con retención clara, 2FA obligatorio para los roles administrativos, SSO si la organización lo usa, y auditoría de accesos activa cada mes.

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

Tener backups y no haberlos probado nunca es, en la práctica, lo mismo que no tener backups: el fallo se descubre siempre en el peor momento posible. Una prueba de restore real, paso a paso, para comprobar que de verdad puedes recuperar el sistema entero cuando haga falta:

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 todavía, este es el orden recomendado, y conviene respetarlo tal cual: red y SSH primero, porque si eso falla nada más importa; después TLS y cabeceras en Nginx, luego base de datos y caché, permisos en la aplicación y, al final, backups probados de verdad.

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, capa por capa, sin saltarse ninguna por prisa. ¿Quieres que auditemos la tuya? Contáctanos — entregamos un informe priorizado con plan de remediación concreto, no una lista genérica de recomendaciones.

Si prefieres no llevar esto tú

Nada de esta lista tiene por qué recaer en tu equipo. En nuestro hosting gestionado el servidor llega endurecido y con las copias funcionando y probadas, y con el mantenimiento contratado los parches y las subidas de versión entran solos, pasando siempre antes por staging.