Ihr Dolibarr-CRM enthält zweifellos das wertvollste Informationskapital Ihres Unternehmens: Kundendatensätze, Auftragshistorien, Lieferantenverträge, Rechnungen, Buchhaltungsdaten und sogar Bankinformationen. Eine Sicherheitslücke, eine Datenbankbeschädigung oder ein einfach vergessenes Backup kann zur Katastrophe führen: finanzielle Verluste, Reputationsschäden, DSGVO-Sanktionen oder sogar Geschäftsaufgabe.
Dennoch unterschätzen viele Unternehmen diese kritische Dimension noch. In diesem umfassenden funktionalen Leitfaden liefert NEXT GESTION Ihnen alle Best Practices, um Ihre Dolibarr-Instanz dauerhaft abzusichern und die Kontinuität Ihrer Daten zu gewährleisten. Wir behandeln sowohl die Perimetersicherheit (Server, Netzwerk) als auch die Anwendungssicherheit (Dolibarr, Datenbank) sowie Backup- und Disaster-Recovery-Strategien nach dem Stand der Technik – mit einer geschäfts- und entscheidungsorientierten Ausrichtung.
Inhaltsverzeichnis
- Warum ist Dolibarr-Sicherheit strategisch?
- Die Architektur von Dolibarr verstehen
- Härtung des Betriebssystems
- Härtung des Webservers
- Einrichtung von HTTPS und SSL/TLS-Zertifikaten
- Absicherung der Datenbank
- Sichere Konfiguration der Anwendungsumgebung
- Anwendungssicherheit in Dolibarr
- Starke Authentifizierung: 2FA, LDAP, SSO
- Datenbank-Backup
- Backup von Dateien und Dokumenten
- Die goldene 3-2-1-Regel und Offsite-Speicherung
- Wiederherstellungstests und Disaster-Recovery-Plan
- Logging, Monitoring und Vorfallserkennung
- DSGVO-Konformität und gesetzliche Verpflichtungen
- Kritische Fehler, die zu vermeiden sind
- Fazit: Eine proaktive Haltung einnehmen
1. Warum ist Dolibarr-Sicherheit strategisch?
Da Dolibarr ein webbasiertes ERP/CRM ist, das über einen Browser zugänglich ist, ist es naturgemäß allen Web-Bedrohungen ausgesetzt: Brute-Force-Angriffe, SQL-Injektionen, Cross-Site Scripting (XSS), Datenexfiltration, Ransomware usw. Hinzu kommen interne Risiken: menschliche Fehler, versehentliche Löschungen, Hardware- oder Softwareausfälle, physische Schäden (Brand, Wasserschaden, Diebstahl).
Die Folgen einer Kompromittierung oder eines Datenverlusts können dramatisch sein:
- Direkte finanzielle Verluste: Unfähigkeit zur Rechnungsstellung, Zahlungsverzögerungen, vertragliche Sanktionen.
- Reputationsschäden: Vertrauensverlust bei Kunden und Lieferanten.
- DSGVO-Bußgelder: bis zu 4 % des weltweiten Umsatzes oder 20 Millionen Euro.
- Geschäftsaufgabe: Mehreren Studien zufolge gehen 60 % der KMU, die Opfer eines schweren Cyberangriffs werden, innerhalb von 6 Monaten in Insolvenz.
Die Absicherung von Dolibarr ist daher keine Option, sondern eine strategische und rechtliche Verpflichtung.
2. Die Architektur von Dolibarr verstehen
Vor der Absicherung muss man verstehen. Dolibarr basiert auf einem klassischen Software-Stack aus vier Schichten: ein Linux-Betriebssystem (Debian, Ubuntu, RHEL, AlmaLinux), ein Webserver (Apache oder Nginx), eine relationale Datenbank (MySQL, MariaDB oder PostgreSQL) und eine PHP-Laufzeitumgebung. Jede dieser Schichten muss individuell abgesichert werden, denn die Kompromittierung einer einzigen kann ausreichen, um das Gesamtsystem zu gefährden.
Drei Speicherzonen müssen vorrangig geschützt werden:
- Die Datenbank: Sie enthält alle Ihre Geschäftsdaten (Kunden, Produkte, Bestellungen, Rechnungen, Buchhaltung).
- Das Verzeichnis der Dokumente: Es enthält die von Dolibarr erzeugten Dateien (PDF-Rechnungen, Belege, elektronisches Dokumentenmanagement, Produktfotos) sowie temporäre Dateien.
- Der Quellcode und die Konfiguration: Sie enthalten den Dolibarr-Code, Ihre kundenspezifischen Module und vor allem die Konfigurationsdatei mit den Datenbank-Anmeldedaten.
Die Konfigurationsdatei verdient besondere Aufmerksamkeit: Ihr Leak entspricht der Kompromittierung des gesamten Systems. Sie muss daher durch strenge Berechtigungen geschützt und in einem aus dem Web nicht zugänglichen Verzeichnis abgelegt werden.
3. Härtung des Betriebssystems
Sicherheit beginnt auf Betriebssystemebene. Hier sind die unverzichtbaren Härtungsmaßnahmen für einen Linux-Server, der Dolibarr hostet.
Systematische Updates
Sicherheitspatches müssen unverzüglich angewendet werden. Konfigurieren Sie einen Mechanismus für automatische Updates der kritischen Pakete (Ubuntu und Debian verfügen über einen dedizierten Dienst, RHEL und AlmaLinux ebenfalls). Mindestens einmal pro Woche prüfen Sie manuell, ob die Updates korrekt angewendet wurden.
Firewall und offene Ports
Der Server sollte nur die unbedingt notwendigen Ports offen haben: HTTPS (443), eventuell HTTP (80) für die Weiterleitung zu HTTPS und SSH (22), beschränkt auf die IP-Adressen der Administratoren. Alle anderen Ports sind geschlossen. Eine Software-Firewall wie UFW oder firewalld ermöglicht eine einfache Anwendung dieser Regel.
Der SSH-Zugang selbst muss verstärkt werden: Authentifizierung ausschließlich per kryptografischem Schlüssel (keine Passwörter), Deaktivierung der direkten Root-Anmeldung, eventuell Wechsel des Standardports und Beschränkung auf vertrauenswürdige IP-Adressen.
Schutz vor Brute-Force-Angriffen
Ein Intrusion-Detection-Werkzeug wie Fail2ban analysiert kontinuierlich die Verbindungsprotokolle und sperrt automatisch IP-Adressen, die wiederholt fehlgeschlagene Versuche unternehmen (auf SSH, im Dolibarr-Anmeldeformular, auf APIs). Konfigurieren Sie mehrere dedizierte „Jails", um alle Eingangspunkte abzudecken.
Konten- und Privilegienverwaltung
Wenden Sie das Least-Privilege-Prinzip an: keine direkte Root-Anmeldung, namentliche Benutzerkonten mit sudo für Administrationsoperationen, Deaktivierung nicht erforderlicher Systemkonten. Jede sensible Aktion muss einem identifizierten Benutzer zuordenbar sein.
Prozesskompartimentierung
Aktivieren Sie SELinux (auf RHEL/AlmaLinux) oder AppArmor (auf Debian/Ubuntu) im strikten Modus („enforcing"). Diese Mechanismen kompartimentieren die Prozesse und begrenzen die Auswirkungen einer Kompromittierung erheblich: Selbst wenn ein Angreifer die Kontrolle über einen Webprozess übernimmt, kann er nicht auf Systemressourcen zugreifen, die ihm nicht ausdrücklich gewährt wurden.
4. Härtung des Webservers
Der Webserver ist der Eingangspunkt von Dolibarr. Seine Konfiguration muss rigoros sein.
Sensible Informationen verbergen
Standardmäßig zeigen Apache und Nginx ihre Version in HTTP-Headern und Fehlerseiten an. Diese Information erleichtert den Angreifern die Arbeit, da sie damit gezielt bekannte Schwachstellen ausnutzen können. Deaktivieren Sie systematisch die Anzeige der Serverversion und der installierten Module.
HTTP-Sicherheitsheader aktivieren
Mehrere moderne HTTP-Header verbessern die Anwendungssicherheit erheblich:
- HSTS zwingt den Browser zur ausschließlichen Nutzung von HTTPS.
- X-Content-Type-Options verhindert die fehlerhafte Interpretation von Dateitypen.
- X-Frame-Options schützt vor Clickjacking-Angriffen.
- Content-Security-Policy beschränkt die Quellen von Skripten, Stylesheets und Bildern und verhindert so viele XSS-Angriffe.
- Referrer-Policy kontrolliert die bei der Navigation übermittelten Informationen.
- Permissions-Policy deaktiviert nicht genutzte sensible Funktionen (Kamera, Mikrofon, Geolokalisierung).
Die Aktivierung dieser Header ist ein wesentlicher Quick Win.
Schutz sensibler Verzeichnisse
Das Verzeichnis der Dokumente und das Konfigurationsverzeichnis dürfen niemals direkt aus dem Web zugänglich sein. Die Best Practice besteht darin, sie außerhalb des Web-Roots zu platzieren: So bleiben sie selbst bei Fehlkonfiguration von außen unsichtbar. Wenn dies nicht möglich ist, konfigurieren Sie den Webserver so, dass er den Zugriff explizit blockiert.
Entfernung des Installationsprogramms
Sobald Dolibarr installiert ist, muss das Installationsverzeichnis entfernt oder gesperrt werden. Ohne diese Vorsichtsmaßnahme könnte ein Angreifer die Installation neu starten und Ihre Datenbank überschreiben. Erstellen Sie auch eine Sperrdatei, die jede unbeabsichtigte Neuinstallation verhindert.
Anwendungs-Firewall (WAF)
Um weiter zu gehen, setzen Sie eine Anwendungs-Firewall wie ModSecurity in Verbindung mit dem OWASP Core Rule Set ein. Sie inspiziert jede HTTP-Anfrage und blockiert verdächtiges Verhalten (SQL-Injektionen, XSS, Schwachstellen-Scans). Für die exponiertesten Sites bietet ein Cloud-WAF-Dienst wie Cloudflare zusätzlichen Schutz vor DDoS-Angriffen.
5. Einrichtung von HTTPS und SSL/TLS-Zertifikaten
Keine produktive Dolibarr-Installation sollte über HTTP betrieben werden. HTTPS ist obligatorisch, um Datenverkehr zu verschlüsseln und Sitzungen, Passwörter, Kundendaten und ausgetauschte Dokumente zu schützen.
Ein Zertifikat erhalten
Der Erhalt eines SSL/TLS-Zertifikats ist heute dank Let's Encrypt, einer von allen Browsern anerkannten Zertifizierungsstelle, einfach und kostenlos. Ein Tool wie Certbot automatisiert die Ausstellung, Installation und Erneuerung des Zertifikats alle 90 Tage. Prüfen Sie regelmäßig, ob die automatische Erneuerung funktioniert, um eine unerwartete Ablauf zu vermeiden.
Für Organisationen, die dies wünschen, bleiben kostenpflichtige Zertifikate (DV, OV oder EV) bei kommerziellen Stellen verfügbar und können in bestimmten Kontexten (im Browser angezeigte erweiterte Validierung) relevant sein.
Moderne TLS-Konfiguration
Deaktivieren Sie veraltete Protokolle (SSL, TLS 1.0, TLS 1.1), die bekannte Schwachstellen aufweisen. Erlauben Sie nur TLS 1.2 und TLS 1.3. Wählen Sie moderne kryptografische Suites (ECDHE mit AES-GCM oder ChaCha20) und deaktivieren Sie schwache Algorithmen. Testen Sie Ihre Konfiguration auf SSL Labs (ssllabs.com/ssltest) und streben Sie die Note A+ an.
HTTP-zu-HTTPS-Weiterleitung erzwingen
Jede HTTP-Anfrage muss automatisch zu HTTPS umgeleitet werden. Diese Regel ist die erste Verteidigungslinie: Sie stellt sicher, dass kein Datenverkehr im Klartext durchgeht.
HSTS und HSTS Preload
HSTS (HTTP Strict Transport Security) zwingt den Browser, für Ihre Domain ausschließlich HTTPS zu verwenden, selbst wenn der Benutzer die URL ohne Angabe des Protokolls eingibt. Sobald der Wert stabil ist, können Sie Ihre Domain bei der HSTS Preload List einreichen, wodurch die Regel direkt in den Browsern verankert wird und jede HTTP-Verbindung blockiert, einschließlich der ersten.
6. Absicherung der Datenbank
Die Datenbank ist der Schatz von Dolibarr. Ihr Schutz ist kritisch.
Sichere Initialisierung
Führen Sie bei der Installation das von MySQL oder MariaDB bereitgestellte Skript zur sicheren Initialisierung aus. Damit können Sie ein robustes Passwort für das Administrationskonto festlegen, anonyme Benutzer entfernen, die Remote-Anmeldung für privilegierte Konten verbieten und die Test-Datenbanken entfernen.
Dediziertes Dolibarr-Konto
Verwenden Sie niemals das Datenbank-Administrationskonto für Dolibarr. Erstellen Sie ein dediziertes Konto mit den strikt notwendigen Privilegien: Lesen, Schreiben, Änderung der Tabellenstrukturen ausschließlich auf der Dolibarr-Datenbank, kein Zugriff auf andere Datenbanken oder globale Administrationsrechte. Diese Kompartimentierung begrenzt die Auswirkungen einer eventuellen Anwendungskompromittierung erheblich.
Beschränkung des Netzwerk-Listenings
Wenn die Datenbank auf demselben Server wie Dolibarr läuft, konfigurieren Sie sie so, dass sie nur auf der lokalen Schnittstelle (Loopback) lauscht. Eine Remote-Verbindung ist dann nicht möglich. Wenn die Datenbank auf einem anderen Server ausgelagert ist, verwenden Sie unbedingt einen verschlüsselten Kanal: VPN, SSH-Tunnel oder natives TLS auf der Datenbank.
Verschlüsselung im Ruhezustand
Aktivieren Sie für die sensibelsten Daten die transparente Datenverschlüsselung im Ruhezustand (TDE) auf Ebene des Datenbankmoduls. Dies schützt Ihre Datendateien im Falle eines physischen Diebstahls der Festplatte oder einer Kompromittierung des Roh-Backups. Die Verschlüsselungsschlüssel müssen auf einem separaten Medium gespeichert werden, idealerweise in einem digitalen Tresor.
Zugriffsprotokollierung
Aktivieren Sie das Audit-Log der Datenbank. Es zeichnet alle Verbindungen und sensiblen Abfragen auf und ermöglicht so die nachträgliche Erkennung einer Eindringung oder einer ungewöhnlichen Nutzung. Diese Logs müssen selbst geschützt und sicher aufbewahrt werden.
7. Sichere Konfiguration der Anwendungsumgebung
Die PHP-Umgebung, die Dolibarr ausführt, muss einer spezifischen Härtung unterzogen werden.
Deaktivierung gefährlicher Funktionen
PHP bietet zahlreiche Funktionen, die von einem Angreifer missbraucht werden können (Ausführung von Systembefehlen, Lesen beliebiger Dateien usw.). Deaktivieren Sie explizit diejenigen, die für Dolibarr nicht erforderlich sind. Vorsicht jedoch: Einige Dolibarr-Module (Export, Mailing, OCR) können sie benötigen. Testen Sie immer in der Pre-Production, bevor Sie produktiv gehen.
Fehler verbergen
In der Produktion niemals PHP-Fehler dem Besucher anzeigen. Sie könnten sensible Informationen preisgeben (Pfade, Anmeldedaten, SQL-Abfragen). Fehler müssen in einem Protokoll erfasst werden, das nur für Administratoren zugänglich ist.
Sichere Sitzungen
Sitzungs-Cookies müssen als HttpOnly (in JavaScript nicht zugänglich), Secure (nur über HTTPS übermittelt) und SameSite Strict (von Drittanbieter-Sites nicht gesendet) markiert werden. Diese Flags verhindern viele Angriffe auf den Sitzungsdiebstahl. Auch die Lebensdauer der Sitzungen muss begrenzt sein (maximal 30 Minuten Inaktivität).
Vernünftige Limits
Konfigurieren Sie geeignete Ressourcenlimits: maximale Upload-Größe, maximale Ausführungsdauer, zugewiesener Speicher. Diese Parameter schützen sowohl vor absichtlichem Missbrauch (Denial of Service) als auch vor versehentlichen Bugs.
Cache und Performance
Aktivieren Sie OPcache, um den kompilierten PHP-Code zwischenzuspeichern. Das verbessert die Performance, reduziert die Serverlast und begrenzt das ausnutzbare Fenster bei einem Angriff durch Ressourcenerschöpfung.
8. Anwendungssicherheit in Dolibarr
Dolibarr bietet nativ mehrere Härtungsmechanismen, die zu aktivieren sind.
Globale Sicherheitsparameter
Im Sicherheits-Konfigurationsmenü sind mehrere Hebel zu aktivieren:
- Sitzungs-Timeout: maximal 30 Minuten, idealerweise 15 für Administratorkonten.
- Passwortrichtlinie: Mindestlänge von 12 Zeichen, Komplexitätsanforderung (Großbuchstaben, Kleinbuchstaben, Zahlen, Sonderzeichen), Ablauf alle 90 Tage, Verbot der Wiederverwendung alter Passwörter.
- Anti-CSRF-Schutz: standardmäßig aktiviert, unbedingt beibehalten und auf die höchste Stufe ausweiten, um einen Token in allen sensiblen Formularen zu verlangen.
- Automatische Sperrung der Konten nach mehreren fehlgeschlagenen Versuchen (5 standardmäßig), mit manueller oder zeitgesteuerter Entsperrung.
Granulare Berechtigungen
Dolibarr bietet ein sehr feines Berechtigungssystem pro Modul und pro Aktion. Wenden Sie das Least-Privilege-Prinzip an: Jeder Benutzer hat nur die für seine Funktion strikt notwendigen Rechte. Ein Vertriebsmitarbeiter hat keinen Zugriff auf die Buchhaltung, ein Buchhalter hat keinen Zugriff auf HR-Daten usw. Diese Disziplin begrenzt interne Datenlecks und die Auswirkungen einer Kontokompromittierung.
Multi-Mandanten und Trennung
Wenn Sie mehrere juristische Personen mit dem Multi-Mandanten-Modul verwalten, achten Sie auf die strikte Datenisolation zwischen den Unternehmen. Konfigurieren Sie Benutzergruppen, um lateralen Datenabfluss zu verhindern, und auditieren Sie regelmäßig die Querzugriffe.
Deaktivierung ungenutzter Module
Jedes aktivierte Modul vergrößert die Angriffsfläche. Führen Sie regelmäßig ein Audit durch und deaktivieren Sie alles, was nicht mehr verwendet wird. Je weniger aktiver Code, desto weniger potenzielle Schwachstellen.
HTTPS auf Anwendungsebene erzwingen
Über die Server-Weiterleitung hinaus kann Dolibarr so konfiguriert werden, dass es nicht-sichere Verbindungen auf Anwendungsebene ablehnt. Dieser doppelte Schutz garantiert, dass kein direkter HTTP-Zugriff die Sitzungen kompromittieren kann.
9. Starke Authentifizierung: 2FA, LDAP, SSO
Das Passwort allein reicht nicht mehr aus. Mehrere Optionen zur Authentifizierungsverstärkung stehen zur Verfügung.
Zwei-Faktor-Authentifizierung (2FA / MFA)
Die Aktivierung der Zwei-Faktor-Authentifizierung ist heute das Mindeste für sensible Konten (Administratoren, Buchhalter, Führungskräfte). Sie fügt einen zweiten Verifizierungsfaktor hinzu, in der Regel einen temporären Code, der von einer Mobile-App generiert wird (Google Authenticator, Authy, Microsoft Authenticator, FreeOTP). Selbst wenn ein Passwort kompromittiert ist, kann der Angreifer sich nicht ohne physischen Zugang zum Telefon des Benutzers anmelden. Ein dediziertes Modul, im Dolistore verfügbar, ermöglicht eine einfache Aktivierung.
LDAP / Active Directory-Authentifizierung
Für Unternehmen mit zentralisiertem Verzeichnis bietet Dolibarr einen nativen Konnektor zu LDAP/Active Directory. Die Benutzer melden sich mit ihren von der IT zentral verwalteten Unternehmens-Anmeldedaten bei Dolibarr an. Vorteile: automatische Anwendung der unternehmensweiten Passwortrichtlinien, sofortige Deaktivierung des Dolibarr-Kontos beim Ausscheiden eines Mitarbeiters, einheitliche Rückverfolgbarkeit.
Single Sign-On (SSO) über SAML oder OpenID Connect
Um weiter zu gehen, ermöglichen Module die Anbindung von Dolibarr an einen Identity Provider (Keycloak, Azure AD, Okta, Google Workspace) über die Standards SAML 2.0 oder OpenID Connect. Ihre Benutzer melden sich einmal an, um auf alle ihre Tools zuzugreifen, MFA wird zentralisiert und einheitlich angewendet, die Compliance wird vereinfacht. Dies ist die Best Practice für Organisationen mit mehreren Geschäftsanwendungen.
10. Datenbank-Backup
Das regelmäßige Backup der Datenbank ist die kritischste Operation.
Frequenz und Aufbewahrung
Planen Sie mindestens ein vollständiges tägliches Backup, das in einer Phase geringer Aktivität (in der Regel nachts) ausgeführt wird. Für kritische Umgebungen ergänzen Sie dies durch häufigere inkrementelle Backups (stündlich oder sogar kontinuierlich). Empfohlene Aufbewahrung: 30 Tage für operative Backups, 1 bis 10 Jahre für archivierte Backups je nach Ihren gesetzlichen Verpflichtungen.
Backup-Methoden
Mehrere Ansätze koexistieren:
- Logisches Backup (SQL-Export): Erzeugt eine lesbare Textdatei, ideal für kleine und mittlere Datenbanken. Vorteile: Portabilität, Möglichkeit der Teilwiederherstellung. Grenzen: langsam ab einigen Gigabyte.
- Heißes physisches Backup: Kopiert die Binärdateien der Datenbank ohne Dienstunterbrechung. Empfohlene Tools: Mariabackup (MariaDB) oder Percona XtraBackup (MySQL). Unverzichtbar für große Datenbanken.
- Replikation auf einen sekundären Server in Echtzeit, der sowohl als Redundanz als auch als Ziel für Backups dienen kann (ohne Auswirkungen auf die Produktion).
- Snapshots auf Speichersystem- oder VM-Ebene.
Komprimierung und Verschlüsselung
Alle Backups müssen komprimiert (Größenreduzierung) und dann verschlüsselt (Schutz vor Lecks) werden. Die Verschlüsselung verwendet idealerweise einen asymmetrischen Schlüssel (z. B. GPG), dessen privater Schlüssel separat in einem digitalen Tresor gespeichert wird. Überprüfen Sie systematisch die Integrität der Backups mit einem kryptografischen Fingerabdruck (Prüfsumme).
Wiederherstellung zu einem Zeitpunkt
Aktivieren Sie die Binary Logs auf der Datenbank-Engine. Sie ermöglichen die Wiederherstellung zu einem genauen Zeitpunkt (Point-In-Time Recovery, PITR), zum Beispiel „die Datenbank in den Zustand von gestern 14:32 Uhr zurückversetzen, kurz vor dem Fehler". Diese Fähigkeit ist wertvoll, um eine versehentliche Löschung zurückzuholen, ohne alle nachfolgenden Daten zu verlieren.
11. Backup von Dateien und Dokumenten
Die Datenbank allein reicht nicht: Das Verzeichnis der Dokumente enthält die Rechnungs-PDFs, Buchhaltungsbelege, ECM-Dateien und Produktfotos. Sein Verlust wäre ebenso gravierend wie ein Datenbankverlust.
Inkrementelle Backups
Bevorzugen Sie für Dateien inkrementelle Backups mit Versionierung: Nur die geänderten Dateien werden bei jedem Zyklus gesichert, und jede Version bleibt zugänglich. Dieser Ansatz ermöglicht es, dank Hardlink- oder Deduplizierungsmechanismen viele Versionen aufzubewahren, ohne den Speicherplatz zu sprengen.
Quellcode und Konfiguration
Vergessen Sie nicht, auch den Quellcode (kundenspezifische Module, Überschreibungen) und die Konfigurationsdatei zu sichern. Ohne sie reicht eine Datenbankwiederherstellung nicht aus, um das System wieder in Betrieb zu nehmen.
Automatisierung und Planung
Alle Backups müssen über einen Scheduler (Cron, systemd-Timer, Windows-Scheduler …) automatisiert und geplant werden. Manuelle Ausführung ist zu vermeiden: Sie wird immer irgendwann vergessen. Richten Sie ein dediziertes technisches Konto für diese Operationen mit den strikt notwendigen Berechtigungen ein.
Überwachung der Backups
Jede Ausführung muss einen Bericht mit ihrem Status erzeugen (Erfolg, Misserfolg, Dauer, Größe). Im Falle eines Fehlschlags muss eine Warnung an den Administrator gesendet werden. Ein Backup, von dem man nicht weiß, ob es korrekt ausgeführt wurde, ist kein zuverlässiges Backup.
12. Die goldene 3-2-1-Regel und Offsite-Speicherung
Die 3-2-1-Regel für Backups ist universell anerkannt:
- 3 Kopien der Daten (das Original + zwei Backups).
- auf 2 verschiedenen Medien (lokale Festplatte + NAS, zum Beispiel).
- davon 1 Offsite-Kopie (Cloud, entferntes Rechenzentrum, digitaler Tresor).
Warum diese Regel?
Diese Regel schützt vor den wichtigsten Schadensszenarien. Eine einzige Kopie kann bei einem Festplattenausfall verloren gehen. Zwei Kopien auf demselben Server sind bei Brand oder Ransomware verloren. Eine Offsite-Kopie gewährleistet die Kontinuität auch bei physischer Zerstörung des Hauptstandorts.
Verschlüsselte Cloud-Synchronisation
Verwenden Sie einen souveränen Cloud-Anbieter (OVHcloud, Scaleway, Outscale, Infomaniak) oder einen Objektspeicherdienst (S3, Backblaze B2, Wasabi), um die Offsite-Kopie zu hosten. Die Daten müssen vor dem Versand clientseitig verschlüsselt werden: So kann selbst der Cloud-Anbieter sie nicht lesen. Tools wie rclone oder restic automatisieren diese verschlüsselte Synchronisation.
Unveränderliche Speicherung (Object Lock / WORM)
Aktivieren Sie den unveränderlichen Modus (WORM, Write Once Read Many) auf Ihrem Cloud-Speicher: Die Backups können während des definierten Aufbewahrungszeitraums weder geändert noch gelöscht werden, auch nicht von einem Administrator. Dies ist Ihre letzte Verteidigungslinie gegen moderne Ransomware, die nun versucht, Backups zu zerstören, bevor sie die Produktion verschlüsselt.
Air Gap für kritische Daten
Bewahren Sie für die kritischsten Daten eine Kopie auf einem physisch getrennten Medium auf (externe Festplatte oder LTO-Band, im Tresor gelagert). Diese „offline" Kopie kann von keinem Computerangriff erreicht werden. Ihre manuelle Rotation (wöchentlich oder monatlich) fügt eine ultimative Sicherheitsschicht hinzu.
13. Wiederherstellungstests und Disaster-Recovery-Plan
Backups testen
Ein nicht getestetes Backup ist kein Backup.
Dies ist eine der in der Praxis am häufigsten verletzten Regeln. Viele Unternehmen entdecken erst dann, dass ihre Backups beschädigt oder unvollständig waren, wenn sie sie benötigen. Planen Sie vierteljährliche Wiederherstellungstests auf einem Pre-Production-Server: vollständige Datenbankwiederherstellung, Dokumentenwiederherstellung, Datenintegritätsprüfung und Anwendungskonsistenz. Dokumentieren Sie die Ergebnisse und eventuelle Probleme.
Disaster-Recovery-Plan (DRP)
Dokumentieren Sie einen Disaster-Recovery-Plan, der Folgendes präzisiert:
- Das RPO (Recovery Point Objective): den maximal tolerierbaren Datenverlust. Beispiel: „Wir akzeptieren den Verlust von höchstens 4 Stunden Daten."
- Das RTO (Recovery Time Objective): die maximale Dauer der Dienstunterbrechung. Beispiel: „Wir müssen in 2 Stunden wieder einsatzfähig sein."
- Die Rollen und Verantwortlichkeiten im Schadensfall: Wer entscheidet, wer ausführt, wer kommuniziert mit den Kunden.
- Die Schritt-für-Schritt-Verfahren zur Wiederherstellung, ausreichend detailliert, damit ein Vertretungsadministrator sie ausführen kann.
- Die Kontaktdaten der Dienstleister (Hoster, Dolibarr-Integrator, Steuerberater), die auch offline zugänglich sind.
Failover auf Backup-Server
Richten Sie für kritische Umgebungen einen synchronisierten Backup-Server in Quasi-Echtzeit über Datenbankreplikation und kontinuierliche Dateisynchronisation ein. Im Schadensfall kann der Failover in wenigen Minuten über DNS-Umleitung oder automatisches Load-Balancer-Failover erfolgen. Diese Hochverfügbarkeitsarchitektur ist mittlerweile auch für KMU-Budgets zugänglich.
Krisenübungen
Organisieren Sie einmal pro Jahr eine Krisenübung, die ein größeres Schadensereignis simuliert. Alle betroffenen Teams (Technik, Fachbereich, Geschäftsleitung) nehmen teil und wenden den Plan an. Diese Übungen offenbaren Mängel, falsche Annahmen und Verbesserungsmöglichkeiten. Es ist besser, ein Problem während einer Übung zu entdecken als in einer realen Situation.
14. Logging, Monitoring und Vorfallserkennung
Log-Zentralisierung
Zentralisieren Sie alle Logs (Webserver, Datenbank, PHP-Umgebung, Dolibarr, fail2ban) in einem dedizierten Tool: Graylog, ELK (Elasticsearch + Logstash + Kibana) oder Loki + Grafana. Diese Zentralisierung ermöglicht es, Ereignisse zu korrelieren und Anomalien zu erkennen, die für das bloße Auge unsichtbar sind (mehrere fehlgeschlagene Verbindungen gefolgt von einer erfolgreichen Verbindung, ungewöhnliche Anfragen, Verkehrsspitzen).
Service-Monitoring
Überwachen Sie kontinuierlich Verfügbarkeit und Performance mit Zabbix, Prometheus + Grafana oder Netdata. Wichtige Indikatoren:
- CPU-, Speicher-, Disk-I/O-Last.
- Antwortzeit der Dolibarr-Seiten.
- Backup-Volumen und Erfolg/Misserfolg geplanter Aufgaben.
- Verbleibender Speicherplatz (Alarm bei 80 % Auslastung).
- Gültigkeit der SSL-Zertifikate (Alarm 30 Tage vor Ablauf).
Datei-Intrusion-Detection (HIDS)
Setzen Sie ein Datei-Intrusion-Detection-Tool wie AIDE, Tripwire oder Wazuh ein. Es berechnet regelmäßig den Fingerabdruck aller System- und Anwendungsdateien und alarmiert bei unerwarteten Änderungen. Es ist die wirksamste Methode, um die Installation einer Backdoor („Webshell") durch einen Angreifer zu erkennen.
Alerting und Bereitschaft
Konfigurieren Sie Alarme per E-Mail, Slack, Microsoft Teams oder Bereitschaftslösung (PagerDuty, Opsgenie). Definieren Sie Kritikalitätsschwellen: Information, Warnung, kritisch. Eine früh erkannte Intrusion ist eine eingedämmte Intrusion; eine spät erkannte Intrusion kann sehr teuer werden.
15. DSGVO-Konformität und gesetzliche Verpflichtungen
Wenn Sie personenbezogene Daten in Dolibarr verarbeiten (Kunden, Interessenten, Mitarbeiter), unterliegen Sie der DSGVO. Und die technische Sicherheit ist eine ausdrückliche Anforderung dieser Verordnung.
Erforderliche technische Maßnahmen
Die DSGVO verlangt technische und organisatorische Maßnahmen, die im Hinblick auf das Risiko „angemessen" sind:
- Verschlüsselung der Daten im Ruhezustand und bei der Übertragung.
- Rollenbasierte Zugriffskontrolle mit Least-Privilege-Prinzip.
- Protokollierung der Zugriffe auf personenbezogene Daten.
- Pseudonymisierung der Daten, wo möglich.
- Verschlüsselte Backups, sicher gespeichert.
- Regelmäßige Tests der Wirksamkeit der Sicherheitsmaßnahmen.
Rechte der Betroffenen
Dolibarr verfügt über native Funktionen, um den DSGVO-Rechten der betroffenen Personen zu entsprechen:
- Auskunftsrecht: Export aller Daten eines Kontakts in einem lesbaren Format.
- Recht auf Datenübertragbarkeit: strukturierter Export (CSV, JSON), der an einen anderen Verantwortlichen übermittelt werden kann.
- Recht auf Löschung: Anonymisierung oder Löschung eines Drittpartei mit Rückverfolgbarkeit der Operation.
- Recht auf Berichtigung: einfache Änderung fehlerhafter Daten.
- Recht auf Einschränkung: Deaktivierung von Datensätzen unter Beibehaltung der Historie aus rechtlichen Gründen.
Verarbeitungsverzeichnis und Datenschutz-Folgenabschätzung
Führen Sie ein Verarbeitungsverzeichnis, das die Nutzung von Dolibarr dokumentiert: Zwecke (Vertriebsmanagement, Buchhaltung, HR), Kategorien der erfassten Daten, Aufbewahrungsdauer, Empfänger, Sicherheitsmaßnahmen. Führen Sie für risikoreiche Verarbeitungen (große Volumen, sensible Daten) vor der Produktivsetzung eine Datenschutz-Folgenabschätzung (DSFA) durch.
Souveränes Hosting
Bevorzugen Sie für sensible Daten ein europäisches Hosting (OVHcloud, Scaleway, Outscale, Infomaniak), um Konflikte mit dem US-amerikanischen Cloud Act zu vermeiden und die Datensouveränität zu gewährleisten. Ein nach HDS (Hébergeur de Données de Santé) oder SecNumCloud zertifizierter Hoster bietet zusätzliche Garantien für regulierte Sektoren.
Meldung bei Verletzung
Im Falle einer Verletzung des Schutzes personenbezogener Daten haben Sie 72 Stunden Zeit, um die Aufsichtsbehörde zu benachrichtigen und, bei hohem Risiko, die betroffenen Personen zu informieren. Bereiten Sie Kommunikationsvorlagen und das interne Verfahren im Voraus vor, um diese Frist einzuhalten.
16. Kritische Fehler, die zu vermeiden sind
Unsere Erfahrung als Dolibarr-Integrator hat es uns ermöglicht, die wiederkehrenden Fallstricke zu identifizieren:
- Niemals Wiederherstellungen testen. Am Tag X stellt sich heraus, dass die Backups beschädigt oder unvollständig waren.
- Backups auf demselben Server speichern wie die Produktion. Eine Ransomware oder ein physisches Schadensereignis verschlüsselt und zerstört alles auf einmal.
- Das Installationsverzeichnis zugänglich lassen. Ein Angreifer kann dann Dolibarr neu installieren und Ihre Datenbank überschreiben.
- Das Admin-Konto für den Alltag verwenden. Im Falle einer Kompromittierung hat der Angreifer alle Befugnisse. Reservieren Sie dieses Konto für explizite Administrationsoperationen.
- Updates vernachlässigen. Dolibarr-Versionen beheben regelmäßig kritische Sicherheitslücken. In der Pre-Production testen und dann zügig anwenden.
- Schwache oder geteilte Passwörter. Erzwingen Sie einen Passwortmanager wie Bitwarden, KeePass oder 1Password für das gesamte Team.
- Logs ignorieren. Sie enthalten oft die ersten Anzeichen einer Intrusion. Ohne aktives Monitoring kommt der Alarm zu spät.
- Die Datenbank im Internet exponieren. Beschränken Sie den Zugriff systematisch auf autorisierte IPs und gehen Sie über ein VPN.
- Redundanz und Backup verwechseln. Ein Hochverfügbarkeitscluster schützt nicht vor einer versehentlichen Löschung oder Ransomware.
- Anwender nicht schulen. Die Mehrheit der Kompromittierungen beginnt mit erfolgreichem Phishing. Sensibilisierung ist genauso wichtig wie die Technik.
17. Fazit: Eine proaktive Haltung einnehmen
Sicherheit und Backup Ihres Dolibarr-CRM sind keine punktuellen Projekte, sondern ein kontinuierlicher Prozess. Sie ruhen auf drei untrennbaren Säulen: Prävention (Härtung, Updates, Schulung), Erkennung (Monitoring, Logging, Audits) und Reaktion (Backups, DRP, Incident Plan).
Bei NEXT GESTION begleiten wir Unternehmen bei der vollständigen Absicherung ihrer Dolibarr-Instanz: technisches und organisatorisches Audit, Server-Härtung, Einrichtung verschlüsselter automatisierter Backups, Disaster-Recovery-Plan, DSGVO-Konformität und proaktives Infrastrukturmanagement. Unser Angebot gemanagtes Dolibarr-Hosting integriert nativ alle in diesem Leitfaden beschriebenen Best Practices und ermöglicht es Ihnen, sich beruhigt auf Ihr Kerngeschäft zu konzentrieren.
Möchten Sie die Sicherheit Ihres Dolibarr auditieren? Kontaktieren Sie NEXT GESTION für eine kostenlose und personalisierte Diagnose. Besser heute vorbeugen als morgen bedauern.
FAQ: Sicherheit und Backup von Dolibarr
Wie oft sollte Dolibarr gesichert werden? Mindestens ein vollständiges tägliches Backup der Datenbank und der Dokumente, ergänzt durch stündliche inkrementelle Backups für kritische Umgebungen.
Wie lange sollten Backups aufbewahrt werden? Mindestens 30 Tage für operative Backups und 1 bis 10 Jahre für archivierte Backups (je nach Ihren buchhalterischen und gesetzlichen Verpflichtungen).
Reicht das native Backup-Modul von Dolibarr aus? Es eignet sich für kleine Instanzen, bleibt jedoch begrenzt. Für die Produktion bevorzugen Sie eine professionelle Strategie mit Verschlüsselung und Offsite-Auslagerung.
Wie schützt man sich vor Ransomware? Verschlüsselte unveränderliche Backups (Object Lock), getrennte Kopie (Air Gap), durchgehendes MFA, Netzwerksegmentierung, EDR auf Administrator-Workstations und Schulung der Teams.
Ist Dolibarr DSGVO-konform? Dolibarr stellt die technischen Werkzeuge bereit (Verschlüsselung, Zugriffsrechte, Export, Anonymisierung), aber die Konformität hängt von Ihrer Konfiguration, Ihren Prozessen und Ihrem Hosting ab.
Sollte man gemanagtes Hosting wählen oder selbst hosten? Selbst-Hosting bleibt möglich, wenn Sie über interne Kompetenzen verfügen. Andernfalls bietet professionelles gemanagtes Hosting ein besseres Sicherheits-/Kosten-Verhältnis und entlastet Ihre Teams.
Artikel verfasst von NEXT GESTION, Experte für die Integration, Absicherung und gemanagte Wartung von Dolibarr ERP/CRM. Für ein Audit oder eine Beratung kontaktieren Sie uns unter contact@nextgestion.com.