Krypteringsbegreper
Overordnet flyt
Du kontrollerer en hovednøkkel i skyen din som OpenAI aldri ser
Hovednøkkelen din brukes til å kryptere datakrypteringsnøkler (DEK-er) som brukes av OpenAI
OpenAI bruker DEK-ene til å kryptere dataene dine i ro. En DEK krypteres med hovednøkkelen din og genererer en eDEK (kryptert DEK), som lagres sammen med dataene dine
For å lese dataene tar OpenAI eDEK-en, ber KMS-et ditt dekryptere den til en DEK, og dekrypterer deretter dataene dine
Hvordan fungerer EKM-kryptering?
Se artikkelen vår for detaljert informasjon: Oversikt over OpenAI Enterprise Key Management (EKM)
Lagrer OpenAI DEK-ene mine?
Nei – vi lagrer de krypterte DEK-ene (eDEK-ene), som genereres av KMS-et ditt. For å dekryptere dataene ber vi KMS-et ditt dekryptere eDEK-en tilbake til DEK-en.
Bufrer OpenAI DEK-ene mine?
Ja – bare i minnet. Dette gjøres av ytelseshensyn, for å unngå å treffe KMS-et ditt ved hver forespørsel om kryptering/dekryptering av data. DEK-er skrives aldri til lagring.
Skytillatelser
Hvilke tillatelser vil OpenAI ha i KMS-et mitt?
Bare tillatelsene du gir oss via policyen du angir. Vi trenger bare minst Encrypt-/Decrypt-operasjoner. Opprett også en ny nøkkel i sky-KMS-et ditt for OpenAI i stedet for å gjenbruke eksisterende nøkler som brukes i produksjon.
Når får OpenAI tillatelser til å få tilgang til KMS-et mitt?
Alle disse trinnene må være utført:
Du har godkjent OpenAIs identitet (via tillitspolicy, workload identity osv., avhengig av skyleverandør).
Du har opprettet en policy for tilgang til KMS.
Du har gitt OpenAIs identitet tillatelse til å bruke policyen.
Hvis du bare oppretter KMS-et uten å utføre alle disse trinnene, har ikke OpenAI tilgang.
Må jeg lagre hovednøkkelen min i skyen min?
Nei – det er opp til deg hvordan du administrerer hovednøkkelen din. Du kan bruke en skyadministrert løsning eller en ekstern løsning der nøkkelen lagres separat. OpenAI trenger bare å kalle encrypt-/decrypt-operasjoner på KMS-et ditt – hvordan hovednøkkelen faktisk utfører encrypt/decrypt, er en implementasjonsdetalj som er skjult for oss.
Nøkkelens livssyklus
DEK-/eDEK-rotasjon (kontrollert av OpenAI)
Hvor ofte roteres DEK-er/eDEK-er?
Hver 24. time på krypteringsstien (forespørsel om et DEK/eDEK-nøkkelpar)
Hver 1. time for dekrypteringsnøkkelstien (DEK -> eDEK)
Må jeg gjøre noe når DEK-en endres?
Nei – DEK-/eDEK-rotasjon gjøres internt i OpenAI. Så lenge hovednøkkelen din forblir gyldig, kan eDEK-er som er kryptert med hovednøkkelen din, fortsatt dekrypteres til DEK-en, som deretter brukes til å dekryptere dataene dine.
Rotasjon og tilbakekalling av hovednøkkel (kontrollert av deg)
Hvor ofte skjer nøkkelrotasjon og nøkkeltilbakekalling?
Dette bestemmes av deg, siden OpenAI ikke har innsyn i hovednøkkelen din.
Hva er forskjellen mellom nøkkelrotasjon og nøkkeltilbakekalling?
Nøkkeltilbakekalling fjerner tilgang til data som er kryptert med eldre nøkler. Nøkkelrotasjon krypterer data med en ny nøkkel, men opprettholder lesetilgang til eldre data.
Hva skjer hvis jeg tilbakekaller hovednøkkelen min?
Hvis en nøkkel tilbakekalles eller tillatelser fjernes, vil arbeidsområdet etter hvert slutte å fungere når bufrede nøkler utløper. Da kan OpenAI ikke lenger dekryptere lagrede data eller kryptere nye data. I praksis er dataene «makulert».
Hvor raskt trer tilbakekalling i kraft?
OpenAI bufret DEK-er i minnet av hensyn til ytelse og robusthet. Tilbakekalling trer vanligvis i kraft innen én time, når bufrede nøkler utløper og ny validering mislykkes.
Kan tilbakekalling testes trygt?
Testing av tilbakekalling i et produksjonsarbeidsområde anbefales ikke, fordi det permanent gjør eksisterende data utilgjengelige. Kunder kan (og bør) likevel teste tilbakekalling i et sandkassemiljø for å verifisere riktig atferd og validere tillitsforutsetningene sine.
Hvis en nøkkel tilbakekalles permanent, kan arbeidsområdet gjenopprettes ved å koble til en ny nøkkel?
Nei. Når nøkkelen først er tapt, er dataene ugjenopprettelige av design. Den eneste løsningen er å opprette et nytt arbeidsområde.
Hva bør vi gjøre hvis et arbeidsområde blir utilgjengelig på grunn av nøkkelendringer?
Forventet tiltak er å opprette et nytt arbeidsområde. Oppdatering av KMS vil ikke gjenopprette eksisterende data.
Hva er tilbakeføringsplanen hvis vi bestemmer oss for å slutte å bruke CMEK?
For øyeblikket finnes det ingen tilbakeføringsplan. Når et arbeidsområde er opprettet med CMEK, krypteres alle tilknyttede data med kundeadministrerte nøkler og kan ikke åpnes uten dem. Den eneste måten å avvikle bruk av CMEK på er å opprette et nytt arbeidsområde – eksisterende krypterte data vil forbli permanent utilgjengelige.
Hva skjer når jeg roterer hovednøkkelen min?
Nytt kryptografisk materiale genereres for kryptering, slik at nye krypteringsforespørsler bruker den nye nøkkelen. Men KMS-identifikatoren (ARN eller nøkkelnavn) forblir den samme, og gamle data kan fortsatt dekrypteres. Mange skyleverandører tilbyr automatisk nøkkelrotasjon (AWS, GCP, Azure).
Blir eldre data kryptert på nytt når jeg roterer hovednøkkelen min?
Nei. Det nye kryptografiske materialet brukes bare til å kryptere nye data.
Hvor lang tid tar det før en nøkkelrotasjon eller nøkkeltilbakekalling trer i kraft?
1 time. Dette skyldes at DEK-ene/eDEK-ene bufres i minnet, og at vi revaliderer disse oppføringene mot KMS-et ditt hver time.
Bytte KMS-identifikator
Er det å bytte KMS-identifikator en nøkkeltilbakekalling eller nøkkelrotasjon?
Nøkkeltilbakekalling. Én nøkkel kan ikke dekryptere data som er kryptert med en annen nøkkel.
Kan OpenAI hjelpe meg med å bytte KMS-identifikator for et ChatGPT-arbeidsområde?
Hvis du bekrefter at hensikten er å tilbakekalle nøkkelen din, kan vi hjelpe deg med dette for et ChatGPT-arbeidsområde. Vær oppmerksom på at når KMS-ARN-et oppdateres, vil eldre data fortsatt være utilgjengelige, så du ender opp med en blanding av utilgjengelige og tilgjengelige data etter endringen.
Kan OpenAI hjelpe meg med å bytte KMS-identifikator for et API-prosjekt?
Hvis du bruker API-et, gjør API-et det enkelt å arkivere og opprette nye prosjekter. Arkiver derfor heller prosjektet der dataene uansett ikke er tilgjengelige, registrer en ny EKM-konfigurasjon hos OpenAI, og opprett et nytt API-prosjekt med den nye KMS-nøkkelen.
Hva om jeg selv vil bytte KMS-identifikator regelmessig?
Dette anbefales ikke, siden du sannsynligvis ikke ønsker å tilbakekalle nøkkelen din regelmessig. Du kan likevel gjøre dette hvis du bruker en skyleverandør som støtter et KMS-nøkkelalias (AWS-eksempel). Du kan registrere dette KMS-nøkkelaliaset hos OpenAI, og deretter kan du når som helst bytte ut den underliggende KMS-identifikatoren som aliaset peker til hos skyleverandøren din, for å utstede en nøkkeltilbakekalling.
Atferd i beta kontra GA
Finnes det kjente risikoer eller endringer på systemnivå ved bruk av krypteringsbetaen i produksjon?
Betamiljøet er funksjonelt likt GA, og det forventes ingen migreringstrinn. Den viktigste risikoen er at enkelte funksjoner i randtilfeller kanskje ennå ikke støtter kryptert innhold på grunn av ufullstendige kodebaner. Disse er sjeldne og blir aktivt løst. Data er fullt kryptert og beskyttet uavhengig av disse potensielle problemene.
Blir det noen migreringstrinn fra beta til GA?
Nei. Arbeidsområder som bruker krypteringsbetaen, støttes automatisk i GA uten at brukeren trenger å gjøre noe.
Ytterligere tekniske detaljer
Konvoluttkryptering og tillatelser
Må vi gi OpenAI GenerateDataKey-tillatelser for EKM?
Nei. OpenAI trenger bare Encrypt- og Decrypt-tillatelser for KMS-nøkkelen din. GenerateDataKey-tillatelsen er ikke nødvendig for EKM-integrasjonen.
Bruker OpenAI konvoluttkryptering for kundedata?
Ja. OpenAI bruker en konvoluttkrypteringsmodell:
Kundens KMS: Administrerer nøkkelkrypteringsnøklene (KEK-er). OpenAI ser eller lagrer aldri KEK-ene.
OpenAI-infrastruktur: Genererer og administrerer datakrypteringsnøkler (DEK-er). Hver DEK krypteres (pakkes inn) med KEK-en din før lagring.
Dataflyt:
Kundedata krypteres med en DEK.
Denne DEK-en krypteres med KEK-en din og produserer en eDEK.
eDEK-en lagres sammen med de krypterte dataene.
For å dekryptere data ber OpenAI KMS-et ditt dekryptere eDEK-en, henter DEK-en og dekrypterer innholdet.
Hvorfor valgte OpenAI denne modellen i stedet for å la KMS administrere både KEK-er og DEK-er?
Det finnes to vanlige tilnærminger til konvoluttkryptering:
KMS-administrerte KEK-er og DEK-er:
Fordeler: Enklere implementering, ingen behov for å vedlikeholde krypteringsinfrastruktur.
Ulemper: Hver krypterings-/dekrypteringsforespørsel går mot KMS, noe som øker ventetid og kostnader og innfører et enkelt feilpunkt.
KMS-administrerte KEK-er / OpenAI-administrerte DEK-er (vår tilnærming):
Fordeler: Betydelig lavere ventetid og kostnad, bedre skalerbarhet og pålitelighet, og fortsatt drift ved delvise KMS-avbrudd (opptil DEK-bufringens TTL).
Ulemper: Litt mer kompleks implementering på OpenAIs side.
Denne utformingen gjør at OpenAI kan gi sterke sikkerhetsgarantier samtidig som operasjonell risiko og kostnader for kundene minimeres.
Hvor ofte roteres DEK-er?
Hver DEK roteres omtrent hvert 60. minutt. Dette gir tidsmessig isolasjon – selv om en DEK på en eller annen måte skulle bli kompromittert, ville virkningen være begrenset til data som er kryptert innenfor det ene timesvinduet.
KMS-forespørselsvolum og observerbarhet
Vi ser langt færre KMS-forespørsler enn antall brukermeldinger. Skal disse tallene samsvare?
Nei, de vil ikke ha en direkte sammenheng.
Fordi OpenAI bufret DEK-er i minnet av ytelseshensyn, gjøres KMS-kall bare når en DEK må dekrypteres – ikke ved hver krypterings- eller dekrypteringsoperasjon. Derfor bør du forvente:
Færre KMS-forespørsler enn brukerinteraksjoner.
Enkelte topper når bufrede DEK-er utløper (omtrent hver time), eller når eldre krypterte data må åpnes.
Flere kall ved henting av historiske data, for eksempel når en bruker fortsetter en langvarig samtale og eldre DEK-er må lastes inn.
Det nøyaktige antallet KMS-forespørsler avhenger av bufringstilstand, brukeratferd, datatilgangsmønstre og samtalelengde, og vil derfor ikke korrelere direkte med meldingsvolum.