Krypteringsbegrepp
Övergripande flöde
Du kontrollerar en huvudnyckel i ditt moln som OpenAI aldrig ser
Din huvudnyckel används för att kryptera datakrypteringsnycklar (DEK:er) som används av OpenAI
OpenAI använder DEK:erna för att kryptera dina vilande data. En DEK krypteras av din huvudnyckel och genererar en eDEK (krypterad DEK), som lagras tillsammans med dina data
För att läsa data tar OpenAI eDEK:en, begär att ditt KMS ska dekryptera den till en DEK och dekrypterar sedan dina data
Hur fungerar EKM-kryptering?
Detaljerad information finns i vår artikel: Översikt över OpenAI Enterprise Key Management (EKM)
Lagrar OpenAI mina DEK:er?
Nej – vi lagrar de krypterade DEK:erna (eDEK:er), som genereras av ditt KMS. För att dekryptera data ber vi ditt KMS att dekryptera eDEK:en tillbaka till DEK:en.
Cachelagrar OpenAI mina DEK:er?
Ja – endast i minnet. Detta görs av prestandaskäl för att undvika att anropa ditt KMS vid varje begäran om kryptering/dekryptering av data. DEK:er skrivs aldrig till lagring.
Molnbehörigheter
Vilka behörigheter kommer OpenAI att ha till mitt KMS?
Endast de behörigheter du ger oss via policyn du anger. Vi behöver bara minst Encrypt/Decrypt-åtgärder. Skapa också en ny nyckel i ditt moln-KMS för OpenAI i stället för att återanvända befintliga nycklar som används i produktion.
När får OpenAI behörighet att komma åt mitt KMS?
Alla dessa steg måste ha genomförts:
Du har godkänt OpenAI:s identitet (via förtroendepolicy, workload identity osv., beroende på molnleverantör).
Du har skapat en policy för åtkomst till KMS.
Du har tilldelat OpenAI:s identitet behörighet att komma åt policyn.
Om du bara skapar KMS utan att genomföra alla dessa steg har OpenAI ingen åtkomst.
Måste jag lagra min huvudnyckel i mitt moln?
Nej – det är upp till dig hur du hanterar din huvudnyckel. Du kan ha en molnhanterad lösning eller en extern lösning där din nyckel lagras separat. OpenAI behöver bara kunna anropa krypterings-/dekrypteringsåtgärder i ditt KMS – hur huvudnyckeln faktiskt utför kryptering/dekryptering är en implementeringsdetalj som är dold för oss.
Nyckellivscykel
DEK/eDEK-rotation (kontrolleras av OpenAI)
Hur ofta roteras DEK:er/eDEK:er?
Var 24:e timme i krypteringssökvägen (begär ett DEK/eDEK-nyckelpar)
Varje timme för dekrypteringsnyckelsökvägen (DEK -> eDEK)
Måste jag göra något när DEK:en ändras?
Nej – DEK/eDEK-rotation sker inom OpenAI. Så länge din huvudnyckel förblir giltig kan alla eDEK:er som krypterats med din huvudnyckel fortsätta att dekrypteras till DEK:en, som sedan används för att dekryptera dina data.
Rotation och återkallelse av huvudnyckel (kontrolleras av dig)
Hur ofta sker nyckelrotation och nyckelåterkallelse?
Detta bestäms av dig, eftersom OpenAI inte har insyn i din huvudnyckel.
Vad är skillnaden mellan nyckelrotation och nyckelåterkallelse?
Nyckelåterkallelse tar bort åtkomst till data som krypterats med äldre nycklar. Nyckelrotation krypterar data med en ny nyckel, men behåller läsåtkomst till äldre data.
Vad händer om jag återkallar min huvudnyckel?
Om en nyckel återkallas eller behörigheter tas bort blir arbetsytan så småningom obrukbar när cachade nycklar löper ut. Vid den tidpunkten kan OpenAI inte längre dekryptera lagrade data eller kryptera nya data. I praktiken är data ”strimlade”.
Hur snabbt börjar en återkallelse gälla?
OpenAI cachelagrar DEK:er i minnet för prestanda och motståndskraft. Återkallelse börjar vanligtvis gälla inom en timme, när cachade nycklar löper ut och omvalideringen misslyckas.
Kan återkallelse testas på ett säkert sätt?
Att testa återkallelse i en produktionsarbetsyta rekommenderas inte eftersom det permanent gör befintliga data oåtkomliga. Kunder kan dock, och bör, testa återkallelse i en sandbox-miljö för att verifiera korrekt beteende och validera sina förtroendeantaganden.
Om en nyckel återkallas permanent, kan arbetsytan återställas genom att koppla en ny nyckel?
Nej. När nyckeln väl har gått förlorad är data oåterkalleliga genom design. Den enda åtgärden är att skapa en ny arbetsyta.
Vad ska vi göra om en arbetsyta blir oåtkomlig på grund av nyckeländringar?
Den förväntade åtgärden är att skapa en ny arbetsyta. Att uppdatera KMS återställer inte befintliga data.
Vad är backout-planen om vi bestämmer oss för att sluta använda CMEK?
För närvarande finns det ingen backout-plan. När en arbetsyta har skapats med CMEK krypteras alla tillhörande data med kundhanterade nycklar och kan inte nås utan dem. Det enda sättet att sluta använda CMEK är att skapa en ny arbetsyta – befintliga krypterade data förblir permanent oåtkomliga.
Vad händer när jag roterar min huvudnyckel?
Nytt kryptografiskt material genereras för kryptering, så nya krypteringsbegäranden använder den nya nyckeln. Däremot förblir KMS-identifieraren (ARN eller nyckelnamn) densamma och gamla data kan fortfarande dekrypteras. Många molnleverantörer erbjuder automatisk nyckelrotation (AWS, GCP, Azure).
Krypterar OpenAI om äldre data när jag roterar min huvudnyckel?
Nej. Det nya kryptografiska materialet används endast för att kryptera nya data.
Hur lång tid tar det innan en nyckelrotation eller nyckelåterkallelse börjar gälla?
1 timme. Det beror på att DEK/eDEK:er cachelagras i minnet och att vi omvaliderar dessa poster mot ditt KMS varje timme.
Byta KMS-identifierare
Är byte av KMS-identifierare en nyckelåterkallelse eller nyckelrotation?
Nyckelåterkallelse. En nyckel kan inte dekryptera data som har krypterats med en annan nyckel.
Kan OpenAI hjälpa mig att byta KMS-identifierare för en ChatGPT-arbetsyta?
Om du bekräftar att avsikten är att återkalla din nyckel kan vi hjälpa dig att göra detta för en ChatGPT-arbetsyta. Observera att när KMS ARN uppdateras förblir äldre data oåtkomliga, så du kommer att få en blandning av oåtkomliga och åtkomliga data efter ändringen.
Kan OpenAI hjälpa mig att byta KMS-identifierare för ett API-projekt?
Om du använder API:et gör API:et det enkelt att arkivera och skapa nya projekt. Arkivera därför i stället projektet vars data ändå inte är åtkomliga, registrera en ny EKM-konfiguration hos OpenAI och skapa ett nytt API-projekt med den nya KMS-nyckeln.
Vad händer om jag regelbundet vill byta KMS-identifierare själv?
Det rekommenderas inte, eftersom du förmodligen inte vill återkalla din nyckel regelbundet. Du kan dock ändå göra detta om du använder en molnleverantör som stöder ett KMS-nyckelalias (AWS-exempel). Du kan registrera detta KMS-nyckelalias hos OpenAI och sedan när som helst hos din molnleverantör byta ut den underliggande KMS-identifierare som aliaset pekar på för att utfärda en nyckelåterkallelse.
Beteende i beta jämfört med GA
Finns det några kända risker eller ändringar på systemnivå när krypteringsbetan används i produktion?
Betamiljön är funktionellt likvärdig med GA, och inga migreringssteg förväntas. Den främsta risken är att vissa specialfallsfunktioner ännu inte stöder krypterat innehåll på grund av ofullständiga kodvägar. Dessa är sällsynta och åtgärdas aktivt. Data är helt krypterade och skyddade oavsett dessa potentiella problem.
Kommer det att finnas några migreringssteg från beta till GA?
Nej. Arbetsytor som använder krypteringsbetan stöds automatiskt i GA utan någon åtgärd från användaren.
Ytterligare teknisk information
Envelope-kryptering & behörigheter
Behöver vi ge OpenAI GenerateDataKey-behörigheter för EKM?
Nej. OpenAI kräver endast Encrypt- och Decrypt-behörigheter för din KMS-nyckel. GenerateDataKey-behörigheten behövs inte för EKM-integreringen.
Använder OpenAI envelope-kryptering för kunddata?
Ja. OpenAI använder en envelope-krypteringsmodell:
Kundens KMS: Hanterar Key Encryption Keys (KEK:er). OpenAI ser eller lagrar aldrig KEK:erna.
OpenAI-infrastruktur: Genererar och hanterar Data Encryption Keys (DEK:er). Varje DEK krypteras (wrappas) med din KEK före lagring.
Dataflöde:
Kunddata krypteras med en DEK.
Denna DEK krypteras med din KEK och skapar en eDEK.
eDEK:en lagras tillsammans med de krypterade data.
För att dekryptera data begär OpenAI att ditt KMS dekrypterar eDEK:en, hämtar DEK:en och dekrypterar innehållet.
Varför valde OpenAI den här modellen i stället för att låta KMS hantera både KEK:er och DEK:er?
Det finns två vanliga metoder för envelope-kryptering:
KMS-hanterade KEK:er och DEK:er:
Fördelar: Enklare implementering, inget behov av att underhålla krypteringsinfrastruktur.
Nackdelar: Varje krypterings-/dekrypteringsbegäran går till KMS, vilket ökar latens och kostnad samt introducerar en enskild felpunkt.
KMS-hanterade KEK:er/OpenAI-hanterade DEK:er (vår metod):
Fördelar: Betydligt lägre latens och kostnad, bättre skalbarhet och tillförlitlighet samt fortsatt drift vid partiella KMS-avbrott (upp till DEK-cachens TTL).
Nackdelar: Något mer komplex implementering på OpenAI:s sida.
Den här designen gör att OpenAI kan ge starka säkerhetsgarantier samtidigt som driftrelaterade risker och kostnader för kunderna minimeras.
Hur ofta roteras DEK:er?
Varje DEK roteras ungefär var 60:e minut. Detta ger tidsmässig isolering – även om en DEK på något sätt skulle komprometteras begränsas påverkan till data som krypterats inom det entimmesfönstret.
KMS-begärandevolym & observerbarhet
Vi ser mycket färre KMS-begäranden än antalet användarmeddelanden. Borde dessa siffror stämma överens?
Nej, de kommer inte att korrelera direkt.
Eftersom OpenAI cachelagrar DEK:er i minnet av prestandaskäl görs KMS-anrop endast när en DEK behöver dekrypteras – inte vid varje krypterings- eller dekrypteringsåtgärd. Därför bör du förvänta dig:
Färre KMS-begäranden än användarinteraktioner.
Tillfälliga toppar när cachade DEK:er löper ut (ungefär varje timme) eller när äldre krypterade data behöver nås.
Ytterligare anrop vid hämtning av historiska data, till exempel när en användare fortsätter en långvarig konversation och äldre DEK:er måste läsas in.
Det exakta antalet KMS-begäranden beror på cachetillstånd, användarbeteende, dataåtkomstmönster och konversationslängd, och korrelerar därför inte direkt med meddelandevolymen.