Krypteringsbegreber
Flow på højt niveau
Du kontrollerer en hovednøgle i din cloud, som OpenAI aldrig ser
Din hovednøgle bruges til at kryptere datakrypteringsnøgler (DEK'er), som bruges af OpenAI
OpenAI bruger DEK'erne til at kryptere dine data i hvile. En DEK krypteres med din hovednøgle, hvorved der genereres en eDEK (krypteret DEK), som gemmes sammen med dine data
For at læse dataene tager OpenAI eDEK'en, anmoder din KMS om at dekryptere den til en DEK og dekrypterer derefter dine data
Hvordan fungerer EKM-kryptering?
Se vores artikel for detaljerede oplysninger: Oversigt over OpenAI Enterprise Key Management (EKM)
Gemmer OpenAI mine DEK'er?
Nej – vi gemmer de krypterede DEK'er (eDEK'er), som genereres af din KMS. For at dekryptere dataene beder vi din KMS om at dekryptere eDEK'en tilbage til DEK'en.
Cachelagrer OpenAI mine DEK'er?
Ja – kun i hukommelsen. Det sker af hensyn til ydeevne for at undgå at ramme din KMS ved hver anmodning om kryptering/dekryptering af data. DEK'er skrives aldrig til lager.
Cloud-tilladelser
Hvilke tilladelser vil OpenAI have til min KMS?
Kun de tilladelser, du giver os via den politik, du angiver. Vi har blot brug for mindst Encrypt-/Decrypt-handlinger. Opret også en ny nøgle i din cloud-KMS til OpenAI i stedet for at genbruge eksisterende nøgler, der bruges til produktionsformål.
Hvornår får OpenAI tilladelser til at få adgang til min KMS?
Alle disse trin skal være udført:
Du har anerkendt OpenAI's identitet (via trust policy, workload identity osv. afhængigt af cloududbyderen).
Du har oprettet en politik for adgang til KMS.
Du har tildelt OpenAI's identitet tilladelse til at få adgang til politikken.
Hvis du blot opretter KMS uden at udføre alle disse trin, har OpenAI ikke adgang.
Skal jeg gemme min hovednøgle i min cloud?
Nej – det er op til dig, hvordan du administrerer din hovednøgle. Du kan bruge en cloud-administreret løsning eller en ekstern løsning, hvor din nøgle gemmes separat. OpenAI skal blot kunne kalde encrypt-/decrypt-handlinger på din KMS – hvordan hovednøglen faktisk udfører encrypt/decrypt, er en implementeringsdetalje, som er usynlig for os.
Nøglens livscyklus
DEK/eDEK-rotation (kontrolleret af OpenAI)
Hvor ofte roteres DEK'er/eDEK'er?
Hver 24. time på krypteringsstien (anmodning om et DEK/eDEK-nøglepar)
Hver 1. time for dekrypteringsnøglestien (DEK -> eDEK)
Skal jeg gøre noget, når DEK'en ændres?
Nej – DEK/eDEK-rotation foretages internt hos OpenAI. Så længe din hovednøgle forbliver gyldig, kan alle eDEK'er, der er krypteret med din hovednøgle, fortsat dekrypteres til DEK'en, som derefter bruges til at dekryptere dine data.
Rotation og tilbagekaldelse af hovednøgle (kontrolleret af dig)
Hvor ofte sker nøglerotation og nøgletilbagekaldelse?
Det bestemmes af dig, da OpenAI ikke har indsigt i din hovednøgle.
Hvad er forskellen på nøglerotation og nøgletilbagekaldelse?
Nøgletilbagekaldelse fjerner adgang til data, der er krypteret med ældre nøgler. Nøglerotation krypterer data med en ny nøgle, men bevarer læseadgang til ældre data.
Hvad sker der, hvis jeg tilbagekalder min hovednøgle?
Hvis en nøgle tilbagekaldes, eller tilladelser fjernes, vil arbejdsområdet med tiden holde op med at fungere, når cachelagrede nøgler udløber. På det tidspunkt kan OpenAI ikke længere dekryptere lagrede data eller kryptere nye data. I praksis er dataene “makuleret”.
Hvor hurtigt træder tilbagekaldelse i kraft?
OpenAI cachelagrer DEK'er i hukommelsen af hensyn til ydeevne og robusthed. Tilbagekaldelse træder typisk i kraft inden for en time, når cachelagrede nøgler udløber, og genvalidering mislykkes.
Kan tilbagekaldelse testes sikkert?
Test af tilbagekaldelse i et produktionsarbejdsområde anbefales ikke, fordi det permanent vil gøre eksisterende data utilgængelige. Kunder kan (og bør) dog teste tilbagekaldelse i et sandbox-miljø for at verificere korrekt adfærd og validere deres tillidsantagelser.
Hvis en nøgle tilbagekaldes permanent, kan arbejdsområdet så gendannes ved at tilknytte en ny nøgle?
Nej. Når nøglen er mistet, kan dataene ikke gendannes. Det er en del af designet. Den eneste afhjælpning er at oprette et nyt arbejdsområde.
Hvad skal vi gøre, hvis et arbejdsområde bliver utilgængeligt på grund af nøgleændringer?
Den forventede afhjælpning er at oprette et nyt arbejdsområde. Opdatering af KMS vil ikke gendanne eksisterende data.
Hvad er planen for tilbageførsel, hvis vi beslutter at stoppe med at bruge CMEK?
I øjeblikket findes der ingen plan for tilbageførsel. Når et arbejdsområde er oprettet med CMEK, krypteres alle tilknyttede data med kundeadministrerede nøgler og kan ikke tilgås uden dem. Den eneste måde at stoppe brugen af CMEK på er at oprette et nyt arbejdsområde — eksisterende krypterede data forbliver permanent utilgængelige.
Hvad sker der, når jeg roterer min hovednøgle?
Nyt kryptografisk materiale genereres til kryptering, så nye krypteringsanmodninger bruger den nye nøgle. Men KMS-identifikatoren (ARN eller nøglenavn) forbliver den samme, og gamle data kan stadig dekrypteres. Mange cloududbydere tilbyder automatisk nøglerotation (AWS, GCP, Azure).
Genkrypterer OpenAI ældre data, når jeg roterer min hovednøgle?
Nej. Det nye kryptografiske materiale bruges kun til at kryptere nye data.
Hvor lang tid tager det, før en nøglerotation eller nøgletilbagekaldelse træder i kraft?
1 time. Det skyldes, at DEK/eDEK'erne cachelagres i hukommelsen, og vi genvaliderer disse poster med din KMS hver time.
Skift af KMS-identifikatoren
Er skift af KMS-identifikatoren en nøgletilbagekaldelse eller nøglerotation?
Nøgletilbagekaldelse. Én nøgle kan ikke dekryptere data, der er krypteret med en anden nøgle.
Kan OpenAI hjælpe mig med at skifte min KMS-identifikator for et ChatGPT-arbejdsområde?
Hvis du bekræfter, at hensigten er at tilbagekalde din nøgle, kan vi hjælpe dig med dette for et ChatGPT-arbejdsområde. Bemærk, at når KMS-ARN'et opdateres, vil ældre data fortsat være utilgængelige, så du ender med en blanding af utilgængelige og tilgængelige data efter ændringen.
Kan OpenAI hjælpe mig med at skifte min KMS-identifikator for et API-projekt?
Hvis du bruger API'et, gør API'et det nemt at arkivere og oprette nye projekter. Arkivér derfor i stedet det projekt, hvis data alligevel ikke er tilgængelige, registrér en ny EKM-konfiguration hos OpenAI, og opret et nyt API-projekt med den nye KMS-nøgle.
Hvad hvis jeg selv vil skifte min KMS-identifikator regelmæssigt?
Det anbefales ikke, da du sandsynligvis ikke ønsker at tilbagekalde din nøgle regelmæssigt. Du kan dog stadig gøre dette, hvis du bruger en cloududbyder, der understøtter et KMS-nøglealias (AWS-eksempel). Du kan registrere dette KMS-nøglealias hos OpenAI, og derefter kan du hos din cloududbyder til enhver tid udskifte den underliggende KMS-identifikator, som aliasset peger på, for at udstede en nøgletilbagekaldelse.
Adfærd i beta kontra GA
Er der kendte risici eller ændringer på systemniveau ved brug af krypteringsbetaen i produktion?
Betamiljøet svarer funktionelt til GA, og der forventes ingen migreringstrin. Den primære risiko er, at visse edge case-funktioner endnu ikke understøtter krypteret indhold på grund af ufuldstændige kodeforløb. Disse er sjældne og bliver aktivt løst. Data er fuldt krypteret og beskyttet uanset disse potentielle problemer.
Vil der være migreringstrin fra beta til GA?
Nej. Arbejdsområder, der bruger krypteringsbetaen, understøttes automatisk i GA uden handling fra brugeren.
Yderligere tekniske oplysninger
Envelope-kryptering & tilladelser
Skal vi give OpenAI GenerateDataKey-tilladelser til EKM?
Nej. OpenAI kræver kun Encrypt- og Decrypt-tilladelser til din KMS-nøgle. GenerateDataKey-tilladelsen er ikke nødvendig for EKM-integrationen.
Bruger OpenAI envelope-kryptering til kundedata?
Ja. OpenAI bruger en envelope-krypteringsmodel:
Kundens KMS: Administrerer Key Encryption Keys (KEK'er). OpenAI ser eller gemmer aldrig KEK'erne.
OpenAI-infrastruktur: Genererer og administrerer Data Encryption Keys (DEK'er). Hver DEK krypteres (wrappes) med din KEK før lagring.
Dataflow:
Kundedata krypteres med en DEK.
Denne DEK krypteres med din KEK, hvilket producerer en eDEK.
eDEK'en gemmes sammen med de krypterede data.
For at dekryptere data anmoder OpenAI din KMS om at dekryptere eDEK'en, henter DEK'en og dekrypterer indholdet.
Hvorfor valgte OpenAI denne model frem for at lade KMS administrere både KEK'er og DEK'er?
Der findes to almindelige tilgange til envelope-kryptering:
KMS-administrerede KEK'er og DEK'er:
Fordele: Enklere implementering og intet behov for at vedligeholde krypteringsinfrastruktur.
Ulemper: Hver krypterings-/dekrypteringsanmodning rammer KMS, hvilket øger latenstid og omkostninger og introducerer et enkelt fejlpunkt.
KMS-administrerede KEK'er / OpenAI-administrerede DEK'er (vores tilgang):
Fordele: Betydeligt lavere latenstid og omkostninger, bedre skalerbarhed og pålidelighed samt fortsat drift under delvise KMS-udfald (op til DEK-cachens TTL).
Ulemper: En lidt mere kompleks implementering på OpenAI's side.
Dette design gør det muligt for OpenAI at give stærke sikkerhedsgarantier og samtidig minimere driftsrisiko og omkostninger for kunderne.
Hvor ofte roteres DEK'er?
Hver DEK roteres cirka hvert 60. minut. Det giver tidsmæssig isolation — selv hvis en DEK på en eller anden måde blev kompromitteret, ville virkningen være begrænset til data krypteret inden for dette tidsrum på én time.
KMS-anmodningsvolumen & observerbarhed
Vi ser langt færre KMS-anmodninger end antallet af brugermeddelelser. Bør disse tal stemme overens?
Nej, de vil ikke korrelere direkte.
Fordi OpenAI cachelagrer DEK'er i hukommelsen af hensyn til ydeevne, foretages KMS-kald kun, når en DEK skal dekrypteres — ikke ved hver krypterings- eller dekrypteringshandling. Derfor bør du forvente:
Færre KMS-anmodninger end brugerinteraktioner.
Lejlighedsvise stigninger, når cachelagrede DEK'er udløber (cirka hver time), eller når ældre krypterede data skal tilgås.
Ekstra kald, når historiske data hentes, f.eks. når en bruger fortsætter en langvarig samtale, og ældre DEK'er skal indlæses.
Det præcise antal KMS-anmodninger afhænger af cachetilstand, brugeradfærd, dataadgangsmønstre og samtalelængde og vil derfor ikke korrelere direkte med meddelelsesvolumen.