Koncepti enkripcije
Tok na visokoj razini
U svojem oblaku kontrolirate glavni ključ koji OpenAI nikada ne vidi
Vaš se glavni ključ upotrebljava za enkripciju ključeva za enkripciju podataka (DEK-ova) koje upotrebljava OpenAI
OpenAI upotrebljava DEK-ove za enkripciju vaših podataka u mirovanju. DEK se enkriptira vašim glavnim ključem, čime nastaje eDEK (enkriptirani DEK), koji se pohranjuje zajedno s vašim podacima
Za čitanje podataka OpenAI uzima eDEK, traži od vašeg KMS-a da ga dekriptira u DEK, a zatim dekriptira vaše podatke
Kako funkcionira EKM enkripcija?
Detaljne informacije potražite u našem članku: Pregled OpenAI Enterprise Key Managementa (EKM)
Pohranjuje li OpenAI moje DEK-ove?
Ne — pohranjujemo enkriptirane DEK-ove (eDEK-ove), koje generira vaš KMS. Za dekripciju podataka tražimo od vašeg KMS-a da dekriptira eDEK natrag u DEK.
Predmemorira li OpenAI moje DEK-ove?
Da — samo u memoriji. To se radi radi performansi kako se vaš KMS ne bi pozivao pri svakom zahtjevu za enkripciju/dekripciju podataka. DEK-ovi se nikada ne zapisuju u pohranu.
Dopuštenja u oblaku
Koja će dopuštenja OpenAI imati na mojem KMS-u?
Samo ona dopuštenja koja nam dodijelite pravilom koje postavite. Potrebne su nam barem operacije Encrypt/Decrypt. Također izradite novi ključ u svojem cloud KMS-u za OpenAI umjesto ponovne upotrebe postojećih ključeva koji se koriste u produkciji.
Kada OpenAI dobiva dopuštenja za pristup mojem KMS-u?
Moraju biti provedeni svi ovi koraci:
Prepoznali ste identitet OpenAI-ja (putem pravila povjerenja, identiteta radnog opterećenja itd., ovisno o pružatelju usluga u oblaku).
Izradili ste pravilo za pristup KMS-u.
Identitetu OpenAI-ja dodijelili ste dopuštenje za pristup pravilu.
Ako samo izradite KMS bez provedbe svih tih koraka, OpenAI nema pristup.
Moram li svoj glavni ključ pohraniti u svojem oblaku?
Ne — na vama je kako ćete upravljati svojim glavnim ključem. Možete imati rješenje kojim upravlja oblak ili vanjsko rješenje u kojem je vaš ključ pohranjen zasebno. OpenAI samo treba pozivati operacije encrypt/decrypt na vašem KMS-u — način na koji glavni ključ stvarno izvodi encrypt/decrypt za nas je nevidljiv implementacijski detalj.
Životni ciklus ključa
Rotacija DEK-a/eDEK-a (u nadležnosti OpenAI-ja)
Koliko se često rotiraju DEK-ovi/eDEK-ovi?
Svakih 24 sata na putu enkripcije (zahtjev za par ključeva DEK/eDEK)
Svakih 1 sat za put ključa za dekripciju (DEK -> eDEK)
Moram li nešto učiniti kada se DEK promijeni?
Ne — rotacija DEK-a/eDEK-a obavlja se unutar OpenAI-ja. Sve dok vaš glavni ključ ostaje valjan, svi eDEK-ovi enkriptirani vašim glavnim ključem mogu se i dalje dekriptirati u DEK, koji se zatim upotrebljava za dekripciju vaših podataka.
Rotacija i opoziv glavnog ključa (u vašoj nadležnosti)
Koliko se često događaju rotacija i opoziv ključa?
To određujete vi jer OpenAI nema uvid u vaš glavni ključ.
Koja je razlika između rotacije ključa i opoziva ključa?
Opoziv ključa uklanja pristup podacima enkriptiranim starijim ključevima. Rotacija ključa enkriptira podatke novim ključem, ali zadržava pristup za čitanje starijih podataka.
Što se događa ako opozovem svoj glavni ključ?
Ako se ključ opozove ili se uklone dopuštenja, radni prostor će s vremenom prestati funkcionirati kada predmemorirani ključevi isteknu. U tom trenutku OpenAI više ne može dekriptirati pohranjene podatke ni enkriptirati nove podatke. U praksi su podaci „uništeni”.
Koliko brzo opoziv stupa na snagu?
OpenAI predmemorira DEK-ove u memoriji radi performansi i otpornosti. Opoziv obično stupa na snagu u roku od jednog sata, kada predmemorirani ključevi isteknu i ponovna provjera ne uspije.
Može li se opoziv sigurno testirati?
Testiranje opoziva u produkcijskom radnom prostoru ne preporučuje se jer će postojeće podatke trajno učiniti nedostupnima. Međutim, korisnici mogu (i trebaju) testirati opoziv u sandbox okruženju kako bi provjerili ispravno ponašanje i potvrdili svoje pretpostavke o povjerenju.
Ako se ključ trajno opozove, može li se radni prostor oporaviti dodavanjem novog ključa?
Ne. Kada se ključ izgubi, podaci su po dizajnu nepovratni. Jedino rješenje je pokrenuti novi radni prostor.
Što trebamo učiniti ako radni prostor postane nedostupan zbog promjena ključa?
Očekivano rješenje je izrada novog radnog prostora. Ažuriranje KMS-a neće oporaviti postojeće podatke.
Koji je plan povratka ako odlučimo prestati upotrebljavati CMEK?
Trenutačno ne postoji plan povratka. Nakon što se radni prostor izradi s CMEK-om, svi povezani podaci enkriptiraju se ključevima kojima upravlja korisnik i bez njih im se ne može pristupiti. Jedini način za prestanak upotrebe CMEK-a jest izrada novog radnog prostora — postojeći enkriptirani podaci ostat će trajno nedostupni.
Što se događa kada rotiram svoj glavni ključ?
Za enkripciju će se generirati novi kriptografski materijal, pa će novi zahtjevi za enkripciju upotrebljavati novi ključ. Međutim, identifikator KMS-a (ARN ili naziv ključa) ostaje isti, a stari se podaci i dalje mogu dekriptirati. Mnogi pružatelji usluga u oblaku nude automatsku rotaciju ključeva (AWS, GCP, Azure).
Ponovno enkriptira li OpenAI starije podatke kada rotiram svoj glavni ključ?
Ne. Novi kriptografski materijal upotrebljavat će se samo za enkripciju novih podataka.
Koliko je potrebno da rotacija ili opoziv ključa stupe na snagu?
1 sat. Razlog je to što se DEK-ovi/eDEK-ovi predmemoriraju u memoriji, a te unose ponovno provjeravamo s vašim KMS-om svakog sata.
Promjena identifikatora KMS-a
Je li promjena identifikatora KMS-a opoziv ključa ili rotacija ključa?
Opoziv ključa. Jedan ključ ne može dekriptirati podatke enkriptirane drugim ključem.
Može li mi OpenAI pomoći promijeniti identifikator KMS-a za ChatGPT radni prostor?
Ako potvrdite da vam je namjera opozvati ključ, možemo vam pomoći da to učinite za ChatGPT radni prostor. Imajte na umu da će nakon ažuriranja KMS ARN-a stariji podaci ostati nedostupni, pa ćete nakon promjene imati mješavinu nedostupnih i dostupnih podataka.
Može li mi OpenAI pomoći promijeniti identifikator KMS-a za API projekt?
Ako upotrebljavate API, API olakšava arhiviranje i izradu novih projekata, pa umjesto toga arhivirajte projekt čiji podaci ionako nisu dostupni, registrirajte novu EKM konfiguraciju kod OpenAI-ja i izradite novi API projekt s novim KMS ključem.
Što ako želim samostalno redovito mijenjati identifikator KMS-a?
To se ne preporučuje jer vjerojatno ne želite redovito opozivati svoj ključ. Međutim, to ipak možete učiniti ako upotrebljavate pružatelja usluga u oblaku koji podržava alias KMS ključa (primjer za AWS). Taj alias KMS ključa možete registrirati kod OpenAI-ja, a zatim kod svojeg pružatelja usluga u oblaku u bilo kojem trenutku zamijeniti temeljni identifikator KMS-a na koji alias upućuje kako biste izdali opoziv ključa.
Ponašanje u beti u odnosu na GA
Postoje li poznati rizici ili promjene na razini sustava pri upotrebi bete enkripcije u produkciji?
Beta okruženje funkcionalno je jednako GA-u i ne očekuju se koraci migracije. Glavni je rizik da neke rubne funkcionalnosti možda još ne podržavaju enkriptirani sadržaj zbog nepotpunih putanja koda. To je rijetko i aktivno se rješava. Podaci su u potpunosti enkriptirani i zaštićeni bez obzira na te moguće probleme.
Hoće li biti koraka migracije iz bete u GA?
Ne. Radni prostori koji upotrebljavaju betu enkripcije automatski će biti podržani u GA-u bez ikakve radnje korisnika.
Dodatni tehnički detalji
Omotna enkripcija i dopuštenja
Moramo li OpenAI-ju za EKM dodijeliti dopuštenja GenerateDataKey?
Ne. OpenAI zahtijeva samo dopuštenja Encrypt i Decrypt za vaš KMS ključ. Dopuštenje GenerateDataKey nije potrebno za EKM integraciju.
Upotrebljava li OpenAI omotnu enkripciju za podatke korisnika?
Da. OpenAI upotrebljava model omotne enkripcije:
Korisnički KMS: Upravlja ključevima za enkripciju ključeva (KEK-ovima). OpenAI nikada ne vidi niti pohranjuje KEK-ove.
Infrastruktura OpenAI-ja: Generira i upravlja ključevima za enkripciju podataka (DEK-ovima). Svaki DEK enkriptira se (omata) vašim KEK-om prije pohrane.
Tok podataka:
Podaci korisnika enkriptiraju se DEK-om.
Taj se DEK enkriptira vašim KEK-om, čime nastaje eDEK.
eDEK se pohranjuje uz enkriptirane podatke.
Za dekripciju podataka OpenAI traži od vašeg KMS-a da dekriptira eDEK, dohvaća DEK i dekriptira sadržaj.
Zašto je OpenAI odabrao ovaj model umjesto da KMS-u prepusti upravljanje i KEK-ovima i DEK-ovima?
Postoje dva uobičajena pristupa omotnoj enkripciji:
KEK-ovi i DEK-ovi kojima upravlja KMS:
Prednosti: Jednostavnija implementacija, bez potrebe za održavanjem infrastrukture za enkripciju.
Nedostaci: Svaki zahtjev za enkripciju/dekripciju ide na KMS, što povećava latenciju i trošak te uvodi jedinstvenu točku kvara.
KEK-ovi kojima upravlja KMS / DEK-ovi kojima upravlja OpenAI (naš pristup):
Prednosti: Znatno niža latencija i trošak, bolja skalabilnost i pouzdanost te nastavak rada tijekom djelomičnih ispada KMS-a (do isteka TTL-a predmemorije DEK-a).
Nedostaci: Nešto složenija implementacija na strani OpenAI-ja.
Ovaj dizajn omogućuje OpenAI-ju pružanje snažnih sigurnosnih jamstava uz smanjenje operativnog rizika i troška za korisnike.
Koliko se često rotiraju DEK-ovi?
Svaki DEK rotira se otprilike svakih 60 minuta. Time se osigurava vremenska izolacija — čak i ako bi DEK nekako bio kompromitiran, učinak bi bio ograničen na podatke enkriptirane unutar tog jednosatnog razdoblja.
Količina KMS zahtjeva i mogućnost promatranja
Vidimo mnogo manje KMS zahtjeva nego korisničkih poruka. Trebaju li se ti brojevi podudarati?
Ne, neće biti izravno povezani.
Budući da OpenAI predmemorira DEK-ove u memoriji radi performansi, KMS pozivi upućuju se samo kada je potrebno dekriptirati DEK — ne pri svakoj operaciji enkripcije ili dekripcije. Zato možete očekivati:
Manje KMS zahtjeva nego korisničkih interakcija.
Povremene skokove kada predmemorirani DEK-ovi isteknu (otprilike svakih sat vremena) ili kada treba pristupiti starijim enkriptiranim podacima.
Dodatne pozive pri dohvaćanju povijesnih podataka, primjerice kada korisnik nastavi dugotrajan razgovor i treba učitati starije DEK-ove.
Točan broj KMS zahtjeva ovisi o stanju predmemorije, ponašanju korisnika, obrascima pristupa podacima i duljini razgovora, pa neće biti izravno povezan s količinom poruka.