Concepten rond encryptie
Globale stroom
Jij beheert een hoofdsleutel in je cloud die OpenAI nooit ziet
Je hoofdsleutel wordt gebruikt om data-encryptiesleutels (DEK's) te versleutelen die door OpenAI worden gebruikt
OpenAI gebruikt de DEK's om je data in rust te versleutelen. Een DEK wordt versleuteld met je hoofdsleutel, waardoor een eDEK (versleutelde DEK) ontstaat, die samen met je data wordt opgeslagen
Om de data te lezen, neemt OpenAI de eDEK, vraagt je KMS om die te ontsleutelen naar een DEK en ontsleutelt daarna je data
Hoe werkt EKM-encryptie?
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 data te ontsleutelen, vragen we je KMS om de eDEK weer terug te ontsleutelen naar de DEK.
Cachet OpenAI mijn DEK's?
Ja — alleen in het geheugen. Dit is voor prestaties, zodat we je KMS niet bij elk verzoek om data te versleutelen/ontsleutelen hoeven aan te spreken. DEK's worden nooit naar opslag geschreven.
Cloudmachtigingen
Welke machtigingen heeft OpenAI op mijn KMS?
Alleen de machtigingen die je ons verleent via het beleid dat je instelt. We hebben minimaal Encrypt/Decrypt-bewerkingen nodig. Maak ook een nieuwe sleutel aan in je cloud-KMS 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 genomen: 1. je hebt de identiteit van OpenAI herkend (via trust policy, workload identity, enz., afhankelijk van de cloudprovider), 2. je hebt een beleid gemaakt voor toegang tot de KMS, en 3. je hebt de identiteit van OpenAI toestemming gegeven om toegang te krijgen tot het beleid. Als je alleen de KMS maakt zonder al deze stappen te nemen, heeft OpenAI geen toegang.
Moet ik mijn hoofdsleutel in mijn cloud opslaan?
Nee — het is aan jou hoe je je hoofdsleutel beheert. Je kunt een cloudbeheerde oplossing hebben 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 encrypt/decrypt daadwerkelijk uitvoert, is een implementatiedetail dat voor ons niet zichtbaar is.
Levenscyclus van sleutels
Rotatie van DEK/eDEK (beheerd door OpenAI)
Hoe vaak worden DEK's/eDEK's geroteerd?
Elke 24 uur op het encryptiepad (bij het aanvragen van een DEK/eDEK-sleutelpaar)
Elk 1 uur voor het ontsleutelingspad (DEK -> eDEK)
Moet ik iets doen wanneer de DEK verandert?
Nee — DEK/eDEK-rotatie gebeurt binnen OpenAI. Zolang je hoofdsleutel geldig blijft, kunnen alle eDEK's die met je hoofdsleutel zijn versleuteld, nog steeds worden ontsleuteld naar de DEK, die vervolgens wordt gebruikt om je data te ontsleutelen.
Rotatie en intrekking van hoofdsleutels (door jou beheerd)
Hoe vaak vinden sleutelrotatie en sleutelintrekking plaats?
Dit bepaal jij, omdat OpenAI geen zicht heeft op je hoofdsleutel.
Wat is het verschil tussen sleutelrotatie en sleutelintrekking?
Sleutelintrekking verwijdert toegang tot data die met oudere sleutels is versleuteld. Sleutelrotatie versleutelt data met een nieuwe sleutel, maar behoudt leestoegang tot oudere data.
Wat gebeurt er als ik mijn hoofdsleutel intrek?
Als een sleutel wordt ingetrokken of machtigingen worden verwijderd, zal de werkruimte uiteindelijk niet meer functioneren zodra gecachte sleutels verlopen. Op dat moment kan OpenAI opgeslagen data niet meer ontsleutelen of nieuwe data versleutelen. Feitelijk wordt de data “vernietigd”.
Hoe snel wordt intrekking van kracht?
OpenAI cachet DEK's in het geheugen voor prestaties en veerkracht. Intrekking wordt doorgaans binnen één uur van kracht, zodra gecachte sleutels verlopen en hervalidatie mislukt.
Kan intrekking veilig worden getest?
Het testen van intrekking in een productiewerkruimte wordt niet aanbevolen, omdat bestaande data daardoor permanent ontoegankelijk wordt. Klanten kunnen (en moeten) intrekking echter testen in een sandboxomgeving om correct gedrag te verifiëren en hun vertrouwensaannames te valideren.
Als een sleutel permanent wordt ingetrokken, kan de werkruimte dan worden hersteld door een nieuwe sleutel te koppelen?
Nee. Zodra de sleutel verloren is, zijn de data volgens ontwerp onherstelbaar. De enige oplossing is een nieuwe werkruimte op te zetten.
Wat moeten we doen als een werkruimte ontoegankelijk wordt door sleutelwijzigingen?
De verwachte oplossing is om een nieuwe werkruimte te maken. Het bijwerken van de KMS herstelt bestaande data niet.
Wat is het terugvalplan als we besluiten CMEK niet meer te gebruiken?
Momenteel is er geen terugvalplan. Zodra een werkruimte met CMEK is gemaakt, worden alle bijbehorende data versleuteld met door de klant beheerde sleutels en zijn ze zonder die sleutels niet toegankelijk. De enige manier om te stoppen met CMEK is een nieuwe werkruimte te maken — bestaande versleutelde data blijven permanent ontoegankelijk.
Wat gebeurt er als ik mijn hoofdsleutel roteer?
Er wordt nieuw cryptografisch materiaal gegenereerd voor encryptie, zodat nieuwe versleutelingsverzoeken de nieuwe sleutel gebruiken. De KMS-identificatie (ARN of sleutelnaam) blijft echter hetzelfde en oude data kunnen nog steeds worden ontsleuteld. Veel cloudproviders bieden automatische sleutelrotatie (AWS, GCP, Azure).
Versleutelt OpenAI oudere data opnieuw wanneer ik mijn hoofdsleutel roteer?
Nee. Het nieuwe cryptografische materiaal wordt alleen gebruikt om nieuwe data te versleutelen.
Hoe lang duurt het voordat een sleutelrotatie of sleutelintrekking van kracht wordt?
1 uur. Dit komt doordat de DEK/eDEK's in het geheugen worden gecachet en we deze items elk uur opnieuw valideren met je KMS.
De KMS-identificatie wijzigen
Is het wijzigen van de KMS-identificatie een sleutelintrekking of sleutelrotatie?
Sleutelintrekking. De ene sleutel kan data die met een andere sleutel zijn versleuteld niet ontsleutelen.
Kan OpenAI me helpen mijn KMS-identificatie te wijzigen voor een ChatGPT-werkruimte?
Als je bevestigt dat het de bedoeling is om je sleutel in te trekken, kunnen we je hierbij helpen voor een ChatGPT-werkruimte. Let op: wanneer de KMS-ARN wordt bijgewerkt, blijven oudere data ontoegankelijk, waardoor je na de wijziging een mix van ontoegankelijke en toegankelijke data krijgt.
Kan OpenAI me helpen mijn KMS-identificatie te wijzigen voor een API-project?
Als je de API gebruikt, maakt de API het eenvoudig om projecten te archiveren en nieuwe projecten aan te maken. Archiveer daarom het project waarvan de data toch al 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 zelf regelmatig wil wijzigen?
Dit wordt niet aanbevolen, omdat je je sleutel waarschijnlijk niet regelmatig wilt intrekken. Je kunt dit echter nog steeds doen als je een cloudprovider gebruikt die een KMS-sleutelalias ondersteunt (AWS example). Je kunt die KMS-sleutelalias bij OpenAI registreren en vervolgens kun je bij je cloudprovider op elk moment de onderliggende KMS-identificatie waarnaar de alias verwijst omwisselen om een sleutelintrekking uit te voeren.
Bèta- versus GA-gedrag
Zijn er bekende risico's of wijzigingen op systeemniveau bij het gebruik van de encryptiebèta in productie?
De bètaomgeving is functioneel gelijkwaardig aan GA en er worden geen migratiestappen verwacht. Het belangrijkste risico is dat sommige edge-case-functies versleutelde content mogelijk nog niet ondersteunen vanwege onvolledige codepaden. Deze gevallen zijn zeldzaam en worden actief opgelost. Data zijn volledig versleuteld en beschermd, ongeacht deze mogelijke problemen.
Zullen er migratiestappen zijn van bèta naar GA?
Nee. Werkruimtes die de encryptiebèta gebruiken, worden automatisch ondersteund in GA zonder enige actie van de gebruiker.
Aanvullende technische details
Envelope-encryptie & machtigingen
Moeten we OpenAI GenerateDataKey-machtigingen geven voor EKM?
Nee. OpenAI heeft alleen Encrypt- en Decrypt-machtigingen nodig op je KMS-sleutel. De GenerateDataKey-machtiging is niet nodig voor EKM-integratie.
Gebruikt OpenAI envelope-encryptie voor klantdata?
Ja. OpenAI gebruikt een envelope-encryptiemodel:
Klant-KMS: 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.
Datastroom:
Klantdata worden versleuteld met een DEK.
Die DEK wordt versleuteld met je KEK, wat een eDEK oplevert.
De eDEK wordt naast de versleutelde data opgeslagen.
Om data te ontsleutelen, vraagt OpenAI je KMS om de eDEK te ontsleutelen, haalt de DEK op en ontsleutelt de content.
Waarom koos OpenAI dit model in plaats van KMS zowel KEK's als DEK's te laten beheren?
Er zijn twee gangbare benaderingen voor envelope-encryptie:
Door KMS beheerde KEK's en DEK's:
Voordelen: Eenvoudigere implementatie, geen noodzaak om encryptie-infrastructuur te onderhouden.
Nadelen: Elk verzoek om te versleutelen/ontsleutelen raakt de KMS, wat latency en kosten verhoogt en één enkel storingspunt introduceert.
Door KMS beheerde KEK's / door OpenAI beheerde DEK's (onze aanpak):
Voordelen: Aanzienlijk lagere latency en kosten, betere schaalbaarheid en betrouwbaarheid, en voortgezette werking tijdens gedeeltelijke KMS-storingen (tot aan de TTL van de DEK-cache).
Nadelen: Iets complexere implementatie aan de kant van OpenAI.
Dit ontwerp stelt OpenAI in staat om sterke beveiligingsgaranties te bieden en tegelijk operationeel risico en kosten voor klanten te minimaliseren.
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 gecompromitteerd zou raken, zou de impact beperkt blijven tot data die binnen dat venster van één uur zijn versleuteld.
KMS-aanvraagvolume & waarneembaarheid
We zien veel minder KMS-verzoeken dan het aantal gebruikersberichten. Moeten deze aantallen overeenkomen?
Nee, ze zullen niet direct 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 ontsleutelingsbewerking. Daardoor kun je het volgende verwachten:
Minder KMS-verzoeken dan gebruikersinteracties.
Incidentele pieken wanneer gecachte DEK's verlopen (ongeveer elk uur) of wanneer oudere versleutelde data moeten worden geopend.
Aanvullende aanroepen bij het ophalen van historische data, bijvoorbeeld wanneer een gebruiker een langlopend gesprek voortzet en oudere DEK's moeten worden geladen.
Het exacte aantal KMS-verzoeken hangt af van de cachestatus, het gedrag van gebruikers, patronen voor datatoegang en de gesprekslengte, en zal daarom niet direct correleren met het berichtvolume.