Voor privacy, informatiebeveiliging en IT-beheer Referentie
Databeamer voor security officers en CISO's
Het architectuurmodel, de cryptografie en het sleutelbeheer, identiteit en toegang, de bewuste uitzonderingen op zero-knowledge, audittrail en incidentafhandeling, hosting en continuïteit, het ontwikkelproces en de normen, en wat je organisatie zelf controleert, inricht en afstemt.
Overzicht voor security officers, CISO's, auditors en anderen die Databeamer vanuit veiligheid, techniek en compliance beoordelen voordat hun organisatie ermee gaat werken. Het legt het architectuurmodel uit, wat dat betekent voor de beoordeling en wat de organisatie zelf moet controleren, inrichten en afstemmen.
Voor de privacykant (persoonsgegevens, bewaartermijnen, rechten van betrokkenen, DPIA) verwijzen we naar Databeamer voor FG's en privacy officers en de DPIA-ondersteuning. De privacyverklaring, de verwerkersovereenkomst (DPA), het beveiligingsbeleid en de algemene voorwaarden staan op de juridische pagina. De cryptografische details per functie staan in de ingeklapte blokken Beveiligingsdetails door de hele documentatie; zie hoe je die leest.
1. Het architectuurmodel in het kort #
Databeamer is een Nederlandse SaaS-dienst van Full Join B.V. voor veilige communicatie, bestandsuitwisseling en samenwerking, met zero-knowledge-versleuteling en hosting binnen de EU. De dienst is ontwikkeld om vertrouwelijke informatie te kunnen uitwisselen en gezamenlijk te gebruiken, ook wanneer mensen uit verschillende organisaties samenwerken.
De belangrijkste uitgangspunten:
- Versleuteling aan de kant van de gebruiker. Bestanden, berichten, antwoorden en logboekinhoud worden op het apparaat van de gebruiker versleuteld en bij de ontvanger ontsleuteld. De server bewaart en vervoert alleen versleutelde gegevens.
- Sleutelbeheer bij de gebruiker. De hoofdsleutel wordt op het apparaat gegenereerd, nooit opgeslagen en 2-van-3 gesplitst. Databeamer heeft één deel en kan inhoud niet zelfstandig ontsleutelen of sleutels namens gebruikers herstellen.
- Hybride post-quantumcryptografie. Klassieke cryptografie wordt gecombineerd met post-quantumcryptografie (PQC) voor sleuteluitwisseling en digitale handtekeningen. Een aanvaller moet beide algoritmen breken.
- Afgeschermde toegang per groep. Elke gebruiker is een groep van één; gedeelde groepen gebruiken hetzelfde sleutelmodel. Beheerrechten op organisatieniveau geven niet automatisch toegang tot de inhoud van iedere groep.
- Controleerbare gebeurtenissen. Wijzigingen worden vastgelegd in een audittrail met gebeurtenissen die het apparaat van de gebruiker ondertekent, verzegeld in aaneengeschakelde epochs.
Wat betekent dit voor de beoordeling? Een compromittering van de serverkant levert in beginsel versleutelde gegevens op, geen leesbare inhoud. Het zwaartepunt van het risico ligt daardoor deels bij de eindpunten en bij het beheer van sleutels, apparaten en groepen. Dat zijn onderwerpen waar de eigen organisatie invloed op heeft en die zij dus moet inrichten. Dat betekent niet dat de serverzijde vanzelf buiten beschouwing kan blijven: zie paragraaf 4 voor de uitzondering en paragraaf 6 voor de metadata.
Zie Technologie voor de volledige cryptografische stack met de bijbehorende RFC's en NIST-standaarden.
2. Cryptografie en sleutelbeheer #
De technologiepagina beschrijft de cryptografische stack met de bijbehorende RFC's en NIST-standaarden en houdt bij wat nog openstaat. Dit overzicht volgt die pagina en voegt toe wat de keuzes betekenen voor de beoordeling; het gaat er niet verder op in.
| Onderwerp | Wat is het? | Toelichting |
|---|---|---|
| Symmetrische versleuteling | ChaCha20-Poly1305 (RFC 8439, AEAD) voor de inhoud. Per context domeingescheiden AAD, zodat ciphertext uit de ene context niet in een andere bruikbaar is. | Constant-time, dus bestand tegen timing-aanvallen. Blok-nonces worden uit de bestandssleutel afgeleid; dezelfde inhoud in twee bestanden versleutelt dus anders en is niet over bestanden heen te matchen. |
| Sleuteluitwisseling | Hybride X25519 (RFC 7748) + ML-KEM-768 (NIST FIPS 203), gecombineerd via HKDF-SHA512, om sleutels voor ontvangers te versleutelen. | Beide algoritmen zijn gestandaardiseerd; een aanvaller moet ze allebei breken. |
| Digitale handtekeningen | Hybride Ed25519 (RFC 8032) + ML-DSA-65 (NIST FIPS 204) op elke groepssleutelset bij aanmaak en rotatie en op elke auditentry. | Het verifiëren van de handtekeningen op groepssleutels in de client bij elk laden is nog openstaand werk; tot die tijd worden ze opgeslagen, niet afgedwongen. De technologiepagina houdt dit onder "Open werk" bij. |
| Hashing en content-addressing | BLAKE3 over elk versleuteld blok als adres (deduplicatie van identieke ciphertext); SHA-256 van de platte inhoud, door de client gemeld voor de malwarecontrole. | |
| Sleutelafleiding | HKDF-SHA512 (RFC 5869) met domeingescheiden info-strings voor werksleutels; Argon2id (RFC 9106, 64 MiB geheugen, 3 iteraties) voor de pincode en voor de wachtwoordzin van gasten. | |
| Sleutelgeneratie | Op het apparaat van de gebruiker bij het aanmaken van het account; willekeur uit de OS-CSPRNG (in de browser de Web Crypto API). | Zie Je account aanmaken. |
| Sleutelbewaring en herstel | Pedersen verifiable secret sharing (Ristretto255), drempel 2 van 3. Het apparaat-deel wordt ontgrendeld met de pincode of een passkey die het apparaat nooit verlaat; het server-deel wordt vrijgegeven na inloggen; het herstel-deel is alleen met de herstelzin van 24 woorden te openen. Eén deel zegt niets over de sleutel en elk deel is verifieerbaar. | De hoofdsleutel wordt nooit opgeslagen: zij wordt tijdelijk opgebouwd om de werksleutels af te leiden en daarna uit het geheugen gewist. Zie Herstelzin en shares en Apparaten en ontgrendelen. |
| Groepssleutels | Per groep een sleutelset met versies, bij aanmaak en bij elke rotatie ondertekend door het apparaat van de beheerder. Bij verwijdering van een lid volgt een nieuwe versie. | Zie Groepen. |
| Nieuw apparaat koppelen | SPAKE2 (RFC 9382) over een korte eenmalige code, met hybride ECIES voor het transcript: het nieuwe apparaat krijgt zijn deel van een apparaat dat je al hebt; de server geeft alleen ciphertext door. | Zie Een tweede apparaat instellen. |
| Implementatie | Server, cryptografiebibliotheken en browserversie (WebAssembly) zijn in Rust geschreven; dezelfde code draait aan beide kanten. unsafe is in de eigen code op compilerniveau uitgeschakeld. Geen zelf ontworpen algoritmen; alleen gestandaardiseerde, breed beoordeelde primitieven. De architectuur is crypto-agiel: primitieven zitten achter strikte interfaces, zodat algoritmen vervangen kunnen worden. |
Wijzigingen aan cryptografische code vereisen de dubbele goedkeuring van de lead engineer én de CISO (zie paragraaf 8). |
| Externe toetsing van de cryptografie | Er is geen afzonderlijke, gepubliceerde onafhankelijke review van het cryptografisch ontwerp. De gebruikte primitieven zijn gestandaardiseerd; de broncode is niet openbaar. | Penetratietests zie paragraaf 8; inzagemogelijkheden zijn bespreekbaar via compliance@databeamer.io. |
Het sleutelmodel #
Voor de beoordeling volstaat het model. Uit de hoofdsleutel van een gebruiker worden diens werksleutels afgeleid. Elke groep, ook de persoonlijke groep van één, heeft een eigen sleutelset; inhoud wordt versleuteld onder sleutels die alleen leden van die groep kunnen openen, en de server bewaart uitsluitend versleutelde kopieën. Gasten krijgen nooit een groepssleutel, maar alleen toegang tot wat met hen is gedeeld (paragraaf 4). Hoe dit per functie uitwerkt, bespreken we op verzoek via compliance@databeamer.io.
3. Identiteit, toegang en rollen #
Databeamer scheidt authenticatie van toegang tot versleutelde inhoud. Inloggen bewijst wie de gebruiker is, maar levert op zichzelf geen sleutels op. Een gecompromitteerde identity provider levert daardoor op zichzelf geen leesbare gegevens op.
| Onderdeel | Beschrijving |
|---|---|
| Authenticatie | Inloggen loopt via de identiteitsdienst van Databeamer (door Full Join zelf gehost op de eigen infrastructuur; geen externe identiteitsleverancier). Multifactor-authenticatie is verplicht voor ieder account: na het wachtwoord een authenticator-app (TOTP) of een apparaatgebonden bevestiging. Het geheim van de tweede factor staat bij de identiteitsdienst, niet in de app. Bij SSO geldt het authenticatiebeleid van de eigen identity provider. |
| Ontgrendeling van sleutels | Na het inloggen is op elk apparaat afzonderlijk een pincode of passkey nodig om de device share te openen; pas dan wordt de hoofdsleutel in het geheugen opgebouwd. Een vergrendelde pincode levert een beveiligingsmelding op. |
| Single sign-on | OpenID Connect of SAML 2.0, in te stellen door de organisatie-eigenaar (afhankelijk van het abonnement), met de optie om inloggen met wachtwoord uit te schakelen. De identiteitsdienst bewaart de geheimen van de koppeling. Een nieuwe SSO-gebruiker blijft in afwachting tot het apparaat van een beheerder de organisatiesleutels voor diens account beschikbaar maakt. SSO verandert hoe mensen inloggen, niet hoe gegevens zijn beschermd; herstel werkt nog steeds via de herstelzin. |
| Autorisatie | Beleidsgestuurd per object, afgedwongen door een centraal beleidspunt bij elk verzoek. Groepslidmaatschap en cryptografische sleutels bepalen toegang tot inhoud; wie geen sleutel heeft, kan ook met een gunstige beleidsbeslissing niets lezen. |
| Rollen | Organisatieniveau: eigenaar, beheerder en lid. Groepsniveau: eigenaar, beheerder, lid en lezer. Beheer van de organisatie (accounts, groepen, rollen, seats) is gescheiden van toegang tot de inhoud van groepen; een organisatiebeheerder ziet welke groepen bestaan, hun naam, leden en leesbare kenmerken, en heeft zonder lidmaatschap geen sleutel. |
| Gasten | Externen zonder account krijgen toegang via een wachtwoordzin of een code per e-mail (paragraaf 4). Inzenders op een request kunnen alleen schrijven en hun eigen inzending na verzending niet meer openen. |
| Apparaten en sessies | Elk apparaat heeft een eigen share en wordt goedgekeurd vanaf een bestaand apparaat (zescijferige code, verloopt na enkele minuten). Een apparaat kan vanaf een ander apparaat worden ingetrokken; de overige apparaten krijgen dan nieuwe shares en de ingetrokken share is onbruikbaar. Apparaatgoedkeuringen en intrekkingen zijn ondertekende auditentries en leveren beveiligingsmeldingen op. Inlogsessies worden beheerd door de identiteitsdienst. |
| Identiteitsverificatie | Full Join kan organisaties en, op verzoek van hun beheerder, gebruikers een verificatiekenmerk geven na controle van de profielgegevens, via een afgeschermd beheerkanaal met verplichte onderbouwing en auditvastlegging. Het kenmerk geeft geen rechten en vervalt automatisch als een gecontroleerd gegeven wijzigt. |
Zie Organisaties, Apparaten en ontgrendelen en Contacten.
Wat vraagt dit van de organisatie?
- In- en uitdiensttreding: bepaal hoe accounts en groepslidmaatschappen worden beheerd wanneer iemand begint, van functie verandert of vertrekt. Bij SSO beheert de organisatie de levenscyclus in de eigen identity provider.
- Groepslidmaatschap: controleer periodiek of personen alleen toegang hebben tot groepen waarvoor zij die toegang nodig hebben.
- Beheerrechten: maak onderscheid tussen beheer van de organisatie en toegang tot de inhoud van afzonderlijke groepen. Besluit wie nieuwe SSO-gebruikers goedkeurt.
- Koppeling met de identity provider: bepaal hoe SSO wordt ingericht en welke aanvullende maatregelen (MFA, voorwaardelijke toegang) bij de eigen IdP worden afgedwongen.
4. Uitzonderingen en aandachtspunten #
Dit zijn de punten waar Databeamer wat zero-knowledge inruilt voor bruikbaarheid. Elk punt staat gedocumenteerd bij de functie, en elk is een keuze waar je organisatie beleid op kan maken.
Gasttoegang via een code per e-mail #
Bij transfers en Secure Mail naar ontvangers zonder account kiest de verzender per zending de ontgrendelmodus. De standaard is een wachtwoordzin: door Databeamer gegenereerd, één per transfer, buiten Databeamer om gedeeld; de sleutel voor de gast wordt eruit afgeleid met Argon2id en de server kent de zin nooit (alleen de salt). Het alternatief is een code per e-mail: de sleutel voor de gast staat versleuteld onder een niet-exporteerbare sleutel in een key-managementdienst (Scaleway Key Manager, EU, regio Amsterdam), zodat een beheerder hem niet kan kopiëren en offline gebruiken. Nadat de gast met een zescijferige code (eenmalig, tien minuten geldig, begrensd in uitgifte en pogingen) aantoont de mailbox te beheren, wordt de sleutel voor die sessie vrijgegeven. Iedere vrijgave wordt in de audittrail geschreven. Intrekken of verlopen vernietigt de escrow-kopie.
Voor de beoordeling: dit is de enige route waarbij de dienst technisch toegang tot inhoud kan krijgen, en de beveiliging van de mailbox van de gast is dan onderdeel van de keten. Het pad vereist toegang tot de productieomgeving én de key-managementdienst; die toegang valt onder het toegangsbeheer uit paragraaf 7 (least privilege, verplichte MFA, kwartaalreview, logging). De DPA (§4.3) en het Beveiligingsbeleid (§4.5) beschrijven deze afweging expliciet.
Wat vraagt dit van de organisatie? Bepaal welke toegangsroute past bij welk type informatie en leg vast wanneer gasttoegang via e-mail is toegestaan en wanneer een wachtwoordzin of andere werkwijze vereist is. Zie Een transfer versturen en Een ontvangen transfer openen.
Controle op bekende malware #
Bij het uploaden berekent de browser vóór het versleutelen een SHA-256-hash van de inhoud en meldt die bij de upload. Een achtergrondproces zoekt de hash op bij een hash-reputatiedienst (OPSWAT MetaDefender); de aanroep bevat alleen de hash. Bij een treffer krijgt het bestand de status Dreiging gevonden en kan het niet in een Drive worden opgeslagen; downloads worden nooit geblokkeerd en de uitkomst is adviserend. Een mislukte opzoeking wordt met oplopende tussenpozen opnieuw geprobeerd.
Voor de beoordeling: een hash kan prijsgeven dat twee gebruikers hetzelfde bestand hebben, of dat een bestand een bekend publiek bestand is; over een uniek bestand zegt de hash niets. Omdat de server de inhoud niet ziet, kan hij geen inhoudelijke scan uitvoeren. Een organisatie die dat vereist, regelt endpoint-scanning aan de eigen kant. Zie Bestanden uploaden en ordenen.
Intrekken van toegang en sleutelrotatie #
Wanneer iemand uit een groep wordt verwijderd, genereert en ondertekent het apparaat van de beheerder een nieuwe versie van de sleutelset; de server genereert nooit sleutels. Nieuwe informatie is daarna niet meer toegankelijk voor de verwijderde persoon. Informatie die al is gedownload of ontsleuteld, kan niet op afstand uit diens bezit worden verwijderd, en eerdere chatberichten en logboekitems worden niet opnieuw versleuteld. Dit is een eigenschap van elk versleuteld uitwisselingsmodel, geen tekortkoming van de implementatie, maar het vraagt wel om organisatorische afspraken. Zie Groepen.
Verlies van apparaten en herstelgegevens #
Een gebruiker kan een apparaat laten intrekken via een ander beschikbaar apparaat. De herstelzin is belangrijk om toegang te behouden. Als alle apparaten én de herstelzin verloren zijn, kan het account niet op de gebruikelijke manier worden hersteld. Als Databeamer het account dan reset, worden de shares en publieke sleutels van de gebruiker verwijderd; de oude hoofdsleutel kan door niemand meer worden opgebouwd en persoonlijke inhoud is definitief weg. Groepsinhoud wordt weer bereikbaar zodra een beheerder de gebruiker opnieuw toevoegt. De reset wordt als beveiligingsgebeurtenis in het auditlog vastgelegd.
Wat vraagt dit van de organisatie? Bepaal hoe medewerkers de herstelzin veilig bewaren, hoe verlies wordt gemeld, wie wordt betrokken bij een reset en hoe je voorkomt dat bedrijfskritische informatie alleen in één account staat. Zie Geen apparaat en geen herstelzin.
5. Audittrail, logging en incidenten #
De audittrail legt gebeurtenissen en wijzigingen vast. Elke wijzigende handeling van een gebruiker draagt een auditentry die het apparaat van die gebruiker ondertekent met de hybride handtekening (Ed25519 + ML-DSA-65) en die samen met de handeling wordt opgeslagen. Handelingen van gasten en handelingen die de server zelf uitvoert (zoals een download door een gast of een verlopen transfer) dragen geen handtekening van een gebruikersapparaat. Elk uur worden entries verzegeld in aaneengeschakelde epochs. Zie Auditlog.
| Onderwerp | Beschrijving |
|---|---|
| Wat wordt vastgelegd | Wie wat met welk object deed en wanneer: uploads en verwijderingen, verstuurde, geaccepteerde, gedownloade en verlopen transfers, gasttoegang (bij een wachtwoordzin als bevestiging van de browser van de gast, bij een code per e-mail bij elke sleutelvrijgave), inzendingen en intrekkingen, leden- en rolwijzigingen, sleutelrotaties, apparaatgoedkeuringen en -intrekkingen, herstelzinnen, accountresets, wijzigingen in organisaties. Entries bevatten nooit inhoud, bestandsnamen of berichten. |
| Scope | Per account, per groep en voor het systeem als geheel. Filters in de app: transfers, requests en mail; bestanden; chat; account en beveiliging; groepen en organisaties. |
| Integriteit | Ondertekend door het handelende apparaat (Ed25519 + ML-DSA-65), verzegeld in aaneengeschakelde epochs die voortdurend opnieuw worden gecontroleerd. Een entry achteraf verwijderen of wijzigen zou de keten breken. |
| Inzage en export voor de afnemer | Gebruikers zien het auditspoor van hun eigen account. Organisaties kunnen de auditgegevens van hun eigen organisatie en groepen inzien en exporteren (DPA §13.6). Koppeling met eigen monitoring of een SIEM wordt in overleg ingericht, afhankelijk van configuratie en afspraken. |
| Bewaartermijn | Auditgegevens blijven bestaan nadat de onderliggende inhoud of het account is verwijderd, geanonimiseerd waar mogelijk, zolang dat noodzakelijk is voor beveiliging, beheer, incidentonderzoek, aantoonbaarheid en wettelijke of contractuele verplichtingen (DPA §13.6). Operationele infrastructuurlogs en foutmonitoring worden beperkt bewaard (ordegrootte één maand) en bevatten geen klantinhoud, persoonsgegevens of sleutels. |
| Meldingen bij verdachte activiteit | Gebeurtenissen die aandacht verdienen, zoals een nieuwe apparaatgoedkeuring of een vergrendelde pincode, verschijnen als Beveiligingsmeldingen op het dashboard van de gebruiker en, afhankelijk van de meldingsinstellingen, per e-mail. |
De audittrail vervangt niet alle organisatorische maatregelen. Spreek af wie gebeurtenissen beoordeelt, wanneer nader onderzoek nodig is en hoe bevindingen worden vastgelegd.
Voorbeelden van situaties en eerste acties #
| Situatie | Eerste aandachtspunten |
|---|---|
| Een apparaat is verloren of gestolen | Trek het apparaat in via een ander beschikbaar apparaat. Beoordeel of de herstelzin mogelijk is blootgesteld en genereer die dan opnieuw. Gids |
| Een medewerker verlaat de organisatie | Verwijder de persoon uit relevante groepen (de sleutel roteert bij het verwijderen) en draag groeps- of organisatie-eigenaarschap eerst over. Gids |
| Een transfer of Secure Mail is naar de verkeerde persoon gestuurd | Verwijder de transfer of trek de levering aan de gast in. Al opgehaalde informatie kan niet op afstand worden teruggenomen. Referentie |
| Een wachtwoordzin is mogelijk bekend geworden bij onbevoegden | Verwijder de transfer en verstuur opnieuw met een nieuwe zin. |
| Er zijn verdachte activiteiten op een account | Bekijk de auditgegevens en beveiligingsmeldingen; ondertekende entries kan de server niet vervalsen. Volg de interne incidentprocedure en meld een vermoeden bij Databeamer via security@databeamer.io. |
Beoordeel bij een mogelijk datalek ook of meldplichten van toepassing zijn, en betrek de FG tijdig.
Incidentafhandeling door Databeamer #
| Onderwerp | Beschrijving |
|---|---|
| Meldkanaal voor de afnemer | Beveiligingsincidenten en kwetsbaarheden: security@databeamer.io, met PGP voor gevoelige meldingen. Overige vragen: compliance@databeamer.io. Een geldige melding wordt binnen vijf werkdagen bevestigd. |
| Detectie en classificatie | Geautomatiseerde alerts op infrastructuur en uitrolstraat, eigen waarneming en externe meldingen. Classificatie bij melding: P1 kritiek (actieve aanval, vermoedelijk datalek, uitval van alle productieclusters, vermoedelijke compromittering van sleutels) eerste respons binnen 1 uur; P2 hoog (ongeautoriseerde toegang zonder exfiltratie, verlies of diefstal van een apparaat) 4 uur; P3 normaal (kwetsbaarheid in productie, niet uitgebuit) 8 uur op een werkdag; P4 laag volgende werkdag. |
| Melding aan de afnemer: termijn en inhoud | Onverwijld en uiterlijk binnen 24 uur na ontdekking, aan het door de afnemer opgegeven beveiligingscontact, per e-mail en zo nodig telefonisch, zodat de afnemer zelf binnen 72 uur kan melden (AVG, NIS2, Cyberbeveiligingswet). Inhoud: aard, betrokken systemen, categorieën gegevens en betrokkenen, gevolgen, maatregelen, contactpunt; aangevuld zodra er meer bekend is (DPA §9.2 en §9.3). |
| Contactpunt en bereikbaarheid | De afnemer geeft een beveiligingscontact op en houdt dat actueel. Bij een grootschalige verstoring volgt een eerste publieke melding binnen dertig minuten, daarna ten minste elk uur een update, en na herstel een bevestiging per e-mail. |
| Evaluatie en nazorg | Na een P1- of P2-incident een evaluatie van oorzaak, detectie, herstel en preventieve maatregelen, en een beoordeling of het ISMS moet worden aangepast; de voor de afnemer relevante uitkomsten worden op verzoek gedeeld. Het incidentproces wordt ten minste jaarlijks getest. |
6. Welke gegevens zijn zichtbaar voor de dienst? #
De zero-knowledge-architectuur beschermt de inhoud. Een beperkte hoeveelheid metadata blijft leesbaar, omdat de dienst die nodig heeft voor accounts, groepen, toegang en uitwisseling.
Voor een CISO is vooral van belang dat dit de gegevens zijn die een aanvaller op de serverzijde of een kwaadwillende beheerder wél zou kunnen zien: namen en e-mailadressen, organisatie- en groepsnamen, ledenlijsten en rollen, classificaties, statussen en labels, titels, afzenders, ontvangers en status van transfers en requests, gebeurtenissen en tijdstippen in de audittrail, aantallen en versleutelde groottes en de vorm van de mappenboom, kanaal, afzender, leesstatus en aanwezigheid in chat en mail, e-mailadressen van gasten, IP-adressen en inlogtijdstippen, en de SHA-256-hash van elk geüpload bestand. Niet zichtbaar zijn bestandsinhoud, bestandsnamen en -typen, mapnamen, berichten, bijlagen, logboekregels, antwoorden, tags en beschrijvingen, en wachtwoorden, pincodes, herstelzinnen, wachtwoordzinnen en sleutels. De technologiepagina houdt deze opsomming actueel.
De privacygevolgen staan beschreven in het overzicht voor FG's. Voor de securitybeoordeling is relevant:
- Wie binnen Databeamer kan bij deze metadata? Alleen medewerkers met een rol in het beheer van de productieomgeving, volgens least privilege en need-to-know, met verplichte MFA (authenticator-app of hardwaresleutel), een kwartaalreview van alle toegangsrechten en logging van beheerhandelingen. Toegang wordt op de laatste werkdag gedeactiveerd bij vertrek. Er is geen aparte supporttoegang.
- Hoe is de metadata beveiligd tijdens transport en opslag? TLS voor al het verkeer, versleuteling in rust op de infrastructuur, netwerksegmentatie en toegangsbeperking. Deze bescherming is van het industriestandaardniveau, niet zero-knowledge: het is de blootstelling bij een serverinbraak.
- Houd groepsnamen, titels, labels en statussen neutraal, zodat de metadata zelf geen vertrouwelijke informatie prijsgeeft.
7. Hosting, infrastructuur en continuïteit #
| Onderwerp | Beschrijving |
|---|---|
| Hostinglocatie en -aanbieder | Scaleway SAS (Frankrijk), Europese Unie, regio Amsterdam, redundant over drie zones. De identiteitsdienst draait op door Full Join zelf beheerde software op dezelfde infrastructuur. Geen data, metadata of back-ups verlaten de EU; geen Amerikaanse hyperscaler. De subverwerkers staan in hoofdstuk 10 van de DPA. |
| Architectuur van de dienst | Gescheiden omgevingen voor ontwikkeling, build, staging en productie, technisch en organisatorisch; de productieomgeving is netwerkmatig niet bereikbaar vanaf ontwikkelwerkstations. Productiegegevens worden nooit in ontwikkel- of testomgevingen gebruikt; testdata is synthetisch of geanonimiseerd. De volledige infrastructuur is als code vastgelegd en wordt daaruit uitgerold. |
| Netwerk- en transportbeveiliging | TLS voor al het verkeer, netwerksegmentatie, firewalls, beveiligde beheerverbindingen, bescherming van publieke endpoints, rate limiting, maatregelen tegen geautomatiseerd misbruik en DDoS, monitoring van netwerkactiviteit. |
| Beheer en toegang tot productie | Beperkt tot de personen voor wie dat noodzakelijk is; persoonlijke accounts met verplichte MFA; voor elk kritiek platform minimaal twee beheerders, zodat continuïteit niet van één persoon afhangt met behoud van persoonlijke herleidbaarheid. Handmatige wijzigingen in productie buiten de uitrolstraat om zijn niet toegestaan en vereisen in noodgevallen het vier-ogenprincipe. Toegangsrechten worden elk kwartaal beoordeeld; verlening en intrekking worden als taak vastgelegd. |
| Back-up en herstel | Geautomatiseerde back-ups van alles wat nodig is voor herstel van de dienst; klantinhoud is daarin altijd versleuteld. Database-back-ups dagelijks, zeven dagen bewaard; versleutelde bestandsblokken redundant over drie zones in Amsterdam. Herstel verloopt uitsluitend via de infrastructure-as-code-pipeline, na vaststelling van de bronoorzaak en met een verificatietest door twee personen. Herstelprocedures worden ten minste jaarlijks getest, inclusief een database- en identiteitsrestore op een afgescheiden omgeving. |
| Doelstellingen voor herstel (RTO en RPO) | Intern vastgesteld voor het productieplatform en de identiteitsinfrastructuur en in het continuïteitsplan vastgelegd. Ze maken geen deel uit van het publieke beleid; voor klanten met een SLA worden ze contractueel vastgelegd (Beveiligingsbeleid §11.3). |
| Cryptografische randvoorwaarde bij herstel | Full Join kan versleutelde klantdata en metadata herstellen uit back-ups, maar gebruikers openen hun gegevens pas weer met hun eigen apparaat of herstelzin. Er is geen hoofdsleutel om dit centraal af te dwingen. |
| Beschikbaarheid en monitoring | Redundante uitvoering waar mogelijk; uptime-monitoring, logalerts en foutmonitoring met gedefinieerde drempelwaarden; maandelijkse security- en monitoringreview. Gepland onderhoud op werkdagen tussen 22:00 en 06:00 uur, bij onbeschikbaarheid ten minste vijf werkdagen vooraf aangekondigd in de app en per e-mail aan beheerders. Bij een grootschalige verstoring een eerste publieke melding binnen dertig minuten en daarna elk uur een update. |
| Onderaannemers en subverwerkers | Zie hoofdstuk 10 van de DPA en paragraaf 6 van de DPIA-ondersteuning. Kritieke leveranciers moeten een actueel ISO 27001-certificaat of SOC 2-rapport en een DPA met EU-dataresidentie hebben en worden ten minste jaarlijks beoordeeld; bij selectie wordt getoetst op eigendom binnen de EU en de herkomst van de onderliggende technologie. |
8. Ontwikkelproces, supply chain en kwetsbaarhedenbeheer #
| Onderwerp | Beschrijving |
|---|---|
| Veilige ontwikkeling | Secure SDLC in zes fasen, van ticket tot onderhoud. Elke wijziging begint als ticket; significante wijzigingen aan de zero-knowledge- of post-quantumarchitectuur vereisen directieakkoord en een toets van de CISO op de risico's. unsafe is in de eigen Rust-code op compilerniveau geblokkeerd; strikte compiler-flags en linters weigeren onvoltooide code. Secrets staan nooit in de repository. Alle code naar staging of productie doorloopt een formele review; zelfstandig samenvoegen is via branch protection geblokkeerd. Wijzigingen aan cryptografische en zero-knowledge-code vereisen via CODEOWNERS de dubbele goedkeuring van de lead engineer én de CISO. |
| Testen | Elke release doorloopt de geautomatiseerde testsuite: unit- en integratietests (tegen lokale database-, cache- en autorisatiecontainers), beleidstests voor de autorisatieregels (een wijziging die bestaande regels breekt wordt geblokkeerd), statische analyse (Semgrep, Clippy, cargo-geiger) en dependency-scanning. Kritieke of hoge bevindingen blokkeren de uitrol. |
| Afhankelijkheden en supply chain | Continu beheer van open-source afhankelijkheden met cargo-deny en Renovate; CVE-meldingen leveren automatisch een wijzigingsvoorstel op, kritieke CVE's worden als risico geregistreerd. Nieuwe releases van cryptografische bibliotheken worden pas na een rijpingsperiode opgenomen, als bescherming tegen supply-chain-aanvallen via snel uitgerolde kwaadaardige updates. Een SBOM wordt niet gepubliceerd; de afhankelijkhedenlijst maakt deel uit van de broncode en is op verzoek bespreekbaar. |
| Wijzigings- en releasebeheer | De CI/CD-pipeline is de enige route naar productie; handmatige uitrol is verboden. Elke uitrol wordt gelogd. Bij een problematische uitrol stelt de lead engineer de rollback naar de vorige stabiele release vast; de storing wordt als incident geregistreerd. Productieservers draaien minimaal (geen debug- of analysetools zonder goedgekeurde, tijdelijke wijziging). Onderhoud met onbeschikbaarheid wordt vijf werkdagen vooraf aangekondigd. |
| Patchmanagement | Kwetsbaarheden worden proactief geïdentificeerd en zo snel mogelijk opgelost; de prioriteit volgt de ernst. Een geïdentificeerde, niet-uitgebuite kwetsbaarheid in productie is een P3-incident (eerste respons binnen 8 uur op een werkdag); een actief uitgebuite kwetsbaarheid is P1 (binnen 1 uur). |
| Pentests en onafhankelijke toetsing | Periodieke externe penetratietests door een onafhankelijke, gecertificeerde partij, met vooraf vastgelegde scope (rules of engagement); bevindingen worden als taak opgevolgd. Tests die klanten zelf laten uitvoeren worden gefaciliteerd na afstemming van de scope. Daarnaast een jaarlijkse onafhankelijke interne audit van het ISMS door een extern bureau. Samenvattingen en assurance-informatie worden op redelijk verzoek gedeeld (DPA hoofdstuk 14). |
| Kwetsbaarhedenbeleid en responsible disclosure | Meldingen via security@databeamer.io (PGP beschikbaar); bevestiging binnen vijf werkdagen; geen aangifte of civiele actie tegen onderzoekers die zich aan de spelregels houden (Beveiligingsbeleid hoofdstuk 16). |
| Reviewbaarheid van de code | De broncode is niet openbaar. Dezelfde Rust-code draait op de server en in de browser (WebAssembly), zodat er één bron van waarheid voor de cryptografie is. Mogelijkheden voor inzage zijn bespreekbaar via compliance@databeamer.io. |
9. Certificeringen, normen en compliance #
| Onderwerp | Status |
|---|---|
| ISO/IEC 27001:2022 | Het ISMS is ingericht conform ISO/IEC 27001:2022 en Annex A, met de Databeamer-productieomgeving, de onderliggende infrastructuur en de ondersteunende systemen in scope. Het externe certificeringstraject is doorlopen; de formele afronding wacht op de rapportage van de certificerende instelling. Het Beveiligingsbeleid (§17.1) geeft de actuele status en wordt bij verlening aangepast. |
| NEN 7510, 7512 en 7513 | Full Join bereidt zich voor op certificering tegen NEN 7510 en richt de dienst in met inachtneming van NEN 7512 (vertrouwensbasis voor gegevensuitwisseling) en NEN 7513 (logging van toegang tot cliëntgegevens); de auditfunctionaliteit is mede op die laatste norm afgestemd. |
| NTA 7516 | Inhoudelijke conformiteit op de meeste pijlers; de ontwikkeling van NEN 7516, NTA 7531 en NTA 7532 wordt gevolgd. Zie de compliancepagina. |
| BIO (overheid), NIS2, DORA | Databeamer ondersteunt de verplichtingen van klanten op het gebied van toegangscontrole, incidentlogging, meldtermijnen en ketenbeveiliging; de mapping per norm staat op de compliancepagina. Full Join valt zelf niet onder de meldplichten van NIS2, maar richt de meldtermijn van 24 uur op klanten in die daar wel onder vallen. |
| Overige normen of rapportages (zoals SOC 2) | Niet beschikbaar. |
| Verklaringen over de technische en organisatorische maatregelen | Bijlage B van de DPA en de compliancepagina; aanvullende documentatie, certificeringen en assurance-informatie op redelijk verzoek (DPA hoofdstuk 14). |
| Verwerkersovereenkomst, privacyverklaring, cookiebeleid | Zie de juridische pagina. |
10. Wat moet je controleren, inrichten en afstemmen? #
| Onderwerp | Wat controleer of regel je? | Afstemmen met |
|---|---|---|
| Risicoanalyse | Past het beveiligingsniveau van Databeamer bij de gevoeligheid van de te delen informatie? | Proceseigenaar, FG |
| Gasttoegang | Welke gasttoegangsopties zijn toegestaan voor welk type informatie? Is de code per e-mail acceptabel voor de gevoeligste informatie? | FG, programmamanager |
| Identiteit en SSO | Hoe wordt SSO gekoppeld aan de eigen IdP? Welke aanvullende eisen (MFA, voorwaardelijke toegang) gelden? Wie keurt nieuwe SSO-gebruikers goed? | IT-manager |
| Groepen en rechten | Hoe worden groepen ingericht en periodiek gecontroleerd? Welke rollen krijgt wie? | Organisatiebeheerder, IT-manager |
| In-, door- en uitstroom | Hoe verlopen accountbeheer en het verwijderen van groepsleden bij vertrek, rekening houdend met sleutelrotatie? | HR, IT-manager |
| Eindpunten | Welke eisen gelden voor apparaten waarop Databeamer wordt gebruikt (updates, schijfversleuteling, malwarebescherming)? Is een passkey verplicht, toegestaan of ontraden? | IT-manager |
| Herstelbeleid | Hoe worden herstelzinnen bewaard, verlies gemeld en resets afgehandeld? Minimaal twee apparaten per gebruiker? | IT-manager, FG |
| Logging en monitoring | Wie beoordeelt auditgegevens, hoe vaak en hoe wordt dit vastgelegd? Is koppeling met de eigen monitoring nodig? | IT-manager |
| Incidentafhandeling | Is duidelijk wie wat doet bij een incident en hoe de leverancier wordt ingeschakeld? Is het beveiligingscontact bij Databeamer actueel? Passen de meldtermijnen bij de eigen verplichtingen? | FG, directie |
| Leveranciersbeheer | Hoe worden certificeringen, pentestrapporten en wijzigingen bij Databeamer periodiek getoetst? | Inkoop |
| Continuïteit en exit | Is de dienst voldoende beschikbaar? Is een SLA nodig voor RTO en RPO? Hoe komt de organisatie bij haar gegevens als de dienst uitvalt of de overeenkomst eindigt (exportfunctie, dertig dagen na beëindiging)? | IT-manager, programmamanager |
11. Waar vind je de technische details? #
Over dit document #
Eigenaar is de CISO van Full Join B.V. Het document wordt ten minste jaarlijks beoordeeld, en daarnaast bij iedere wijziging van het beveiligingsbeleid, de DPA, de certificeringsstatus of de technische architectuur. De datum van de laatste wijziging staat onderaan de pagina.
Vragen over beveiliging of compliance? Neem contact op via de compliancepagina of mail naar compliance@databeamer.io. Kwetsbaarheden meld je via security@databeamer.io.