Ga naar hoofdinhoud

Beveiligingsoverzicht

Versie 0.6, bijgewerkt op 30 oktober 2026 voor wat sinds 16 oktober is uitgeleverd.

Voor wie: de security officer of inkoper van een klant die wil weten hoe zijn gegevens beschermd zijn.

1 · In het kort​

BTWB is een werkomgeving voor consultants waarin per klant een werkruimte (canvas) wordt opgebouwd, met een dossier van aangeleverde documenten en AI-ondersteuning. Alle gegevens staan in de Europese Unie (Frankfurt). Toegang is uitsluitend op uitnodiging. Een gebruiker is lid van een of meer organisaties en ziet alleen de gegevens van die organisaties, en van de werkruimten waaraan die gebruiker deelneemt; die scheiding wordt niet in de schermen maar in de database afgedwongen, zodat een fout in een scherm haar niet kan doorbreken. Belita, als beheerder van het platform, heeft geen toegang tot de inhoud van de werkruimten van een klant, tenzij de klant daar zelf tijdelijk toegang voor geeft.

Dit overzicht volgt uit het informatiebeveiligingsbeleid van Belita en wordt bij elke uitlevering bijgewerkt.

2 · Toegang en identiteit​

  • Alleen op uitnodiging. Een account ontstaat alleen uit een uitnodiging die vooraf is vastgelegd: voor welk e-mailadres, in welke organisatie, met welke rol en door wie. De database weigert elke aanmelding zonder zo'n uitnodiging; er ontstaat dan geen account, ook geen account zonder rechten. Zelfregistratie bestaat niet, niet in de applicatie en niet bij de authenticatieleverancier, en een nachtelijke controle bewaakt dat laatste. Uitnodigen doet de beheerder van de organisatie, voor zijn eigen organisatie; Belita nodigt alleen de eerste beheerder van een nieuwe organisatie uit, en daarna alleen als een organisatie geen actieve beheerder meer heeft. Belita kan per organisatie instellen binnen welke e-maildomeinen en tot welk aantal leden er mag worden uitgenodigd; een beheerder van de organisatie kan die grenzen niet zelf verruimen.
  • Eén account, meer organisaties. Wie al een account heeft, kan in meerdere organisaties werken. De uitnodiging staat na het inloggen klaar en het lidmaatschap ontstaat pas als de gebruiker haar accepteert; heeft iemand meer dan één organisatie, dan kiest die in de kop met welke organisatie wordt gewerkt.
  • Inloggen gaat met e-mailadres en wachtwoord. Een wachtwoord telt minimaal tien tekens en wordt bij het kiezen gecontroleerd tegen lijsten van gelekte wachtwoorden; een bekend gelekt wachtwoord wordt geweigerd. Lengte en lekcontrole beschermen beter dan verplichte leestekens.
  • Tweede factor. Beheerders kunnen inloggen met een tweede factor via een authenticator-app (tijdcode), met een tweede apparaat als reserve. De tweede factor wordt per organisatie ingeschakeld; daarna moet elke beheerder van die organisatie hem instellen en weigert de beheerfunctie elke beheerhandeling zonder tweede stap. De platformbeheerder kan per organisatie ook eisen dat alle leden en deelnemers een tweede factor gebruiken; die schakelaar staat standaard uit. Zolang hij uit staat, merken gewone gebruikers er niets van. Staat hij aan, dan ziet wie alleen een wachtwoord heeft de werkruimten van die organisatie niet meer. Bij een verloren apparaat zet de beheerder van de organisatie, of Belita, de factor terug.
  • Sessies. Een sessie wordt op de achtergrond ververst en sluit uiterlijk na dertig dagen, en na zeven dagen zonder gebruik. Meer dan één actieve sessie per gebruiker is toegestaan, zodat een consultant op laptop en tablet kan werken.
  • Rollen op drie niveaus. Belita beheert het platform als platformbeheerder. In een organisatie is iemand beheerder of lid, en wie in meerdere organisaties werkt heeft in elke een eigen rol. Op een werkruimte is iemand eigenaar, bewerker of lezer: de eigenaar beheert wie meewerkt, de bewerker wijzigt de inhoud, de lezer kijkt mee en mag rapporten downloaden. Een beheerder van een organisatie nodigt uit, beëindigt lidmaatschappen en wijzigt rollen, alleen binnen de eigen organisatie, en ziet en bewerkt elke werkruimte van die organisatie. Een lezer kan geen AI-functie starten, ook niet buiten het scherm om: de server weigert dat en de organisatie betaalt er niets voor. Een beheerder kan zichzelf of een ander nooit tot platformbeheerder maken. Dat is in de database afgedwongen, niet alleen in het scherm.
  • Wat Belita kan en niet kan. De platformbeheerder kan tijdelijk in de omgeving van een organisatie werken om instellingen, gebruikers en budgetten te beheren; zolang dat zo is staat er een niet-wegklikbare balk in beeld. Die wissel geeft geen toegang tot de inhoud van de werkruimten van die organisatie: geen toegangsregel op gegevens van een werkruimte kent de platformbeheerder. Wil een klant dat Belita in een werkruimte meekijkt, bijvoorbeeld bij een vraag over de inhoud, dan geeft de klant daarvoor zelf toegang: de eigenaar van de werkruimte of een beheerder van de organisatie kiest in het deelnemersscherm «Toegang voor ondersteuning», met de rol (lezer of bewerker) en de duur (24 uur, 3 dagen of 7 dagen). De toegang vervalt vanzelf, kan eerder worden ingetrokken, en staat in de deelnemerslijst als «Belita», zonder persoonlijke adressen.

3 · Scheiding tussen organisaties​

  • In de database, niet in het scherm. Elke tabel met klantgegevens draagt toegangsregels (row level security): een rij is alleen zichtbaar en wijzigbaar voor wie aan de bijbehorende werkruimte deelneemt, naar rol, en voor de beheerder van de organisatie waar die werkruimte bij hoort. Wie je bent en waartoe je toegang hebt, bepaalt de server; het verzoek uit de browser heeft daar geen invloed op.
  • Per werkruimte een eigen toegang. Op elke werkruimte staat wie eigenaar, bewerker of lezer is. Een deelnemer die geen lid van de organisatie is, bijvoorbeeld een consultant van een bureau, ziet alleen die ene werkruimte en leest de instellingen van de organisatie niet (zoals maxima en beveiligingsinstellingen); alleen naam en huisstijl zijn zichtbaar.
  • Een bezoeker die niet is ingelogd kan precies één ding lezen: de teksten en instellingen die het inlogscherm nodig heeft. Alles daarbuiten is afgesloten, en een controle die na elke databasewijziging en elke nacht draait, meldt het zodra dat verandert.
  • Getoetst, niet beloofd. Een eigen toetsreeks draait bij elke wijziging die de database raakt en elke nacht tegen een echte database: een gebruiker van organisatie A probeert gegevens van organisatie B te lezen en te schrijven, en de toets is pas groen als dat mislukt. Honderdvierendertig reeksen bewaken de scheiding en de toegangsregels, en de automatische tests draaien uitsluitend in een eigen organisatie, Platform, waar hun testcanvassen voor mensen alleen-lezen zijn.
  • Nieuwe tabellen krijgen de regels vanzelf. Een controle eist dat elke tabel minstens één regel heeft die een organisatie- of werkruimtegrens noemt, of op een korte lijst van gemotiveerde uitzonderingen staat (platformbeheer, algemene referentiegegevens, tabellen waar alleen de server bij kan). Die lijst kan alleen korter worden, en een poort weigert elke nieuwe regel in een losse vorm.
  • De werkruimte hoort bij dezelfde organisatie als de rij. Op alle tabellen met gegevens van een werkruimte toetst de regel niet alleen dat de rij bij de organisatie van de schrijver hoort, maar ook dat de werkruimte van die rij erbij hoort. Een beheerder van een organisatie kan dus geen eigen rij aan een werkruimte van een andere organisatie hangen. Een poort weigert elke nieuwe regel die dat niet toetst, en bewaakt dat er geen uitzonderingen zijn.

4 · Waar de gegevens staan en hoe ze beschermd zijn​

  • Locatie. Database, bestanden en authenticatie bij Supabase in Frankfurt; de applicatie en de serverfuncties bij Vercel in Frankfurt. Beide staan vast in onze configuratie.
  • Onderweg. Alle verkeer loopt over HTTPS. Twee beveiligingskoppen zetten we zelf: «alleen HTTPS» (HSTS) en «niet in te bouwen in een andere site».
  • In rust. De opslag is versleuteld met de standaardvoorziening van de leverancier. De scheiding tussen organisaties in de database is de eerste laag.
  • AI-verwerking. Dossierinhoud die aan een AI-model wordt voorgelegd, gaat rechtstreeks naar de modelleverancier. Die gebruikt haar niet voor training en bewaart haar dertig dagen voor misbruik- en veiligheidscontrole; daarna wordt ze verwijderd. Inhoud die de leverancier als misbruik markeert, kan zij langer bewaren. In de standaardstand kan die verwerking buiten de EU plaatsvinden. Op verzoek van een klant zet Belita het hele platform op EU-verwerking van de tekstgeneratie: dezelfde modellen, via aanbieders die in de EU verwerken, zonder bewaring van de inhoud; kan een aanroep die eis niet waarmaken, dan weigert het platform de aanroep in plaats van uit te wijken. Het doorzoekbaar maken van documenten loopt ook dan rechtstreeks naar OpenAI, buiten de EU. Wat er precies heen gaat, wat terugkomt en wat niet wordt bewaard, staat in de AI-verklaring (B7). De consultant keurt elk AI-voorstel goed vóór het in de werkruimte landt.
  • Geheimen. Sleutels van leveranciers staan uitsluitend in de afgeschermde omgeving van de hostingpartij en van de bouwstraat, nooit in de code.

5 · Back-up en herstel​

  • Wekelijkse kopie van de productiedatabase, acht weken bewaard, met minstens één kopie buiten de leverancier en buiten de code-opslag. Vóór elke ingreep die gegevens kan raken wordt eerst een extra kopie gemaakt. De leverancier houdt daarnaast zijn eigen herstelpunten bij.
  • Herstel is getest. Een productiekopie wordt op een aparte omgeving teruggezet en vergeleken op structuur en aantallen; de laatste geslaagde hersteltest was in juli 2026.
  • Ouderdom bewaakt. Elke nacht controleert een script of de laatste kopie niet ouder is dan tien dagen; is dat wel zo, dan staat het de volgende ochtend op het interne statusbord.

6 · Logging en audit​

  • AI-gebruik wordt per aanroep geteld: model, aantal tokens, kosten, duur. De inhoud van vraag en antwoord wordt daarbij niet opgeslagen.
  • Foutmeldingen van de server gaan in synthetische vorm naar een foutenmonitor: code en soort, nooit de tekst van de fout en nooit klantinhoud.
  • Aanrakingen van productie door Belita (databasecommando's, uitleveringen) staan in een alleen-toevoegen-logboek: soort commando, geraakte tabellen en een vingerafdruk, nooit de waarden. Dat logboek is niet ongemerkt te wijzigen.
  • Toegang tot het platform wordt door de authenticatieleverancier vastgelegd in een auditlog in de databank: elke inlog, uitlog, sessievernieuwing, wachtwoordwijziging en tweede-factorgebeurtenis, met tijdstip, gebruiker en IP-adres. Dat log is niet in de applicatie zichtbaar; Belita kan het op verzoek per organisatie uitleveren, bijvoorbeeld bij een incident.
  • Beheerhandelingen op toegang (de tweede factor inschakelen, een factor terugzetten) worden zonder inhoud in het serverlogboek vastgelegd. Elke wijziging in lidmaatschap en in deelname aan een werkruimte, ook het geven en intrekken van toegang voor ondersteuning, wordt vastgelegd in een eigen gebeurtenistabel: wat er veranderde, voor wie, door wie en wanneer.
  • Herkomst van AI-voorstellen. AI-voorstellen dragen hun herkomst: het brondocument, het werkblad of de aanduiding algemene kennis.

7 · Wijzigingsbeheer​

  • Elke wijziging gaat via een pull request; rechtstreeks naar productie of naar de testomgeving schrijven is technisch geblokkeerd, net als het verwijderen of overschrijven van die takken. Een wijziging komt eerst op de testomgeving; productie verandert alleen door een uitlevering, en die doet alleen de eigenaar van Belita.
  • Vier verplichte controles vóór samenvoegen: de volledige testreeks van de applicatie, inclusief de bewakingen die vastleggen dat afgesproken regels niet stil terugdraaien; de scheidingstoets tussen organisaties (§3); een bewijs dat die bewakingen zelf rood kunnen worden; en een controle op bouwbrekende fouten. Een wijziging moet bovendien op de laatste stand van de doeltak staan.
  • Twee onafhankelijke ogen. Elke inhoudelijke wijziging wordt vóór samenvoegen door een onafhankelijke reviewer en een onafhankelijke tester beoordeeld; de pull request kan pas worden samengevoegd nadat die twee hebben gerapporteerd.
  • Databasewijzigingen gaan eerst naar de testomgeving, worden daar bewezen, en pas dan naar productie; een controle na elke stap bewijst dat elke wijziging daadwerkelijk is aangekomen.
  • Na elke uitrol draait een rooktest, en op de testomgeving een diepe rooktest: inloggen, elk van de acht werkbladen openen, één generatie met het echte model, één rapport aanmaken en downloaden. Elke nacht loopt bovendien een volledige reis door de applicatie tegen de testomgeving.

8 · Kwetsbaarheden en risico's​

  • Nachtelijke scan op kwetsbare afhankelijkheden. Elke nacht controleert een scan de pakketten waarop de applicatie draait op bekende kwetsbaarheden. Een kwetsbaarheid van hoge of kritieke ernst in een pakket dat draait kleurt de controle rood en leidt tot een melding bij Belita; in bouwgereedschap geeft ze een waarschuwing. Een scan die niets kon lezen telt niet als groen. Daarnaast stelt een geautomatiseerde pakketbeheerder wekelijks gebundelde updates voor.
  • Een onafhankelijke penetratietest voeren we uit op verzoek van een klant.
  • Risico's houden we bij in een intern risicolog, elk met een eigenaar en een voorwaarde voor opvolging.

9 · Storingen en incidenten​

  • Bij een onverwachte fout ziet de gebruiker een algemene melding met een herlaadknop; er lekt geen technische informatie naar het scherm.