Koncepti šifriranja
Tok na visokom nivou
Vi kontrolišete glavni ključ u svom cloudu, 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 se šifrira vašim glavnim ključem, čime nastaje eDEK (šifrirani DEK), koji se pohranjuje zajedno s vašim podacima
Da bi pročitao podatke, OpenAI uzima eDEK, traži od vašeg KMS-a da ga dešifrira u DEK, a zatim dešifrira vaše podatke
Kako funkcioniše EKM šifriranje?
Za detaljne informacije pogledajte naš članak: Pregled OpenAI Enterprise Key Management (EKM)
Da li OpenAI pohranjuje moje DEK-ove?
Ne — pohranjujemo šifrirane DEK-ove (eDEK-ove), koje generiše vaš KMS. Da bismo dešifrirali podatke, tražimo od vašeg KMS-a da dešifrira eDEK nazad u DEK.
Da li OpenAI kešira moje DEK-ove?
Da — samo u memoriji. To je radi performansi, kako se vaš KMS ne bi pozivao pri svakom zahtjevu za šifriranje/dešifriranje podataka. DEK-ovi se nikada ne zapisuju u pohranu.
Cloud dozvole
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 kreirajte novi ključ u svom cloud KMS-u za OpenAI, umjesto da ponovo koristite postojeće ključeve koji imaju produkcijsku namjenu.
Kada OpenAI dobija dozvole za pristup mom KMS-u?
Svi ovi koraci moraju biti obavljeni:
Prepoznali ste identitet OpenAI-ja (putem trust policyja, workload identityja itd., zavisno od cloud pružatelja).
Kreirali ste pravilo za pristup KMS-u.
Dodijelili ste identitetu OpenAI-ja dozvolu za pristup pravilu.
Ako samo kreirate KMS bez provođenja svih ovih koraka, OpenAI nema pristup.
Moram li pohraniti svoj glavni ključ u svom cloudu?
Ne — na vama je kako ćete upravljati svojim glavnim ključem. Možete imati rješenje kojim upravlja cloud ili eksterno rješenje u kojem je vaš ključ pohranjen odvojeno. OpenAI samo treba pozivati operacije šifriranja/dešifriranja na vašem KMS-u — način na koji glavni ključ stvarno obavlja šifriranje/dešifriranje je implementacijski detalj koji nam nije vidljiv.
Životni ciklus ključa
Rotacija DEK/eDEK ključeva (kontroliše OpenAI)
Koliko često se rotiraju DEK/eDEK ključevi?
Svakih 24 sata na putanji šifriranja (zahtjev za DEK/eDEK par ključeva)
Svakih 1 sat za putanju ključa za dešifriranje (DEK -> eDEK)
Moram li nešto uraditi kada se DEK promijeni?
Ne — rotacija DEK/eDEK-ova obavlja se unutar OpenAI-ja. Sve dok vaš glavni ključ ostaje važeći, 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 (kontrolišete vi)
Koliko često se dešavaju rotacija ključa 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 šifriranim starijim ključevima. Rotacija ključa šifrira podatke novim ključem, ali zadržava pristup za čitanje starijih podataka.
Šta se dešava ako opozovem svoj glavni ključ?
Ako se ključ opozove ili se dozvole uklone, radni prostor će s vremenom prestati funkcionisati kada keširani ključevi isteknu. U tom trenutku OpenAI više ne može dešifrirati pohranjene podatke niti šifrirati nove podatke. U praksi, podaci su „isjeckani“.
Koliko brzo opoziv stupa na snagu?
OpenAI kešira DEK-ove u memoriji radi performansi i otpornosti. Opoziv obično stupa na snagu u roku od jednog sata, kada keširani ključevi isteknu i ponovna validacija ne uspije.
Može li se opoziv sigurno testirati?
Testiranje opoziva u produkcijskom radnom prostoru se ne preporučuje jer će postojeće podatke trajno učiniti nedostupnim. Međutim, korisnici mogu (i trebaju) testirati opoziv u sandbox okruženju kako bi potvrdili ispravno ponašanje i provjerili svoje pretpostavke o povjerenju.
Ako je ključ trajno opozvan, 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.
Šta trebamo učiniti ako radni prostor postane nedostupan zbog promjena ključa?
Očekivano rješenje je kreiranje novog radnog prostora. Ažuriranje KMS-a neće oporaviti postojeće podatke.
Koji je plan povlačenja ako odlučimo prestati koristiti CMEK?
Trenutno ne postoji plan povlačenja. Kada se radni prostor kreira s CMEK-om, svi povezani podaci šifriraju se ključevima kojima upravlja korisnik i bez njih im se ne može pristupiti. Jedini način da prestanete koristiti CMEK je kreiranje novog radnog prostora — postojeći šifrirani podaci ostat će trajno nedostupni.
Šta se dešava kada rotiram svoj glavni ključ?
Za šifriranje će se generisati novi kriptografski materijal, pa će novi zahtjevi za šifriranje koristiti novi ključ. Međutim, KMS identifikator (ARN ili naziv ključa) ostaje isti i stari podaci se i dalje mogu dešifrirati. Mnogi cloud pružatelji nude automatsku rotaciju ključeva (AWS, GCP, Azure).
Da li OpenAI ponovo šifrira starije podatke kada rotiram svoj glavni ključ?
Ne. Novi kriptografski materijal koristit će se samo za šifriranje novih podataka.
Koliko je 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, a mi te unose ponovo validiramo s vašim KMS-om svakog sata.
Promjena KMS identifikatora
Da li je 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 da promijenim KMS identifikator za ChatGPT radni prostor?
Ako potvrdite da je namjera opozvati vaš ključ, možemo vam pomoći da to uradite za ChatGPT radni prostor. Imajte na umu da će, kada se KMS ARN ažurira, stariji podaci ostati nedostupni, pa ćete nakon promjene imati mješavinu nedostupnih i dostupnih podataka.
Može li mi OpenAI pomoći da promijenim KMS identifikator za API projekt?
Ako koristite API, API olakšava arhiviranje i kreiranje novih projekata, pa umjesto toga arhivirajte projekt čiji podaci ionako nisu dostupni, registrujte novu EKM konfiguraciju kod OpenAI-ja i kreirajte novi API projekt s novim KMS ključem.
Šta ako želim samostalno redovno mijenjati svoj KMS identifikator?
To se ne preporučuje jer vjerovatno ne želite redovno opozivati svoj ključ. Ipak, to možete uraditi ako koristite cloud pružatelja koji podržava alias KMS ključa (AWS primjer). Taj alias KMS ključa možete registrovati kod OpenAI-ja, a zatim kod svog cloud pružatelja u bilo kojem trenutku zamijeniti osnovni KMS identifikator na koji alias upućuje kako biste izvršili opoziv ključa.
Ponašanje u beti u odnosu na GA
Postoje li poznati rizici ili promjene na nivou sistema pri korištenju beta verzije šifriranja u produkciji?
Beta okruženje je funkcionalno ekvivalentno GA verziji i ne očekuju se koraci migracije. Glavni rizik je da neke funkcije za rubne slučajeve možda još ne podržavaju šifrirani sadržaj zbog nedovršenih putanja koda. To je rijetko i aktivno se rješava. Podaci su u potpunosti šifrirani i zaštićeni bez obzira na ove moguće probleme.
Hoće li biti koraka migracije iz bete u GA?
Ne. Radni prostori koji koriste beta verziju šifriranja bit će automatski podržani u GA verziji bez ikakve radnje korisnika.
Dodatni tehnički detalji
Envelope šifriranje i dozvole
Trebamo li OpenAI-ju dodijeliti GenerateDataKey dozvole za EKM?
Ne. OpenAI zahtijeva samo Encrypt i Decrypt dozvole za vaš KMS ključ. GenerateDataKey dozvola nije potrebna za EKM integraciju.
Koristi li OpenAI envelope šifriranje za podatke korisnika?
Da. OpenAI koristi model envelope šifriranja:
KMS korisnika: Upravlja ključevima za šifriranje ključeva (KEK-ovima). OpenAI nikada ne vidi niti pohranjuje KEK-ove.
OpenAI infrastruktura: Generiše i upravlja ključevima za šifriranje podataka (DEK-ovima). Svaki DEK se prije pohrane šifrira (wrapuje) vašim KEK-om.
Tok podataka:
Podaci korisnika se šifriraju DEK-om.
Taj DEK se šifrira vašim KEK-om, čime nastaje eDEK.
eDEK se pohranjuje uz šifrirane podatke.
Da bi dešifrirao podatke, OpenAI traži od vašeg KMS-a da dešifrira eDEK, preuzima DEK i dešifrira 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 envelope šifriranju:
KEK i DEK ključevi kojima upravlja KMS:
Prednosti: Jednostavnija implementacija, nema potrebe za održavanjem infrastrukture za šifriranje.
Nedostaci: Svaki zahtjev za šifriranje/dešifriranje ide na KMS, što povećava kašnjenje i troškove te uvodi jedinstvenu tačku kvara.
KEK-ovi kojima upravlja KMS / DEK-ovi kojima upravlja OpenAI (naš pristup):
Prednosti: Znatno manje kašnjenje i troškovi, bolja skalabilnost i pouzdanost te nastavak rada tokom djelimičnih prekida KMS-a (do isteka TTL-a DEK keša).
Nedostaci: Nešto složenija implementacija na strani OpenAI-ja.
Ovaj dizajn omogućava OpenAI-ju da pruži snažne sigurnosne garancije uz minimiziranje operativnog rizika i troškova za korisnike.
Koliko često se rotiraju DEK-ovi?
Svaki DEK se rotira otprilike svakih 60 minuta. To pruža vremensku izolaciju — čak i ako bi DEK nekako bio kompromitovan, uticaj bi bio ograničen na podatke šifrirane unutar tog jednosatnog perioda.
Obim KMS zahtjeva i uočljivost
Vidimo daleko manje KMS zahtjeva nego korisničkih poruka. Trebaju li se ovi brojevi poklapati?
Ne, neće biti direktno povezani.
Budući da OpenAI kešira DEK-ove u memoriji radi performansi, KMS pozivi se izvršavaju samo kada DEK treba dešifrirati — ne pri svakoj operaciji šifriranja ili dešifriranja. Zbog toga možete očekivati:
Manje KMS zahtjeva nego korisničkih interakcija.
Povremene skokove kada keširani DEK-ovi isteknu (otprilike svakog sata) ili kada treba pristupiti starijim šifriranim podacima.
Dodatne pozive pri dohvaćanju historijskih podataka, na primjer kada korisnik nastavlja dugotrajni razgovor i moraju se učitati stariji DEK-ovi.
Tačan broj KMS zahtjeva zavisi od stanja keširanja, ponašanja korisnika, obrazaca pristupa podacima i dužine razgovora, pa se neće direktno povezivati s obimom poruka.