Toen we jaren geleden voor het eerst een blog schreven over de beveiliging van Odoo, ging een groot deel van de aandacht naar hosting. Waar staat mijn database? Hoe zijn de servers beveiligd? Zijn er back-ups? Hoe worden wachtwoorden opgeslagen?
Allemaal terechte vragen.
Maar als je me nu vraagt waar ik me bij de beveiliging van Odoo het meeste zorgen over maak, staat het datacenter niet bovenaan mijn lijst.
Ik maak me meer zorgen over de medewerker die administratorrechten krijgt omdat hij anders af en toe iets niet kan. Over bedrijfsgegevens die zonder nadenken in een publieke AI-tool worden geplakt. Over een AI-agent die rechtstreeks toegang krijgt tot Odoo en zelfstandig gegevens kan wijzigen. En over maatwerkcode die in een paar minuten met AI wordt gegenereerd en daarna zonder goede review op een productiedatabase terechtkomt.
Of iets korter:
Maak iedereen administrator en je hebt nooit meer vragen dat ze iets niet kunnen.
Het werkt. Alleen is het als beveiligingsstrategie wat minder sterk.
Is Odoo zelf veilig?
Laten we eerst de basisvraag beantwoorden: ja, Odoo beschikt over een behoorlijk volwassen beveiligingsarchitectuur.
Bij gebruik van Odoo Cloud wordt klantdata per klant in een afzonderlijke database opgeslagen. Data wordt versleuteld tijdens transport en ook opgeslagen data en bestanden worden versleuteld. Odoo maakt daarnaast meerdere generaties back-ups en repliceert die over verschillende datacenters.
Voor gebruikersaccounts zijn onder andere tweestapsverificatie, beveiligde HTTPS-verbindingen en mogelijkheden voor het beperken van herhaalde inlogpogingen beschikbaar. Tweestapsverificatie kan bovendien centraal worden afgedwongen voor medewerkers of voor alle gebruikers.
Dat betekent niet dat Odoo onkwetsbaar is. Dat is geen enkele software. Maar de technische basis is niet het onderdeel waar ik als eerste naar zou kijken als een bedrijf mij vraagt hoe het zijn Odoo-omgeving veiliger kan maken.
Het interessantere gesprek begint daarna.
Over het datacenter maak ik me minder zorgen
Bedrijven besteden soms veel aandacht aan de fysieke locatie van hun ERP-systeem. Dat begrijp ik. Je administratie, klantgegevens, verkoopinformatie, voorraad, personeelsgegevens en misschien zelfs productiegegevens staan allemaal in hetzelfde systeem.
Daar wil je zorgvuldig mee omgaan.
Maar wanneer je Odoo Cloud gebruikt, zijn beveiliging van infrastructuur, versleuteling, back-ups en disaster recovery zaken waar Odoo dagelijks professioneel mee bezig is. Odoo bewaart verschillende generaties volledige back-ups en verspreidt die over meerdere datacenters.
Ik zou daarom niet zeggen dat de infrastructuur onbelangrijk is. Integendeel. Alleen is het risico daar vaak beter beheerst dan het risico binnen je eigen organisatie.
Want vervolgens logt een gebruiker in die overal bij kan.
En dat heb je zelf ingericht.
Maak iedereen administrator en je bent van het gezeur af
Rechten zijn een van de krachtigste beveiligingsmechanismen binnen Odoo en tegelijkertijd een van de gemakkelijkste om verkeerd in te richten.
Odoo kent uitgebreide mogelijkheden om vast te leggen welke gebruikers bepaalde gegevens mogen lezen, aanmaken, wijzigen en verwijderen. Met groepen, rollen, toegangsrechten en record rules kun je behoorlijk precies bepalen wie bij welke informatie mag. Rechten uit verschillende groepen kunnen daarbij bij elkaar worden opgeteld.
Dat laatste maakt goed rechtenbeheer belangrijk.
In de praktijk ontstaat namelijk al snel een ander patroon.
Een medewerker kan iets niet. Er moet snel iets gebeuren. Iemand geeft ruimere rechten. Probleem opgelost.
Een maand later gebeurt hetzelfde ergens anders.
Na een paar jaar heb je een organisatie vol gebruikers die veel meer mogen dan nodig is voor hun functie.
Dat is handig totdat er iets misgaat.
Het uitgangspunt zou juist andersom moeten zijn: geef iemand precies de rechten die nodig zijn om zijn werk te doen. Niet meer.
Dat principe wordt vaak least privilege genoemd. Een medewerker van verkoop hoeft bijvoorbeeld niet automatisch alle financiële gegevens te kunnen bekijken. Iemand die klantgegevens onderhoudt, hoeft niet per definitie gebruikersrechten te kunnen aanpassen. En iemand die rapportages maakt, hoeft misschien wel gegevens te kunnen lezen, maar niet te verwijderen.
Dat vraagt bij de implementatie iets meer nadenkwerk. Daarna bespaart het juist problemen.
Beveiliging stopt niet na de implementatie
Een veelgemaakte fout is dat gebruikersrechten tijdens de implementatie worden ingericht en daarna jaren blijven staan.
Maar organisaties veranderen.
Mensen krijgen een andere functie. Teams worden samengevoegd. Een medewerker neemt tijdelijk taken over van een collega. Iemand krijgt voor een project extra rechten. Nieuwe Odoo-apps worden in gebruik genomen.
De tijdelijke uitzondering van vandaag wordt opvallend vaak de permanente inrichting van morgen.
Daarom horen gebruikers en rechten periodiek opnieuw bekeken te worden.
Wie heeft nog toegang tot Odoo? Welke medewerkers hebben administratorrechten? Wie kan gevoelige informatie exporteren? Welke externe gebruikers bestaan nog? Welke accounts worden nauwelijks meer gebruikt?
Odoo registreert bovendien informatie over apparaten waarmee gebruikers zijn ingelogd en biedt de mogelijkheid toegang van apparaten weer in te trekken.
Ook tweestapsverificatie zou wat mij betreft bij bedrijfssoftware met gevoelige gegevens eerder regel dan uitzondering moeten zijn.
Een goed wachtwoord is prettig. Een goed wachtwoord plus een tweede factor is beter.
En toen kwam AI
Hier wordt het beveiligingsvraagstuk de komende jaren interessanter.
AI verandert niet alleen hoe we informatie opzoeken of teksten schrijven. AI krijgt steeds meer toegang tot bedrijfsinformatie en bedrijfsprocessen.
Daar ontstaan twee heel verschillende risico’s.
Aan de ene kant gaat data vanuit Odoo naar AI.
Aan de andere kant komt AI juist Odoo binnen.
Beide vragen om beleid.
Wat gebeurt er wanneer medewerkers Odoo-data in een AI-tool stoppen?
Een medewerker wil snel iets analyseren en kopieert een export met klantgegevens naar een AI-tool.
Of een contract.
Een lijst met openstaande posten.
Een personeelsdocument.
Een e-mailwisseling met een klant.
Technisch is dat heel eenvoudig. Juist dat maakt het een risico.
Op het moment dat persoonsgegevens of vertrouwelijke bedrijfsinformatie naar een externe AI-dienst worden gestuurd, moet je weten wat die leverancier met de gegevens doet, waar die worden verwerkt, welke afspraken er gelden en of het gebruik past binnen je privacybeleid en de AVG.
“Het was alleen even voor ChatGPT” is geen categorie binnen de AVG.
Je hoeft AI daarom niet te verbieden. Dat zou wat mij betreft ook weinig realistisch zijn. Je moet alleen wel afspraken maken.
Welke AI-tools mogen medewerkers gebruiken? Welke gegevens mogen daarin worden verwerkt? Welke gegevens absoluut niet? Worden bedrijfsaccounts gebruikt of privéaccounts? Welke contractuele afspraken zijn er met de leverancier?
Dat zijn inmiddels gewone onderdelen van informatiebeveiliging.
Het wordt nog interessanter als AI toegang krijgt tot Odoo
De volgende stap is al bezig.
AI wordt niet alleen gebruikt om informatie te analyseren, maar krijgt toegang tot bedrijfssystemen om zelfstandig werkzaamheden uit te voeren.
Ook Odoo ontwikkelt in die richting. AI-agents kunnen binnen Odoo worden ingericht met specifieke instructies, informatiebronnen en tools waarmee ze taken uitvoeren.
Dat biedt enorme mogelijkheden.
Een agent kan bijvoorbeeld informatie verzamelen, gegevens verwerken of terugkerende handelingen uitvoeren. Maar zodra een AI-agent gegevens kan lezen of wijzigen, moet je dezelfde beveiligingsvragen stellen als bij een menselijke gebruiker.
Misschien zelfs strengere.
Welke klanten mag de agent zien?
Mag hij financiële informatie lezen?
Mag hij een offerte aanmaken?
Mag hij die offerte ook versturen?
Mag hij records wijzigen?
Mag hij gegevens verwijderen?
En wat gebeurt er als de agent een verkeerde conclusie trekt?
Een agent die alleen informatie uit een gecontroleerde dataset mag lezen, heeft een ander risicoprofiel dan een agent die via een API volledige lees-, schrijf- en verwijderrechten op je ERP-database heeft.
Dat klinkt vanzelfsprekend. Toch verwacht ik dat hier de komende jaren veel fouten mee gemaakt gaan worden.
AI maakt automatisering zo eenvoudig dat we het risico lopen eerst toegang te geven en pas later na te denken over de gevolgen.
Behandel een AI-agent als een gebruiker
Mijn uitgangspunt zou simpel zijn: behandel een AI-agent alsof het een medewerker is.
Geef hem een eigen identiteit en alleen toegang tot wat noodzakelijk is.
Odoo adviseert ook bij langdurige geautomatiseerde API-toegang om aparte gebruikers te gebruiken. Daarmee kunnen minimale rechten worden toegekend en blijven handelingen beter herleidbaar naar die specifieke technische gebruiker.
Een AI-agent die alleen verkoopinformatie nodig heeft, hoeft dus niet ook de boekhouding, personeelsinformatie en instellingen te kunnen benaderen.
En als een agent acties uitvoert die grote gevolgen kunnen hebben, kun je een menselijke controle inbouwen.
Laat AI gerust een conceptofferte opstellen. Maar moet een AI-agent zelfstandig een offerte van €250.000 versturen?
Laat een agent gerust gegevens controleren. Maar moet hij zelfstandig duizenden records kunnen verwijderen?
Technisch kunnen is iets anders dan verstandig inrichten.
Voor AI geldt daarom hetzelfde principe als voor gebruikers: zo weinig mogelijk rechten, zoveel als noodzakelijk.
En dan hebben we AI-gegenereerde code nog
Er is nog een ontwikkeling waar ik me minstens zoveel zorgen over maak.
Software ontwikkelen is door AI veel toegankelijker geworden.
Je beschrijft wat je wilt: een AI-tool genereert Python, XML en misschien zelfs een complete Odoo-app. Even installeren en klaar.
Of niet.
Je kunt tegenwoordig razendsnel zelf een Odoo-app maken en vervolgens je hele database om zeep helpen.
Dat klinkt misschien overdreven, maar de achterliggende zorg is serieus.
Code hoeft niet zichtbaar fout te zijn om onveilig te zijn.
Een app kan prima lijken te werken en ondertussen verkeerde toegangsrechten bevatten. Een methode kan via een externe call bereikbaar zijn terwijl daar onvoldoende controle op zit. Code kan security rules omzeilen. Een functie kan gegevens wijzigen waarvoor de gebruiker eigenlijk helemaal geen toegang zou moeten hebben.
Odoo waarschuwt ontwikkelaars zelf expliciet voor dit soort beveiligingsproblemen in maatwerkcode. Onder andere publieke methods, toegangsrechten en het verkeerd omgaan met de ORM kunnen beveiligingsproblemen veroorzaken.
AI verandert daar niets aan.
Sterker nog, AI vergroot het risico dat code wordt gebruikt door iemand die onvoldoende begrijpt wat de code precies doet.
De AI-tool geeft je binnen dertig seconden een overtuigend antwoord. Dat betekent niet dat je binnen dertig seconden een veilige bedrijfsapplicatie hebt.
AI-code blijft gewoon code
Daarom hanteren we voor AI-gegenereerde code exact hetzelfde uitgangspunt als voor code die door een ontwikkelaar wordt geschreven.
De code moet worden beoordeeld.
Hij moet in versiebeheer staan.
Hij moet getest worden.
En je test hem eerst in een gecontroleerde omgeving voordat hij naar productie gaat.
Bij securitygevoelige onderdelen kijk je expliciet naar toegangsrechten, record rules, externe toegang, API-calls, gebruik van elevated privileges en de consequenties van fouten.
AI kan een developer enorm versnellen. Daar ben ik absoluut voorstander van.
Maar AI vervangt daarmee niet de verantwoordelijkheid van de developer.
Dat sluit ook aan bij waarom we kritisch zijn op onbekende apps uit de Odoo App Store. Als je code toevoegt aan een systeem dat centraal staat in je bedrijf, wil je weten wie die code heeft gemaakt, wat hij doet en wie hem onderhoudt.
Of die code door een mens of door AI is geschreven, verandert daar weinig aan.
Odoo Studio vraagt om dezelfde discipline
Voor kleinere aanpassingen biedt Odoo zelf mogelijkheden via Studio. Ook daar geldt: omdat iets eenvoudig aanpasbaar is, betekent dat niet dat iedere aanpassing automatisch verstandig is.
Een extra veld maken is iets anders dan processen, automatiseringen en datamodellen ingrijpend wijzigen.
We hebben daar eerder uitgebreid over geschreven in waarom Odoo Studio niet de heilige graal is.
De gemene deler is steeds dezelfde.
De drempel om iets technisch te veranderen wordt lager. Dat is positief zolang kennis en controle niet tegelijkertijd verdwijnen.
Een back-up lost niet ieder beveiligingsprobleem op
Back-ups zijn belangrijk. Heel belangrijk zelfs.
Wanneer een foutieve import, slechte code of een verkeerde geautomatiseerde actie grote hoeveelheden data beschadigt, wil je kunnen herstellen.
Maar een back-up is het laatste vangnet.
Het is geen beveiligingsbeleid.
Wanneer iemand vertrouwelijke gegevens heeft geëxporteerd en meegenomen, helpt terugzetten van een back-up niet.
Wanneer persoonsgegevens naar een verkeerde externe dienst zijn gestuurd, kun je ze niet terughalen door de database van gisteren terug te zetten.
En wanneer een account maandenlang te veel toegang heeft gehad, weet je met een goede back-up nog steeds niet automatisch wat ermee is gebeurd.
Beveiliging bestaat daarom wat mij betreft uit drie onderdelen: voorkomen dat iets misgaat, kunnen zien wanneer iets misgaat en kunnen herstellen als het toch gebeurt.
Alle drie zijn nodig.
Goed Odoo-beheer begint met drie onderwerpen
Als we bij een organisatie naar de beveiliging van Odoo kijken, zou ik tegenwoordig drie gebieden expliciet meenemen.
Het eerste is gebruikers en rechten.
Bepaal rollen op basis van functies en processen. Geef niet iedereen voor het gemak brede rechten. Beperk administratorrechten en controleer periodiek wie toegang heeft. Activeer tweestapsverificatie waar dat passend is.
Het tweede is AI en data.
Maak duidelijke afspraken over welke AI-diensten gebruikt mogen worden en welke informatie daarin verwerkt mag worden. Zodra AI rechtstreeks toegang krijgt tot Odoo, behandel je die integratie of agent als een gebruiker. Met een eigen identiteit, beperkte rechten en waar nodig menselijke goedkeuring.
Het derde is maatwerk en code.
Of code nu geschreven is door een ervaren developer, afkomstig is uit een externe app of gegenereerd wordt door AI: beoordeel hem voordat hij toegang krijgt tot je belangrijkste bedrijfsdatabase.
Dat sluit aan bij onze bredere aanpak van een Odoo-implementatie. We proberen niet zoveel mogelijk techniek toe te voegen, maar juist gecontroleerd te bepalen wat nodig is, wie waarvoor verantwoordelijk is en hoe je wijzigingen test voordat gebruikers ervan afhankelijk worden.
Dus, hoe veilig is Odoo?
Odoo beschikt technisch over veel beveiligingsmaatregelen die je van moderne bedrijfssoftware mag verwachten.
Daarmee is de vraag alleen niet klaar.
Je kunt een uitstekend beveiligd platform alsnog behoorlijk onveilig gebruiken.
Geef iedere gebruiker administratorrechten en de toegangsbeveiliging stelt weinig meer voor. Laat medewerkers willekeurig bedrijfsgegevens naar AI-diensten sturen en je verliest grip op waar informatie terechtkomt. Geef een AI-agent onbeperkte toegang en een verkeerde actie kan ineens op enorme schaal worden uitgevoerd. Installeer zonder review gegenereerde maatwerkcode en je weet simpelweg niet voldoende wat je aan je database toevoegt.
Daarom maak ik me tegenwoordig minder zorgen over de vraag in welk datacenter Odoo staat.
Ik wil liever weten wie er bij de data kan, welke rechten die persoon heeft, welke AI-systemen meekijken en welke software we toegang geven tot de database.
Daar zit een steeds groter deel van je werkelijke beveiligingsrisico.
En het goede nieuws is: daar kun je zelf behoorlijk veel aan doen.
