Bijgewerkt november 11, 2026
Kort: Nextcloud E2EE beschermt bestanden zo dat zelfs de hostingpartij geen toegang heeft, maar vereist zorgvuldige sleutelbeheerkeuzes (HSM, KMIP, Vault) en post-kwantumgereedheid via ML-KEM (FIPS 203). Dit artikel legt uit hoe overheids- en juridische organisaties dit aantoonbaar compliant inrichten.

End-to-end encryptie (E2EE) in Nextcloud houdt in dat bestanden worden versleuteld op het apparaat van de gebruiker, vóórdat zij de server bereiken, zodat de hostingpartij, beheerder en eventuele derde partijen uitsluitend cijfertekst te zien krijgen. Voor organisaties in de overheids- en juridische sector die migreren van Microsoft 365 naar een soevereine Nextcloud-omgeving, is de keuze van sleutelbeheerarchitectuur en de post-kwantumbestendigheid van die encryptie bepalend voor zowel juridische compliance als operationele veiligheid.

Server-side encryptie versus E2EE: een fundamenteel onderscheid

Nextcloud biedt twee encryptielagen die vaak worden verward, maar die wezenlijk verschillende beveiligingsgaranties geven.

Bij server-side encryptie (Nextcloud’s ingebouwde “Default Encryption Module”) versleutelt de server de bestanden met sleutels die op de server worden beheerd. Dit beschermt data op de schijf tegen fysieke diefstal van hardware, maar een beheerder met toegang tot de serveromgeving kan in principe de master-key inzien en bestanden ontsleutelen. Voor een gehoste omgeving betekent dit dat de hostingpartij technisch gezien toegang heeft.

De Nextcloud E2EE-app (End-to-End Encryption) werkt anders: encryptie en decryptie vinden plaats op de client. De server ontvangt en slaat uitsluitend versleutelde blokken op. Zelfs bij volledige servercompromittering blijft de inhoud onleesbaar zolang de privésleutels niet zijn blootgesteld. Dit is de architectuur die overheids- en juridische organisaties zouden moeten hanteren voor hun meest gevoelige dossiers.

Let op: Server-side encryptie in Nextcloud beschermt niet tegen een nieuwsgierige of gecompromitteerde beheerder. Alleen de Nextcloud E2EE-app biedt volledige sleutelisolatie van de server.

Sleutelbeheerarchitectuur voor overheid en juridische sector

De keuze van sleutelbeheerinfrastructuur is de hoeksteen van een betrouwbare E2EE-implementatie. Er zijn drie architectuurmodellen relevant voor organisaties die Nextcloud on-premise of in een privécloud beheren.

Intern Nextcloud-sleutelbeheer

De Nextcloud E2EE-app genereert per gebruiker een asymmetrisch sleutelpaar en versleutelt de privésleutel met het wachtwoord van de gebruiker. Dit is de eenvoudigste opstelling, maar biedt geen centrale controle over sleutelrotatie, intrekking of auditlogging. Voor kleine teams of lagere risicoklassen kan dit volstaan; voor kritieke infrastructuur is het onvoldoende.

HashiCorp Vault als softwarematige sleutelkluis

HashiCorp Vault biedt een gelaagde sleutelbeheerdienst die via het KMIP-protocol (Key Management Interoperability Protocol) kan worden gekoppeld aan applicaties, inclusief Nextcloud-extensies die KMIP ondersteunen. Vault biedt sleutelrotatie, dynamische sleutels, gedetailleerde auditlogs en toegangsbeleid op basis van rollen. Voor juridische organisaties die intern willen beheren zonder HSM-investering, is Vault een haalbaar startpunt, op voorwaarde dat de Vault-instantie zelf voldoende is gehard en geïsoleerd.

Hardware Security Module (HSM): Thales en vergelijkbare oplossingen

Een Thales HSM (bijvoorbeeld de Luna-serie) of vergelijkbare FIPS 140-2/3 Level 3-gecertificeerde hardware biedt de hoogste zekerheid: privésleutels verlaten de hardware nooit en alle cryptografische bewerkingen vinden intern in de HSM plaats. Koppeling met Nextcloud verloopt via een KMIP-interface. Dit is de aanbevolen architectuur voor overheidsorganisaties die werken met gerubriceerde informatie of voor advocatenkantoren met beursgenoteerde cliënten.

Architectuur Sleutelisolatie KMIP-ondersteuning Geschikt voor Certificering
Nextcloud intern sleutelbeheer Gebruikersapparaat Nee Kleine teams, lage risicoklasse Geen extra
HashiCorp Vault Softwarematige kluis Ja (via plugin) Middelgrote organisaties, intern beheer Variabel
Thales HSM (Luna / CipherTrust) Hardware, sleutels verlaten HSM nooit Ja (native) Overheid, juridisch, kritieke infrastructuur FIPS 140-2/3 Level 3

Post-kwantumbestendigheid: ML-KEM (FIPS 203) en TLS 1.3

De dreiging van quantumcomputers op huidige asymmetrische versleuteling is geen toekomstige hypothese. De aanvalsstrategie “harvest now, decrypt later” (nu onderscheppen, later ontsleutelen) maakt dat gegevens die vandaag worden verstuurd over niet-PQC-bestendige verbindingen in de toekomst leesbaar kunnen worden zodra voldoende krachtige quantumcomputers beschikbaar zijn.

“Harvest now, decrypt later is geen theoretisch risico meer. Organisaties die vandaag gevoelige data verwerken moeten nu al nadenken over post-kwantumbestendige sleuteluitwisseling.”

Lukasz Olejnik, onafhankelijk onderzoeker cybersecurity en privacybeleid, voormalig adviseur ICRC

NIST publiceerde in augustus 2024 FIPS 203 (ML-KEM, afgeleid van het Kyber-algoritme) als definitieve standaard voor post-kwantumsleutelinkapseling. De praktische implementatie voor een zelfgehoste Nextcloud-instantie verloopt via de TLS-laag, niet via de applicatielaag zelf.

Concreet betekent dit: configureer de webserver (nginx of Apache) met een versie van OpenSSL 3.x of BoringSSL die de hybride sleuteluitwisselingsgroep X25519MLKEM768 ondersteunt. Deze groep combineert het klassieke X25519 (Curve25519 Diffie-Hellman) met ML-KEM-768, waardoor de verbinding ook beschermd blijft als een van beide algoritmen gekraakt wordt. Moderne browsers (Chromium-gebaseerd en Firefox 132+) ondersteunen deze hybride groep reeds. Verifieer de cipher-suite-volgorde in uw TLS 1.3-configuratie en test via tools zoals de SSL Labs-server test van Qualys.

Let op: PQC-bestendige TLS beschermt de verbinding, maar niet de opgeslagen sleutels. Zorg dat uw sleutelbeheersysteem (HSM of Vault) eveneens PQC-gereed is, of plan een migratiepad zodra post-kwantumveilige KEM-algoritmen breed beschikbaar zijn in HSM-firmware.

AVG artikel 32 en NIS-2 artikel 21: wat documenteert u en hoe

AVG artikel 32 verplicht verwerkingsverantwoordelijken tot het treffen van passende technische maatregelen, waaronder expliciet encryptie van persoonsgegevens. De Autoriteit Persoonsgegevens stelt hierover:

“Versleuteling is geen luxe maar een wettelijke verplichting. Artikel 32 AVG vereist dat organisaties passende technische maatregelen nemen, en encryptie wordt daarin expliciet als voorbeeld genoemd.”

Autoriteit Persoonsgegevens, richtsnoeren beveiliging van persoonsgegevens

NIS-2 artikel 21 voegt een sectoroverstijgende verplichting toe voor essentiële en belangrijke entiteiten: risicobeheermaatregelen voor netwerk- en informatiesystemen, inclusief versleuteling, moeten aantoonbaar zijn geïmplementeerd. Boetes voor niet-naleving lopen op tot 10 miljoen euro of 2% van de wereldwijde jaaromzet voor essentiële entiteiten (NIS2-richtlijn (EU) 2022/2555, artikel 34).

Statistisch onderzoek bevestigt de urgentie: het Verizon Data Breach Investigations Report 2023 stelde vast dat 82% van de onderzochte inbreuken menselijke elementen of configuratiefouten betrof, waaronder de afwezigheid van encryptie als mitigerende maatregel.

Voor documentatie richting toezichthouders legt u minimaal het volgende vast:

  • De gehanteerde versleutelingsalgoritmen, sleutellengte en protocollen (bijvoorbeeld: AES-256-GCM voor data-at-rest, TLS 1.3 met X25519MLKEM768 voor data-in-transit).
  • De sleutelbeheerprocedure: wie beheert sleutels, hoe verloopt rotatie, hoe worden sleutels ingetrokken bij uitdiensttreding.
  • De risicoafweging die ten grondslag ligt aan de gekozen maatregelen (documenteer dit als onderdeel van de DPIA of het informatiebeveiligingsbeleid).
  • Auditlogs van het sleutelbeheerplatform (HashiCorp Vault of HSM-auditlog) als bewijs van operationele controle.

Dit geheel vormt de technische paragraaf van uw verwerkingsregister en wordt op verzoek overlegd aan de Autoriteit Persoonsgegevens of de nationale NIS-2-toezichthouder (in Nederland: het Nationaal Cyber Security Centrum in samenwerking met sectorale toezichthouders).

E2EE inzetten zonder verlies van samenwerking en zoekfunctionaliteit

De Nextcloud E2EE-app werkt op mapniveau. Een organisatie wijst specifieke mappen aan als versleuteld; bestanden buiten die mappen blijven via server-side encryptie of onversleuteld beschikbaar voor indexering en samenwerking.

De functionele afweging is concreet: de Nextcloud-server kan versleutelde bestanden niet doorzoeken, omdat hij de inhoud niet kent. Zoeken in Nextcloud’s eigen interface werkt dan ook niet op de inhoud van E2EE-bestanden, alleen op bestandsnamen die in de metadata zijn opgeslagen (en die zijn eveneens versleuteld in de volledige E2EE-implementatie). Volletekstzoekopdrachten vereisen dat de gebruiker bestanden lokaal opent via de Nextcloud-desktopclient.

Praktische aanpak: segmenteer uw mapstructuur. Gebruik de E2EE-app voor mappen met de hoogste gevoeligheidsclassificatie (cliëntdossiers, gerubriceerde beleidsstukken), en reserveer niet-E2EE-mappen voor werkdocumenten waarbij zoeken en co-editeren via Nextcloud Office (Collabora) centraal staan. Synchroniseer E2EE-mappen via de Nextcloud-desktopclient, niet via de webinterface, want de webclient ondersteunt E2EE-decryptie niet volledig in alle versies.

Teamsamenwerking binnen E2EE-mappen werkt doordat elk teamlid een versleutelde kopie van de mapsleutel ontvangt, versleuteld met de publieke sleutel van die gebruiker. Voeg een nieuw teamlid toe aan een E2EE-map, dan versleutelt een bestaand teamlid de mapsleutel opnieuw voor de nieuwe gebruiker. Dit vereist dat ten minste één bestaand teamlid op dat moment online en geauthentiseerd is via de desktopclient.

Jurisdictionele risico’s en de waarde van soevereine opslag

Organisaties die nog data opslaan bij Amerikaanse hyperscalers (Microsoft Azure, AWS, Google Cloud) zijn blootgesteld aan de Amerikaanse CLOUD Act, die Amerikaanse autoriteiten de bevoegdheid geeft om data op te vragen bij Amerikaanse bedrijven, ongeacht de fysieke opslaglocatie. Zelfgehoste Nextcloud op Europese infrastructuur, of gehost bij een Zwitserse provider buiten de EU maar met sterke contractuele garanties, onttrekt data aan deze jurisdictie, mits het hostingbedrijf geen Amerikaanse moedermaatschappij heeft.

E2EE versterkt deze soevereiniteitsgarantie technisch: zelfs als een server door een autoriteit wordt gevorderd, levert die server uitsluitend onleesbare cijfertekst op. Dit is de combinatie die organisaties in de juridische sector en bij de overheid nodig hebben: juridische soevereiniteit via de hostinglocatie en eigendomsstructuur, versterkt door technische soevereiniteit via end-to-end encryptie met sleutels die de organisatie zelf beheert.

FAQ

Kan de Nextcloud-beheerder bij E2EE bestanden meelezen?

Nee. Bij correct geconfigureerde Nextcloud E2EE-app worden bestanden versleuteld op het apparaat van de gebruiker voordat ze de server bereiken. De server slaat alleen cijfertekst op. Zolang de privésleutels uitsluitend bij de gebruiker berusten, heeft noch de beheerder noch de hostingpartij toegang tot de klartekst.

Wat is het verschil tussen server-side encryptie en E2EE in Nextcloud?

Bij server-side encryptie versleutelt de server de bestanden met sleutels die de server zelf beheert. Een beheerder met servertoegang kan die sleutels in principe inzien. Bij E2EE worden bestanden versleuteld voordat ze de client verlaten; de server ziet alleen cijfertekst en beschikt nooit over de sleutels.

Is Nextcloud E2EE geschikt voor teamgedeelde mappen?

De Nextcloud E2EE-app ondersteunt versleuteling op mapniveau, ook voor gedeelde mappen binnen een team. Elk teamlid ontvangt een versleutelde kopie van de mapsleutel. Zoeken in versleutelde bestanden is echter beperkt, omdat de server de inhoud niet kan indexeren. Organisaties moeten dit afwegen tegen de beveiligingswinst.

Hoe maakt een organisatie haar Nextcloud TLS-verbinding post-kwantumbestendig?

Door een hybride TLS 1.3-configuratie in te zetten waarbij ML-KEM (FIPS 203) gecombineerd wordt met een klassiek ECDH-sleuteluitwisselingsmechanisme. Browsers zoals Chrome en Firefox ondersteunen X25519MLKEM768 reeds. Op serverniveau vereist dit een recente versie van OpenSSL (3.x) of BoringSSL en correcte cipher-suite-configuratie.

Welke documentatie is nodig voor AVG artikel 32 en NIS-2 artikel 21?

Een organisatie documenteert de gehanteerde versleutelingsalgoritmen en sleutellengte, het sleutelbeheerproces (wie beheert, hoe worden sleutels geroteerd), de toegangscontroles, en de risicoafweging die tot deze keuzes leidde. Dit vormt onderdeel van het verwerkingsregister en het informatiebeveiligingsbeleid, en wordt op verzoek overlegd aan de Autoriteit Persoonsgegevens of de nationale NIS-2-toezichthouder.

Veelgestelde vragen

Kan de Nextcloud-beheerder bij E2EE bestanden meelezen?
Nee. Bij correct geconfigureerde Nextcloud E2EE-app worden bestanden versleuteld op het apparaat van de gebruiker voordat ze de server bereiken. De server slaat alleen cijfertekst op. Zolang de privu00e9sleutels uitsluitend bij de gebruiker berusten, heeft noch de beheerder noch de hostingpartij toegang tot de klartekst.
Wat is het verschil tussen server-side encryptie en E2EE in Nextcloud?
Bij server-side encryptie versleutelt de server de bestanden met sleutels die de server zelf beheert. Een beheerder met servertoegang kan die sleutels in principe inzien. Bij E2EE worden bestanden versleuteld voordat ze de client verlaten; de server ziet alleen cijfertekst en beschikt nooit over de sleutels.
Is Nextcloud E2EE geschikt voor teamgedeelde mappen?
De Nextcloud E2EE-app ondersteunt versleuteling op mapniveau, ook voor gedeelde mappen binnen een team. Elk teamlid ontvangt een versleutelde kopie van de mapsleutel. Zoeken in versleutelde bestanden is echter beperkt, omdat de server de inhoud niet kan indexeren. Organisaties moeten dit afwegen tegen de beveiligingswinst.
Hoe maakt een organisatie haar Nextcloud TLS-verbinding post-kwantumbestendig?
Door een hybride TLS 1.3-configuratie in te zetten waarbij ML-KEM (FIPS 203, voorheen Kyber) gecombineerd wordt met een klassiek ECDH-sleuteluitwisselingsmechanisme. Browsers zoals Chrome en Firefox ondersteunen X25519MLKEM768 reeds. Op serverniveau vereist dit een recente versie van OpenSSL (3.x of BoringSSL) en correcte cipher-suite-configuratie.
Welke documentatie is nodig voor AVG artikel 32 en NIS-2 artikel 21?
Een organisatie documenteert de gehanteerde versleutelingsalgoritmen en sleutellengte, het sleutelbeheerproces (wie beheert, hoe worden sleutels geroteerd), de toegangscontroles, en de risicoafweging die tot deze keuzes leidde. Dit vormt onderdeel van het verwerkingsregister en het informatiebeveiligingsbeleid, en wordt op verzoek overlegd aan de Autoriteit Persoonsgegevens of de nationale NIS-2-toezichthouder.