Odoo Veiligheid

Back-ups / Disaster Recovery

• We bewaren 14 volledige back-ups van elke Odoo database gedurende ten minste 3 maanden: 1/dag gedurende 7 dagen, 1/week gedurende 4 weken, 1/maand gedurende 3 maanden.
• Back-ups worden gekopieerd in minimaal 3 verschillende datacenters, op minimaal 2 verschillende continenten.
• De feitelijke locaties van onze datacenters staan vermeld in ons Privacybeleid.
• Je kan ook op elk moment handmatige back-ups van je livegegevens downloaden via het controlepaneel.
• Je kan contact opnemen met onze Helpdesk om één van die back-ups terug te zetten op je live database (of ernaast).
• Hardware failover: voor diensten die gehost worden op bare-metal, waar hardware storingen mogelijk zijn, implementeren we lokale hot-standy replicatie, met monitoring en een handmatige failover-procedure die minder dan 5 minuten duurt.
• Disaster recovery: in het geval van een complete ramp, met een datacenter dat voor langere periode volledig uitvalt, waardoor de failover naar onze lokale hot-standby niet mogelijk is (tot nu toe nog nooit gebeurd, dit is het worst case scenario), hebben wij de volgende doelstellingen:
  • RPO (Recovery Point Objective) = 24 uur. Dit betekent dat je maximaal 24 uur aan werk kunt verliezen als de gegevens niet kunnen worden hersteld en we je laatste dagelijkse back-up moeten herstellen.
  • RTO (Recovery Time Objective) = 24 uur voor betalende abonnementen, 48 uur voor gratis proefversies, het educatief aanbod, freemium gebruikers, enz. Dit is de tijd die nodig is om de diensten in een ander datacenter te herstellen als zich een ramp voordoet en een datacenter volledig uitvalt.
  • Hoe wordt dit bereikt: we houden onze dagelijkse back-ups actief in de gaten en ze worden gekopieerd op meerdere locaties op verschillende continenten. We hebben geautomatiseerde provisioning om onze diensten op een nieuwe hostinglocatie te implementeren. Het terugzetten van gegevens op basis van de back-ups van de vorige dag is mogelijk in een paar uur (voor de grootste clusters), met voorrang voor de betalende abonnementen.
    We gebruiken routinematig zowel de dagelijkse back-ups en de provisioning-scripts voor dagelijkse operaties, dus beide delen van het noodherstelplan worden voortdurend getest.

Databasebeveiliging

• Klantgegevens worden opgeslagen in een speciale database - geen uitwisseling van gegevens tussen klanten.
• Regels voor gegevenstoegang zorgen voor een volledige isolatie tussen klantdatabases die op hetzelfde cluster draaien, er is geen toegang mogelijk van de ene database tot de andere.

Wachtwoordbeveiliging

• Wachtwoorden van klanten worden beschermd met de industriestandaard PBKDF2+SHA512-encryptie (salting + stretching voor duizenden rondes).
• Het personeel van Odoo heeft geen toegang tot je wachtwoord en kan het niet voor u opvragen. De enige optie als je het verliest is om het opnieuw in te stellen.
• Inloggegevens worden altijd veilig verzonden via HTTPS.
• Beheerders van klantdatabases hebben zelfs de mogelijkheid omeen snelheidsbeperking in te stellen evenals een afkoelduur voor herhaalde inlogpogingen.
• Wachtwoordbeleid: databasebeheerders hebben een ingebouwde instelling voor het afdwingen van een minimale lengte van gebruikerswachtwoorden. Andere beleidsregels voor wachtwoorden, zoals verplichte tekenklassen worden niet standaard ondersteund, omdat ze bewezen contraproductief zijn. Zie bijvoorbeeld [Shay et al. 2016]), evenals NIST SP 800-63b.

Toegang van het personeel

• Medewerkers van Odoo's helpdesk kunnen inloggen op je account om toegang te krijgen tot instellingen met betrekking tot je ondersteuningsprobleem. Hiervoor gebruiken ze hun eigen speciale inloggegevens, niet je wachtwoord (dat ze op geen enkele manier kunnen weten).
• Deze speciale personeelstoegang verbetert de efficiëntie en veiligheid: ze kunnen het probleem dat je ondervindt onmiddellijk reproduceren, je hoeft nooit je wachtwoord te delen en wij kunnen de acties van het personeel afzonderlijk controleren en nazien!
• Onze Helpdesk-medewerkers streven ernaar je privacy zoveel mogelijk te respecteren en hebben alleen toegang tot bestanden en instellingen die nodig zijn om je probleem te constateren en op te lossen.

Beveiliging van het systeem

• Alle Odoo Cloud servers draaien geharde Linux-distributies met up-to-date beveiligingspatches.
• Installaties zijn ad-hoc en minimaal om het aantal diensten dat kwetsbaarheden zou kunnen bevatten te beperken (geen PHP/MySQL stack bijvoorbeeld).
• Alleen een paar vertrouwde Odoo ingenieurs hebben toestemming om de servers op afstand te beheren - en toegang is enkel mogelijk via een versleuteld persoonlijk SSH-sleutelpaar, vanaf een computer met volledige versleuteling.

Fysieke beveiliging

Odoo Cloud-servers worden gehost in vertrouwde datacenters in verschillende regio's van de wereld (bv. OVH, Google Cloud), en ze moeten allemaal onze fysieke beveiligingscriteria overtreffen:

• Beperkte perimeter, alleen fysiek toegankelijk voor geautoriseerde medewerkers van het datacenter.
• Fysieke toegangscontrole met beveiligingsbadges of biometrische beveiliging.
• Beveiligingscamera's bewaken de datacenters 24/7.
• Beveiligingspersoneel dat 24/7 ter plaatse is.

Beveiliging van creditcards

• We slaan nooit creditcardgegevens op onze eigen systemen op.
• Je creditcardgegevens zijn altijd veilig en rechtstreeks verzonden tussen u en onze PCI-conforme betaalproviders (zie de lijst verstrekt in ons Privacybeleid ).

Gegevensversleuteling

• Alle communicatie van gegevens naar klantinstanties is beveiligd met de modernste 256-bits SSL-encryptie (HTTPS).
• Alle interne communicatie van gegevens tussen onze servers is eveneens beveiligd met de modernste encryptie (SSH).
• Onze servers staan onder strenge veiligheidscontrole en worden altijd gepatcht tegen de laatste SSL kwetsbaarheden, waardoor ze te allen tijde een SSL A-rating genieten.
• Al onze SSL-certificaten gebruiken een robuuste 2048-bits modulus met volledige SHA-2-certificaatketens.
• Alle klantgegevens (inhoud en bestanden opgeslagen in de database) worden in rust versleuteld, zowel in productie als in back-ups (AES-128 of AES-256).

Netwerkverdediging

• Alle door Odoo Cloud gebruikte datacenter providers hebben zeer grote netwerkcapaciteiten en hebben hun infrastructuur ontworpen om de grootste Distributed-denial-of-service-aanvallen (DDoS) te weerstaan. Hun automatische en handmatige mitigatiesystemen kunnen verkeer aan de rand van hun multi-continentale netwerken detecteren en omleiden, voordat het de kans krijgt om de beschikbaarheid van diensten te verstoren.
• Firewalls en inbraakpreventiesystemen op de Odoo Cloud-servers helpen bij het detecteren en blokkeren van bedreigingen zoals brute-force aanvallen op wachtwoorden.
• Beheerder van klantdatabases hebben zelfs de mogelijkheid om een snelheidsbeperking in te stellen evenals een afkoelduur voor herhaalde inlogpogingen.

Beveiliging van software

Odoo is open source, dus de hele codebase wordt voortdurend onderzocht door Odoo gebruikers en medewerkers wereldwijd. De bugrapporten van de community zijn dus een belangrijke bron van feedback met betrekking van beveiliging. We moedigen ontwikkelaars aan om de code te controleren en beveiligingsproblemen te melden.

De Odoo R&D-processen voorzien code review stappen die beveiligingsaspecten omvatten, voor nieuwe en bijgedragen stukken code.

Secure by design

Odoo is ontworpen op een manier die de introductie van de meest voorkomende beveiligingsproblemen voorkomt:

• SQL-injecties worden voorkomen door het gebruik van een API op hoger niveau die geen handmatige SQL queries vereisten.
• XSS aanvallen worden voorkomen door het gebruik van een sjabloonsysteem op hoog niveau dat automatisch geïnjecteerde gegevens ontloopt.
• Het framework voorkomt de toegang van RPC tot private methodes, waardoor het moeilijker wordt om exploiteerbare kwetsbaarheden te introduceren.

Zie ook de sectie over de Meest voorkomende kwetsbaarheden volgens OWASP om te zien hoe Odoo van meet af aan ontworpen is om dergerlijke kwetsbaarheden te voorkomen.

Onafhankelijke beveiligingsaudits

Odoo wordt regelmatig gecontroleerd door onafhankelijke bedrijven die door onze klanten en prospects worden ingehuurd om audits en penetratietests uit te voeren. Het Odoo Security Team ontvangt de resultaten en neemt passende corrigerende maatregelen wanneer dat nodig is.

We kunnen die resultaten echter niet openbaar maken, omdat ze vertrouwelijk zijn en toebehoren aan de opdrachtgevers. Gelieve er dus niet naar te vragen ;-)

Odoo heeft ook een heel actieve gemeenschap van onafhankelijke beveiligingsonderzoekers, die voortdurend de broncode controleren en met ons samenwerken om de veiligheid van Odoo te verbeteren en te verharden. Ons beveiligingsprogramma is omschreven op onze Responsible Disclosure pagina.

Meest voorkomende kwetsbaarheden volgens OWASP

Hier is Odoo's kijk op de meest voorkomende beveiligingsproblemen voor webapplicaties, zoals vermeld door het Open Web Application Security Project (OWASP):

• Injectiekwetsbaarheden: Injectiekwetsbaarheden, zoals SQL-injecties, komen vaak voor in webapplicaties. Injectie treedt op wanneer door de gebruiker verstrekte gegevens naar een interpreter worden gestuurd als onderdeel van een commando of query. De vijandige gegevens van de aanvaller verleiden de interpreter tot het uitvoeren van onbedoelde commando's of het wijziging van gegevens.

  Odoo vertrouwt op object-relationele mapping (ORM) dat het bouwen van queries abstraheert en SQL-injecties standaard voorkomt. Ontwikkelaars maken SQL-queries meestal niet handmatig, ze worden gegenereerd door het ORM en parameters worden altijd correct geëscaped.

• Cross Site Scripting (XSS): XSS-fouten doen zich voor wanneer een applicatie door de gebruiker verstrekte gegevens naar een webbrower stuurt zonder die inhoud eerst te valideren of te coderen. XSS laat aanvallers toe om scrips uit toe voeren in de browser van het slachtoffer die gebruikerssessies kunnen kapen, websites bekladden, eventueel wormen introduceren, enz.

  Het Odoo framework escapeert standaard alle expressies die in weergaven en pagina's worden weergegevens, waardoor XSS wordt voorkomen. Ontwikkelaars moeten expressies uitdrukkelijk markeren als "veilig" voor ruwe opname in weergegeven pagina's.

• Cross Site Request Forgery (CSRF): Een CSRF-aanval dwingt de browser van een aangemeld slachtoffer om een vervalst HTTP-verzoek, met inbegrip van de sessiecookie van het slachtoffer en andere automatisch opgenomen authentificatiegegevens, naar een kwetsbare webapplicatie te versturen. Hierdoor kan de aanvaller de browser van het slachtoffer dwingen om verzoeken te genereren waarvan de kwetsbare applicatie denkt dat het legitieme verzoeken van het slachtoffer zijn.

  De website van Odoo bevat een ingebouwd CSRF-beschermingsmechanisme. Het voorkomt dat een HTTP-controller een POST-verzoek ontvangt zonder het bijbehorende beveiligingstoken. Dit is de aanbevolen techniek om CSRF te voorkomen. Het beveiligingstoken is alleen gekend en aanwezig als de gebruiker werkelijk het relevantie formulier op de website heeft bezocht en een aanvaller kan geen verzoek vervalsen zonder dit token.

• Kwaadwillige uitvoering van bestanden: Code die kwetsbaar is voor remote file inclusion (RFI) stelt aanvallers in staat om vijandige code en gegevens op te nemen, wat resulteert in verwoestende aanvallen, zoals een totale compromittering van de server.

  Odoo biedt geen functies om remote file inclusion uit te voeren. Het staat echter bevoorrechte gebruikers toe om functies aan te passen door aangepaste expressies toe te voegen die door het systeem worden geëvalueerd. Deze expressies worden altijd geëvalueerd door een sandbox- en gezuiverde omgeving die alleen toegang geeft tot toegestane functies.

• Ongeautoriseerde directe objectreferenties: Een directe objectreferentie treedt op wanneer een ontwikkelaar een verwijzing naar een intern implementatieobject, zoals een bestand, directory, databaserecord, of sleutel, openbaar maakt als URL of formulierparameter. Aanvallers kunnen deze verwijzingen manipuleren om toegang te krijgen tot andere objecten zonder toestemming.

  Odoo's toegangscontrole is niet geïmplementeerd op gebruikersinterfaceniveau, dus er is geen risico dat verwijzingen naar interne objecten als URL openbaar worden gemaakt. Aanvallers kunnen de controlelaag niet omzeilen door deze verwijzingen te manipuleren, omdat elk verzoek nog steeds de toegangscontrole moet ondergaan.

• Onveilige cryptografische opslag: Webapplicaties maken zelden gebruik van cryptografische functies om gegevens en inloggegevens te beschermen. Aanvallers gebruiken slecht beschermde gegevens om identiteitsdiefstal en andere misdrijven uit te voeren, zoals fraude met creditcards.

  Odoo maakt gebruik van industriestandaard veilige hashing voor gebruikerswachtwoorden (standaard PKFDB2 + SHA-512, met key stretching) om opgeslagen wachtwoorden te beschermen. Het is ook mogelijk om externe authentificatiesystemen te gebruiken, zoals OAuth 2.0 of LDAP, om te voorkomen dat gebruikerswachtwoorden lokaal worden opgeslagen.

• Onveilige communicatie: Applicaties falen vaak om netwerkverkeer te versleutelen wanneer het nodig is om gevoelige gegevens te beschermen.

  Odoo Cloud draait standaard op HTTPS. Voor on-premise installaties, wordt aanbevolen om Odoo te draaien achter een webserver die de versleuteling implementeerd en verzoeken via een proxy laten verlopen, zoals Apache, Lighttpd of nginx. De implementatiegids van Odoo bevat een beveiligingschecklist voor veiligere publieke implementaties.

• Het niet-beperken van URL-toegang: Vaak beschermt een applicatie alleen gevoelige functies door te voorkomen dat links of URL's aan onbevoegde gebruikers worden getoond. Aanvallers kunnen deze kwetsbaarheid gebruiken om toegang te krijgen en ongeoorloofde bewerkingen uit te voeren door deze URL's rechtstreeks te openen.

  Odoo's toegangscontrole is niet geïmplementeerd op gebruikersinterfaceniveau en de beveiliging berust niet op het verbergen van speciale URL's. Aanvallers kunnen de toegangscontrole niet omzeilen door een willekeurige URL te hergebruiken of te manipuleren, omdat elk verzoek nog steeds de toegangscontrole moet ondergaan. In zeldzame gevallen waarin een URL een ongeoorloofde toegang verschaft tot gevoelige gegegevens, zoals speciale URL's die klanten gebruiken om een bestelling te bevestingen, worden deze URL's digitaal ondertekend met unieke tokens en enkel verstuurd via e-mail naar de beoogde ontvanger.

Beveiligingsproblemen melden

Als je een beveiligingsprobleem wilt melden, ga dan naar onze responsible disclosure pagina. Deze rapporten worden met hoge prioriteit behandeld, het probleem wordt onmiddellijk beoordeeld en opgelost door het Odoo security team, in samenwerking met de melder, en vervolgens op een verantwoorde manier openbaar gemaakt aan klanten en gebruikers van Odoo.