Wie kan data werkelijk afdwingen?
"Versleuteld in rust" is de meest geruststellende zinsnede in de zakelijke IT, en een van de minst informatieve. De vraag die de blootstelling werkelijk bepaalt, is eenvoudiger en lastiger: wie heeft de sleutels, en wie kan gedwongen worden ze te gebruiken?
Onderdeel van de pijlerreeks Soevereiniteit die te operationaliseren is.
In de begeleidende post betoogden we dat een gehaalde audit een levende afhankelijkheid kan verhullen. Hier volgt het scherpste voorbeeld van dat gat. Twee systemen kunnen allebei "versleuteld in rust" zijn en toch volstrekt verschillend scoren op soevereiniteit: bij het ene levert een rechtmatig bevel aan de aanbieder de data in platte tekst op; bij het andere levert hetzelfde bevel cijfertekst op die niemand ter plaatse kan lezen. Het verschil zit niet in de versleuteling. Het zit in sleutelbeheer.
Deze post gaat over waar de sleutels leven, wie gedwongen kan worden ze te gebruiken, en hoe zo te bouwen dat het eerlijke antwoord op een buitenlands rechtsbevel luidt: "er is niets leesbaars om te overhandigen."
Versleuteling is noodzakelijk. Het is niet het hele antwoord.
Versleuteling verdedigt data tegen de verkeerde mensen die de bytes in handen krijgen. Ze doet uit zichzelf niets tegen de juiste mensen die rechtmatig bevolen worden te ontsleutelen. Wie de ontsleutelingssleutels bij de aanbieder laat, ook binnen een "EU-regio", heeft ermee te maken dat een dwangbevel aan het moederbedrijf van die aanbieder de data kan bereiken, omdat de aanbieder feitelijk in staat is die te leveren.
De bruikbare vraag is dus niet "is het versleuteld?" maar "wie kan gedwongen worden er platte tekst van te maken?", precies de splitsing die hierboven te zien is.
Daarom dichten "bring your own key"-constructies die de sleutel alsnog binnen de eigen key manager van de aanbieder opslaan, het gat niet volledig: de aanbieder kan nog steeds gedwongen worden die te gebruiken. Wat het gat wél dicht, zijn sleutels die buiten het bereik van de aanbieder worden gehouden, bij de organisatie zelf, of bij een EU-bestuurde entiteit die niet onder het buitenlandse bevel valt.
De lagen die er werkelijk toe doen
Echte gegevensbescherming is niet één beheersmaatregel maar een stapel ervan, elk met een antwoord op een andere dreiging. Dit is het model, beschreven naar wat elke laag doet in plaats van naar enig product.
| Laag | Waartegen het beschermt | Hoe "goed" eruitziet |
|---|---|---|
| Tijdens transport | Onderschepping op de lijn | Sterke transportversleuteling overal, intern en extern |
| In rust (op veldniveau) | Massale diefstal van opgeslagen data | Geauthenticeerde versleuteling op gevoelige velden; cijfertekst kan geen sleutel of filter zijn |
| Sleutelafleiding | Eén gelekte sleutel die alles opent | Sleutels per doel afgeleid, zodat een sleutel voor de ene taak de andere niet kan ontsleutelen |
| Sleutelrotatie | Een gecompromitteerde sleutel die eeuwig geldig blijft | Geversioneerde cijfertekst, zodat sleutels roteren zonder storing door massale herversleuteling |
| Sleutelbeheer | Rechtmatige dwang jegens de aanbieder | Sleutels bij de organisatie zelf of bij een onafhankelijke EU-entiteit, buiten het bereik van de aanbieder |
| Tijdens gebruik | Blootstelling tijdens verwerking | Hardware-geïsoleerde uitvoering met attestatie, met open ogen (zie hieronder) |
De eerste twee zijn de basisvoorwaarden. De onderscheidende factoren zitten lager: per doel afgeleide sleutels betekenen dat een inbreuk in één subsysteem een aanvaller niet het hele landschap in handen geeft; geversioneerde cijfertekst betekent dat sleutels routinematig geroteerd kunnen worden in plaats van dat rotatie een risicovolle gebeurtenis is; en sleutelbeheer is de laag die de dwangvraag beslist.
En "versleuteling tijdens gebruik"?
De nieuwste horizon is het verwerken van data terwijl die versleuteld blijft, binnen hardware-geïsoleerde omgevingen die zelfs de beheerder naar verluidt niet kan lezen, met cryptografische attestatie dat de isolatie standhield. Het is werkelijk nuttig en de moeite waard om te gebruiken, maar de marketing verdient behoedzaamheid. Eind 2025 demonstreerden onderzoekers aanvallen die verschillende gangbare hardware-isolatietechnologieën omzeilden met een goedkope fysieke interposer, en die zelfs attestatie vervalsten (BleepingComputer, 2025). Voor specifiek het soevereiniteitsdreigingsmodel, waarin de tegenstander die zorgen baart juist de partij is met fysieke toegang tot de hardware, verkleint confidential computing het venster, maar vervangt het uit zichzelf geen sleutels in eigen beheer. De eerlijke stack gebruikt beide.
Bewijs dat niet stilletjes te bewerken is
Er speelt een tweede vraag rond beheer die minder aandacht krijgt: wie kan het verslag van wat er gebeurd is herschrijven? Een audittrail die de beheerder stilzwijgend kan wijzigen is geen bewijs; het is een verhaal.
Het architecturale antwoord is een tamper-evident, hash-geketende audittrail, elke regel cryptografisch geketend aan de vorige, beschermd door een integriteitssleutel, en achteraf verifieerbaar. De ontwerpkeuze die het echt maakt is contra-intuïtief: de trail moet fail closed gaan. Ontbreekt de integriteitssleutel, dan hoort het systeem de handeling te weigeren in plaats van een regel te schrijven die later niet te bewijzen valt. Beter een handeling afwijzen dan iets onverifieerbaars vastleggen.
Hoe de Soveryne Cloud Foundation omgaat met sleutels en bewijs
We hebben de Soveryne Cloud Foundation gebouwd rond het principe waarvoor deze hele post pleit: soevereiniteit wordt beslist bij de sleutelgrens, dus daar hebben we het ingenieurswerk neergelegd.
Data wordt end-to-end versleuteld, tijdens transport en in rust, met sleutels die binnen de EU-jurisdictie blijven, niet in de key manager van een buitenlandse aanbieder, zodat een bevel gericht aan een buitenlandse aanbieder alleen cijfertekst oplevert. Gevoelige velden worden afzonderlijk versleuteld met per doel afgeleide sleutels, zodat één compromittering niet doorwerkt, en cijfertekst is geversioneerd voor naadloze sleutelrotatie in plaats van dat rotatie eens per decennium een noodgeval is. Elke geprivilegieerde handeling wordt weggeschreven naar een tamper-evident, hash-geketende audittrail die fail closed gaat zonder de integriteitssleutel, zodat het verslag van wie wat deed te bewijzen valt en niet alleen te beweren. En omdat AI- en LLM-inferentie op EU-soevereine infrastructuur draaien, passeert de data die naar een model gaat nooit de sleutelgrens die zojuist is getrokken.
Voor de strengste posities voegt het Soveryne-abonnement een toegewijde omgeving toe met eigen inferentie-GPU's en on-premises opties, plus kennisoverdracht aan het eigen team, zodat de sleutels, en de zeggenschap erover, bij de organisatie blijven.
Veelgestelde vragen
Geldt de CLOUD Act ook als de data versleuteld is? Dat hangt af van wie de sleutels heeft. Kan de aanbieder gedwongen worden te ontsleutelen, dan verslaat versleuteling het bevel niet. Liggen de sleutels bij de organisatie zelf of bij een onafhankelijke EU-entiteit buiten het bereik van de aanbieder, dan levert het bevel alleen cijfertekst op.
Wat is het verschil tussen BYOK en HYOK? "Bring your own key" slaat de sleutel doorgaans alsnog op in de key manager van de aanbieder, waardoor die gedwongen kan worden hem te gebruiken. Eigen sleutelbeheer ("hold your own key") houdt de sleutel volledig buiten de aanbieder, en dat is wat de aanbieder daadwerkelijk het vermogen ontneemt om platte tekst te produceren.
Is "versleuteld in rust" genoeg voor datasoevereiniteit? Nee. Het beschermt tegen diefstal van opgeslagen data, maar niet tegen rechtmatige dwang jegens degene die de sleutels heeft. Sleutelbeheer, niet versleuteling alleen, beslist de soevereiniteitsvraag.
Lost confidential computing het risico op buitenlandse toegang op? Het helpt door data tijdens verwerking te beschermen, maar recent onderzoek laat zien dat hardware-isolatie met fysieke toegang aanvalbaar is, precies het scenario waar het bij soevereiniteit om draait. Gebruik het naast sleutels in eigen beheer, niet in plaats daarvan.
De bytes doen er niet toe als een ander de sleutel heeft die ze weer in woorden verandert. Zie hoe de Soveryne Cloud Foundation het sleutelbeheer, en de audittrail, binnen de EU-jurisdictie houdt: verken het platform, of lees het begeleidende stuk over waarom compliance geen soevereiniteit is.
Bronnen
- The Register, Microsoft "cannot guarantee" data sovereignty (2025), https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
- BleepingComputer, hardware-isolation (TEE) attack research (2025), https://www.bleepingcomputer.com/news/security/teefail-attack-breaks-confidential-computing-on-intel-amd-nvidia-cpus/
- Public Sector Network, encryption doesn't guarantee sovereignty, https://publicsectornetwork.com/insight/cloud-act-and-data-protection-encryption-doesnt-guarantee-sovereignty
- Utimaco, achieving data sovereignty through key control, https://utimaco.com/news/blog-posts/achieve-data-sovereignty-gaining-control-over-encryption-keys-three-approaches
- CSIS, the CLOUD Act and transatlantic trust, https://www.csis.org/analysis/cloud-act-and-transatlantic-trust
In de begeleidende post is betoogd dat soevereiniteit een draaiknop is, geen muur. Dit is hoe die draaiknop wordt gebouwd, en, minstens zo belangrijk, hoe wordt aangetoond dat hij daadwerkelijk ergens op aangesloten zit.
Lees het volgende deel
Elke audit op de kalender doorstaan en toch niet de eigen infrastructuur beheersen, het kan allebei tegelijk waar zijn. Compliance en soevereiniteit zijn niet hetzelfde, en die twee door elkaar halen is op dit moment de duurste vergissing in de Europese IT.
Lees het bijbehorende artikel
