Krypteringskonsepter

Flyt på høyt nivå

• 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 hvile. En DEK krypteres av hovednøkkelen din, og genererer en eDEK (kryptert DEK), som lagres sammen med dataene dine

• For å lese dataene tar OpenAI eDEK-en, ber KMS-en din om å 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-er), som genereres av KMS-en din. For å dekryptere dataene ber vi KMS-en din om å dekryptere eDEK-en tilbake til DEK-en.

Mellomlagrer OpenAI DEK-ene mine?

Ja - kun i minnet. Dette er av ytelseshensyn for å unngå å treffe KMS-en din ved hver forespørsel om kryptering/dekryptering av data. DEK-er skrives aldri til lagring.

Skytillatelser

Hvilke tillatelser vil OpenAI ha på KMS-en min?

Bare tillatelsene du gir oss via policyen du angir. Vi trenger bare minst operasjonene Encrypt/Decrypt. Opprett også en ny nøkkel i sky-KMS-en din for OpenAI i stedet for å gjenbruke eksisterende nøkler som har produksjonsformål.

Når får OpenAI tillatelser til å få tilgang til KMS-en min?

Alle disse trinnene må være fullført: 1. du har gjenkjent OpenAIs identitet (via trust policy, workload identity osv. avhengig av skyleverandøren), 2. du har opprettet en policy for tilgang til KMS-en, og 3. du har gitt OpenAIs identitet tillatelse til å få tilgang til policyen. Hvis du bare oppretter KMS-en uten å gjennomfø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 vil administrere hovednøkkelen din. Du kan ha en skyløsning som administreres av leverandøren, eller en ekstern løsning der nøkkelen din lagres separat. OpenAI trenger bare å kunne kalle krypterings-/dekrypteringsoperasjoner på KMS-en din - hvordan hovednøkkelen faktisk utfører kryptering/dekryptering, er en implementeringsdetalj som er ugjennomsiktig for oss.

Nøkkellivssyklus

DEK-/eDEK-rotasjon (styres av OpenAI)

Hvor ofte roteres DEK-er/eDEK-er?

Hver 24. time på krypteringsbanen (ved forespørsel om et DEK-/eDEK-nøkkelpar)

Hver 1. time for dekrypteringsnøkkelbanen (DEK -> eDEK)

Må jeg gjøre noe når DEK-en endres?

Nei - DEK-/eDEK-rotasjon utføres innenfor OpenAI. Så lenge hovednøkkelen din forblir gyldig, kan alle 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 (styres 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 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 til slutt bli ikke-fungerende når mellomlagrede nøkler utløper. På det tidspunktet kan OpenAI ikke lenger dekryptere lagrede data eller kryptere nye data. I praksis blir dataene «makulert».

Hvor raskt trer tilbakekalling i kraft?

OpenAI mellomlagrer DEK-er i minnet for ytelse og robusthet. Tilbakekalling trer vanligvis i kraft innen én time, når mellomlagrede nøkler utløper og ny validering mislykkes.

Kan tilbakekalling testes trygt?

Det anbefales ikke å teste tilbakekalling i et arbeidsområde i produksjon, fordi det permanent vil gjøre eksisterende data utilgjengelige. Kunder kan imidlertid (og bør) teste tilbakekalling i et sandkassemiljø for å verifisere korrekt oppførsel og validere tillitsforutsetningene sine.

Hvis en nøkkel tilbakekalles permanent, kan arbeidsområdet gjenopprettes ved å knytte til en ny nøkkel?

Nei. Når nøkkelen er tapt, kan dataene ikke gjenopprettes av design. Den eneste avhjelpingen er å opprette et nytt arbeidsområde.

Hva bør vi gjøre hvis et arbeidsområde blir utilgjengelig på grunn av nøkkelendringer?

Den forventede avhjelpingen er å opprette et nytt arbeidsområde. Oppdatering av KMS-en vil ikke gjenopprette eksisterende data.

Hva er tilbakeføringsplanen hvis vi bestemmer oss for å slutte å bruke CMEK?

Per i dag 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 nås uten dem. Den eneste måten å slutte å bruke 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 vil bli generert for kryptering, så nye krypteringsforespørsler vil bruke den nye nøkkelen. KMS-identifikatoren (ARN eller nøkkelnavn) forblir imidlertid den samme og gamle data kan fortsatt dekrypteres. Mange skyleverandører tilbyr automatisk nøkkelrotasjon (AWS, GCP, Azure).

Krypterer OpenAI eldre data på nytt når jeg roterer hovednøkkelen min?

Nei. Det nye kryptografiske materialet vil bare bli brukt til å kryptere nye data.

Hvor lang tid tar det før nøkkelrotasjon eller nøkkeltilbakekalling trer i kraft?

1 time. Dette er fordi DEK-/eDEK-ene mellomlagres i minnet, og vi revaliderer disse oppføringene med KMS-en din hver time.

Bytte av KMS-identifikator

Er bytte av 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 å gjøre dette for et ChatGPT-arbeidsområde. Merk at når KMS-ARN-en oppdateres, vil eldre data forbli utilgjengelige, så du vil ende 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, så arkiver i stedet prosjektet hvis data uansett ikke er tilgjengelige, registrer en ny EKM-konfigurasjon med OpenAI, og opprett et nytt API-prosjekt med den nye KMS-nøkkelen.

Hva om jeg vil bytte KMS-identifikator selv regelmessig?

Dette anbefales ikke, siden du sannsynligvis ikke ønsker å tilbakekalle nøkkelen din regelmessig. Du kan imidlertid fortsatt gjøre dette hvis du bruker en skyleverandør som støtter et alias for KMS-nøkkel (AWS-eksempel). Du kan registrere dette KMS-nøkkelaliaset hos OpenAI, og deretter kan du hos skyleverandøren bytte ut den underliggende KMS-identifikatoren som aliaset peker til, når som helst for å utstede en nøkkeltilbakekalling.

Atferd i beta vs. GA

Er det noen kjente risikoer eller endringer på systemnivå ved bruk av krypteringsbetaen i produksjon?

Beta-miljøet er funksjonelt ekvivalent med GA, og det forventes ingen migreringstrinn. Den primære risikoen er at enkelte kanttilfellefunksjoner ennå kanskje 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.

Vil det være noen migreringstrinn fra beta til GA?

Nei. Arbeidsområder som bruker krypteringsbetaen, vil automatisk bli støttet 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 krever bare Encrypt- og Decrypt-tillatelser på KMS-nøkkelen din. GenerateDataKey-tillatelsen er ikke nødvendig for EKM-integrasjon.

Bruker OpenAI konvoluttkryptering for kundedata?

Ja. OpenAI bruker en modell for konvoluttkryptering:

• Kunde-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-en din om å dekryptere eDEK-en, henter DEK-en og dekrypterer innholdet.

Hvorfor valgte OpenAI denne modellen fremfor å 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, ikke behov for å vedlikeholde krypteringsinfrastruktur.

Ulemper: Hver forespørsel om kryptering/dekryptering treffer KMS, noe som øker ventetid og kostnad og introduserer 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, samt fortsatt drift under delvise KMS-brudd (opptil TTL-en for DEK-bufferen).

Ulemper: Litt mer kompleks implementering på OpenAIs side.

Denne utformingen gjør at OpenAI kan tilby sterke sikkerhetsgarantier samtidig som operasjonell risiko og kostnad 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 kryptert innenfor dette én-timesvinduet.

KMS-forespørselsvolum og observerbarhet

Vi ser langt færre KMS-forespørsler enn antall brukermeldinger. Bør disse tallene samsvare?

Nei, de vil ikke korrelere direkte.

Fordi OpenAI mellomlagrer DEK-er i minnet av ytelsesårsaker, foretas KMS-kall bare når en DEK må dekrypteres — ikke ved hver krypterings- eller dekrypteringsoperasjon. Som et resultat bør du forvente:

• Færre KMS-forespørsler enn brukerinteraksjoner.

• Leilighetsvise topper når mellomlagrede DEK-er utløper (omtrent hver time) eller når eldre krypterte data må åpnes.

• Ytterligere 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 mellomlagringstilstand, brukeratferd, datatilgangsmønstre og samtalelengde, og vil derfor ikke korrelere direkte med meldingsvolumet.