Versleutelingsconcepten
Proces op hoofdlijnen
Jij beheert een hoofdsleutel in je cloud die OpenAI nooit te zien krijgt
Je hoofdsleutel wordt gebruikt om data-encryptiesleutels (DEK's) te versleutelen die OpenAI gebruikt
OpenAI gebruikt de DEK's om je gegevens in rust te versleutelen. Een DEK wordt versleuteld met je hoofdsleutel, waardoor een eDEK (versleutelde DEK) ontstaat die samen met je gegevens wordt opgeslagen
Om de gegevens te lezen, neemt OpenAI de eDEK, vraagt je KMS om deze te ontsleutelen naar een DEK en ontsleutelt daarna je gegevens
Hoe werkt EKM-versleuteling?
Raadpleeg ons artikel voor gedetailleerde informatie: Overzicht van OpenAI Enterprise Key Management (EKM)
Slaat OpenAI mijn DEK's op?
Nee, we slaan de versleutelde DEK's (eDEK's) op, die door je KMS worden gegenereerd. Om de gegevens te ontsleutelen, vragen we je KMS om de eDEK terug te ontsleutelen naar de DEK.
Cachet OpenAI mijn DEK's?
Ja, alleen in het geheugen. Dit gebeurt om prestatieredenen, zodat je KMS niet bij elke aanvraag voor gegevensversleuteling of -decryptie wordt aangeroepen. DEK's worden nooit naar opslag geschreven.
Cloudmachtigingen
Welke machtigingen krijgt OpenAI voor mijn KMS?
Alleen de machtigingen die je ons verleent via het beleid dat je instelt. We hebben minimaal Encrypt/Decrypt-bewerkingen nodig. Maak in je cloud-KMS ook een nieuwe sleutel voor OpenAI, in plaats van bestaande sleutels te hergebruiken die voor productie worden gebruikt.
Wanneer krijgt OpenAI machtigingen om toegang te krijgen tot mijn KMS?
Al deze stappen moeten zijn uitgevoerd:
Je hebt de identiteit van OpenAI erkend (via een trust policy, workload identity, enzovoort, afhankelijk van de cloudprovider).
Je hebt een beleid gemaakt voor toegang tot de KMS.
Je hebt de identiteit van OpenAI de machtiging gegeven om toegang te krijgen tot het beleid.
Als je alleen de KMS maakt zonder al deze stappen uit te voeren, heeft OpenAI geen toegang.
Moet ik mijn hoofdsleutel in mijn cloud opslaan?
Nee, je bepaalt zelf hoe je je hoofdsleutel beheert. Je kunt een door de cloud beheerde oplossing gebruiken of een externe oplossing waarbij je sleutel apart wordt opgeslagen. OpenAI hoeft alleen encrypt/decrypt-bewerkingen op je KMS aan te roepen; hoe de hoofdsleutel die versleuteling en decryptie precies uitvoert, is een implementatiedetail dat voor ons niet zichtbaar is.
Levenscyclus van sleutels
DEK/eDEK-rotatie (beheerd door OpenAI)
Hoe vaak worden DEK's/eDEK's geroteerd?
Elke 24 uur op het versleutelingspad (bij het aanvragen van een DEK/eDEK-sleutelpaar)
Elk uur voor het decryptiesleutelpad (DEK -> eDEK)
Moet ik iets doen wanneer de DEK verandert?
Nee, DEK/eDEK-rotatie gebeurt binnen OpenAI. Zolang je hoofdsleutel geldig blijft, kunnen eDEK's die met je hoofdsleutel zijn versleuteld nog steeds worden ontsleuteld naar de DEK, die vervolgens wordt gebruikt om je gegevens te ontsleutelen.
Rotatie en intrekking van de hoofdsleutel (door jou beheerd)
Hoe vaak vinden sleutelrotatie en sleutelintrekking plaats?
Dat bepaal je zelf, omdat OpenAI geen zicht heeft op je hoofdsleutel.
Wat is het verschil tussen sleutelrotatie en sleutelintrekking?
Sleutelintrekking verwijdert toegang tot gegevens die met oudere sleutels zijn versleuteld. Bij sleutelrotatie worden gegevens met een nieuwe sleutel versleuteld, terwijl leestoegang tot oudere gegevens behouden blijft.
Wat gebeurt er als ik mijn hoofdsleutel intrek?
Als een sleutel wordt ingetrokken of machtigingen worden verwijderd, zal de werkruimte uiteindelijk niet meer werken zodra sleutels in de cache verlopen. Vanaf dat moment kan OpenAI opgeslagen gegevens niet meer ontsleutelen en geen nieuwe gegevens meer versleutelen. In feite zijn de gegevens dan “versnipperd”.
Hoe snel wordt intrekking van kracht?
OpenAI bewaart DEK's in het geheugen als cache voor prestaties en veerkracht. Intrekking wordt doorgaans binnen een uur van kracht, zodra gecachte sleutels verlopen en hervalidatie mislukt.
Kan intrekking veilig worden getest?
Intrekking testen in een productiewerkruimte wordt niet aanbevolen, omdat bestaande gegevens daardoor permanent ontoegankelijk worden. Klanten kunnen (en moeten) intrekking wel testen in een sandboxomgeving om te controleren of het gedrag klopt en hun vertrouwensaannames te valideren.
Kan de werkruimte worden hersteld door een nieuwe sleutel te koppelen als een sleutel permanent is ingetrokken?
Nee. Zodra de sleutel verloren is, zijn de gegevens bewust onherstelbaar. De enige oplossing is een nieuwe werkruimte opzetten.
Wat moeten we doen als een werkruimte ontoegankelijk wordt door sleutelwijzigingen?
De verwachte oplossing is een nieuwe werkruimte maken. Het bijwerken van de KMS herstelt bestaande gegevens niet.
Wat is het terugdraaiplan als we besluiten te stoppen met het gebruik van CMEK?
Op dit moment is er geen terugdraaiplan. Zodra een werkruimte met CMEK is gemaakt, worden alle bijbehorende gegevens versleuteld met door de klant beheerde sleutels en zijn ze zonder die sleutels niet toegankelijk. De enige manier om het gebruik van CMEK te beëindigen is een nieuwe werkruimte maken — bestaande versleutelde gegevens blijven permanent ontoegankelijk.
Wat gebeurt er wanneer ik mijn hoofdsleutel roteer?
Er wordt nieuw cryptografisch materiaal gegenereerd voor versleuteling, zodat nieuwe versleutelingsaanvragen de nieuwe sleutel gebruiken. De KMS-identificatie (ARN of sleutelnaam) blijft echter hetzelfde en oude gegevens kunnen nog steeds worden ontsleuteld. Veel cloudproviders bieden automatische sleutelrotatie (AWS, GCP, Azure).
Versleutelt OpenAI oudere gegevens opnieuw wanneer ik mijn hoofdsleutel roteer?
Nee. Het nieuwe cryptografische materiaal wordt alleen gebruikt om nieuwe gegevens te versleutelen.
Hoe lang duurt het voordat sleutelrotatie of sleutelintrekking van kracht wordt?
1 uur. Dit komt doordat de DEK/eDEK's in het geheugen worden gecachet en we deze vermeldingen elk uur opnieuw valideren met je KMS.
De KMS-identificatie wijzigen
Is het wijzigen van de KMS-identificatie sleutelintrekking of sleutelrotatie?
Sleutelintrekking. Een sleutel kan geen gegevens ontsleutelen die met een andere sleutel zijn versleuteld.
Kan OpenAI mij helpen de KMS-identificatie voor een ChatGPT-werkruimte te wijzigen?
Als je bevestigt dat het de bedoeling is je sleutel in te trekken, kunnen we je helpen dit voor een ChatGPT-werkruimte te doen. Let op: wanneer de KMS-ARN wordt bijgewerkt, blijven oudere gegevens ontoegankelijk. Na de wijziging heb je dus een mix van ontoegankelijke en toegankelijke gegevens.
Kan OpenAI mij helpen de KMS-identificatie voor een API-project te wijzigen?
Als je de API gebruikt, kun je via de API eenvoudig projecten archiveren en nieuwe projecten maken. Archiveer daarom het project waarvan de gegevens toch niet toegankelijk zijn, registreer een nieuwe EKM-configuratie bij OpenAI en maak een nieuw API-project met de nieuwe KMS-sleutel.
Wat als ik mijn KMS-identificatie regelmatig zelf wil wijzigen?
Dit wordt niet aanbevolen, omdat je je sleutel waarschijnlijk niet regelmatig wilt intrekken. Je kunt dit echter wel doen als je een cloudprovider gebruikt die een KMS-sleutelalias ondersteunt (AWS-voorbeeld). Je kunt die KMS-sleutelalias bij OpenAI registreren en vervolgens bij je cloudprovider op elk moment de onderliggende KMS-identificatie waarnaar de alias verwijst omwisselen om een sleutelintrekking uit te voeren.
Gedrag in bèta versus GA
Zijn er bekende risico's of wijzigingen op systeemniveau wanneer de versleutelingsbèta in productie wordt gebruikt?
De bètaomgeving is functioneel gelijkwaardig aan GA en er worden geen migratiestappen verwacht. Het belangrijkste risico is dat sommige edgecasefuncties versleutelde inhoud mogelijk nog niet ondersteunen door onvolledige codepaden. Deze gevallen zijn zeldzaam en worden actief opgelost. Gegevens zijn volledig versleuteld en beschermd, ongeacht deze mogelijke problemen.
Komen er migratiestappen van bèta naar GA?
Nee. Werkruimten die de versleutelingsbèta gebruiken, worden automatisch ondersteund in GA zonder dat gebruikers iets hoeven te doen.
Aanvullende technische details
Envelope encryption & machtigingen
Moeten we OpenAI GenerateDataKey-machtigingen verlenen voor EKM?
Nee. OpenAI heeft alleen Encrypt- en Decrypt-machtigingen voor je KMS-sleutel nodig. De GenerateDataKey-machtiging is niet nodig voor EKM-integratie.
Gebruikt OpenAI envelope encryption voor klantgegevens?
Ja. OpenAI gebruikt een envelope-encryptionmodel:
KMS van de klant: beheert de Key Encryption Keys (KEK's). OpenAI ziet of bewaart de KEK's nooit.
OpenAI-infrastructuur: genereert en beheert Data Encryption Keys (DEK's). Elke DEK wordt vóór opslag versleuteld (wrapped) met je KEK.
Gegevensstroom:
Klantgegevens worden versleuteld met een DEK.
Die DEK wordt versleuteld met je KEK, waardoor een eDEK ontstaat.
De eDEK wordt naast de versleutelde gegevens opgeslagen.
Om gegevens te ontsleutelen, vraagt OpenAI je KMS om de eDEK te ontsleutelen, haalt de DEK op en ontsleutelt de inhoud.
Waarom heeft OpenAI voor dit model gekozen in plaats van KMS zowel KEK's als DEK's te laten beheren?
Er zijn twee gangbare benaderingen voor envelope encryption:
Door KMS beheerde KEK's en DEK's:
Voordelen: eenvoudigere implementatie; geen versleutelingsinfrastructuur nodig om te onderhouden.
Nadelen: elke versleutelings- of decryptieaanvraag gaat langs de KMS, wat de latentie en kosten verhoogt en één enkel storingspunt introduceert.
Door KMS beheerde KEK's / door OpenAI beheerde DEK's (onze aanpak):
Voordelen: aanzienlijk lagere latentie en kosten, betere schaalbaarheid en betrouwbaarheid, en blijvende werking bij gedeeltelijke KMS-storingen (tot aan de TTL van de DEK-cache).
Nadelen: iets complexere implementatie aan de kant van OpenAI.
Met dit ontwerp kan OpenAI sterke beveiligingsgaranties bieden en tegelijk het operationele risico en de kosten voor klanten beperken.
Hoe vaak worden DEK's geroteerd?
Elke DEK wordt ongeveer elke 60 minuten geroteerd. Dit biedt temporele isolatie: zelfs als een DEK op de een of andere manier wordt gecompromitteerd, blijft de impact beperkt tot gegevens die binnen dat venster van één uur zijn versleuteld.
KMS-aanvraagvolume & observability
We zien veel minder KMS-aanvragen dan het aantal gebruikersberichten. Moeten deze aantallen overeenkomen?
Nee, ze zullen niet rechtstreeks correleren.
Omdat OpenAI DEK's om prestatieredenen in het geheugen cachet, worden KMS-aanroepen alleen gedaan wanneer een DEK moet worden ontsleuteld — niet bij elke versleutelings- of decryptiebewerking. Daarom kun je het volgende verwachten:
Minder KMS-aanvragen dan gebruikersinteracties.
Incidentele pieken wanneer gecachte DEK's verlopen (ongeveer elk uur) of wanneer oudere versleutelde gegevens moeten worden geopend.
Extra aanroepen bij het ophalen van historische gegevens, bijvoorbeeld wanneer een gebruiker een langlopende conversatie voortzet en oudere DEK's moeten worden geladen.
Het exacte aantal KMS-aanvragen hangt af van de cachestatus, gebruikersgedrag, patronen in gegevenstoegang en conversatielengte, en correleert daarom niet rechtstreeks met het berichtenvolume.