De meeste SaaS-boekhoudplatformen werken op dezelfde manier: één toepassing, één database, alle klanten erin. Dat is efficiënt voor de leverancier — en het betekent dat alle klanten hetzelfde lot delen. Dit artikel legt uit hoe dat model werkt, hoe een inbreuk erin eruitziet en waarin FiscFort anders is gebouwd.
Hoe een typische gedeelde SaaS uw gegevens opslaat
In een multi-tenantplatform worden veel klanten ("tenants") bediend door dezelfde toepassing en heel vaak dezelfde database. Elke rij draagt een tenant-ID, en de toepassing voegt aan elke query "alleen deze tenant" toe. De scheiding tussen klanten is toepassingslogica: ze houdt stand zolang elke query, elk rapport, elke export en elke koppeling het filter correct toepast.
De richtlijnen van OWASP over multi-tenantbeveiliging zeggen het duidelijk: de architectuur is kostenefficiënt en de basis van moderne SaaS, maar één enkele kwetsbaarheid kan de gegevens van alle tenants blootleggen en een verkeerde configuratie kan gegevens over tenantgrenzen heen laten lekken (OWASP). Beveiligingstesters zeggen hetzelfde: op een platform met een gedeelde database kan één SQL-injectie of één verkeerd afgebakend filter alle tenants tegelijk blootstellen, omdat de isolatie alleen in de toepassingslaag bestaat en niet door de database zelf wordt afgedwongen (AppSecure).
Wat "gecompromitteerd" in elk model betekent
| Situatie | Gedeelde multi-tenant SaaS | Dedicated instanties van FiscFort |
|---|---|---|
| Waar klantgegevens staan | In tabellen die alle klanten delen, gescheiden door een tenant-ID | In een aparte database per klant, binnen de eigen Odoo-instantie van die klant |
| Wat de scheiding afdwingt | Toepassingscode die bij elke query correct moet zijn | De database, containers, netwerken en inloggegevens zelf |
| Een fout in het tenantfilter | Kan veel of alle klanten blootstellen | Beperkt tot de eigen instantie van die klant; er staan geen gegevens van andere klanten in |
| Gelekte database- of beheerdersgegevens | Opent de gedeelde database: alle klanten | Opent alleen de database van één klant; andere klanten gebruiken andere inloggegevens |
| Het account van één klant wordt overgenomen | De aanvaller begint binnen het gedeelde platform | De aanvaller blijft beperkt tot de eigen instantie van die klant |
| Hosting | Gedeeld cloudplatform | Dedicated, in de EU gehoste infrastructuur |
Hoe FiscFort is gebouwd
- Eén Odoo, één PostgreSQL-database en eigen opslag per klant. De scheiding is een eigenschap van de database, niet van een filter dat voor altijd correct moet blijven. De multi-bedrijvenmodus van Odoo zelf houdt alle bedrijven in één database en hangt af van recordregels die voor elk model correct moeten zijn; we hebben die juist daarom niet gebruikt.
- Eigen netwerk en firewallregels. De containers van elke klant draaien op een eigen vast netwerk, en de poorten van elke klant hebben eigen expliciete firewallregels.
- Eigen inloggegevens. Elke klant krijgt een eigen databasewachtwoord en eigen API-sleutels, voor die klant gegenereerd en nooit van een andere overgenomen.
- Eigen adressen en logins. De boekhouder bereikt de Odoo van elke klant via een eigen URL met een eigen login; de klant bereikt zijn eigen portaal met een eigen login. De databaselijst wordt nooit getoond — Odoo kiest de database van de klant op basis van de hostnaam en niets kan worden opgelijst.
Wie waar bij kan
- De klant logt in op zijn eigen portaal en ziet alleen zijn eigen instantie.
- De boekhouder logt apart in op de Odoo van elke klant — één URL en één login per klant — zodat toegang tot de ene klant nooit toegang tot een andere impliceert.
- FiscFort Operations heeft beheerderstoegang in elke instantie, omdat updates en regelgevingswijzigingen dat vereisen. Die toegang wordt gebruikt door geautomatiseerde agenten en workflows via een speciaal serviceaccount, niet door mensen die inloggen; de inloggegevens verschillen per server en worden versleuteld opgeslagen.
- Alle anderen hebben niets: de servers zelf hebben geen openbaar adres.
In Odoo toont elk record wie het heeft aangemaakt of het laatst heeft gewijzigd, en geboekte boekhoudposten kunnen alleen worden teruggedraaid, nooit bewerkt. Odoo registreert niet wie een record alleen heeft bekeken; wijzigingen worden gelogd.
De perimeter eromheen
Verkeer bereikt een klant alleen via Cloudflare (DDoS-bescherming en een webtoepassingsfirewall) en onze reverse-proxylaag via HTTPS. De servers hebben geen openbaar IP-adres, alleen het portaal en Odoo zijn bereikbaar, en beheertoegang is niet bereikbaar vanaf het internet. De andere lagen die op onze productpagina's staan — de bedrijfsfirewall, dubbele versleuteling op opslagniveau, redundante EU-verbindingen, realtime antivirusscans en URL-bewaking — komen daar bovenop. De servers worden dag en nacht bewaakt, en het besturingssysteem, Docker en leverancierssoftware worden wekelijks gepatcht, met een snapshot en terugdraaimogelijkheid.
Altijd actueel, zonder uw gegevens te verplaatsen
Dezelfde engine bedient Litouwen en België. Een vastgelegd proces en meerdere AI-agenten controleren de officiële bronnen van beide landen en werken elke vroege ochtend om 3 uur de Odoo van elke klant bij met de geldende regels. De update wijzigt de regels, niet de gegevens, en wordt binnen de eigen instantie van elke klant toegepast — de gegevens van de ene klant reizen nooit naar een andere.
Vragen die u aan elke SaaS-leverancier moet stellen
- Staan mijn gegevens in een database die ik met andere klanten deel?
- Wat voorkomt dat een fout in het tenantfilter iedereen blootstelt?
- Hoeveel klanten opent één gelekte inlogsleutel?
- Wie bij de leverancier kan mijn gegevens lezen, hoe wordt die toegang verleend en waar wordt ze gelogd?
- Waar wordt het platform gehost, en wie beheert het?
Gerelateerd
Gegevenslocatie in de EU voor de boekhoudgegevens van klanten, uitgelegd
Bronnen
- OWASP — Multi-Tenant Security Cheat Sheet
- AppSecure — penetratietesten voor multi-tenant SaaS-architecturen (2026)
De beschrijving van gedeelde SaaS-platformen is het gangbare patroon; individuele leveranciers verschillen.