Tu CRM Dolibarr contiene sin duda el capital informativo más valioso de tu empresa: fichas de clientes, históricos de pedidos, contratos con proveedores, facturas, datos contables e incluso información bancaria. Una brecha de seguridad, una corrupción de la base de datos o simplemente un olvido de respaldo puede provocar una catástrofe: pérdidas financieras, daño a la reputación, sanciones del RGPD, e incluso el cese de la actividad.
Sin embargo, muchas empresas todavía subestiman esta dimensión crítica. En esta guía funcional completa, NEXT GESTION te entrega todas las buenas prácticas para asegurar de manera duradera tu instancia Dolibarr y garantizar la continuidad de tus datos. Abordaremos tanto la seguridad perimetral (servidor, red) como la seguridad aplicativa (Dolibarr, base de datos) y las estrategias de respaldo y recuperación ante desastres acordes con el estado del arte, manteniendo un enfoque orientado al negocio y a la decisión.
Índice
- ¿Por qué la seguridad de Dolibarr es estratégica?
- Comprender la arquitectura de Dolibarr
- Endurecimiento del sistema operativo
- Endurecimiento del servidor web
- Implementación de HTTPS y certificados SSL/TLS
- Asegurar la base de datos
- Configuración segura del entorno aplicativo
- Seguridad aplicativa en Dolibarr
- Autenticación fuerte: 2FA, LDAP, SSO
- Respaldo de la base de datos
- Respaldo de archivos y documentos
- La regla de oro 3-2-1 y el almacenamiento fuera del sitio
- Pruebas de restauración y plan de recuperación ante desastres
- Registro, monitorización y detección de incidentes
- Conformidad con el RGPD y obligaciones legales
- Errores críticos a evitar
- Conclusión: adoptar una postura proactiva
1. ¿Por qué la seguridad de Dolibarr es estratégica?
Al ser Dolibarr un ERP/CRM web accesible mediante un navegador, está por naturaleza expuesto a todas las amenazas de la web: ataques de fuerza bruta, inyecciones SQL, cross-site scripting (XSS), exfiltración de datos, ransomware, etc. A esto se suman los riesgos internos: errores humanos, eliminaciones accidentales, fallos de hardware o software, siniestros físicos (incendio, daños por agua, robo).
Las consecuencias de un compromiso o de una pérdida de datos pueden ser dramáticas:
- Pérdidas financieras directas: imposibilidad de facturar, retrasos en los pagos, sanciones contractuales.
- Daño a la reputación: pérdida de confianza de clientes y proveedores.
- Sanciones RGPD: hasta el 4 % de la facturación mundial o 20 millones de euros.
- Cese de actividad: según varios estudios, el 60 % de las pymes víctimas de un ciberataque importante quiebran en los 6 meses siguientes.
Asegurar Dolibarr no es, por tanto, una opción, es una obligación estratégica y legal.
2. Comprender la arquitectura de Dolibarr
Antes de asegurar, hay que entender. Dolibarr se apoya en una pila de software clásica compuesta por cuatro capas: un sistema operativo Linux (Debian, Ubuntu, RHEL, AlmaLinux), un servidor web (Apache o Nginx), una base de datos relacional (MySQL, MariaDB o PostgreSQL) y un entorno de ejecución PHP. Cada una de estas capas debe asegurarse individualmente porque el compromiso de una sola puede bastar para poner en peligro el conjunto.
Tres zonas de almacenamiento deben protegerse de forma prioritaria:
- La base de datos: contiene todos tus datos de negocio (clientes, productos, pedidos, facturas, contabilidad).
- El directorio de documentos: contiene los archivos generados por Dolibarr (facturas PDF, justificantes, gestión documental, fotos de productos) así como los archivos temporales.
- El código fuente y la configuración: contiene el código de Dolibarr, tus módulos personalizados y, sobre todo, el archivo de configuración que guarda las credenciales de conexión a la base de datos.
El archivo de configuración merece una atención particular: su filtración equivale a comprometer la totalidad del sistema. Debe por tanto protegerse con permisos estrictos y colocarse en un directorio no accesible desde la web.
3. Endurecimiento del sistema operativo
La seguridad comienza a nivel del sistema operativo. Estas son las acciones de endurecimiento («hardening») imprescindibles en un servidor Linux que aloja Dolibarr.
Actualizaciones sistemáticas
Los parches de seguridad deben aplicarse sin demora. Configura un mecanismo de actualizaciones automáticas de los paquetes críticos (Ubuntu y Debian disponen de un servicio dedicado, RHEL y AlmaLinux también). Al menos una vez por semana, valida manualmente que las actualizaciones se hayan aplicado correctamente.
Cortafuegos y puertos abiertos
El servidor solo debe exponer los puertos estrictamente necesarios: HTTPS (443), eventualmente HTTP (80) para la redirección hacia HTTPS, y SSH (22) restringido únicamente a las direcciones IP de los administradores. Todos los demás puertos están cerrados. Un cortafuegos software como UFW o firewalld permite aplicar esta regla de forma sencilla.
El acceso SSH en sí debe reforzarse: conexión únicamente mediante clave criptográfica (sin contraseñas), desactivación de la conexión directa como root, eventual cambio del puerto por defecto, y restricción a las direcciones IP de confianza.
Protección contra los ataques de fuerza bruta
Una herramienta de detección de intrusiones como Fail2ban analiza continuamente los registros de conexión y bloquea automáticamente las direcciones IP que multiplican los intentos fallidos (en SSH, en el formulario de inicio de sesión Dolibarr, en las API). Configura varias «jails» dedicadas para cubrir todos los puntos de entrada.
Gestión de cuentas y privilegios
Aplica el principio de mínimo privilegio: sin conexión directa como root, cuentas de usuario nominativas con sudo para las operaciones de administración, desactivación de las cuentas de sistema no necesarias. Cada acción sensible debe poder rastrearse hasta un usuario identificado.
Compartimentación de los procesos
Activa SELinux (en RHEL/AlmaLinux) o AppArmor (en Debian/Ubuntu) en modo estricto («enforcing»). Estos mecanismos compartimentan los procesos y limitan considerablemente el impacto de un compromiso: incluso si un atacante toma el control de un proceso web, no podrá acceder a recursos del sistema que no le sean explícitamente autorizados.
4. Endurecimiento del servidor web
El servidor web es la puerta de entrada de Dolibarr. Su configuración debe ser rigurosa.
Ocultar la información sensible
Por defecto, Apache y Nginx exponen su versión en los encabezados HTTP y las páginas de error. Esta información facilita el trabajo de los atacantes al permitirles dirigirse a vulnerabilidades conocidas. Desactiva sistemáticamente la visualización de la versión del servidor y de los módulos instalados.
Activar los encabezados de seguridad HTTP
Varios encabezados HTTP modernos mejoran significativamente la seguridad aplicativa:
- HSTS obliga al navegador a usar exclusivamente HTTPS.
- X-Content-Type-Options impide la interpretación incorrecta de los tipos de archivo.
- X-Frame-Options protege contra los ataques de clickjacking.
- Content-Security-Policy restringe las fuentes de scripts, estilos e imágenes, previniendo así muchos ataques XSS.
- Referrer-Policy controla la información transmitida durante la navegación.
- Permissions-Policy desactiva las funcionalidades sensibles no utilizadas (cámara, micrófono, geolocalización).
La activación de estos encabezados es una victoria rápida esencial.
Protección de los directorios sensibles
El directorio de documentos y el directorio de configuración no deben nunca ser directamente accesibles desde la web. La buena práctica consiste en colocarlos fuera de la raíz web: así, incluso en caso de mala configuración, permanecen invisibles desde el exterior. Si esto no es posible, configura el servidor web para bloquear explícitamente su acceso.
Eliminación del instalador
Una vez instalado Dolibarr, el directorio de instalación debe ser eliminado o bloqueado. Sin esta precaución, un atacante podría relanzar la instalación y sobrescribir tu base de datos. Crea también un archivo de bloqueo que impida cualquier reinstalación involuntaria.
Cortafuegos aplicativo (WAF)
Para ir más lejos, despliega un cortafuegos aplicativo como ModSecurity acoplado al OWASP Core Rule Set. Este dispositivo inspecciona cada solicitud HTTP y bloquea los comportamientos sospechosos (inyecciones SQL, XSS, escaneos de vulnerabilidades). Para los sitios más expuestos, un servicio WAF en la nube como Cloudflare ofrece una protección complementaria contra los ataques DDoS.
5. Implementación de HTTPS y certificados SSL/TLS
Ninguna instalación de Dolibarr en producción debería funcionar en HTTP. HTTPS es obligatorio para cifrar los flujos y proteger las sesiones, las contraseñas, los datos de los clientes y los documentos intercambiados.
Obtener un certificado
La obtención de un certificado SSL/TLS es hoy sencilla y gratuita gracias a Let's Encrypt, autoridad de certificación reconocida por todos los navegadores. Una herramienta como Certbot automatiza la emisión, la instalación y la renovación del certificado cada 90 días. Verifica regularmente que la renovación automática funciona para evitar una expiración imprevista.
Para las organizaciones que lo deseen, los certificados de pago (DV, OV o EV) siguen estando disponibles en autoridades comerciales y pueden ser pertinentes en ciertos contextos (validación extendida mostrada en el navegador).
Configuración TLS moderna
Desactiva los protocolos obsoletos (SSL, TLS 1.0, TLS 1.1) que presentan vulnerabilidades conocidas. Solo autoriza TLS 1.2 y TLS 1.3. Selecciona suites criptográficas modernas (ECDHE con AES-GCM o ChaCha20) y desactiva los algoritmos débiles. Prueba tu configuración en SSL Labs (ssllabs.com/ssltest) y apunta a la calificación A+.
Forzar la redirección HTTP hacia HTTPS
Cualquier solicitud HTTP debe redirigirse automáticamente a HTTPS. Esta regla es la primera línea de defensa: garantiza que ningún tráfico transite en claro.
HSTS y HSTS preload
HSTS (HTTP Strict Transport Security) impone al navegador el uso exclusivo de HTTPS para tu dominio, incluso si el usuario teclea la URL sin precisar el protocolo. Una vez que el valor sea estable, puedes enviar tu dominio a la HSTS Preload List, lo que inscribe la regla directamente en los navegadores y bloquea cualquier conexión HTTP, incluida la primera.
6. Asegurar la base de datos
La base de datos es el tesoro de Dolibarr. Su protección es crítica.
Inicialización segura
En la instalación, ejecuta el script de inicialización segura proporcionado por MySQL o MariaDB. Te permite definir una contraseña robusta para la cuenta de administración, eliminar los usuarios anónimos, prohibir la conexión remota para las cuentas privilegiadas y eliminar las bases de prueba.
Cuenta dedicada a Dolibarr
Nunca uses la cuenta de administración de la base de datos para Dolibarr. Crea una cuenta dedicada con los privilegios estrictamente necesarios: lectura, escritura, modificación de las estructuras de tablas únicamente sobre la base Dolibarr, sin acceso a otras bases ni a derechos de administración globales. Esta compartimentación limita considerablemente el impacto de un eventual compromiso de la aplicación.
Restricción de la escucha de red
Si la base de datos está en el mismo servidor que Dolibarr, configúrala para escuchar solo en la interfaz local (loopback). Ninguna conexión remota es entonces posible. Si la base se encuentra en otro servidor, usa imperativamente un canal cifrado: VPN, túnel SSH o TLS nativo en la base de datos.
Cifrado en reposo
Para los datos más sensibles, activa el cifrado transparente en reposo (TDE) a nivel del motor de base de datos. Esto protege tus archivos de datos en caso de robo físico del disco o de compromiso del respaldo bruto. Las claves de cifrado deben almacenarse en un soporte separado, idealmente en una caja fuerte digital.
Registro de los accesos
Activa el registro de auditoría de la base de datos. Registra todas las conexiones y consultas sensibles, permitiendo detectar a posteriori una intrusión o un uso anormal. Estos registros deben estar a su vez protegidos y conservados de manera segura.
7. Configuración segura del entorno aplicativo
El entorno PHP que ejecuta Dolibarr debe ser objeto de un endurecimiento específico.
Desactivación de las funciones peligrosas
PHP propone numerosas funciones susceptibles de ser desviadas por un atacante (ejecución de comandos del sistema, lectura de archivos arbitrarios, etc.). Desactiva explícitamente las que no son necesarias para Dolibarr. Cuidado, sin embargo: algunos módulos Dolibarr (exportación, mailing, OCR) pueden necesitarlas. Prueba siempre en preproducción antes de la puesta en producción.
Ocultar los errores
En producción, nunca muestres los errores PHP al visitante. Podrían revelar información sensible (rutas, credenciales, consultas SQL). Los errores deben consignarse en un registro accesible únicamente a los administradores.
Sesiones seguras
Las cookies de sesión deben marcarse como HttpOnly (inaccesibles en JavaScript), Secure (transmitidas únicamente en HTTPS) y SameSite Strict (no enviadas por sitios de terceros). Estas marcas previenen numerosos ataques de robo de sesión. La duración de vida de las sesiones también debe limitarse (30 minutos de inactividad como máximo).
Límites razonables
Configura límites de recursos adecuados: tamaño máximo de subida, duración máxima de ejecución, memoria asignada. Estos parámetros protegen tanto contra los abusos voluntarios (denegación de servicio) como contra los errores accidentales.
Caché y rendimiento
Activa OPcache para almacenar en caché el código PHP compilado. Esto mejora el rendimiento, reduce la carga del servidor y limita la ventana explotable durante un ataque por agotamiento de recursos.
8. Seguridad aplicativa en Dolibarr
Dolibarr propone de forma nativa varios mecanismos de endurecimiento que activar.
Parámetros de seguridad globales
En el menú de configuración de la seguridad, hay que activar varias palancas:
- Tiempo de expiración de sesión: 30 minutos como máximo, idealmente 15 para las cuentas de administradores.
- Política de contraseñas: longitud mínima de 12 caracteres, exigencia de complejidad (mayúsculas, minúsculas, cifras, caracteres especiales), expiración cada 90 días, prohibición de reutilizar las antiguas contraseñas.
- Protección anti-CSRF: activada por defecto, a conservar imperativamente y a extender al nivel más alto para exigir un token en todos los formularios sensibles.
- Bloqueo automático de las cuentas tras varios intentos fallidos (5 por defecto), con desbloqueo manual o temporizado.
Permisos granulares
Dolibarr ofrece un sistema de permisos por módulo y por acción muy fino. Aplica el principio del menor privilegio: cada usuario solo tiene los derechos estrictamente necesarios para su función. Un comercial no tiene acceso a la contabilidad, un contable no tiene acceso a los datos de RR. HH., etc. Esta disciplina limita las fugas de datos internas y el impacto de un compromiso de cuenta.
Multi-empresa y compartimentación
Si gestionas varias entidades jurídicas con el módulo multi-empresa, vela por el aislamiento estricto de los datos entre empresas. Configura los grupos de usuarios para evitar cualquier fuga lateral, y audita regularmente los accesos cruzados.
Desactivación de los módulos no utilizados
Cada módulo activado aumenta la superficie de ataque. Haz una auditoría regular y desactiva todo lo que ya no se utiliza. Cuanto menos código activo haya, menos vulnerabilidades potenciales.
Forzar HTTPS a nivel aplicativo
Más allá de la redirección del servidor, Dolibarr puede configurarse para rechazar las conexiones no seguras a nivel aplicativo. Esta doble protección garantiza que ningún acceso directo en HTTP pueda comprometer las sesiones.
9. Autenticación fuerte: 2FA, LDAP, SSO
La contraseña sola ya no es suficiente. Existen varias opciones de refuerzo de la autenticación.
Doble autenticación (2FA / MFA)
La activación de la doble autenticación es hoy el mínimo para las cuentas sensibles (administradores, contables, directivos). Añade un segundo factor de verificación, generalmente un código temporal generado por una aplicación móvil (Google Authenticator, Authy, Microsoft Authenticator, FreeOTP). Incluso si una contraseña se ve comprometida, el atacante no puede conectarse sin acceso físico al teléfono del usuario. Un módulo dedicado, disponible en el Dolistore, permite activarla de forma sencilla.
Autenticación LDAP / Active Directory
Para las empresas que disponen de un directorio centralizado, Dolibarr ofrece un conector nativo hacia LDAP/Active Directory. Los usuarios se conectan a Dolibarr con sus credenciales de empresa, gestionadas centralmente por la TI. Ventajas: aplicación automática de las políticas de contraseñas de empresa, desactivación inmediata de la cuenta Dolibarr en caso de salida de un colaborador, trazabilidad unificada.
Single Sign-On (SSO) mediante SAML u OpenID Connect
Para ir más lejos, ciertos módulos permiten conectar Dolibarr a un proveedor de identidad (Keycloak, Azure AD, Okta, Google Workspace) mediante los estándares SAML 2.0 u OpenID Connect. Tus usuarios se conectan una vez para acceder a todas sus herramientas, el MFA se centraliza y aplica uniformemente, la conformidad se simplifica. Es la mejor práctica para las organizaciones con varias aplicaciones de negocio.
10. Respaldo de la base de datos
El respaldo regular de la base de datos es la operación más crítica.
Frecuencia y retención
Como mínimo, planifica un respaldo completo diario, ejecutado durante un periodo de baja actividad (en general por la noche). Para los entornos críticos, complementa con respaldos incrementales más frecuentes (cada hora, o incluso en continuo). La retención recomendada: 30 días para los respaldos operativos, de 1 a 10 años para los respaldos archivados en función de tus obligaciones legales.
Métodos de respaldo
Coexisten varios enfoques:
- Respaldo lógico (exportación SQL): produce un archivo de texto legible, ideal para las pequeñas y medianas bases. Ventajas: portabilidad, posibilidad de restauración parcial. Limitaciones: lento más allá de algunos gigabytes.
- Respaldo físico en caliente: copia los archivos binarios de la base sin interrupción del servicio. Herramientas recomendadas: Mariabackup (MariaDB) o Percona XtraBackup (MySQL). Indispensable para las grandes bases.
- Replicación hacia un servidor secundario en tiempo real, que puede servir tanto como redundancia como objetivo para los respaldos (sin impacto en producción).
- Snapshots a nivel del sistema de almacenamiento o de la máquina virtual.
Compresión y cifrado
Todos los respaldos deben comprimirse (reducción de tamaño) y luego cifrarse (protección contra la fuga). El cifrado utiliza idealmente una clave asimétrica (GPG por ejemplo) cuya clave privada se almacena por separado, en una caja fuerte digital. Verifica sistemáticamente la integridad de los respaldos con una huella criptográfica (suma de control).
Restauración a un punto en el tiempo
Activa los registros binarios (binary logs) en el motor de la base de datos. Permiten la restauración a un punto preciso en el tiempo (Point-In-Time Recovery, PITR), por ejemplo «llevar la base al estado de las 14:32 de ayer, justo antes del error». Esta capacidad es preciosa para recuperar una eliminación accidental sin perder todos los datos posteriores.
11. Respaldo de archivos y documentos
La base de datos no basta: el directorio de documentos contiene los PDF de facturas, los justificantes contables, los archivos de gestión documental y las fotos de productos. Su pérdida sería igualmente grave que una pérdida de base de datos.
Respaldos incrementales
Para los archivos, prioriza los respaldos incrementales con versionado: solo se respaldan los archivos modificados en cada ciclo, y cada versión sigue siendo accesible. Este enfoque permite conservar numerosas versiones sin disparar el espacio en disco, gracias a mecanismos de enlaces duros o de deduplicación.
Código fuente y configuración
No olvides respaldar también el código fuente (módulos personalizados, sobrecargas) y el archivo de configuración. Sin ellos, una restauración de la base no basta para volver a poner en funcionamiento el sistema.
Automatización y planificación
Todos los respaldos deben ser automatizados y planificados mediante un planificador (cron, timer systemd, planificador Windows…). La ejecución manual debe evitarse: siempre acaba olvidándose. Implementa una cuenta técnica dedicada a estas operaciones, con los permisos estrictamente necesarios.
Vigilancia de los respaldos
Cada ejecución debe producir un informe que indique su estado (éxito, fallo, duración, tamaño). En caso de fallo, una alerta debe enviarse al administrador. Un respaldo del que no se sabe si se ha desarrollado correctamente no es un respaldo fiable.
12. La regla de oro 3-2-1 y el almacenamiento fuera del sitio
La regla 3-2-1 del respaldo es universalmente reconocida:
- 3 copias de los datos (el original + dos respaldos).
- en 2 soportes diferentes (disco local + NAS, por ejemplo).
- de las cuales 1 copia fuera del sitio (nube, centro de datos remoto, caja fuerte digital).
¿Por qué esta regla?
Esta regla protege contra los principales escenarios de siniestro. Una sola copia puede perderse en un fallo de disco. Dos copias en el mismo servidor se pierden en caso de incendio o ransomware. Una copia fuera del sitio garantiza la continuidad incluso en caso de destrucción física del sitio principal.
Sincronización en la nube cifrada
Usa un proveedor en la nube soberano (OVHcloud, Scaleway, Outscale, Infomaniak) o un servicio de almacenamiento de objetos (S3, Backblaze B2, Wasabi) para alojar la copia fuera del sitio. Los datos deben estar cifrados del lado del cliente antes del envío: así, ni siquiera el proveedor en la nube puede leerlos. Herramientas como rclone o restic automatizan esta sincronización cifrada.
Almacenamiento inmutable (Object Lock / WORM)
Activa el modo inmutable (WORM, Write Once Read Many) en tu almacenamiento en la nube: los respaldos no podrán modificarse ni eliminarse durante el periodo de retención definido, ni siquiera por un administrador. Es tu última línea de defensa frente a los ransomware modernos que ahora buscan destruir los respaldos antes de cifrar la producción.
Air gap para los datos críticos
Para los datos más sensibles, conserva una copia en un soporte físicamente desconectado (disco externo o cinta LTO almacenada en una caja fuerte). Esta copia «sin conexión» no puede ser alcanzada por ningún ataque informático. Su rotación manual (semanal o mensual) añade una capa de seguridad final.
13. Pruebas de restauración y plan de recuperación ante desastres
Probar tus respaldos
Un respaldo no probado no es un respaldo.
Es una de las reglas más violadas en la práctica. Muchas empresas descubren que sus respaldos estaban corruptos o incompletos el día en que los necesitan. Programa pruebas de restauración trimestrales en un servidor de preproducción: restauración completa de la base, restauración de los documentos, verificación de la integridad de los datos y de la coherencia aplicativa. Documenta los resultados y los eventuales problemas encontrados.
Plan de recuperación ante desastres (DRP)
Documenta un plan de recuperación ante desastres que precise:
- El RPO (Recovery Point Objective): la pérdida de datos máxima tolerable. Por ejemplo, «aceptamos perder como máximo 4 horas de datos».
- El RTO (Recovery Time Objective): la duración máxima de interrupción del servicio. Por ejemplo, «debemos estar de nuevo operativos en 2 horas».
- Los roles y responsabilidades en caso de siniestro: quién decide, quién ejecuta, quién comunica a los clientes.
- Los procedimientos paso a paso de restauración, suficientemente detallados para que un administrador de reemplazo pueda ejecutarlos.
- Los contactos de los proveedores (proveedor de hosting, integrador Dolibarr, asesor contable) accesibles incluso sin conexión.
Conmutación a servidor de respaldo
Para los entornos críticos, implementa un servidor de respaldo sincronizado en tiempo casi real mediante la replicación de la base de datos y la sincronización continua de los archivos. En caso de siniestro, la conmutación puede efectuarse en pocos minutos mediante redirección DNS o conmutación automática de un balanceador de carga. Esta arquitectura de alta disponibilidad se ha vuelto accesible a presupuestos de pyme.
Ejercicios de crisis
Una vez al año, organiza un ejercicio de crisis que simule un siniestro mayor. Todos los equipos implicados (técnico, negocio, dirección) participan y aplican el plan. Estos ejercicios revelan las carencias, las hipótesis falsas y las oportunidades de mejora. Más vale descubrir un problema durante un ejercicio que en situación real.
14. Registro, monitorización y detección de incidentes
Centralización de los registros
Centraliza todos los registros (servidor web, base de datos, entorno PHP, Dolibarr, fail2ban) en una herramienta dedicada: Graylog, ELK (Elasticsearch + Logstash + Kibana) o Loki + Grafana. Esta centralización permite correlacionar los eventos y detectar anomalías invisibles a simple vista (múltiples conexiones fallidas seguidas de una conexión exitosa, consultas inusuales, picos de tráfico).
Monitorización de los servicios
Vigila continuamente la disponibilidad y el rendimiento con Zabbix, Prometheus + Grafana o Netdata. Los indicadores clave a vigilar:
- Carga de CPU, memoria, E/S de disco.
- Tiempo de respuesta de las páginas Dolibarr.
- Volumen de los respaldos y éxito/fallo de las tareas planificadas.
- Espacio en disco restante (alerta al 80 % de ocupación).
- Validez de los certificados SSL (alerta 30 días antes de la expiración).
Detección de intrusión de archivos (HIDS)
Despliega una herramienta de detección de intrusión de archivos como AIDE, Tripwire o Wazuh. Calcula regularmente la huella de todos los archivos del sistema y aplicativos, y alerta en caso de modificación no prevista. Es el medio más eficaz de detectar la instalación de una puerta trasera («webshell») por un atacante.
Alertas y guardia
Configura alertas por correo electrónico, Slack, Microsoft Teams o solución de guardia (PagerDuty, Opsgenie). Define umbrales de criticidad: información, advertencia, crítico. Una intrusión detectada pronto es una intrusión contenida; una intrusión detectada tarde puede costar muy caro.
15. Conformidad con el RGPD y obligaciones legales
Si tratas datos personales en Dolibarr (clientes, prospectos, empleados), estás sujeto al RGPD. Y la seguridad técnica es una exigencia explícita de este reglamento.
Medidas técnicas requeridas
El RGPD exige medidas técnicas y organizativas «apropiadas» en relación con el riesgo:
- Cifrado de los datos en reposo y en tránsito.
- Control de acceso por rol, con principio de mínimo privilegio.
- Registro de los accesos a los datos personales.
- Seudonimización de los datos cuando sea posible.
- Respaldos cifrados y almacenados de manera segura.
- Pruebas regulares de eficacia de las medidas de seguridad.
Derechos de las personas
Dolibarr dispone de funciones nativas para responder a los derechos del RGPD de las personas afectadas:
- Derecho de acceso: exportación de todos los datos de un contacto en un formato legible.
- Derecho a la portabilidad: exportación estructurada (CSV, JSON) transmisible a otro responsable de tratamiento.
- Derecho al olvido: anonimización o supresión de un tercero, con trazabilidad de la operación.
- Derecho de rectificación: modificación simple de los datos erróneos.
- Derecho a la limitación: desactivación de fichas conservando el histórico por razones legales.
Registro de tratamientos y evaluación de impacto
Lleva un registro de tratamientos que documente el uso de Dolibarr: finalidades (gestión comercial, contabilidad, RR. HH.), categorías de datos recogidos, plazos de conservación, destinatarios, medidas de seguridad. Para los tratamientos de alto riesgo (volúmenes importantes, datos sensibles), realiza una evaluación de impacto (EIPD) antes de la puesta en producción.
Hosting soberano
Para los datos sensibles, prioriza un hosting europeo (OVHcloud, Scaleway, Outscale, Infomaniak) para evitar los conflictos con el Cloud Act estadounidense y garantizar la soberanía de los datos. Un anfitrión certificado HDS (Hospedaje de Datos de Salud) o SecNumCloud ofrece garantías suplementarias para los sectores regulados.
Notificación en caso de violación
En caso de violación de datos personales, dispones de 72 horas para notificar a la autoridad de control (AEPD en España) y, si el riesgo es elevado, informar a las personas afectadas. Prepara con antelación los modelos de comunicación y el procedimiento interno para respetar este plazo.
16. Errores críticos a evitar
Nuestra experiencia como integrador Dolibarr nos ha permitido identificar los escollos recurrentes:
- No probar nunca las restauraciones. El día D, descubres que los respaldos estaban corruptos o incompletos.
- Almacenar los respaldos en el mismo servidor que la producción. Un ransomware o un siniestro físico cifrará y destruirá todo de una vez.
- Dejar el directorio de instalación accesible. Un atacante puede entonces reinstalar Dolibarr y sobrescribir tu base.
- Usar la cuenta admin para el día a día. En caso de compromiso, el atacante tiene todos los poderes. Reserva esta cuenta para las operaciones de administración explícitas.
- Descuidar las actualizaciones. Las versiones de Dolibarr corrigen regularmente vulnerabilidades críticas. Probar en preproducción y luego aplicar rápidamente.
- Contraseñas débiles o compartidas. Impón un gestor de contraseñas tipo Bitwarden, KeePass o 1Password a todo el equipo.
- Ignorar los registros. A menudo contienen los primeros indicios de una intrusión. Sin monitorización activa, la alerta llega demasiado tarde.
- Exponer la base de datos en Internet. Restringe sistemáticamente el acceso a las IP autorizadas y pasa por una VPN.
- Confundir redundancia y respaldo. Un clúster de alta disponibilidad no protege contra una eliminación accidental o un ransomware.
- No formar a los usuarios. La mayoría de los compromisos comienzan con un phishing exitoso. La sensibilización es tan importante como la técnica.
17. Conclusión: adoptar una postura proactiva
La seguridad y el respaldo de tu CRM Dolibarr no son proyectos puntuales sino un proceso continuo. Se basan en tres pilares indisociables: la prevención (endurecimiento, actualizaciones, formación), la detección (monitorización, registro, auditorías) y la reacción (respaldos, DRP, plan de incidentes).
En NEXT GESTION, acompañamos a las empresas en la seguridad completa de su instancia Dolibarr: auditoría técnica y organizativa, endurecimiento del servidor, implementación de respaldos automatizados cifrados, plan de recuperación ante desastres, conformidad con el RGPD y gestión proactiva de la infraestructura. Nuestra oferta de hosting gestionado Dolibarr integra de forma nativa todas las buenas prácticas descritas en esta guía, lo que te permite concentrarte en tu actividad principal con total tranquilidad.
¿Quieres auditar la seguridad de tu Dolibarr? Contacta con NEXT GESTION para un diagnóstico gratuito y personalizado. Más vale prevenir hoy que lamentar mañana.
FAQ: Seguridad y respaldo de Dolibarr
¿Con qué frecuencia hay que respaldar Dolibarr? Como mínimo una copia de seguridad completa diaria de la base de datos y de los documentos, completada con copias incrementales cada hora para los entornos críticos.
¿Cuánto tiempo conservar los respaldos? Al menos 30 días para los respaldos operativos, y de 1 a 10 años para los archivados (según tus obligaciones contables y legales).
¿Es suficiente el módulo de respaldo nativo de Dolibarr? Sirve para pequeñas instancias, pero es limitado. Para producción, prioriza una estrategia profesional con cifrado y deportación fuera del sitio.
¿Cómo protegerse frente a los ransomware? Respaldos cifrados inmutables (Object Lock), copia desconectada (air gap), MFA generalizado, segmentación de red, EDR en los puestos de administración y formación de los equipos.
¿Es Dolibarr conforme con el RGPD? Dolibarr proporciona las herramientas técnicas (cifrado, derechos de acceso, exportación, anonimización), pero la conformidad depende de tu configuración, de tus procesos y de tu hosting.
¿Es mejor un hosting gestionado o se puede auto-alojar? El auto-alojamiento sigue siendo posible si dispones de las competencias internas. De lo contrario, el hosting gestionado profesional ofrece una mejor relación seguridad/coste y libera a tus equipos.
Artículo redactado por NEXT GESTION, experto en integración, securización y gestión proactiva de Dolibarr ERP/CRM. Para una auditoría o un acompañamiento, contáctanos en contact@nextgestion.com.