Koncepti šifriranja
Potek na visoki ravni
Vi nadzorujete glavni ključ v svojem oblaku, ki ga OpenAI nikoli ne vidi
Vaš glavni ključ se uporablja za šifriranje ključev za šifriranje podatkov (DEK), ki jih uporablja OpenAI
OpenAI uporablja DEK-e za šifriranje vaših podatkov v mirovanju. DEK je šifriran z vašim glavnim ključem, pri čemer nastane eDEK (šifrirani DEK), ki je shranjen skupaj z vašimi podatki
Za branje podatkov OpenAI vzame eDEK, od vašega KMS zahteva, da ga dešifrira v DEK, nato pa dešifrira vaše podatke
Kako deluje šifriranje EKM?
Za podrobne informacije si oglejte naš članek: Pregled OpenAI Enterprise Key Management (EKM)
Ali OpenAI shranjuje moje DEK-e?
Ne — shranjujemo šifrirane DEK-e (eDEK), ki jih ustvari vaš KMS. Za dešifriranje podatkov vaš KMS prosimo, da eDEK dešifrira nazaj v DEK.
Ali OpenAI predpomni moje DEK-e?
Da — samo v pomnilniku. To je namenjeno zmogljivosti, da se vaš KMS ne zadene pri vsaki zahtevi za šifriranje/dešifriranje podatkov. DEK-i se nikoli ne zapišejo v shrambo.
Dovoljenja v oblaku
Katera dovoljenja bo imel OpenAI za moj KMS?
Samo dovoljenja, ki nam jih podelite s pravilnikom, ki ga nastavite. Potrebujemo vsaj operaciji Encrypt/Decrypt. V svojem oblačnem KMS za OpenAI ustvarite tudi nov ključ, namesto da znova uporabite obstoječe ključe, namenjene produkciji.
Kdaj OpenAI dobi dovoljenja za dostop do mojega KMS?
Izvesti morate vse te korake:
Prepoznali ste identiteto OpenAI (prek pravilnika zaupanja, identitete delovne obremenitve itd., odvisno od ponudnika oblaka).
Ustvarili ste pravilnik za dostop do KMS.
Identiteti OpenAI ste dodelili dovoljenje za dostop do pravilnika.
Če samo ustvarite KMS, ne da bi izvedli vse te korake, OpenAI nima dostopa.
Ali moram svoj glavni ključ shranjevati v svojem oblaku?
Ne — sami se odločite, kako boste upravljali svoj glavni ključ. Uporabite lahko rešitev, upravljano v oblaku, ali zunanjo rešitev, kjer je vaš ključ shranjen ločeno. OpenAI mora samo klicati operacije šifriranja/dešifriranja v vašem KMS; kako glavni ključ dejansko izvaja šifriranje/dešifriranje, je izvedbena podrobnost, ki nam ni vidna.
Življenjski cikel ključa
Rotacija DEK/eDEK (nadzira OpenAI)
Kako pogosto se rotirajo DEK-i/eDEK-i?
Vsakih 24 ur na poti šifriranja (zahteva za par ključev DEK/eDEK)
Vsako 1 uro za pot ključa za dešifriranje (DEK -> eDEK)
Ali moram kaj storiti, ko se DEK spremeni?
Ne — rotacija DEK/eDEK se izvede znotraj OpenAI. Dokler vaš glavni ključ ostane veljaven, je mogoče vse eDEK-e, šifrirane z vašim glavnim ključem, še naprej dešifrirati v DEK, ki se nato uporabi za dešifriranje vaših podatkov.
Rotacija in preklic glavnega ključa (nadzorujete vi)
Kako pogosto pride do rotacije in preklica ključa?
To določite vi, saj OpenAI nima vpogleda v vaš glavni ključ.
Kakšna je razlika med rotacijo ključa in preklicem ključa?
Preklic ključa odstrani dostop do podatkov, šifriranih s starejšimi ključi. Rotacija ključa šifrira podatke z novim ključem, vendar ohrani bralni dostop do starejših podatkov.
Kaj se zgodi, če prekličem svoj glavni ključ?
Če je ključ preklican ali so dovoljenja odstranjena, bo delovni prostor sčasoma postal nedelujoč, ko potečejo predpomnjeni ključi. Takrat OpenAI ne more več dešifrirati shranjenih podatkov ali šifrirati novih podatkov. V praksi so podatki »razrezani«.
Kako hitro začne veljati preklic?
OpenAI zaradi zmogljivosti in odpornosti predpomni DEK-e v pomnilniku. Preklic običajno začne veljati v eni uri, ko potečejo predpomnjeni ključi in ponovno preverjanje ne uspe.
Ali je mogoče varno preizkusiti preklic?
Preizkušanje preklica v produkcijskem delovnem prostoru ni priporočljivo, ker bodo obstoječi podatki trajno postali nedostopni. Vendar lahko stranke preklic preizkusijo v peskovniškem okolju (in bi ga morale), da preverijo pravilno delovanje in potrdijo svoje predpostavke zaupanja.
Če je ključ trajno preklican, ali je mogoče delovni prostor obnoviti s priložitvijo novega ključa?
Ne. Ko je ključ izgubljen, podatkov načrtno ni mogoče več pridobiti. Edina rešitev je vzpostavitev novega delovnega prostora.
Kaj moramo storiti, če delovni prostor zaradi sprememb ključa postane nedostopen?
Pričakovana rešitev je ustvariti nov delovni prostor. Posodobitev KMS ne bo obnovila obstoječih podatkov.
Kakšen je načrt za umik, če se odločimo prenehati uporabljati CMEK?
Trenutno načrta za umik ni. Ko je delovni prostor ustvarjen s CMEK, so vsi povezani podatki šifrirani s ključi, ki jih upravlja stranka, in brez njih niso dostopni. Edini način za prenehanje uporabe CMEK je ustvariti nov delovni prostor — obstoječi šifrirani podatki bodo ostali trajno nedostopni.
Kaj se zgodi, ko rotiram svoj glavni ključ?
Za šifriranje bo ustvarjen nov kriptografski material, zato bodo nove zahteve za šifriranje uporabljale novi ključ. Vendar identifikator KMS (ARN ali ime ključa) ostane enak, stare podatke pa je še vedno mogoče dešifrirati. Številni ponudniki oblaka omogočajo samodejno rotacijo ključev (AWS, GCP, Azure).
Ali OpenAI ob rotaciji mojega glavnega ključa znova šifrira starejše podatke?
Ne. Novi kriptografski material bo uporabljen samo za šifriranje novih podatkov.
Koliko časa traja, da začne veljati rotacija ali preklic ključa?
1 uro. Razlog je, da so DEK/eDEK-i predpomnjeni v pomnilniku, te vnose pa vsako uro znova preverimo z vašim KMS.
Zamenjava identifikatorja KMS
Ali je zamenjava identifikatorja KMS preklic ključa ali rotacija ključa?
Preklic ključa. En ključ ne more dešifrirati podatkov, šifriranih z drugim ključem.
Ali mi lahko OpenAI pomaga zamenjati identifikator KMS za delovni prostor ChatGPT?
Če potrdite, da želite preklicati svoj ključ, vam lahko pri tem pomagamo za delovni prostor ChatGPT. Upoštevajte, da bodo ob posodobitvi KMS ARN starejši podatki ostali nedostopni, zato boste po spremembi imeli mešanico nedostopnih in dostopnih podatkov.
Ali mi lahko OpenAI pomaga zamenjati identifikator KMS za projekt API?
Če uporabljate API, ta omogoča preprosto arhiviranje in ustvarjanje novih projektov. Zato raje arhivirajte projekt, katerega podatki tako ali tako niso dostopni, registrirajte novo konfiguracijo EKM pri OpenAI in ustvarite nov projekt API z novim ključem KMS.
Kaj pa, če želim sam redno zamenjevati svoj identifikator KMS?
To ni priporočljivo, saj verjetno ne želite redno preklicevati svojega ključa. Kljub temu lahko to storite, če uporabljate ponudnika oblaka, ki podpira vzdevek ključa KMS (primer AWS). Ta vzdevek ključa KMS lahko registrirate pri OpenAI, nato pa lahko pri svojem ponudniku oblaka kadar koli zamenjate osnovni identifikator KMS, na katerega kaže vzdevek, in s tem izvedete preklic ključa.
Vedenje v različici beta v primerjavi z GA
Ali so pri uporabi beta različice šifriranja v produkciji znana tveganja ali sistemske spremembe?
Okolje beta je funkcionalno enakovredno GA in migracijski koraki niso predvideni. Glavno tveganje je, da nekatere funkcije za robne primere zaradi nepopolnih poti kode morda še ne podpirajo šifrirane vsebine. Ti primeri so redki in jih aktivno odpravljamo. Podatki so v celoti šifrirani in zaščiteni ne glede na te morebitne težave.
Ali bodo potrebni kakšni migracijski koraki iz beta v GA?
Ne. Delovni prostori, ki uporabljajo beta različico šifriranja, bodo v GA samodejno podprti brez kakršnega koli dejanja uporabnika.
Dodatne tehnične podrobnosti
Ovojno šifriranje in dovoljenja
Ali moramo OpenAI za EKM podeliti dovoljenja GenerateDataKey?
Ne. OpenAI za vaš ključ KMS potrebuje samo dovoljenji Encrypt in Decrypt. Dovoljenje GenerateDataKey ni potrebno za integracijo EKM.
Ali OpenAI za podatke strank uporablja ovojno šifriranje?
Da. OpenAI uporablja model ovojnega šifriranja:
KMS stranke: upravlja ključe za šifriranje ključev (KEK). OpenAI KEK-ov nikoli ne vidi ali shranjuje.
Infrastruktura OpenAI: ustvarja in upravlja ključe za šifriranje podatkov (DEK). Vsak DEK je pred shranjevanjem šifriran (ovít) z vašim KEK.
Tok podatkov:
Podatki stranke so šifrirani z DEK.
Ta DEK je šifriran z vašim KEK, pri čemer nastane eDEK.
eDEK je shranjen skupaj s šifriranimi podatki.
Za dešifriranje podatkov OpenAI od vašega KMS zahteva, da dešifrira eDEK, pridobi DEK in dešifrira vsebino.
Zakaj je OpenAI izbral ta model, namesto da bi KMS upravljal tako KEK-e kot DEK-e?
Obstajata dva pogosta pristopa k ovojnemu šifriranju:
KEK-i in DEK-i, ki jih upravlja KMS:
Prednosti: preprostejša uvedba, brez potrebe po vzdrževanju šifrirne infrastrukture.
Slabosti: vsaka zahteva za šifriranje/dešifriranje zadene KMS, kar poveča zakasnitev in stroške ter uvede eno samo točko odpovedi.
KEK-i, ki jih upravlja KMS / DEK-i, ki jih upravlja OpenAI (naš pristop):
Prednosti: bistveno manjša zakasnitev in stroški, boljša razširljivost in zanesljivost ter nadaljnje delovanje med delnimi izpadi KMS (do TTL predpomnilnika DEK).
Slabosti: nekoliko bolj zapletena uvedba na strani OpenAI.
Ta zasnova OpenAI omogoča zagotavljanje močnih varnostnih jamstev, hkrati pa zmanjšuje operativno tveganje in stroške za stranke.
Kako pogosto se rotirajo DEK-i?
Vsak DEK se rotira približno vsakih 60 minut. To zagotavlja časovno izolacijo — tudi če bi bil DEK nekako ogrožen, bi bil vpliv omejen na podatke, šifrirane v tem enournem obdobju.
Obseg zahtev KMS in opazljivost
Vidimo precej manj zahtev KMS kot uporabniških sporočil. Ali bi se morale te številke ujemati?
Ne, neposredno ne bodo povezane.
Ker OpenAI zaradi zmogljivosti predpomni DEK-e v pomnilniku, se klici KMS izvedejo samo, ko je treba dešifrirati DEK — ne pri vsaki operaciji šifriranja ali dešifriranja. Zato lahko pričakujete:
Manj zahtev KMS kot uporabniških interakcij.
Občasne skoke, ko potečejo predpomnjeni DEK-i (približno vsako uro) ali ko je treba dostopati do starejših šifriranih podatkov.
Dodatne klice pri pridobivanju zgodovinskih podatkov, na primer ko uporabnik nadaljuje dolgotrajen pogovor in je treba naložiti starejše DEK-e.
Natančno število zahtev KMS je odvisno od stanja predpomnilnika, vedenja uporabnikov, vzorcev dostopa do podatkov in dolžine pogovorov, zato ne bo neposredno povezano s količino sporočil.