Odoo Sicherheit

Backups/Notfallwiederherstellung

• Wir bewahren 14 vollständige Backups von jeder Odoo-Datenbank für bis zu 3 Monate auf: 1/Tag für 7 Tage, 1/Woche für 4 Wochen, 1/Monat für 3 Monate.
• Backups werden in mindestens 3 verschiedenen Datenzentren auf mindestens 2 verschiedenen Kontinenten kopiert.
• Die tatsächlichen Standorte unserer Datenzentren sind aufgeführt in unserer Datenschutzrichtlinie.
• Sie können auch jederzeit manuelle Backups Ihrer Live-Daten über das Bedienfeld herunterladen.
• Sie können unseren Kundendienst kontaktieren, um diese Backups auf Ihrer Live-Datenbank (oder auf der Seite) wiederherzustellen.
• Hardware-Ausfallsicherung: Für Dienste, die auf Bare-Metal-Servern gehostet werden und bei denen ein Hardware-Ausfall möglich ist, implementieren wir eine lokale Kopie auf einem sofort einsatzbaren Ersatzrechner mit Überwachung und einem manuellen Ausfallsicherungsverfahren, das weniger als 5 Minuten dauert.
• Notfallwiederherstellung: Im Falle einer vollständigen Katastrophe, bei der ein Datenzentrum für einen längeren Zeitraum vollständig ausfällt und die Ausfallsicherung auf unserem sofort einsatzbereiten Ersatzrechner verhindert wird (ist bisher noch nie passiert, dies ist der Worst-Case-Plan), haben wir die folgenden Ziele:
  • Maximal zulässiger Datenverlust (Recovery Point Objective, RPO) = 24 Stunden. Das bedeutet, dass Sie maximal 24 Stunden Ihrer Arbeit verlieren können, wenn die Daten nicht wiederhergestellt werden können und wir Ihre letzte tägliche Sicherung wiederherstellen müssen.
  • Wiederherstellungszeitvorgabe (Recovery Time Objective, RTO) = 24 Stunden für kostenpflichtige Abonnements, 48 Stunden für kostenlose Testversionen, Bildungsangebote, Freemium-Benutzer usw. Das ist die Zeit, die benötigt wird, um den Dienst in einem anderen Datenzentrum wiederherzustellen, wenn eine Katastrophe eintritt und ein Datenzentrum komplett ausfällt.
  • Wie wird dies bewerkstelligt: Wir überwachen aktiv unsere täglichen Backups, die an mehreren Standorten auf verschiedenen Kontinenten kopiert werden. Wir haben ein automatisiertes Provisionierungsprogramm, um unsere Dienste an einem neuen Hosting-Standort bereitzustellen. Die Wiederherstellung der Daten auf der Grundlage unserer Backups vom Vortag kann dann innerhalb weniger Stunden erfolgen (bei den größten Clustern), wobei die bezahlten Abonnements Vorrang haben.
    Wir verwenden routinemäßig sowohl die täglichen Backups als auch die Provisionierungsskripte für den täglichen Betrieb, sodass beide Teile des Notfallwiederherstellungsverfahren ständig getestet werden.

Datenbanksicherheit

• Kundendaten sind auf einer gesonderten Datenbank gespeichert. Daten werden nicht zwischen Kunden geteilt.
• Die Regeln für die Datenzugriffskontrolle implementieren eine vollständige Trennung zwischen Kundendatenbanken, die auf demselben Cluster laufen; ein Zugriff von einer Datenbank auf eine andere ist nicht möglich.

Passwortsicherheit

• Kundenpasswörter werden mit PBKDF2+SHA512-Verschlüsselung nach Industriestandard (gesalzen + gestreckt für tausende von Runden) geschützt.
• Odoo-Mitarbeiter haben keinen Zugriff auf Ihr Passwort und können es nicht für Sie abrufen. Wenn Sie es verlieren, können Sie es nur zurücksetzen.
• Die Anmeldedaten werden immer sicher über HTTPS übertragen.
• Ab Odoo 12.0 haben die Administratoren der Kundendatenbank sogar die Möglichkeit, die Ratenbegrenzung und die Zwischendauer für wiederholte Anmeldeversuche zu konfigurieren.
• Passwortrichtlinien: Ab Odoo 12 haben Datenbankadministratoren die Möglichkeit, eine Mindestlänge für Benutzerpasswörter festzulegen. Bei älteren Versionen ist es möglich, den gleichen Effekt durch Anpassung zu erzielen. Andere Passwortrichtlinien wie erforderliche Zeichenklassen werden standardmäßig nicht unterstützt, da sie sich als kontraproduktiv erwiesen haben (siehe z. B. [Shay et al. 2016]).

Mitarbeiterzugriff

• Kundendienstmitarbeiter von Odoo können sich in Ihrem Konto anmelden, um auf Einstellungen zuzugreifen, die mit Ihrem Support-Problem zusammenhängen. Dazu verwenden sie ihre eigenen speziellen Mitarbeiteranmeldedaten und nicht Ihr Passwort (das sie nicht kennen können).
• Dieser spezielle Mitarbeiterzugriff verbessert die Effizienz und die Sicherheit: Die Mitarbeiter können das Problem, das Sie sehen, sofort reproduzieren, Sie müssen Ihr Passwort nicht weitergeben und wir können die Aktionen der Mitarbeiter separat prüfen und kontrollieren!
• Unsere Kundendienstmitarbeiter sind bestrebt, Ihre Privatsphäre so weit wie möglich zu respektieren, und greifen nur auf Dateien und Einstellungen zu, die für die Diagnose und Lösung Ihres Problems erforderlich sind.

Systemsicherheit

• Auf allen Odoo-Cloud-Servern laufen gehärtete Linux-Distributionen mit aktuellen Sicherheitspatches.
• Installationen sind ad-hoc und minimal, um die Anzahl der Dienste zu begrenzen, die Sicherheitslücken enthalten könnten (z. B. kein PHP/MySQL-Stack).
• Nur einige wenige vertrauenswürdige Odoo-Ingenieure sind berechtigt, die Server aus der Ferne zu verwalten, und der Zugriff ist nur über ein verschlüsseltes persönliches SSH-Schlüsselpaar von einem Computer mit vollständiger Festplattenverschlüsselung möglich.

Physische Sicherheit

Odoo-Cloud-Server werden in vertrauenswürdigen Datenzentren in unterschiedlichen Regionen in der ganzen Welt gehostet (z. B. OVH, Google Cloud) und sie müssen alle unsere physischen Sicherheitskriterien erfüllen:

• Eingeschränkter Umkreis, physischer Zugang nur für autorisierte Mitarbeiter des Datenzentrums.
• Physische Zugriffskontrolle mit Sicherheitsausweisen oder biometrischen Sicherheitsmethoden.
• Sicherheitskameras, die die Standorte der Datenzentren 24/7 überwachen.
• Sicherheitspersonal, das 24/7 vor Ort ist.

Kreditkartensicherheit

• Kreditkarteninformationen werden niemals in unserem eigenen System gespeichert.
• Ihre Kreditkarteninformationen werden immer sicher und direkt zwischen Ihnen und unseren PCI-konformen Zahlungsanbietern übertragen (siehe die Liste in unserer Datenschutzrichtlinie ).

Datenverschlüsselung

• Die gesamte Datenkommunikation zu den Kundeninstanzen wird mit modernster 256-Bit-SSL-Verschlüsselung (HTTPS) geschützt.
• Die interne Datenkommunikation zwischen unseren Servern ist mit hochmoderner Verschlüsselung (SSH) geschützt.
• Unsere Server stehen unter strenger Sicherheitsüberwachung und sind stets gegen die neuesten SSL-Sicherheitslücken gepatcht, sodass sie jederzeit über eine SSL-Bewertung der Stufe A verfügen.
• Alle unsere SSL-Zertifikate verwenden robuste 2048-Bit-Module mit vollständigen SHA-2-Zertifikatsketten.
• Alle Kundendaten (Datenbankinhalte und gespeicherte Dateien) werden im Ruhezustand verschlüsselt, sowohl in der Produktion als auch in den Backups (AES-128 oder AES-256).

Netzwerkverteidigung

• Alle von Odoo Cloud genutzten Datenzentrumsanbieter verfügen über sehr große Netzwerkkapazitäten und haben ihre Infrastruktur so ausgelegt, dass sie auch den größten Distributed-Denial-of-Service-(DDoS-)Angriffen standhalten. Ihre automatischen und manuellen Abwehrsysteme können den Angriffsverkehr am Rande ihrer multikontinentalen Netzwerke erkennen und umleiten, bevor er die Möglichkeit hat, die Verfügbarkeit der Dienste zu stören.
• Firewalls und Intrusion-Prevention-Systeme auf den Odoo-Cloud-Servern helfen dabei, Bedrohungen wie Brute-Force-Angriffe auf Passwörter zu erkennen und zu blockieren.
• Ab Odoo 12.0 haben die Administratoren der Kundendatenbank sogar die Möglichkeit, die Ratenbegrenzung und die Zwischendauer für wiederholte Anmeldeversuche zu konfigurieren.

Softwaresicherheit

Da es sich bei Odoo um eine Open-Source-Software handelt, wird die gesamte Codegrundlage ständig von Odoo-Benutzern und -Mitwirkenden weltweit überprüft. Fehlerberichte der Community sind daher eine wichtige Quelle für Rückmeldungen zur Sicherheit. Wir ermutigen die Entwickler, den Code zu überprüfen und Sicherheitsprobleme zu melden.

Die F&E-Prozesse von Odoo umfassen Schritte zur Überprüfung des Codes, die auch Sicherheitsaspekte für neue und beigesteuerte Teile des Codes beinhalten.

Sicherheit durch Design

Odoo wurde so gestaltet, dass die häufigsten Sicherheitslücken nicht auftreten:

• SQL-Einschleusungen werden durch den Einsatz einer übergeordneten Programmierschnittstelle verhindert, die keine manuellen SQL-Abfragen erfordert.
• XSS-Angriffe werden durch die Verwendung eines hochrangigen Templating-Systems verhindert, das eingefügte Daten automatisch umgeht.
• Das Framework verhindert den RPC-Zugriff auf private Methoden, was das Einschleusen ausnutzbarer Sicherheitslücken erschwert.

Siehe auch den Abschnitt Die größten OWASP-Sicherheitslücken , um zu erfahren, wie Odoo von Grund auf entwickelt wurde, um das Auftreten solcher Sicherheitslücken zu verhindern.

Unabhängige Sicherheitsprüfungen

Odoo wird regelmäßig von unabhängigen Unternehmen geprüft, die von unseren Kunden und Interessenten beauftragt werden, um Prüfungen und Penetrationstests durchzuführen. Das Sicherheitsteam von Odoo erhält die Ergebnisse und ergreift, wenn nötig, entsprechende Korrekturmaßnahmen.

Wir können jedoch keine dieser Ergebnisse veröffentlichen, da sie vertraulich sind und den Bevollmächtigten gehören. Bitte fragen Sie nicht danach ;-)

Odoo verfügt auch über eine sehr aktive Gemeinschaft unabhängiger Sicherheitsexperten, die den Quellcode kontinuierlich überwachen und mit uns zusammenarbeiten, um die Sicherheit von Odoo zu verbessern und zu stärken. Unser Sicherheitsprogramm beschreiben wir in unserer Verantwortungsvollen Offenlegung .

Die größten OWASP-Sicherheitslücken

Wie Odoo zu den wichtigsten Sicherheitsproblemen für Webanwendungen steht, die vom Open Web Application Security Project (OWASP) aufgelistet werden:

• Injection Flaws: Einschleusungsfehler, insbesondere SQL-Einschleusung, sind in Webanwendungen weit verbreitet. Einschleusungen treten auf, wenn vom Benutzer bereitgestellte Daten als Teil eines Befehls oder einer Abfrage an einen Interpreter gesendet werden. Die feindlichen Daten des Angreifers verleiten den Interpreter dazu, unbeabsichtigte Befehle auszuführen oder Daten zu ändern.

  Odoo stützt sich auf ein objektrelationales Abbildungsframework (object-relational mapping, ORM), das den Aufbau von Abfragen abstrahiert und SQL-Einschleusungen standardmäßig verhindert. Entwickler erstellen SQL-Abfragen in der Regel nicht manuell, sondern sie werden von der ORM generiert, und die Parameter werden immer korrekt escaped.

• Cross-Site-Scripting (XSS): XSS-Sicherheitslücken treten immer dann auf, wenn eine App vom Benutzer eingegebene Daten aufgreift und sie an einen Webbrowser sendet, ohne diese Inhalte vorher zu validieren oder zu verschlüsseln. XSS ermöglicht es Angreifern, Skripte im Browser des Opfers auszuführen, die Benutzersitzungen entführen, Websites verunstalten, möglicherweise Würmer einschleusen können.

  Das Odoo-Framework umgeht standardmäßig alle Ausdrücke, die in Ansichten und Seiten gerendert werden, um XSS zu verhindern. Entwickler müssen Ausdrücke speziell als „sicher“ kennzeichnen, um sie in gerenderte Seiten einzubinden.

• Cross Site Request Forgery (CSRF): Ein CSRF-Angriff zwingt den Browser eines angemeldeten Opfers, eine gefälschte HTTP-Anfrage mit dem Sitzungscookie des Opfers und anderen automatisch enthaltenen Authentifizierungsinformationen an eine anfällige Webanwendung zu senden. Auf diese Weise kann der Angreifer den Browser des Opfers zwingen, Anfragen zu generieren, die die anfällige Anwendung für legitime Anfragen des Opfers hält.

  Das Odoo-Websitemodul enthält einen eingebauten CSRF-Schutzmechanismus. Er verhindert, dass eine HTTP-Steuerung eine POST-Anfrage ohne das entsprechende Sicherheitstoken erhält. Dies ist die empfohlene Technik zum Schutz vor CSRF. Dieses Sicherheitstoken ist nur dann bekannt und vorhanden, wenn der Benutzer wirklich auf das entsprechende Website-Formular zugegriffen hat, und ein Angreifer kann eine Anfrage ohne dieses Token nicht fälschen.

• Malicious File Execution: Code, der für die Ferneinbindung von Dateien (Remote File Inclusion, RFI) anfällig ist, ermöglicht es Angreifern, feindliche Codes und Daten einzufügen, was zu verheerenden Angriffen führt, z. B. zur vollständigen Kompromittierung des Servers.

  Odoo stellt keine Funktionen für Remote File Inclusion zur Verfügung. Es erlaubt jedoch privilegierten Benutzern, Funktionen anzupassen, indem sie benutzerdefinierte Ausdrücke hinzufügen, die vom System ausgewertet werden. Diese Ausdrücke werden immer in einer Sandbox-Umgebung ausgewertet, die nur den Zugriff auf zulässige Funktionen zulässt.

• Insecure Direct Object Reference: Ein direkter Objektverweis liegt vor, wenn ein Entwickler einen Verweis auf ein internes Implementierungsobjekt wie eine Datei, ein Verzeichnis, einen Datenbankeintrag oder einen Schlüssel als URL oder Formularparameter preisgibt. Angreifer können diese Verweise manipulieren, um unbefugt auf andere Objekte zuzugreifen.

  Die Zugriffskontrolle von Odoo ist nicht auf der Ebene der Benutzeroberfläche implementiert, sodass kein Risiko besteht, wenn URLs Verweise auf interne Objekte enthalten. Angreifer können die Zugriffskontrolle nicht umgehen, indem sie diese Verweise manipulieren, da jede Anfrage immer noch die Datenzugriffsvalidierung durchlaufen muss.

• Insecure Cryptographic Storage: Webanwendungen verwenden kryptografische Funktionen nur selten ordnungsgemäß, um Daten und Anmeldeinformationen zu schützen. Angreifer nutzen schwach geschützte Daten, um Identitätsdiebstahl und andere Straftaten wie Kreditkartenbetrug zu begehen.

  Odoo verwendet einen sicheren, dem Industriestandard entsprechenden Hash für Benutzerpasswörter (standardmäßig PKFDB2 + SHA-512, mit Schlüsselsteckung), um gespeicherte Passwörter zu schützen. Es ist auch möglich, externe Authentifizierungssysteme wie OAuth 2.0 oder LDAP zu verwenden, um die lokale Speicherung von Benutzerpasswörtern ganz zu vermeiden.

• Insecure Communications: Anwendungen verschlüsseln den Netzwerkverkehr häufig nicht, wenn dies zum Schutz sensibler Kommunikation erforderlich ist.

  Odoo Cloud läuft standardmäßig über HTTPS. Für on-premise-Installationen wird empfohlen, Odoo hinter einem Webserver laufen zu lassen, der die Verschlüsselung implementiert und Anfragen über einen Proxy-Server an Odoo sendet, z. B. Apache, Lighttpd oder nginx.  Der Odoo-Implementierungsleitfaden enthält eine Sicherheitscheckliste für sicherere öffentliche Implementierungen.

• Failure to Restrict URL Access: Häufig schützt eine Anwendung sensible Funktionen nur, indem sie die Anzeige von Links oder URLs für nichtautorisierte Benutzer verhindert. Angreifer können diese Schwachstelle ausnutzen, um auf diese URLs direkt zuzugreifen und unbefugte Operationen durchzuführen.

  Die Zugriffskontrolle von Odoo ist nicht auf der Ebene der Benutzeroberfläche implementiert und die Sicherheit beruht nicht auf dem Verstecken spezieller URLs. Angreifer können die Zugriffskontrolle nicht umgehen, indem sie eine beliebige URL wiederverwenden oder manipulieren, da jede Anfrage immer noch die Datenzugriffsvalidierung durchlaufen muss. In den seltenen Fällen, in denen eine URL einen nichtauthentifizierten Zugang zu sensiblen Daten bietet, wie z. B. spezielle URLs, die Kunden zur Bestätigung einer Bestellung verwenden, werden diese URLs mit eindeutigen Token digital signiert und nur per E-Mail an den vorgesehenen Empfänger gesendet.

Melden von Sicherheitslücken

Wenn Sie eine Sicherheitslücke melden müssen, besuchen sie bitte unsere Seite für verantwortungsvolle Offenlegung. Diese Berichte werden mit hoher Priorität behandelt, das Problem wird sofort vom Odoo-Sicherheitsteam in Zusammenarbeit mit dem Meldenden bewertet und gelöst und dann auf verantwortungsvolle Weise an die Kunden und Benutzer von Odoo weitergegeben.