Klantbezitters versus klantbeheerde encryptiesleutels: Wat is het verschil en waarom is het belangrijk

Wie beheert de sleutels die uw gevoelige gegevens ontsleutelen? Dit bepaalt of uw organisatie echte gegevensprivacy bereikt of slechts een schijn van beveiliging creëert. Cloudproviders bieden standaard encryptie, en veel organisaties gaan ervan uit dat hun gegevens beschermd blijven zolang bestanden versleuteld zijn. Echter, de kracht van encryptie is veel minder belangrijk dan sleutelbeheer wanneer cloudproviders technisch in staat zijn om toegang te krijgen tot uw encryptiesleutels en uw gegevens te ontsleutelen zonder uw medeweten of toestemming.

Er bestaan drie verschillende modellen voor encryptiesleutelbeheer: door de provider beheerde sleutels, door de klant beheerde sleutels (BYOK), en door de klant beheerde en bewaarde sleutels (HYOK). Elk model biedt een ander niveau van controle over wie toegang heeft tot uw versleutelde gegevens. Het verschil tussen het beheren en het bezitten van sleutels wordt cruciaal wanneer overheidsinstanties dagvaardingen uitvaardigen, wanneer compliancekaders aantoonbare datasoevereiniteit vereisen, of wanneer organisaties moeten bewijzen dat zelfs hun cloudprovider geen toegang heeft tot gevoelige informatie.

Samenvatting voor Executives

Belangrijkste punt: Door de klant beheerde encryptiesleutels (BYOK) blijven in de omgeving van de cloudprovider, waar providers toegang kunnen krijgen tot deze sleutels bij juridische verzoeken. Door de klant beheerde en bewaarde sleutels (HYOK) blijven volledig onder controle van de klant en voorkomen volledig dat de provider toegang heeft.

Waarom dit belangrijk is: Organisaties die encryptie gebruiken via providerbeheer of BYOK lopen risico’s op het gebied van gegevensprivacy door overheidsverzoeken onder de CLOUD Act, bedreigingen van binnenuit bij de provider, en het niet voldoen aan compliancekaders die echte datasoevereiniteit vereisen, zoals GDPR na Schrems II en CMMC Level 3.

5 Belangrijkste Inzichten

1. Door de klant beheerde sleutels (BYOK) en door de klant beheerde en bewaarde sleutels (HYOK) zijn fundamenteel verschillende beveiligingsmodellen ondanks vergelijkbare namen. BYOK slaat door de klant gegenereerde sleutels op in de sleutelbeheerdienst van de provider, waar de provider technisch toegang behoudt. HYOK houdt sleutels exclusief onder controle van de klant in on-premises HSM’s of private infrastructuur.

2. De CLOUD Act stelt Amerikaanse wetshandhaving in staat om cloudproviders te dwingen klantgegevens overal ter wereld te ontsleutelen, vaak zonder de klant op de hoogte te stellen. Dit juridische kader betekent dat BYOK-encryptie geen bescherming biedt tegen wettige overheidsinzage via uw cloudprovider, ongeacht waar de gegevens fysiek zijn opgeslagen.

3. Datasoevereiniteit en gegevensprivacy zijn verschillende concepten die verschillende technische maatregelen vereisen. Gegevens opslaan in een specifieke geografische regio (soevereiniteit) voorkomt niet dat uw cloudprovider toegang heeft als zij de encryptiesleutels beheren. Sleutelbezit is essentieel voor echte privacybescherming.

4. Compliancekaders vereisen steeds vaker door de klant beheerde encryptiesleutels na de Schrems II-uitspraak die US-EU-gegevensoverdracht ongeldig verklaarde. GDPR, NIS2, CMMC Level 3 en FedRAMP High vereisen nu feitelijk encryptiemodellen waarbij providers geen toegang hebben tot klantgegevens.

5. De operationele afwegingen van door de klant beheerde sleutels betreffen complexiteit en kosten, niet beveiliging of functionaliteit. Organisaties kunnen met HYOK dezelfde encryptiekracht en applicatieprestaties behouden en tegelijk echte privacybescherming verkrijgen, hoewel sleutelbeheer extra infrastructuur en expertise vereist.

De Drie Modellen voor Encryptiesleutelbeheer

Wat zijn door de provider beheerde encryptiesleutels?

Door de provider beheerde encryptie is het standaardmodel waarbij cloudproviders alle encryptiesleutels genereren, opslaan en beheren binnen hun infrastructuur.

Wanneer organisaties gegevens uploaden naar cloudopslag, versleutelt de provider deze automatisch met sleutels die de provider beheert. Deze aanpak vereist geen klantconfiguratie en werkt transparant. De provider verzorgt sleutelrotatie, back-up en het volledige levenscyclusbeheer. Klanten krijgen versleutelde opslag zonder zelf encryptiekennis of sleutelbeheerinfrastructuur nodig te hebben.

Dit model creëert echter fundamentele privacykwetsbaarheden. De provider bezit zowel de versleutelde gegevens als de sleutels om deze te ontsleutelen, wat betekent dat zij altijd toegang kunnen krijgen tot klantgegevens wanneer zij dat willen of daartoe wettelijk worden verplicht. Wetshandhavingsinstanties kunnen de provider dagvaarden om klantgegevens te ontsleutelen en te overhandigen. Provider-medewerkers met de juiste toegang kunnen versleutelde informatie bekijken. Beveiligingsincidenten die de systemen van de provider compromitteren, stellen zowel gegevens als sleutels tegelijk bloot.

Wanneer door de provider beheerde sleutels acceptabel zijn:

• Niet-gevoelige gegevens zonder wettelijke vereisten
• Interne ontwikkel- en testomgevingen
• Publieke informatie die alleen integriteitsbescherming vereist
• Organisaties die volledig vertrouwen op de beveiliging en wettelijke naleving van hun cloudprovider

Wat is Bring Your Own Key (BYOK)?

BYOK-encryptie stelt klanten in staat om encryptiesleutels in hun eigen omgeving te genereren en deze te uploaden naar de sleutelbeheerdienst van de cloudprovider.

Klanten maken sleutels met hun eigen cryptografische tools en dragen deze vervolgens over aan de KMS-infrastructuur van de provider, zoals AWS KMS, Azure Key Vault of Google Cloud KMS. De provider slaat klantensleutels gescheiden op van door de provider gegenereerde sleutels en past extra toegangscontroles toe. Klanten kunnen sleutels intrekken of verwijderen uit de KMS van de provider, waardoor hun gegevens onleesbaar worden. Dit model geeft klanten meer controle over de levenscyclus van sleutels, terwijl de provider de operationele complexiteit van sleutelopslag en cryptografische bewerkingen afhandelt.

De belangrijkste beperking is dat BYOK-sleutels zich in de omgeving van de provider bevinden. De systemen van de provider voeren alle encryptie- en decryptiebewerkingen uit, wat betekent dat de infrastructuur van de provider toegang moet hebben tot het sleutelmateriaal. Hoewel providers strikte toegangscontroles en auditlogs implementeren, behouden zij de technische mogelijkheid om klantensleutels te gebruiken. Wetshandhaving kan providers dwingen om BYOK-sleutels te gebruiken om klantgegevens te ontsleutelen. Providerbeheerders met voldoende rechten kunnen toegang krijgen tot het sleutelmateriaal. Beveiligingsincidenten die de KMS-infrastructuur van de provider treffen, kunnen klantensleutels blootstellen.

BYOK-implementatieproces:

1. Klant genereert encryptiesleutels met lokale cryptografische tools of HSM’s
2. Klant draagt sleutels veilig over aan de KMS van de provider via versleutelde kanalen
3. Provider slaat sleutels op in hun KMS-infrastructuur met klant-specifieke toegangsbeleid
4. Alle encryptie-/decryptiebewerkingen vinden plaats binnen de provideromgeving met klantensleutels
5. Klant kan sleutels roteren, intrekken of verwijderen via de beheerinterface van de provider

BYOK-beperkingen voor privacybescherming:

• Sleutels opgeslagen in de KMS-infrastructuur van de provider
• Provider kan sleutels gebruiken voor wettelijke naleving, administratieve doeleinden of bij compromittering
• CLOUD Act maakt overheidsinzage via provider mogelijk zonder klantmelding
• Provider-medewerkers met juiste toegang kunnen sleutels gebruiken om gegevens te ontsleutelen

Wat is Hold Your Own Key (HYOK)?

HYOK houdt encryptiesleutels exclusief onder controle van de klant in on-premises hardwarebeveiligingsmodules of private cloudinfrastructuur waar de provider nooit toegang toe heeft.

Klanten genereren en bewaren sleutels in hun eigen HSM’s of sleutelbeheersystemen. Wanneer cloudapplicaties gegevens moeten versleutelen of ontsleutelen, sturen ze verzoeken naar de sleutelbeheerinfrastructuur van de klant in plaats van providerbeheerde sleutels te gebruiken. De encryptiesleutels komen nooit in de omgeving van de provider terecht, en de provider heeft geen technische mogelijkheid om toegang te krijgen. Deze architectuur maakt zero-knowledge-systemen mogelijk waarbij de provider klantgegevens niet kan ontsleutelen, zelfs niet als zij daartoe wettelijk worden verplicht.

HYOK biedt echte privacybescherming omdat providers geen toegang hebben om klantinformatie te ontsleutelen. Wetshandhavingsdagvaardingen gericht aan de provider leveren geen ontsleutelde gegevens op, omdat de provider geen encryptiesleutels bezit. Beveiligingsincidenten bij de provider stellen geen sleutelmateriaal bloot. Providerbeheerders kunnen geen versleutelde inhoud benaderen, ongeacht hun rechtenniveau. Alleen de klantorganisatie bepaalt wanneer en hoe encryptiesleutels worden gebruikt.

HYOK-implementatiebenaderingen:

• On-premises HSM’s geïntegreerd met cloudworkloads
• Private cloud-inzet waarbij de klant volledige infrastructuurcontrole heeft
• Hybride architecturen met klantensleutelservers en providercomputercapaciteit
• Air-gapped systemen voor maximale beveiligingsvereisten

HYOK-voordelen voor privacy:

• Sleutels verlaten nooit de controle van de klant
• Provider heeft geen technische mogelijkheid om gegevens te ontsleutelen
• Bescherming tegen wettige overheidsinzage via de provider
• Klant beheert alle levenscyclusoperaties van sleutels zonder tussenkomst van de provider

Waarom Toegang tot Sleutels door de Provider Gegevensprivacy Vernietigt

Hoe maakt de CLOUD Act overheidsinzage mogelijk zonder medeweten van de klant?

De Clarifying Lawful Overseas Use of Data (CLOUD) Act stelt Amerikaanse wetshandhaving in staat om Amerikaanse technologiebedrijven te dwingen gegevens te verstrekken die overal ter wereld zijn opgeslagen, ongeacht de fysieke locatie van die gegevens.

De in 2018 aangenomen CLOUD Act loste een juridisch geschil op over de vraag of Amerikaanse bevelen bedrijven konden verplichten gegevens te produceren die op buitenlandse servers zijn opgeslagen. De wet bepaalt dat in de VS gevestigde cloudproviders moeten voldoen aan geldige Amerikaanse juridische procedures voor alle gegevens die zij beheren, waardoor de geografische locatie van gegevens irrelevant wordt wanneer providers de encryptiesleutels beheren. Wetshandhaving kan een bevel of dagvaarding verkrijgen waarmee de provider wordt verplicht klantgegevens te ontsleutelen en te overhandigen. De provider moet hieraan voldoen, ongeacht of de gegevens zich op servers in Europa, Azië of elders bevinden.

Nationale veiligheidsbrieven bevatten vaak zwijgplichtsbepalingen die providers verbieden klanten te informeren dat hun gegevens zijn ingezien. Klanten die providerbeheer of BYOK-encryptie gebruiken, komen mogelijk nooit te weten dat wetshandhaving hun gevoelige informatie heeft ontsleuteld en bekeken. De provider heeft de technische mogelijkheid om encryptiesleutels te gebruiken, wetshandhaving heeft de wettelijke bevoegdheid om dat af te dwingen, en klanten hebben geen technische controle om toegang te voorkomen.

Dit kader betekent dat datasoevereiniteitsmaatregelen, zoals het opslaan van gegevens in specifieke geografische regio’s, geen privacybescherming bieden wanneer providers de encryptiesleutels beheren. Europese gegevens die op Europese servers zijn opgeslagen, blijven toegankelijk voor Amerikaanse wetshandhaving als een Amerikaanse cloudprovider de encryptiesleutels bezit.

Implicaties van de CLOUD Act voor encryptiemodellen:

• Door de provider beheerde sleutels: Provider kan gegevens ontsleutelen bij geldig juridisch verzoek
• BYOK-sleutels in provider KMS: Provider kan klantensleutels gebruiken om gegevens te ontsleutelen bij wettelijke verplichting
• HYOK-sleutels onder klantcontrole: Provider kan gegevens niet ontsleutelen omdat zij geen toegang tot sleutels hebben

Wat is de SHIELD Act en waarom is deze niet voldoende?

De Securing and Handling of Internet and Electronic Data (SHIELD) Act, voorgesteld maar nog niet aangenomen, probeert te voorkomen dat buitenlandse overheden toegang krijgen tot Amerikaanse gegevens via cloudproviders.

De wetgeving zou cloudproviders verbieden om te voldoen aan verzoeken van buitenlandse overheden voor gegevens van Amerikaanse personen zonder goedkeuring van een Amerikaanse rechtbank. Het doel is wederzijdse bescherming te creëren, vergelijkbaar met wat de CLOUD Act biedt voor Amerikaanse wetshandhaving die toegang zoekt tot in het buitenland opgeslagen gegevens. Zelfs als de wet wordt aangenomen, zou de SHIELD Act geen betrekking hebben op toegang door de Amerikaanse overheid tot klantgegevens, zou het de technische mogelijkheid van providers om klantinformatie te ontsleutelen niet wegnemen, en zou het de fundamentele privacykwetsbaarheid van door providers beheerde encryptiesleutels niet veranderen.

Organisaties die zich zorgen maken over gegevensprivacy kunnen niet vertrouwen op voorgestelde wetgeving die mogelijk nooit wordt aangenomen en het kernprobleem van toegang tot sleutels door de provider niet oplost. Technische maatregelen via door de klant beheerde encryptiesleutels bieden betrouwbare privacybescherming, ongeacht wetswijzigingen.

Waarom voorgestelde wetgeving technische maatregelen niet kan vervangen:

• Wetten kunnen veranderen of worden ingetrokken
• Handhaving varieert per rechtsbevoegdheid en politieke situatie
• Zwijgplichtsbepalingen voorkomen dat klanten weten wanneer toegang plaatsvindt
• Technische maatregelen zoals HYOK elimineren de mogelijkheid van de provider om toegang te krijgen, ongeacht het juridische kader

Hoe heeft Schrems II de vereisten voor datasoevereiniteit veranderd?

De Schrems II-uitspraak van het Europese Hof van Justitie in 2020 maakte het Privacy Shield-kader ongeldig, dat Amerikaanse bedrijven toestond om EU-persoonsgegevens naar de Verenigde Staten over te dragen.

Het hof oordeelde dat Amerikaanse toezichtswetten, met name FISA Sectie 702 en Executive Order 12333, onvoldoende bescherming bieden voor gegevens van EU-burgers. Amerikaanse cloudproviders die onder de Amerikaanse wet vallen, kunnen niet garanderen dat EU-gegevens privé blijven voor toegang door de Amerikaanse overheid. De uitspraak stelde specifiek dat de Amerikaanse wet inlichtingendiensten toestaat om gegevens die door Amerikaanse bedrijven worden beheerd, te benaderen zonder voldoende rechterlijk toezicht of rechtsmiddelen voor EU-burgers.

Deze beslissing veranderde fundamenteel hoe Europese organisaties cloudencryptie moeten benaderen. Gegevens alleen in EU-regio’s opslaan voldoet niet aan de GDPR-vereisten als Amerikaanse providers de encryptiesleutels beheren en kunnen worden gedwongen deze gegevens te ontsleutelen onder de Amerikaanse wet. De uitspraak vereist feitelijk technische maatregelen die provider-toegang voorkomen, waardoor organisaties worden gedwongen tot door de klant beheerde encryptiesleutels of private inzetmodellen.

Implicaties van Schrems II voor sleutelbeheer:

• EU-organisaties kunnen niet vertrouwen op alleen contractuele gegevensbeschermingsovereenkomsten
• Technische maatregelen die provider-toegang voorkomen zijn nu vereist voor US-EU-gegevensoverdracht
• Door de klant beheerde encryptiesleutels maken GDPR-naleving mogelijk door provider-toegang tot gegevens uit te sluiten
• NIS2-richtlijn versterkt vereisten voor entiteiten in kritieke sectoren

Welke Compliancekaders Vereisen Sleutelbezit door de Klant?

Regelgevende vereisten schrijven steeds vaker encryptiemodellen voor waarbij providers geen toegang hebben tot klantgegevens, vooral voor overheidscontractanten, kritieke infrastructuur en entiteiten die EU-persoonsgegevens verwerken.

CMMC Level 3 voor defensie-aannemers die Beschermde informatie over defensie verwerken, vereist dat cryptografische mechanismen worden toegepast om ongeoorloofde openbaarmaking tijdens overdracht en opslag te voorkomen. De nadruk van het kader op CUI-bescherming en de afstemming met NIST 800-172 versterkte beveiligingsvereisten betekent feitelijk dat sleutels onder controle van de klant moeten zijn, zodat provider-toegang tot geclassificeerde of gevoelige defensie-informatie wordt voorkomen.

FedRAMP High-autorisatie en DoD Impact Level 5-workloads vereisen cryptografische bescherming die cloudproviders verhindert toegang te krijgen tot klantgegevens. Deze kaders gaan ervan uit dat gegevens die door federale instanties of defensiesystemen worden verwerkt, bescherming vereisen tegen alle partijen buiten de klantorganisatie, inclusief de hostingprovider.

GDPR Artikel 32 vereist passende technische maatregelen om gegevensbeveiliging te waarborgen, en na Schrems II geeft de richtlijn aan dat encryptie alleen onvoldoende is wanneer providers de sleutels beheren en kunnen worden gedwongen gegevens te ontsleutelen onder buitenlandse wetgeving. Organisaties die EU-persoonsgegevens overdragen aan landen zonder adequate gegevensbeschermingswetten moeten aanvullende maatregelen implementeren, waarbij door de klant beheerde encryptiesleutels een van de weinige technische maatregelen zijn die aan deze vereiste voldoen.

Compliancekaders die sleutelbezit door de klant vereisen:

• CMMC Level 3 voor CUI-bescherming in de defensieketen
• FedRAMP High en DoD IL5 voor federale overheidsgegevens
• GDPR voor EU-persoonsgegevens die na Schrems II naar derde landen worden overgedragen
• NIS2 voor essentiële en belangrijke entiteiten in kritieke sectoren
• Duitse BDSG en Franse datasoevereiniteitsvereisten

Technische Implementatie: Hoe Elk Model Werkt

Hoe implementeren cloudproviders BYOK?

Cloudproviders implementeren BYOK via sleutelbeheerdiensten die door de klant gegenereerde sleutels accepteren, terwijl zij operationele controle over de encryptie-infrastructuur behouden.

Klanten genereren encryptiesleutels met lokale tools zoals OpenSSL, cloudprovider CLI’s of hardwarebeveiligingsmodules. De klant uploadt het sleutelmateriaal vervolgens naar de KMS van de provider via beveiligde API-aanroepen die TLS-encryptie gebruiken om sleutels tijdens verzending te beschermen. De provider slaat klantensleutels op in hun KMS-infrastructuur, vaak in FIPS 140-2 gevalideerde HSM’s, met toegangscontroles die bepalen welke klantaccounts en diensten elke sleutel mogen gebruiken.

Wanneer applicaties gegevens moeten versleutelen, roepen ze de KMS-API van de provider aan om de bewerking uit te voeren. De KMS gebruikt de klantensleutel om de gegevens te versleutelen en retourneert de ciphertext. Ontsleutelen werkt op vergelijkbare wijze: de applicatie stuurt ciphertext naar de KMS, die de klantensleutel gebruikt om deze te ontsleutelen en de plaintext retourneert. Alle cryptografische bewerkingen vinden plaats binnen de infrastructuur van de provider met klantensleutels die in de systemen van de provider verblijven.

BYOK-werkstroom:

1. Klant genereert sleutel met lokale cryptografische tools
2. Klant uploadt sleutel naar provider KMS via versleutelde API-aanroep
3. Provider slaat sleutel op in hun KMS met klant-specifiek toegangsbeleid
4. Applicaties vragen encryptie-/decryptiebewerkingen aan bij provider KMS
5. Provider KMS voert cryptografische bewerkingen uit met klantensleutel
6. Provider retourneert resultaten aan applicatie

Hoe behoudt HYOK klantcontrole?

HYOK-implementaties houden encryptiesleutels in door de klant beheerde infrastructuur en voeren cryptografische bewerkingen buiten de omgeving van de provider uit.

Klanten implementeren on-premises HSM’s of sleutelbeheersystemen die nooit sleutels synchroniseren met de infrastructuur van de provider. Wanneer cloudapplicaties gegevens moeten versleutelen of ontsleutelen, maken ze verbinding met het sleutelbeheersysteem van de klant via beveiligde netwerkverbindingen. De infrastructuur van de klant voert de cryptografische bewerking uit en retourneert de resultaten, zodat sleutels nooit de controle van de klant verlaten. Sommige implementaties gebruiken private cloud-inzet waarbij de klant de volledige infrastructuurstack beheert, waardoor provider-toegang technisch onmogelijk is.

Geavanceerde HYOK-architecturen implementeren encryptie op applicatieniveau, waarbij gegevens op clientapparaten worden versleuteld voordat ze naar cloudopslag worden verzonden. De cloudprovider ontvangt alleen ciphertext en heeft geen mechanisme om deze te ontsleutelen. Deze aanpak maakt zero-knowledge-systemen mogelijk waarbij de provider letterlijk geen toegang heeft tot klantgegevens, ongeacht wettelijke verplichtingen.

HYOK-werkstroom:

1. Klant implementeert HSM of sleutelbeheersysteem in hun infrastructuur
2. Klant genereert en bewaart alle encryptiesleutels lokaal
3. Cloudapplicaties maken verbinding met het sleutelbeheersysteem van de klant
4. Systeem van de klant voert encryptie-/decryptiebewerkingen uit
5. Sleutels verlaten nooit de controle van de klant of komen in de omgeving van de provider
6. Provider ontvangt alleen versleutelde gegevens en kan deze niet ontsleutelen

Beveiligings- en Compliance-implicaties

Tegen welke bedreigingen beschermt sleutelbezit door de klant?

Door de klant beheerde encryptiesleutels elimineren volledige categorieën bedreigingen die bij providerbeheer of BYOK onopgelost blijven.

Toegang door wetshandhaving via providercompliance verdwijnt wanneer providers geen ontsleutelmogelijkheid hebben. Dagvaardingen en bevelen gericht aan de provider leveren geen ontsleutelde gegevens op, omdat de provider geen encryptiesleutels bezit. Inlichtingendiensten kunnen providers niet dwingen tot medewerking als providers technisch geen toegang hebben tot klantinformatie. Deze bescherming geldt ongeacht welke overheid het verzoek doet en ongeacht het juridische kader dat openbaarmaking afdwingt.

Kwaadwillende insiders bij de cloudprovider kunnen geen toegang krijgen tot klantgegevens wanneer sleutels buiten de infrastructuur van de provider blijven. Beveiligingsincidenten bij de provider die administratieve systemen, KMS-infrastructuur of back-ups compromitteren, stellen geen encryptiesleutels bloot en maken ontsleuteling van gegevens onmogelijk. Externe auditors, aanbieders van beveiligingsdiensten en andere partijen met toegang tot providersystemen kunnen klantgegevens niet ontsleutelen.

Bedreigingen beperkt door sleutelbezit door de klant:

• Overheidsinzage via wettelijke providercompliance (CLOUD Act-scenario’s)
• Toegang door insiders van de provider tot versleutelde gegevens
• Beveiligingsincidenten bij de provider waarbij zowel gegevens als sleutels worden blootgesteld
• Grensoverschrijdende toegang tot gegevens die datasoevereiniteitsmaatregelen omzeilt
• Toegang door derden via providersystemen of partnerschappen

Wat zijn de operationele afwegingen?

Door de klant beheerde encryptiesleutels brengen operationele complexiteit en kosten met zich mee die organisaties moeten afwegen tegen privacy- en compliancevoordelen.

De impact op prestaties varieert per implementatie. HYOK-oplossingen die netwerkverkeer naar klantensleutelbeheersystemen vereisen, voegen latentie toe aan encryptiebewerkingen in vergelijking met provider-native KMS. Organisaties moeten zorgen voor betrouwbare netwerkconnectiviteit tussen cloudworkloads en on-premises sleutelbeheerinfrastructuur. Private inzetmodellen waarbij klanten de volledige infrastructuur beheren, elimineren echter netwerkvertraging terwijl sleutelbezit behouden blijft.

Beschikbaarheid en disaster recovery worden complexer wanneer klanten encryptiesleutels beheren. Organisaties moeten HSM-redundantie, sleutelback-up en herstelprocedures implementeren zonder te vertrouwen op providerbeheer. Sleutelbeheer vereist gespecialiseerde expertise die veel organisaties niet in huis hebben. De kosten van HSM-hardware, beveiligde faciliteiten en gekwalificeerd personeel liggen hoger dan de nul extra kosten van door de provider beheerde encryptie.

Operationele aandachtspunten:

• Prestaties: Mogelijke latentie bij sleutelbewerkingen over het netwerk versus provider-native KMS
• Beschikbaarheid: Klantverantwoordelijkheid voor redundantie en disaster recovery van sleutelbeheerinfrastructuur
• Complexiteit: Vereist encryptie-expertise en procedures voor sleutelbeheer
• Kosten: HSM-hardware, faciliteiten, personeel versus gratis providerbeheer

Wanneer is HYOK of private inzet vereist?

Bepaalde compliancevereisten, dreigingsmodellen en gevoeligheidsniveaus van gegevens maken door de klant beheerde encryptiesleutels verplicht in plaats van optioneel.

Organisaties die CUI verwerken voor defensiecontracten op CMMC Level 3 moeten provider-toegang voorkomen om te voldoen aan de verhoogde beveiligingsvereisten. Federale instanties die Impact Level 5-gegevens verwerken of FedRAMP High-autorisatie nastreven, hebben cryptografische bescherming nodig waarbij providers niet kunnen ontsleutelen. Europese organisaties die persoonsgegevens overdragen aan Amerikaanse providers na Schrems II moeten technische maatregelen implementeren die toegang door de Amerikaanse overheid via providercompliance voorkomen.

Zero-trust-architecturen die ervan uitgaan dat alle netwerksegmenten en dienstverleners mogelijk gecompromitteerd zijn, vereisen door de klant beheerde sleutels. Organisaties in vijandige dreigingsomgevingen waar statelijke actoren providers kunnen dwingen tot medewerking, hebben encryptiemodellen nodig waarbij providers technisch niet kunnen helpen. Kritieke infrastructuur-entiteiten onder NIS2-vereisten moeten aantonen dat essentiële diensten beschermd blijven, zelfs als cloudproviders beveiligingsincidenten of wettelijke verplichtingen ondervinden.

Scenario’s waarbij sleutelbezit door de klant vereist is:

• CMMC Level 3 CUI-bescherming voor defensie-aannemers
• FedRAMP High en DoD IL5 federale workloads
• GDPR-conforme EU-US-gegevensoverdracht na Schrems II
• Overheids- en defensie-geclassificeerde informatiesystemen
• Financiële sector intellectueel eigendom en handelsalgoritmen
• Zorgsystemen die patiëntprivacy tegen alle externe partijen beschermen

Uw Gegevensprivacybehoeften Gaan Boven Alle Andere Encryptiesleutelvariabelen en -beslissingen

Het verschil tussen door de klant beheerde en door de klant beheerde en bewaarde encryptiesleutels bepaalt of organisaties echte gegevensprivacy bereiken of slechts een schijn van beveiliging creëren. BYOK-modellen die door de klant gegenereerde sleutels opslaan in providerinfrastructuur maken nog steeds provider-toegang mogelijk wanneer juridische processen samenwerking afdwingen of wanneer beveiligingsincidenten providersystemen compromitteren. De CLOUD Act en vergelijkbare juridische kaders maken de geografische locatie van gegevens irrelevant wanneer providers de encryptiesleutels beheren en kunnen worden gedwongen klantinformatie te ontsleutelen zonder kennisgeving.

Door de klant beheerde encryptiesleutels via HYOK-implementatie of private inzet zijn het enige model dat beschermt tegen wettige overheidsinzage via providers, bedreigingen van binnenuit bij de provider en complianceproblemen die ontstaan wanneer providers toegang hebben tot versleutelde gegevens. Organisaties die onder CMMC Level 3, FedRAMP High of GDPR-vereisten na Schrems II vallen, merken steeds vaker dat sleutelbezit door de klant is verschoven van optionele beveiligingsversterking naar verplichte compliance-eis.

De operationele afwegingen betreffen complexiteit en kosten, niet beveiliging of functionaliteit. Organisaties kunnen met door de klant beheerde sleutels dezelfde encryptiekracht en applicatiemogelijkheden behouden, terwijl zij de privacybescherming verkrijgen die compliancekaders nu eisen. Kiteworks levert deze mogelijkheid via private inzetopties die klanten volledige controle geven over encryptiesleutels, provider-toegang tot gevoelige gegevens elimineren en echte datasoevereiniteit mogelijk maken die voldoet aan de strengste regelgevingseisen.

Hoe Kiteworks Klantgestuurde Encryptie Levert

Kiteworks implementeert door de klant beheerde encryptie via private inzetopties waarmee organisaties volledige controle krijgen over encryptiesleutels en gegevensbeheer.

De Private Content Network-architectuur wordt ingezet on-premises, in private cloudomgevingen of in air-gapped netwerken waar klanten de volledige infrastructuurstack beheren. AES-256 Encryptie beschermt alle gegevens in rust met sleutels die nooit de infrastructuur van de klant verlaten. Medewerkers en ondersteunend personeel van Kiteworks hebben geen toegang tot klantensleutels of tot het ontsleutelen van klantgegevens, waardoor een echte zero-knowledge-architectuur ontstaat.

Integratie met Hardware Security Modules biedt FIPS 140-2 Level 3-bescherming voor encryptiesleutels met sabotagebestendige hardware onder exclusieve controle van de klant. Organisaties kunnen hun eigen procedures voor sleutelbeheer, rotatieschema’s en toegangscontroles implementeren zonder betrokkenheid van Kiteworks. Het platform ondersteunt zowel on-premises HSM-apparaten als door de klant beheerde cloud-HSM-diensten.

Private inzet elimineert de privacykwetsbaarheden die inherent zijn aan multi-tenant cloudarchitecturen. Wetshandhavingsdagvaardingen kunnen Kiteworks niet dwingen klantgegevens te ontsleutelen, omdat Kiteworks technisch niet in staat is dit te doen. De CLOUD Act wordt irrelevant wanneer de dienstverlener nooit klantensleutels bezit. Organisaties bereiken echte datasoevereiniteit die voldoet aan de post-Schrems II-vereisten voor GDPR-naleving.

Het platform consolideert beveiligde e-mail, bestandsoverdracht, beheerde bestandsoverdracht en webformulieren in één omgeving met consistente encryptie en toegangscontrole. Deze aanpak elimineert de beveiligingsgaten die ontstaan wanneer organisaties afzonderlijke point solutions gebruiken met verschillende sleutelbeheer voor diverse communicatiekanalen.

Wilt u meer weten over het maximaliseren van gegevensprivacy met door de klant beheerde encryptiesleutels? Plan een persoonlijke demo.

Aanvullende bronnen

• Blog Post
  Publieke versus private sleutelencryptie: een gedetailleerde uitleg
• Blog Post
  Essentiële beste practices voor gegevensencryptie
• eBook Top 10 trends in gegevensencryptie: een diepgaande analyse van AES-256
• Blog Post
  E2EE verkennen: praktijkvoorbeelden van end-to-end encryptie
• Blog Post
  Ultieme gids voor AES 256-encryptie: gegevensbescherming versterken voor onbreekbare beveiliging