Odoo Beveiliging & Toegangscontrole
Odoo's beveiligingsmodel is krachtiger dan de meeste teams beseffen — en vaker fout geconfigureerd dan men toegeeft. Goed gedaan geeft het fijnmazige controle per gebruiker, per record en per bedrijf. Slecht gedaan ziet de CEO de rapporten van de stagiair en de verkoper de leveranciersprijzen.
We worden regelmatig gevraagd om Odoo-beveiligingssetups te repareren die afgedreven zijn: te veel admins, custom groepen die niemand bezit, in paniek toegevoegde record rules die elkaar tegenspreken, multi-company lekken. Het patroon is hetzelfde — beveiliging werd niet ontworpen bij start, alleen toegevoegd toen er iets brak.
Deze gids is de referentie die we gebruiken bij het ontwerpen of auditen van beveiliging op een Odoo-instantie. Hij dekt de concepten (groepen, ACL's, record rules), het multi-company model, de audit trail, GDPR-essentials, en de operationele praktijken die beveiliging proper houden in de tijd.
Groepen, ACL's, record rules — de drie lagen
Odoo-beveiliging heeft drie lagen. Groepen (gebruiker → groepslidmaatschap) bepalen wat een gebruiker is. ACL's (groep → model) bepalen wat elke groep mag lezen, schrijven, aanmaken, verwijderen op elk model. Record rules (groep → record-subset) verfijnen tot specifieke records — alleen leads van je team, alleen aankopen van je afdeling.
De meeste beveiligingsincidenten die we onderzoeken gaan terug op twee patronen: te veel gebruikers in 'Settings' of 'Admin' (waardoor ACL's niet bijten), of tegenstrijdige record rules tussen groepen (een gebruiker erft 'Eigen alleen' én 'Alles', OR-logica geeft alles). Discipline op groepslidmaatschap is de helft van de strijd.
- Drie lagen: groepen (wie), ACL's (mag wat op model), record rules (welke records)
- Discipline op lidmaatschap = halve strijd — te veel admins = geen beveiliging
- Record rules in OR-logica tussen groepen — tegenstrijdigheden geven breedste toegang
- Standaard Odoo-groepen (User/Manager/Settings) dekken 80% van de noden
- Custom groepen zeldzaam en goed gedocumenteerd — elk voegt onderhoudskost toe
Multi-company isolatie — de val waar veel groepen in trappen
Multi-company in Odoo kan isolatie betekenen (data per bedrijf onzichtbaar voor de andere) of delen (groepsniveau-data overal zichtbaar). De default neigt naar delen, wat past bij de meeste groepen maar info kan lekken die je niet bedoelde — financiële cijfers van bedrijf A zichtbaar voor een gebruiker van bedrijf B.
We doen altijd een 'multi-company audit' op bestaande setups: inloggen als gebruiker van elk bedrijf, menu's doorlopen, verifiëren wat zichtbaar is. Verrassingen komen vaak voor. De fix is meestal het aantrekken van company-aware record rules en een review van welke modellen company-isolatie native ondersteunen.
- Multi-company kan isolatie of delen zijn — default neigt naar delen
- Sommige modellen (partners, producten) gedeeld; andere (facturen, verkoop) per bedrijf
- Auditen door in te loggen als gebruiker van elk bedrijf en menu's te doorlopen
- Record rules per bedrijf aantrekken waar lekken gevonden
- Inter-company transacties hebben eigen setup — gedeeltelijke zichtbaarheid by design
Audit trail en de vraag 'wie deed wat'
Odoo's mail-thread vangt de meeste gebruikersacties op records — wie maakte aan, wie wijzigde, wie postte welk bericht. Voor diepere audit (wie wijzigde welk veld wanneer) is een audit-log module (OCA of betaald) nodig. Voor compliance-gevoelige sectoren (finance, gezondheidszorg, gereguleerde industrie) is dit niet optioneel.
De audit trail is alleen nuttig als hij geconsulteerd wordt. We zetten een standaard review-cadans op met klanten — maandelijkse blik op meest-gewijzigde records, meest-actieve gebruikers, ongebruikelijke patronen. Het vangt issues vroeg en demonstreert governance aan auditors.
- Mail thread vangt meeste gebruikersacties native — basis audit out of the box
- Veld-niveau audit vraagt module (OCA of betaald) — niet optioneel in gereguleerde sector
- Audit log enkel nuttig indien herzien — maandelijkse cadans vangt issues vroeg
- Login logs en sessie-tracking beschikbaar via standaard Odoo admin tools
- Externe SIEM-integratie mogelijk via Odoo's logs en webhooks
Authenticatie, SSO, MFA — de moderne baseline
Native Odoo-auth is OK maar de moderne baseline is single sign-on (SSO) via SAML of OAuth, idealiter met MFA afgedwongen. Odoo ondersteunt beide native of via modules. Voor Microsoft-centrische Belgische KMO's is Azure AD SSO de meest gangbare setup die we uitrollen.
MFA moet verplicht zijn voor wie admin- of manager-rechten heeft, idealiter voor alle gebruikers. Wachtwoord-policies, sessie-timeouts en IP-whitelisting waar gepast voltooien de baseline. Niets exotisch — het is standaard voor elke business-applicatie in 2026.
- Native auth OK voor kleine teams — SSO + MFA is moderne baseline
- SAML en OAuth ondersteund — Azure AD SSO is typische Belgische KMO-setup
- MFA verplicht voor admins en managers minimum — alle gebruikers idealiter
- Wachtwoord-policies, sessie-timeouts, IP-whitelisting voltooien de baseline
- Integreer Odoo-logs in je SIEM indien aanwezig — webhooks maken het makkelijk
GDPR-essentials — wat Odoo geeft en wat je moet toevoegen
Odoo geeft het technische fundament voor GDPR: persoonsdata-inventaris (Contacten, HR, partners), audit trail, encryptie in transit, back-ups, verwijdering van persoonsdata via standaard of custom procedures. Wat het niet geeft: het beleid, het toestemmingsbeheer, de gedocumenteerde retentieregels.
We helpen klanten met de GDPR-Odoo overlap: data subject access requests (export en deletion), retentieschema's (auto-archiveren na X jaar), toestemmingtracking voor marketing, en data-processing agreements met Odoo / Odoo.sh / hosting. Het technische deel is oplosbaar; het procesdeel vraagt eigenaarschap in je organisatie.
- Odoo geeft technisch fundament — data-inventaris, audit trail, encryptie, back-ups
- Data subject access requests (export, deletion) implementeerbaar maar vragen procedure
- Retentieschema's via auto-archief jobs — expliciet per data-categorie implementeren
- Toestemmingtracking voor marketing — module-ondersteund, vraagt configuratie
- DPA met Odoo / Odoo.sh / hosting provider verplicht — tekenen vóór go-live
Beveiligingsfouten die we blijven zien in audits
Dit zijn de patronen die echte blootstelling produceren — soms regulatoir, soms commercieel.
- Te veel gebruikers in admin/settings — ACL's bijten niet.
- Custom groepen door de jaren toegevoegd zonder doc — niemand weet wat ze geven.
- Multi-company verondersteld geïsoleerd terwijl het niet is — financieel lek tussen bedrijven.
- Geen MFA op admin-accounts — één wachtwoord-compromittering = volledige toegang.
- Audit trail aangezet maar nooit herzien — alleen nuttig na incident, niet ervoor.
Metrics die bewijzen dat je Odoo-beveiligingshouding gezond is
Per kwartaal opgevolgd met IT en DPO. Stabiele metrics = stabiele houding.
- Aantal admins <5% van gebruikers — minimum-privilege werkt.
- MFA op 100% afgedwongen voor admins/managers, >80% voor alle gebruikers.
- Custom groepen geïnventariseerd met gedocumenteerd doel — nul wees-groepen.
- Multi-company audit-walkthrough minstens jaarlijks zonder lekken gevonden.
- Audit-log review-cadans gerespecteerd (typisch maandelijks) met gedocumenteerde bevindingen.
Hoe we Odoo-beveiliging ontwerpen en auditen bij Flydoo
Op nieuwe implementaties ontwerpen we beveiliging vanaf dag één: gebruikersmatrix per rol, groep-overerving, ACL-design, record rules. Multi-company setups krijgen een expliciet isolatieplan. SSO en MFA worden geconfigureerd vóór go-live, niet erna.
Op bestaande setups doen we een beveiligingsaudit: review groepen, ACL's, record rules, multi-company-config, MFA-dekking, audit-log review. Output is een geprioriteerd remediation-plan. De meeste audits brengen één à twee echte blootstellingen plus enkele cleanup-items aan het licht.
- Gebruikersmatrix per rol ontworpen vóór configuratie start
- Custom groepen beperkt en gedocumenteerd; standaard groepen geprefereerd
- Multi-company isolatieplan expliciet, geaudit door menu's te doorlopen als test-gebruikers
- SSO en MFA geconfigureerd vóór go-live, verplicht voor admins en managers
- Audit-log review-cadans afgesproken met DPO en finance — maandelijks minimum
Praktische beveiligingschecklist voor een Odoo-instantie
Loop deze lijst af met IT, security officer en DPO. Meestendeels afgevinkt = gezonde houding.
- Gebruikersmatrix per rol gedocumenteerd en toegepast
- Admins <5% van totaal — minimum-privilege gerespecteerd
- Custom groepen geïnventariseerd met gedocumenteerd doel
- Multi-company isolatie geaudit door menu's te doorlopen als test-gebruikers
- MFA afgedwongen voor alle admins en managers, idealiter alle gebruikers
- SSO geconfigureerd (Azure AD, Okta, Google) waar van toepassing
- Audit-log review-cadans afgesproken en gedocumenteerd
- DPA getekend met Odoo / Odoo.sh / hosting provider
Belangrijkste inzichten
- Odoo-beveiliging heeft drie lagen: groepen, ACL's, record rules — ontwerp ze, schroef ze er niet op
- Discipline op groepslidmaatschap (vooral admin) is de helft van de strijd
- Multi-company default neigt naar delen — auditeer expliciet om te bevestigen wat lekt
- MFA is verplicht voor admins en managers in 2026 — geen uitzonderingen
- GDPR: Odoo geeft de tools, jij moet beleid en review-cadans bezitten
- Audit logs zijn alleen nuttig als ze herzien worden — maandelijkse cadans vangt issues vroeg
Veelgestelde vragen
Hoe granulair kunnen Odoo's record rules worden?
Zeer. Je kunt zichtbaarheid beperken tot records van de gebruiker, hun team, hun bedrijf, elke veldcombinatie. We hebben regels gebouwd zoals 'sales managers zien alle leads in hun regio behalve die getagd vertrouwelijk'. Het risico is niet 'Odoo kan het niet' — het is 'we bouwden tien gelaagde regels en niemand snapt het resultaat nog'. Hou regels minimaal en gedocumenteerd.
Is Odoo's multi-company sterk genoeg voor een holding met dochters?
Voor de meeste holdings, ja. Elke dochter als bedrijf, isolatieregels aangetrokken, finance per bedrijf. Voor een gereguleerde holding (bank, verzekering) met strikte scheidingsvereisten kunnen extra controles en mogelijk aparte Odoo-databases nodig zijn. We beoordelen geval per geval naargelang je regelgevend kader.
Ondersteunt Odoo SAML / OAuth / Azure AD SSO?
Ja — SAML en OAuth native in Enterprise; Community heeft modules. Azure AD is de meest gangbare SSO die we configureren voor Belgische KMO's. We koppelen het meestal met MFA afgedwongen op Azure AD-niveau, dus de Odoo-ervaring is 'klik knop → binnen', en de beveiligingsdrempel ligt bij de IdP.
Wat met GDPR-retentie voor Odoo?
Odoo dwingt retentie zelf niet af — jij beslist. We configureren typisch auto-archief jobs die records naar gearchiveerd zetten na een gedefinieerde periode (bv. 7 jaar voor finance, 3 jaar voor marketing-leads). Hard-delete van persoonsdata wordt geïmplementeerd via DSAR-procedure. De technische mechanismen zijn er; het beleid is aan jou.
Hoe auditen we een bestaande Odoo op beveiligingsissues?
Begin met vijf zaken: (1) lijst alle gebruikers met admin- of settings-rechten, (2) inventariseer alle custom groepen en wat ze geven, (3) doorloop multi-company menu's als test-gebruiker van elk bedrijf, (4) check MFA-dekking, (5) verifieer dat de audit log werkelijk herzien wordt. Vanaf daar duurt onze standaard beveiligingsaudit 2-5 dagen voor een KMO-instantie en levert een geprioriteerd remediation-plan op.
Hulp nodig om dit toe te passen op uw eigen context? We praten er graag over.