Il tuo CRM Dolibarr contiene senza dubbio il capitale informativo più prezioso della tua azienda: schede clienti, storici degli ordini, contratti con i fornitori, fatture, dati contabili e persino informazioni bancarie. Una falla di sicurezza, una corruzione del database o una semplice dimenticanza di backup può portare a un disastro: perdite finanziarie, danni reputazionali, sanzioni GDPR, o persino la cessazione dell'attività.
Eppure, molte aziende sottovalutano ancora questa dimensione critica. In questa guida funzionale completa, NEXT GESTION ti fornisce tutte le best practice per mettere in sicurezza in modo duraturo la tua istanza Dolibarr e garantire la continuità dei tuoi dati. Affronteremo sia la sicurezza perimetrale (server, rete) che la sicurezza applicativa (Dolibarr, database) e le strategie di backup e disaster recovery conformi allo stato dell'arte, mantenendo un approccio orientato al business e alle decisioni.
Sommario
- Perché la sicurezza di Dolibarr è strategica?
- Comprendere l'architettura di Dolibarr
- Hardening del sistema operativo
- Hardening del server web
- Implementazione di HTTPS e certificati SSL/TLS
- Mettere in sicurezza il database
- Configurazione sicura dell'ambiente applicativo
- Sicurezza applicativa in Dolibarr
- Autenticazione forte: 2FA, LDAP, SSO
- Backup del database
- Backup di file e documenti
- La regola d'oro 3-2-1 e lo storage off-site
- Test di ripristino e piano di disaster recovery
- Logging, monitoraggio e rilevamento di incidenti
- Conformità GDPR e obblighi legali
- Errori critici da evitare
- Conclusione: adottare un atteggiamento proattivo
1. Perché la sicurezza di Dolibarr è strategica?
Essendo Dolibarr un ERP/CRM web accessibile tramite un browser, è per natura esposto a tutte le minacce del web: attacchi brute-force, SQL injection, cross-site scripting (XSS), esfiltrazione di dati, ransomware, ecc. A questo si aggiungono i rischi interni: errori umani, cancellazioni accidentali, guasti hardware o software, sinistri fisici (incendio, allagamento, furto).
Le conseguenze di una compromissione o di una perdita di dati possono essere drammatiche:
- Perdite finanziarie dirette: impossibilità di fatturare, ritardi nei pagamenti, sanzioni contrattuali.
- Danno reputazionale: perdita di fiducia di clienti e fornitori.
- Sanzioni GDPR: fino al 4% del fatturato mondiale o 20 milioni di euro.
- Cessazione dell'attività: secondo diversi studi, il 60% delle PMI vittime di un grave attacco informatico fallisce entro 6 mesi.
Mettere in sicurezza Dolibarr non è quindi un'opzione, è un obbligo strategico e legale.
2. Comprendere l'architettura di Dolibarr
Prima di mettere in sicurezza, bisogna capire. Dolibarr si basa su uno stack software classico composto da quattro livelli: un sistema operativo Linux (Debian, Ubuntu, RHEL, AlmaLinux), un server web (Apache o Nginx), un database relazionale (MySQL, MariaDB o PostgreSQL) e un ambiente di esecuzione PHP. Ognuno di questi livelli deve essere messo in sicurezza individualmente perché la compromissione di uno solo può bastare a mettere a rischio l'insieme.
Tre zone di archiviazione devono essere protette in via prioritaria:
- Il database: contiene tutti i tuoi dati aziendali (clienti, prodotti, ordini, fatture, contabilità).
- La directory dei documenti: contiene i file generati da Dolibarr (fatture PDF, giustificativi, gestione documentale, foto prodotti) nonché i file temporanei.
- Il codice sorgente e la configurazione: contiene il codice di Dolibarr, i moduli personalizzati e soprattutto il file di configurazione che detiene le credenziali di connessione al database.
Il file di configurazione merita un'attenzione particolare: la sua fuga equivale a compromettere l'intero sistema. Deve quindi essere protetto da permessi rigorosi e posto in una directory non accessibile dal web.
3. Hardening del sistema operativo
La sicurezza inizia a livello del sistema operativo. Ecco le azioni di hardening imprescindibili su un server Linux che ospita Dolibarr.
Aggiornamenti sistematici
Le patch di sicurezza devono essere applicate senza indugio. Configura un meccanismo di aggiornamenti automatici dei pacchetti critici (Ubuntu e Debian dispongono di un servizio dedicato, RHEL e AlmaLinux anche). Almeno una volta a settimana, valida manualmente che gli aggiornamenti siano stati ben applicati.
Firewall e porte aperte
Il server deve esporre solo le porte strettamente necessarie: HTTPS (443), eventualmente HTTP (80) per la redirezione verso HTTPS, e SSH (22) ristretto solo agli indirizzi IP degli amministratori. Tutte le altre porte sono chiuse. Un firewall software come UFW o firewalld permette di applicare questa regola facilmente.
L'accesso SSH stesso deve essere rafforzato: connessione solo tramite chiave crittografica (niente password), disattivazione della connessione diretta in root, eventuale cambio della porta predefinita e restrizione agli indirizzi IP di fiducia.
Protezione contro gli attacchi brute-force
Uno strumento di rilevamento intrusioni come Fail2ban analizza in continuo i log di connessione e banna automaticamente gli indirizzi IP che moltiplicano i tentativi falliti (su SSH, sul form di login Dolibarr, sulle API). Configura più «jail» dedicate per coprire l'insieme dei punti d'ingresso.
Gestione di account e privilegi
Applica il principio del minimo privilegio: niente connessione diretta in root, account utente nominativi con sudo per le operazioni di amministrazione, disattivazione degli account di sistema non necessari. Ogni azione sensibile deve poter essere tracciata a un utente identificato.
Compartimentazione dei processi
Attiva SELinux (su RHEL/AlmaLinux) o AppArmor (su Debian/Ubuntu) in modalità rigorosa («enforcing»). Questi meccanismi compartimentano i processi e limitano considerevolmente l'impatto di una compromissione: anche se un attaccante prende il controllo di un processo web, non potrà accedere a risorse di sistema che non gli sono esplicitamente autorizzate.
4. Hardening del server web
Il server web è la porta d'ingresso di Dolibarr. La sua configurazione deve essere rigorosa.
Nascondere le informazioni sensibili
Per impostazione predefinita, Apache e Nginx espongono la loro versione negli header HTTP e nelle pagine di errore. Questa informazione facilita il lavoro degli attaccanti permettendo loro di mirare a vulnerabilità note. Disattiva sistematicamente la visualizzazione della versione del server e dei moduli installati.
Attivare gli header di sicurezza HTTP
Diversi header HTTP moderni migliorano significativamente la sicurezza applicativa:
- HSTS obbliga il browser a usare esclusivamente HTTPS.
- X-Content-Type-Options impedisce l'interpretazione errata dei tipi di file.
- X-Frame-Options protegge contro gli attacchi di clickjacking.
- Content-Security-Policy limita le sorgenti di script, stili e immagini, prevenendo così molti attacchi XSS.
- Referrer-Policy controlla le informazioni trasmesse durante la navigazione.
- Permissions-Policy disattiva le funzionalità sensibili non utilizzate (camera, microfono, geolocalizzazione).
L'attivazione di questi header è una vittoria rapida essenziale.
Protezione delle directory sensibili
La directory dei documenti e quella di configurazione non devono mai essere direttamente accessibili dal web. La best practice consiste nel posizionarle al di fuori della radice web: così, anche in caso di errata configurazione, restano invisibili dall'esterno. Se questo non è possibile, configura il server web per bloccare esplicitamente il loro accesso.
Rimozione dell'installer
Una volta installato Dolibarr, la directory di installazione deve essere rimossa o bloccata. Senza questa precauzione, un attaccante potrebbe rilanciare l'installazione e sovrascrivere il tuo database. Crea anche un file di blocco che impedisca qualsiasi reinstallazione involontaria.
Firewall applicativo (WAF)
Per andare oltre, distribuisci un firewall applicativo come ModSecurity abbinato all'OWASP Core Rule Set. Questo dispositivo ispeziona ogni richiesta HTTP e blocca i comportamenti sospetti (SQL injection, XSS, scansioni di vulnerabilità). Per i siti più esposti, un servizio WAF cloud come Cloudflare offre una protezione complementare contro gli attacchi DDoS.
5. Implementazione di HTTPS e certificati SSL/TLS
Nessuna installazione di Dolibarr in produzione dovrebbe funzionare in HTTP. HTTPS è obbligatorio per cifrare i flussi e proteggere le sessioni, le password, i dati dei clienti e i documenti scambiati.
Ottenere un certificato
L'ottenimento di un certificato SSL/TLS è oggi semplice e gratuito grazie a Let's Encrypt, autorità di certificazione riconosciuta da tutti i browser. Uno strumento come Certbot automatizza l'emissione, l'installazione e il rinnovo del certificato ogni 90 giorni. Verifica regolarmente che il rinnovo automatico funzioni per evitare una scadenza imprevista.
Per le organizzazioni che lo desiderano, certificati a pagamento (DV, OV o EV) restano disponibili presso autorità commerciali e possono essere pertinenti in determinati contesti (validazione estesa visualizzata nel browser).
Configurazione TLS moderna
Disattiva i protocolli obsoleti (SSL, TLS 1.0, TLS 1.1) che presentano vulnerabilità note. Autorizza solo TLS 1.2 e TLS 1.3. Seleziona suite crittografiche moderne (ECDHE con AES-GCM o ChaCha20) e disattiva gli algoritmi deboli. Testa la tua configurazione su SSL Labs (ssllabs.com/ssltest) puntando al voto A+.
Forzare la redirezione HTTP verso HTTPS
Qualsiasi richiesta HTTP deve essere automaticamente reindirizzata a HTTPS. Questa regola è la prima linea di difesa: garantisce che nessun traffico transiti in chiaro.
HSTS e HSTS preload
L'HSTS (HTTP Strict Transport Security) impone al browser l'uso esclusivo di HTTPS per il tuo dominio, anche se l'utente digita l'URL senza precisare il protocollo. Una volta che il valore è stabile, puoi inviare il tuo dominio alla HSTS Preload List, che inserisce la regola direttamente nei browser e blocca qualsiasi connessione HTTP, compresa la prima.
6. Mettere in sicurezza il database
Il database è il tesoro di Dolibarr. La sua protezione è critica.
Inizializzazione sicura
All'installazione, lancia lo script di inizializzazione sicura fornito da MySQL o MariaDB. Ti permette di definire una password robusta per l'account di amministrazione, di rimuovere gli utenti anonimi, di vietare la connessione remota per gli account privilegiati e di rimuovere i database di test.
Account dedicato a Dolibarr
Non usare mai l'account di amministrazione del database per Dolibarr. Crea un account dedicato con i privilegi strettamente necessari: lettura, scrittura, modifica delle strutture delle tabelle solo sul database Dolibarr, niente accesso ad altri database né ai diritti di amministrazione globale. Questa compartimentazione limita considerevolmente l'impatto di un'eventuale compromissione dell'applicazione.
Restrizione dell'ascolto di rete
Se il database è sullo stesso server di Dolibarr, configuralo per ascoltare solo sull'interfaccia locale (loopback). Nessuna connessione remota è quindi possibile. Se il database è esterno su un altro server, usa imperativamente un canale cifrato: VPN, tunnel SSH o TLS nativo sul database.
Cifratura at rest
Per i dati più sensibili, attiva la cifratura trasparente at rest (TDE) a livello del motore del database. Questa protegge i tuoi file di dati in caso di furto fisico del disco o di compromissione del backup grezzo. Le chiavi di cifratura devono essere conservate su un supporto separato, idealmente in una cassaforte digitale.
Logging degli accessi
Attiva il log di audit del database. Registra tutte le connessioni e le query sensibili, permettendo di rilevare a posteriori un'intrusione o un uso anormale. Questi log devono essere essi stessi protetti e conservati in modo sicuro.
7. Configurazione sicura dell'ambiente applicativo
L'ambiente PHP che esegue Dolibarr deve essere oggetto di un hardening specifico.
Disattivazione delle funzioni pericolose
PHP propone numerose funzioni suscettibili di essere usate impropriamente da un attaccante (esecuzione di comandi di sistema, lettura di file arbitrari, ecc.). Disattiva esplicitamente quelle non necessarie a Dolibarr. Attenzione tuttavia: alcuni moduli Dolibarr (export, mailing, OCR) potrebbero averne bisogno. Testa sempre in pre-produzione prima della messa in produzione.
Mascherare gli errori
In produzione, non visualizzare mai gli errori PHP al visitatore. Potrebbero rivelare informazioni sensibili (percorsi, credenziali, query SQL). Gli errori devono essere consegnati in un log accessibile solo agli amministratori.
Sessioni sicure
I cookie di sessione devono essere marcati come HttpOnly (inaccessibili in JavaScript), Secure (trasmessi solo in HTTPS) e SameSite Strict (non inviati dai siti terzi). Queste flag prevengono numerosi attacchi di furto di sessione. La durata di vita delle sessioni deve anche essere limitata (30 minuti di inattività al massimo).
Limiti ragionevoli
Configura limiti di risorse adatti: dimensione massima di upload, durata massima di esecuzione, memoria allocata. Questi parametri proteggono sia contro gli abusi volontari (denial of service) sia contro i bug accidentali.
Cache e performance
Attiva OPcache per mettere in cache il codice PHP compilato. Questo migliora le prestazioni, riduce il carico del server e limita la finestra sfruttabile durante un attacco di esaurimento delle risorse.
8. Sicurezza applicativa in Dolibarr
Dolibarr offre nativamente diversi meccanismi di hardening da attivare.
Parametri di sicurezza globali
Nel menu di configurazione della sicurezza, diverse leve sono da attivare:
- Timeout di sessione: 30 minuti massimo, idealmente 15 per gli account amministratori.
- Politica di password: lunghezza minima di 12 caratteri, requisiti di complessità (maiuscole, minuscole, cifre, caratteri speciali), scadenza ogni 90 giorni, divieto di riutilizzare le vecchie password.
- Protezione anti-CSRF: attiva di default, da conservare imperativamente e da estendere al livello più alto per richiedere un token su tutti i form sensibili.
- Blocco automatico degli account dopo diversi tentativi falliti (5 di default), con sblocco manuale o temporizzato.
Permessi granulari
Dolibarr offre un sistema di permessi per modulo e per azione molto fine. Applica il principio del minimo privilegio: ogni utente ha solo i diritti strettamente necessari alla sua funzione. Un commerciale non ha accesso alla contabilità, un contabile non ha accesso ai dati HR, ecc. Questa disciplina limita le fughe di dati interne e l'impatto di una compromissione di account.
Multi-società e compartimentazione
Se gestisci più entità giuridiche con il modulo multi-società, assicurati dell'isolamento rigoroso dei dati tra società. Configura i gruppi utenti per evitare qualsiasi fuga laterale, e audita regolarmente gli accessi incrociati.
Disattivazione dei moduli inutilizzati
Ogni modulo attivato aumenta la superficie di attacco. Fai un audit regolare e disattiva tutto ciò che non è più utilizzato. Meno codice attivo c'è, meno vulnerabilità potenziali ci sono.
Forzare HTTPS a livello applicativo
Oltre alla redirezione del server, Dolibarr può essere configurato per rifiutare le connessioni non sicure a livello applicativo. Questa doppia protezione garantisce che nessun accesso diretto in HTTP possa compromettere le sessioni.
9. Autenticazione forte: 2FA, LDAP, SSO
La sola password non è più sufficiente. Diverse opzioni di rafforzamento dell'autenticazione sono disponibili.
Doppia autenticazione (2FA / MFA)
L'attivazione della doppia autenticazione è oggi il minimo per gli account sensibili (amministratori, contabili, dirigenti). Aggiunge un secondo fattore di verifica, generalmente un codice temporaneo generato da un'app mobile (Google Authenticator, Authy, Microsoft Authenticator, FreeOTP). Anche se una password è compromessa, l'attaccante non può connettersi senza accesso fisico al telefono dell'utente. Un modulo dedicato, disponibile sul Dolistore, permette di attivarla semplicemente.
Autenticazione LDAP / Active Directory
Per le aziende dotate di una directory centralizzata, Dolibarr offre un connettore nativo verso LDAP/Active Directory. Gli utenti si connettono a Dolibarr con le loro credenziali aziendali, gestite centralmente dall'IT. Vantaggi: applicazione automatica delle politiche password aziendali, disattivazione immediata dell'account Dolibarr in caso di partenza di un collaboratore, tracciabilità unificata.
Single Sign-On (SSO) tramite SAML o OpenID Connect
Per andare oltre, alcuni moduli permettono di collegare Dolibarr a un identity provider (Keycloak, Azure AD, Okta, Google Workspace) tramite gli standard SAML 2.0 o OpenID Connect. I tuoi utenti si connettono una volta per accedere a tutti i loro strumenti, l'MFA è centralizzato e applicato uniformemente, la conformità è semplificata. È la best practice per le organizzazioni con più applicazioni di business.
10. Backup del database
Il backup regolare del database è l'operazione più critica.
Frequenza e retention
Almeno, pianifica un backup completo quotidiano, eseguito durante un periodo di scarsa attività (in generale di notte). Per gli ambienti critici, completa con backup incrementali più frequenti (ogni ora, o anche in continuo). La retention raccomandata: 30 giorni per i backup operativi, da 1 a 10 anni per i backup archiviati a seconda dei tuoi obblighi legali.
Metodi di backup
Coesistono diversi approcci:
- Backup logico (export SQL): produce un file testuale leggibile, ideale per piccoli e medi database. Vantaggi: portabilità, possibilità di ripristino parziale. Limiti: lento oltre qualche gigabyte.
- Backup fisico a caldo: copia i file binari del database senza interruzione di servizio. Strumenti raccomandati: Mariabackup (MariaDB) o Percona XtraBackup (MySQL). Indispensabile per i grandi database.
- Replicazione verso un server secondario in tempo reale, che può servire sia da ridondanza sia da target per i backup (senza impatto sulla produzione).
- Snapshot a livello del sistema di storage o della macchina virtuale.
Compressione e cifratura
Tutti i backup devono essere compressi (riduzione delle dimensioni) e poi cifrati (protezione contro la fuga). La cifratura usa idealmente una chiave asimmetrica (GPG per esempio) la cui chiave privata è conservata separatamente, in una cassaforte digitale. Verifica sistematicamente l'integrità dei backup con un'impronta crittografica (checksum).
Ripristino a un punto nel tempo
Attiva i binary log sul motore del database. Permettono il ripristino a un punto preciso nel tempo (Point-In-Time Recovery, PITR), per esempio «riportare il database allo stato delle 14:32 di ieri, appena prima dell'errore». Questa capacità è preziosa per recuperare una cancellazione accidentale senza perdere tutti i dati successivi.
11. Backup di file e documenti
Il database non basta: la directory dei documenti contiene i PDF delle fatture, i giustificativi contabili, i file di gestione documentale e le foto prodotti. La sua perdita sarebbe altrettanto grave di una perdita di database.
Backup incrementali
Per i file, prediligi i backup incrementali con versioning: solo i file modificati vengono salvati a ogni ciclo, e ogni versione resta accessibile. Questo approccio permette di conservare numerose versioni senza far esplodere lo spazio disco, grazie a meccanismi di hardlink o di deduplicazione.
Codice sorgente e configurazione
Non dimenticare di salvare anche il codice sorgente (moduli personalizzati, sovrascritture) e il file di configurazione. Senza di essi, un ripristino del database non basta a rimettere in funzione il sistema.
Automazione e pianificazione
Tutti i backup devono essere automatizzati e pianificati tramite uno scheduler (cron, timer systemd, scheduler Windows…). L'esecuzione manuale è da evitare: finisce sempre per essere dimenticata. Imposta un account tecnico dedicato a queste operazioni, con i permessi strettamente necessari.
Sorveglianza dei backup
Ogni esecuzione deve produrre un rapporto che indichi il suo stato (successo, fallimento, durata, dimensione). In caso di fallimento, un avviso deve essere inviato all'amministratore. Un backup di cui non si sa se si è svolto correttamente non è un backup affidabile.
12. La regola d'oro 3-2-1 e lo storage off-site
La regola 3-2-1 del backup è universalmente riconosciuta:
- 3 copie dei dati (l'originale + due backup).
- su 2 supporti diversi (disco locale + NAS, ad esempio).
- di cui 1 copia off-site (cloud, datacenter remoto, cassaforte digitale).
Perché questa regola?
Questa regola protegge contro i principali scenari di sinistro. Una sola copia può essere persa in un crash disco. Due copie sullo stesso server sono perse in caso di incendio o ransomware. Una copia off-site garantisce la continuità anche in caso di distruzione fisica del sito principale.
Sincronizzazione cloud cifrata
Usa un fornitore cloud sovrano (OVHcloud, Scaleway, Outscale, Infomaniak) o un servizio di storage a oggetti (S3, Backblaze B2, Wasabi) per ospitare la copia off-site. I dati devono essere cifrati lato client prima dell'invio: così, anche il fornitore cloud non può leggerli. Strumenti come rclone o restic automatizzano questa sincronizzazione cifrata.
Storage immutabile (Object Lock / WORM)
Attiva la modalità immutabile (WORM, Write Once Read Many) sul tuo storage cloud: i backup non potranno essere né modificati né eliminati durante il periodo di retention definito, nemmeno da un amministratore. È la tua ultima linea di difesa contro i ransomware moderni che ora cercano di distruggere i backup prima di cifrare la produzione.
Air gap per i dati critici
Per i dati più sensibili, conserva una copia su un supporto fisicamente disconnesso (disco esterno o nastro LTO conservato in cassaforte). Questa copia «offline» non può essere raggiunta da alcun attacco informatico. La sua rotazione manuale (settimanale o mensile) aggiunge un livello di sicurezza definitivo.
13. Test di ripristino e piano di disaster recovery
Testare i propri backup
Un backup non testato non è un backup.
È una delle regole più violate nella pratica. Molte aziende scoprono che i loro backup erano corrotti o incompleti il giorno in cui ne hanno bisogno. Pianifica test di ripristino trimestrali su un server di pre-produzione: ripristino completo del database, ripristino dei documenti, verifica dell'integrità dei dati e della coerenza applicativa. Documenta i risultati ed eventuali problemi riscontrati.
Piano di disaster recovery (DRP)
Documenta un piano di disaster recovery che precisi:
- Il RPO (Recovery Point Objective): la perdita massima di dati tollerabile. Per esempio, «accettiamo di perdere al massimo 4 ore di dati».
- Il RTO (Recovery Time Objective): la durata massima di interruzione del servizio. Per esempio, «dobbiamo essere di nuovo operativi in 2 ore».
- I ruoli e responsabilità in caso di sinistro: chi decide, chi esegue, chi comunica ai clienti.
- Le procedure passo-passo di ripristino, sufficientemente dettagliate perché un amministratore di sostituzione possa eseguirle.
- I contatti dei fornitori (hosting provider, integratore Dolibarr, commercialista) accessibili anche offline.
Failover su server di backup
Per gli ambienti critici, predisponi un server di backup sincronizzato in tempo quasi reale tramite la replicazione del database e la sincronizzazione continua dei file. In caso di sinistro, il failover può avvenire in pochi minuti tramite redirezione DNS o failover automatico di un load balancer. Questa architettura ad alta disponibilità è ormai accessibile a budget PMI.
Esercizi di crisi
Una volta all'anno, organizza un esercizio di crisi che simuli un sinistro maggiore. Tutti i team coinvolti (tecnico, business, direzione) partecipano e applicano il piano. Questi esercizi rivelano le carenze, le ipotesi false e le opportunità di miglioramento. Meglio scoprire un problema durante un esercizio che in situazione reale.
14. Logging, monitoraggio e rilevamento di incidenti
Centralizzazione dei log
Centralizza tutti i log (server web, database, ambiente PHP, Dolibarr, fail2ban) in uno strumento dedicato: Graylog, ELK (Elasticsearch + Logstash + Kibana) o Loki + Grafana. Questa centralizzazione permette di correlare gli eventi e rilevare anomalie invisibili a occhio nudo (multiple connessioni fallite seguite da una connessione riuscita, query insolite, picchi di traffico).
Monitoraggio dei servizi
Monitora in continuo la disponibilità e le prestazioni con Zabbix, Prometheus + Grafana o Netdata. Gli indicatori chiave da monitorare:
- Carico CPU, memoria, I/O disco.
- Tempo di risposta delle pagine Dolibarr.
- Volume dei backup e successo/fallimento dei task pianificati.
- Spazio disco rimanente (allerta all'80% di occupazione).
- Validità dei certificati SSL (allerta 30 giorni prima della scadenza).
Rilevamento intrusioni file (HIDS)
Distribuisci uno strumento di rilevamento intrusioni file come AIDE, Tripwire o Wazuh. Calcola regolarmente l'impronta di tutti i file di sistema e applicativi, e avvisa in caso di modifica non prevista. È il modo più efficace per rilevare l'installazione di una backdoor («webshell») da parte di un attaccante.
Alerting e reperibilità
Configura avvisi via email, Slack, Microsoft Teams o soluzione di reperibilità (PagerDuty, Opsgenie). Definisci soglie di criticità: informazione, avvertimento, critico. Un'intrusione rilevata presto è un'intrusione contenuta; un'intrusione rilevata tardi può costare molto.
15. Conformità GDPR e obblighi legali
Se tratti dati personali in Dolibarr (clienti, prospect, dipendenti), sei soggetto al GDPR. E la sicurezza tecnica è un'esigenza esplicita di questo regolamento.
Misure tecniche richieste
Il GDPR esige misure tecniche e organizzative «appropriate» rispetto al rischio:
- Cifratura dei dati at rest e in transito.
- Controllo degli accessi per ruolo, con principio del minimo privilegio.
- Logging degli accessi ai dati personali.
- Pseudonimizzazione dei dati quando possibile.
- Backup cifrati e conservati in modo sicuro.
- Test regolari di efficacia delle misure di sicurezza.
Diritti delle persone
Dolibarr dispone di funzioni native per rispondere ai diritti GDPR degli interessati:
- Diritto di accesso: export di tutti i dati di un contatto in un formato leggibile.
- Diritto alla portabilità: export strutturato (CSV, JSON) trasmissibile a un altro titolare del trattamento.
- Diritto all'oblio: anonimizzazione o cancellazione di un terzo, con tracciabilità dell'operazione.
- Diritto di rettifica: modifica semplice dei dati erronei.
- Diritto alla limitazione: disattivazione di schede pur conservando lo storico per ragioni legali.
Registro dei trattamenti e valutazione d'impatto
Tieni un registro dei trattamenti che documenti l'uso di Dolibarr: finalità (gestione commerciale, contabilità, HR), categorie di dati raccolti, durate di conservazione, destinatari, misure di sicurezza. Per i trattamenti ad alto rischio (volumi importanti, dati sensibili), realizza una valutazione d'impatto (DPIA) prima della messa in produzione.
Hosting sovrano
Per i dati sensibili, prediligi un hosting europeo (OVHcloud, Scaleway, Outscale, Infomaniak) per evitare i conflitti con il Cloud Act statunitense e garantire la sovranità dei dati. Un host certificato HDS (Host di Dati Sanitari) o SecNumCloud offre garanzie supplementari per i settori regolamentati.
Notifica in caso di violazione
In caso di violazione di dati personali, hai 72 ore per notificare l'autorità di controllo (Garante Privacy in Italia) e, se il rischio è elevato, informare gli interessati. Prepara in anticipo i modelli di comunicazione e la procedura interna per rispettare questo termine.
16. Errori critici da evitare
La nostra esperienza di integratore Dolibarr ci ha permesso di identificare le insidie ricorrenti:
- Non testare mai i ripristini. Il giorno X, scopri che i backup erano corrotti o incompleti.
- Conservare i backup sullo stesso server della produzione. Un ransomware o un sinistro fisico cifrerà e distruggerà tutto in una volta.
- Lasciare la directory di installazione accessibile. Un attaccante può allora reinstallare Dolibarr e sovrascrivere il tuo database.
- Usare l'account amministratore per il quotidiano. In caso di compromissione, l'attaccante ha tutti i poteri. Riserva questo account alle operazioni di amministrazione esplicite.
- Trascurare gli aggiornamenti. Le versioni Dolibarr correggono regolarmente vulnerabilità critiche. Testare in pre-produzione e applicare rapidamente.
- Password deboli o condivise. Imponi un password manager tipo Bitwarden, KeePass o 1Password a tutto il team.
- Ignorare i log. Spesso contengono i primi segnali di un'intrusione. Senza monitoraggio attivo, l'avviso arriva troppo tardi.
- Esporre il database su Internet. Restringi sistematicamente l'accesso agli IP autorizzati e passa attraverso una VPN.
- Confondere ridondanza e backup. Un cluster ad alta disponibilità non protegge contro una cancellazione accidentale o un ransomware.
- Non formare gli utenti. La maggior parte delle compromissioni inizia con un phishing riuscito. La sensibilizzazione è importante quanto la tecnica.
17. Conclusione: adottare un atteggiamento proattivo
La sicurezza e il backup del tuo CRM Dolibarr non sono progetti puntuali ma un processo continuo. Si basano su tre pilastri inseparabili: la prevenzione (hardening, aggiornamenti, formazione), il rilevamento (monitoraggio, logging, audit) e la reazione (backup, DRP, piano di incidente).
Da NEXT GESTION, accompagniamo le aziende nella messa in sicurezza completa della loro istanza Dolibarr: audit tecnico e organizzativo, hardening del server, implementazione di backup automatizzati cifrati, piano di disaster recovery, conformità GDPR e gestione proattiva. La nostra offerta di hosting gestito Dolibarr integra nativamente tutte le best practice descritte in questa guida, permettendoti di concentrarti sul tuo core business in tutta serenità.
Vuoi fare un audit della sicurezza del tuo Dolibarr? Contatta NEXT GESTION per una diagnosi gratuita e personalizzata. Meglio prevenire oggi che rimpiangere domani.
FAQ: Sicurezza e backup di Dolibarr
Con quale frequenza fare il backup di Dolibarr? Almeno un backup completo quotidiano del database e dei documenti, integrato da backup incrementali ogni ora per gli ambienti critici.
Quanto tempo conservare i backup? Almeno 30 giorni per i backup operativi e da 1 a 10 anni per quelli archiviati (a seconda dei tuoi obblighi contabili e legali).
Il modulo di backup nativo di Dolibarr è sufficiente? È utile per piccole istanze, ma resta limitato. Per la produzione, prediligi una strategia professionale con cifratura e replica off-site.
Come proteggersi dai ransomware? Backup cifrati immutabili (Object Lock), copia disconnessa (air gap), MFA generalizzata, segmentazione di rete, EDR sulle postazioni amministratori e formazione dei team.
Dolibarr è conforme al GDPR? Dolibarr fornisce gli strumenti tecnici (cifratura, diritti d'accesso, esportazione, anonimizzazione), ma la conformità dipende dalla tua configurazione, dai tuoi processi e dal tuo hosting.
Meglio un hosting gestito o si può auto-ospitare? L'auto-hosting resta possibile se disponi delle competenze interne. Altrimenti, l'hosting gestito professionale offre un miglior rapporto sicurezza/costo e libera i tuoi team.
Articolo redatto da NEXT GESTION, esperto in integrazione, messa in sicurezza e gestione proattiva di Dolibarr ERP/CRM. Per un audit o un accompagnamento, contattaci a contact@nextgestion.com.