Ga uit van gecompromitteerde servers

Voordat een vermelding de store bereikt, wordt haar payload met een symmetrische sleutel (AES-256-GCM) versleuteld. Die versleuteling hoort bij het datamodel, niet bij het transport. De server die de vermeldingen bewaart, kan de inhoud niet lezen — hij ziet alleen versleutelde bytes.

Antwoordt de server op een sync-verzoek, dan verpakt hij de payloads van de vermeldingen in een extra RSA-laag met de publieke sleutel van de vragende gebruiker. Zelfs wie het HTTP-antwoord onderschept, kan het zonder de privé-RSA-sleutel van de ontvanger niet ontsleutelen.

Alle communicatie loopt over TLS. Dat beschermt de metadata (vermeldings-ID's, tijdstempels, verzoekparameters) die de payload-lagen niet dekken. Samen sluiten de drie lagen de gegevens volledig af: opgeslagen, onderweg en op de verbinding.

Alle documenten worden versleuteld met de AES-256-standaardsleutel van de tenant, tenzij een andere sleutel is opgegeven. Elke geregistreerde gebruiker krijgt die sleutel bij de onboarding. Geschikt voor algemene gegevens binnen de hele tenant.

Voor gevoelige documenten maak je een benoemde versleutelingssleutel aan en deel je die alleen met bevoegde gebruikers. Sleutels worden offline verdeeld (de versleutelde sleutel per e-mail, het wachtwoord telefonisch of persoonlijk) of via een beleidsregel zonder admin-inzage: wie de sleutel al heeft, pakt hem voor elke ontvanger in met diens persoonlijke publieke (RSA-)sleutel, zodat een beheerder hem kan doorgeven zonder hem ooit te lezen. Alleen wie de sleutel heeft, kan ontsleutelen.

Een speciale sleutel die uitsluitend de toegangscontrolevermeldingen van de directory versleutelt (gebruikersregistraties, intrekkingen, groepen). Servers controleren daarmee welke ondertekeningssleutels worden vertrouwd — zonder gebruikersnamen of bedrijfsgegevens te zien. Gebruikersnamen staan er als SHA-256-hashes in; de echte namen zijn versleuteld met de RSA-sleutel van de admin.

Elke sync-sessie begint met een challenge-response-handshake:

• De client stuurt zijn publieke ondertekeningssleutel naar de server
• De server zoekt de sleutel op in de directory en stuurt een willekeurige challenge
• De client ondertekent de challenge met zijn privésleutel
• De server toetst de handtekening, controleert of de gebruiker is ingetrokken en geeft een kortlevende JWT uit

Geen wachtwoorden of sessiedatabases op de server. Een ingetrokken gebruiker komt zelfs niet aan het begin van de authenticatie.

Nieuwe gebruikers komen erbij via een handshake in drie stappen waarbij privésleutels het apparaat nooit verlaten:

• Toetredingsverzoek — De nieuwe gebruiker maakt zijn sleutels lokaal aan en stelt een verzoek op dat alleen publieke sleutels bevat. Dat is veilig via elk kanaal te versturen.
• Goedkeuring door de beheerder — De beheerder registreert de gebruiker in de directory en versleutelt de symmetrische sleutels met een eenmalig deelwachtwoord.
• Uitwisseling via twee kanalen — Het toetredingsantwoord gaat per e-mail of chat; het deelwachtwoord komt apart telefonisch of persoonlijk.

• Ondertekening: Ed25519 (128 bits beveiliging, elliptische kromme)
• Payload-versleuteling: AES-256-GCM (256 bits beveiliging)
• Transportversleuteling: RSA-OAEP met SHA-256 (3072-bits sleutels)
• Sleutelafleiding: PBKDF2 met een eigen salt per sleuteltype
• Token-ondertekening: HMAC-SHA256
• Hashing: SHA-256 (content-adressering, privacy van gebruikersnamen)

• Vertrouwelijkheid: AES-256-GCM-versleuteling — alleen wie de sleutel heeft, kan lezen
• Authenticiteit: Ed25519-handtekeningen — bewijzen wie een wijziging maakte
• Integriteit: Hash-ketening — manipulatie breekt de ketting en is op elk punt te zien
• Onweerlegbaarheid: Handtekeningen zijn niet na te maken — wie iets schreef, is te bewijzen
• Privacy: Gebruikersnamen gehasht en versleuteld — de server kan gebruikers niet herkennen

• Gekraakte server — Een aanvaller krijgt alleen versleutelde gegevens en publieke sleutels. Niets leesbaar, geen privésleutels, geen gebruikersnamen.
• Afluisteren van het netwerk — Drie versleutelingslagen beschermen de gegevens, ook als TLS is gekraakt.
• Onbevoegde wijzigingen — Elke wijziging is ondertekend; niet of verkeerd ondertekende wijzigingen worden afgewezen.
• Manipulatie — Hash-ketening maakt elke aanpassing zichtbaar.
• Toegang van ingetrokken gebruikers — Het intrekken werkt bij de challenge en bij de tokencontrole; de sync is meteen geblokkeerd.
• Meelezen bij het relay — Relayknopen bewaren en geven versleutelde vermeldingen door die ze niet kunnen ontsleutelen.

De inhoud van de payload is altijd versleuteld, maar een deel van de metadata is bewust zichtbaar voor de server. Dat is een doelbewuste trade-off: het sync-protocol heeft metadata nodig om vermeldingen af te stemmen.

• Zichtbaar: tijdstempels van vermeldingen, content-hashes, documentstructuur (hoeveel vermeldingen per document), toegangspatronen (wanneer gebruikers synchroniseren)
• Niet zichtbaar: documentinhoud, gebruikersnamen, versleutelingssleutels, inhoud van bijlagen

Content-hashes verraden wanneer twee vermeldingen identieke versleutelde gegevens bevatten (voor de deduplicatie). Dat is een aanvaarde trade-off voor efficiënte opslag.

Een gebruiker intrekken blokkeert alle verdere sync en wijst zijn volgende wijzigingen af. Gegevens die al naar zijn apparaat zijn gesynchroniseerd, blijven daar echter leesbaar — geen enkel systeem kan verwijdering garanderen op een apparaat dat nooit meer verbinding maakt. Beperk het risico: gebruik benoemde sleutels voor gevoelige documenten (kleiner bereik) en roteer sleutels als gebruikers vertrekken. Haven Enterprise voegt aan diezelfde governance-beleidsregels een admin-ondertekend wissen op afstand toe: de tenant verdwijnt van een gestolen of afgedankt apparaat zodra dat weer verbinding maakt.

Meerdere sleutels per gebruiker (ondertekening, versleuteling, benoemde symmetrische sleutels) moeten veilig worden verdeeld. Beperk het risico: één wachtwoord ontgrendelt alle sleutels via PBKDF2 met verschillende salts. De KeyBag biedt daarvoor één gezamenlijke sleutelopslag. De join-request/response-flow regelt de sleuteluitwisseling voor nieuwe gebruikers. Haven Enterprise automatiseert het werk daarna: admin-ondertekende beleidsregels voor sleuteldistributie geven sleutels aan gebruikers en groepen — en trekken ze weer in — per ontvanger ingepakt, en elke client stemt zijn KeyBag bij de volgende sync af.

Standaard kan de server niet in documentinhoud zoeken, omdat hij alleen versleutelde gegevens ziet. Alle query's lopen via de client met incrementele indexering. Vraagt jouw toepassing toch om verwerking op de server (bijvoorbeeld een online boekingssysteem of een openbare website), dan kun je het serverproces een ontsleutelingssleutel geven of een deel van de gegevens met hem delen. Dat is per installatie een bewuste architectuurkeuze — standaard geldt vertrouwelijkheid, met serveropslag alleen waar je die zelf aanzet.

Een uitgebreide beveiligingsaudit heeft benoemd wat steviger moet: rate limiting op de endpoints, het intrekken van JWT-tokens en rotatie van de admin-sleutel. Wijzigingen die ingetrokken gebruikers met terugwerkende kracht aanbrengen, worden inmiddels tegengehouden door getuigenbewijzen met vertrouwde tijd (zie het model van de toegangscontrole). Het cryptografische fundament (Ed25519, AES-256-GCM, RSA-OAEP) staat stevig. Het steviger maken van de operatie loopt.