Koncepti enkripcije

Tok na visokoj razini

• Vi upravljate glavnim ključem u svom oblaku koji OpenAI nikada ne vidi

• Vaš glavni ključ koristi se za šifriranje ključeva za šifriranje podataka (DEK-ova) koje koristi OpenAI

• OpenAI koristi DEK-ove za šifriranje vaših podataka u mirovanju. DEK je šifriran vašim glavnim ključem, čime nastaje eDEK (šifrirani DEK), koji se pohranjuje zajedno s vašim podacima

• Za čitanje podataka OpenAI uzima eDEK, traži od vašeg KMS-a da ga dešifrira u DEK, a zatim dešifrira vaše podatke

Kako funkcionira EKM enkripcija?

Za detaljne informacije pogledajte naš članak: Pregled OpenAI Enterprise Key Managementa (EKM)

Pohranjuje li OpenAI moje DEK-ove?

Ne - pohranjujemo šifrirane DEK-ove (eDEK-ove), koje generira vaš KMS. Za dešifriranje podataka tražimo od vašeg KMS-a da dešifrira eDEK natrag u DEK.

Kešira li OpenAI moje DEK-ove?

Da - samo u memoriji. To je radi performansi kako bismo izbjegli pozivanje vašeg KMS-a pri svakom zahtjevu za šifriranje/dešifriranje podataka. DEK-ovi se nikada ne zapisuju u pohranu.

Dozvole u oblaku

Koje će dozvole OpenAI imati na mom KMS-u?

Samo dozvole koje nam dodijelite putem pravila koje postavite. Potrebne su nam barem operacije Encrypt/Decrypt. Također izradite novi ključ u svom cloud KMS-u za OpenAI umjesto da ponovno koristite postojeće ključeve koji služe za produkciju.

Kada OpenAI dobiva dozvole za pristup mom KMS-u?

Svi ovi koraci moraju biti poduzeti: 1. prepoznali ste identitet OpenAI-ja (putem pravila povjerenja, identiteta radnog opterećenja itd., ovisno o pružatelju usluge u oblaku), 2. izradili ste pravilo za pristup KMS-u i 3. dodijelili ste identitetu OpenAI-ja dozvolu za pristup tom pravilu. Ako samo izradite KMS bez svih ovih koraka, OpenAI nema pristup.

Moram li pohraniti svoj glavni ključ u svom 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 se vaš ključ pohranjuje zasebno. OpenAI samo treba pozivati operacije šifriranja/dešifriranja na vašem KMS-u - način na koji glavni ključ zapravo obavlja šifriranje/dešifriranje implementacijski je detalj koji nama nije vidljiv.

Životni ciklus ključa

Rotacija DEK/eDEK-ova (kontrolira OpenAI)

Koliko često se DEK/eDEK-ovi rotiraju?

Svakih 24 sata na putu šifriranja (zahtijevanje para ključeva DEK/eDEK)

Svakih 1 sat za put ključa dešifriranja (DEK -> eDEK)

Moram li nešto učiniti kada se DEK promijeni?

Ne - rotacija DEK/eDEK-ova obavlja se unutar OpenAI-ja. Dok god vaš glavni ključ ostaje valjan, svi eDEK-ovi šifrirani vašim glavnim ključem mogu se i dalje dešifrirati u DEK, koji se zatim koristi za dešifriranje vaših podataka.

Rotacija i opoziv glavnog ključa (vi kontrolirate)

Koliko često dolazi do rotacije ključa i opoziva 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 šifriranima starijim ključevima. Rotacija ključa šifrira 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 dozvole, radni prostor će s vremenom postati nefunkcionalan kada keširani ključevi isteknu. U tom trenutku OpenAI više ne može dešifrirati pohranjene podatke ni šifrirati nove podatke. U praksi su podaci „uništeni”.

Koliko brzo opoziv stupa na snagu?

OpenAI kešira DEK-ove u memoriji radi performansi i otpornosti. Opoziv obično stupa na snagu unutar jednog sata, nakon što keširani 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 trajno učiniti postojeće podatke 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 je ključ trajno opozvan, može li se radni prostor oporaviti priključivanjem novog ključa?

Ne. Kada se ključ izgubi, podaci su prema dizajnu nepovratni. Jedini način sanacije je pokretanje novog radnog prostora.

Što trebamo učiniti ako radni prostor postane nedostupan zbog promjena ključa?

Očekivani način sanacije jest izrada novog radnog prostora. Ažuriranje KMS-a neće oporaviti postojeće podatke.

Koji je plan povratka ako odlučimo prestati koristiti CMEK?

Trenutačno ne postoji plan povratka. Nakon što se radni prostor izradi s CMEK-om, svi povezani podaci šifrirani su korisnički upravljanim ključevima i ne mogu im se pristupiti bez njih. Jedini način za prekid korištenja CMEK-a jest izrada novog radnog prostora — postojeći šifrirani podaci ostat će trajno nedostupni.

Što se događa kada rotiram svoj glavni ključ?

Novi kriptografski materijal generirat će se za šifriranje pa će novi zahtjevi za šifriranje koristiti novi ključ. Međutim, KMS identifikator (ARN ili naziv ključa) ostaje isti i stari podaci i dalje se mogu dešifrirati. Mnogi pružatelji cloud usluga nude automatsku rotaciju ključa (AWS, GCP, Azure).

Šifrira li OpenAI ponovno starije podatke kada rotiram svoj glavni ključ?

Ne. Novi kriptografski materijal koristit će se samo za šifriranje novih podataka.

Koliko je vremena potrebno da rotacija ključa ili opoziv ključa stupe na snagu?

1 sat. To je zato što se DEK/eDEK-ovi keširaju u memoriji i te unose ponovno provjeravamo s vašim KMS-om svakih sat vremena.

Promjena KMS identifikatora

Je li promjena KMS identifikatora opoziv ključa ili rotacija ključa?

Opoziv ključa. Jedan ključ ne može dešifrirati podatke šifrirane drugim ključem.

Može li mi OpenAI pomoći promijeniti moj KMS identifikator za ChatGPT radni prostor?

Ako potvrdite da je namjera opozvati vaš ključ, možemo vam pomoći to učiniti za ChatGPT radni prostor. Imajte na umu da će, kada se ažurira KMS ARN, stariji podaci ostati nedostupni, pa ćete nakon promjene imati mješavinu nedostupnih i dostupnih podataka.

Može li mi OpenAI pomoći promijeniti moj KMS identifikator 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 s OpenAI-jem i izradite novi API projekt s novim KMS ključem.

Što ako želim redovito sam mijenjati svoj KMS identifikator?

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 cloud usluga koji podržava alias KMS ključa (AWS primjer). Taj alias KMS ključa možete registrirati s OpenAI-jem, a zatim kod svojeg pružatelja cloud usluga u bilo kojem trenutku možete zamijeniti osnovni KMS identifikator na koji alias pokazuje kako biste izdali opoziv ključa.

Ponašanje bete u odnosu na GA

Postoje li poznati rizici ili promjene na razini sustava pri korištenju beta enkripcije u produkciji?

Beta okruženje funkcionalno je ekvivalentno GA-u i ne očekuju se nikakvi koraci migracije. Primarni rizik jest da neke funkcije rubnih slučajeva možda još ne podržavaju šifrirani sadržaj zbog nepotpunih putova u kodu. To je rijetko i aktivno se rješava. Podaci su u potpunosti šifrirani i zaštićeni bez obzira na te moguće probleme.

Hoće li biti ikakvih koraka migracije iz bete u GA?

Ne. Radni prostori koji koriste beta enkripciju automatski će biti podržani u GA-u bez ikakve radnje korisnika.

Dodatni tehnički detalji

Envelope enkripcija i dozvole

Trebamo li OpenAI-ju dodijeliti dozvole GenerateDataKey za EKM?

Ne. OpenAI zahtijeva samo dozvole Encrypt i Decrypt na vašem KMS ključu. Dozvola GenerateDataKey nije potrebna za integraciju EKM-a.

Koristi li OpenAI envelope enkripciju za korisničke podatke?

Da. OpenAI koristi model envelope enkripcije:

• Korisnički KMS: Upravlja ključevima za šifriranje ključeva (KEK-ovima). OpenAI nikada ne vidi niti pohranjuje KEK-ove.

• OpenAI infrastruktura: Generira i upravlja ključevima za šifriranje podataka (DEK-ovima). Svaki DEK šifrira se (omata) vašim KEK-om prije pohrane.

• Tok podataka:

  • Korisnički podaci šifriraju se DEK-om.

  • Taj DEK šifrira se vašim KEK-om, čime nastaje eDEK.

  • eDEK se pohranjuje uz šifrirane podatke.

  • Za dešifriranje podataka OpenAI traži od vašeg KMS-a da dešifrira eDEK, dohvaća DEK i dešifrira sadržaj.

Zašto je OpenAI odabrao ovaj model umjesto da KMS upravlja i KEK-ovima i DEK-ovima?

Postoje dva uobičajena pristupa envelope enkripciji:

KEK-ovi i DEK-ovi kojima upravlja KMS:

Prednosti: jednostavnija implementacija, nema potrebe za održavanjem infrastrukture za šifriranje.

Nedostaci: svaki zahtjev za šifriranje/dešifriranje pogađa KMS, što povećava latenciju i trošak te uvodi jednu točku otkaza.

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 TTL-a DEK keša).

Nedostaci: nešto složenija implementacija na strani OpenAI-ja.

Ovaj dizajn omogućuje OpenAI-ju da pruži snažna sigurnosna jamstva uz smanjenje operativnog rizika i troška za korisnike.

Koliko često se DEK-ovi rotiraju?

Svaki DEK rotira se otprilike svakih 60 minuta. To pruža vremensku izolaciju — čak i ako bi DEK nekako bio kompromitiran, utjecaj bi bio ograničen na podatke šifrirane unutar tog jednosatnog prozora.

Opseg KMS zahtjeva i vidljivost

Vidimo mnogo manje KMS zahtjeva od broja korisničkih poruka. Trebaju li se ti brojevi podudarati?

Ne, neće biti izravno povezani.

Budući da OpenAI kešira DEK-ove u memoriji radi performansi, KMS pozivi obavljaju se samo kada DEK treba dešifrirati — ne pri svakoj operaciji šifriranja ili dešifriranja. Kao rezultat, trebali biste očekivati:

• Manje KMS zahtjeva nego korisničkih interakcija.

• Povremene skokove kada keširani DEK-ovi isteknu (otprilike svakih sat vremena) ili kada treba pristupiti starijim šifriranim podacima.

• Dodatne pozive pri dohvaćanju povijesnih podataka, primjerice kada korisnik nastavlja dugotrajan razgovor i starije DEK-ove treba učitati.

Točan broj KMS zahtjeva ovisi o stanju keša, ponašanju korisnika, obrascima pristupa podacima i duljini razgovora te stoga neće biti izravno povezan s količinom poruka.