Concepte de criptare
Flux la nivel înalt
Controlați o cheie principală în cloudul dvs., pe care OpenAI nu o vede niciodată
Cheia dvs. principală este folosită pentru a cripta cheile de criptare a datelor (DEK-uri) utilizate de OpenAI
OpenAI folosește DEK-urile pentru a cripta datele dvs. în repaus. Un DEK este criptat cu cheia dvs. principală, generând un eDEK (DEK criptat), care este stocat împreună cu datele dvs.
Pentru a citi datele, OpenAI preia eDEK-ul, solicită KMS-ului dvs. să îl decripteze într-un DEK, apoi decriptează datele dvs.
Cum funcționează criptarea EKM?
Consultați articolul nostru pentru informații detaliate: Prezentare generală OpenAI Enterprise Key Management (EKM)
Stochează OpenAI DEK-urile mele?
Nu — stocăm DEK-urile criptate (eDEK-uri), generate de KMS-ul dvs. Pentru a decripta datele, solicităm KMS-ului dvs. să decripteze eDEK-ul înapoi în DEK.
OpenAI păstrează DEK-urile mele în cache?
Da — doar în memorie. Acest lucru este făcut pentru performanță, pentru a evita accesarea KMS-ului dvs. la fiecare solicitare de criptare/decriptare a datelor. DEK-urile nu sunt scrise niciodată în stocare.
Permisiuni cloud
Ce permisiuni va avea OpenAI asupra KMS-ului meu?
Doar permisiunile pe care ni le acordați prin politica pe care o configurați. Avem nevoie cel puțin de operațiunile Encrypt/Decrypt. De asemenea, creați o cheie nouă în KMS-ul dvs. cloud pentru OpenAI, în loc să reutilizați chei existente folosite în producție.
Când primește OpenAI permisiuni de acces la KMS-ul meu?
Toți acești pași trebuie să fi fost parcurși:
Ați recunoscut identitatea OpenAI (prin politica de încredere, identitatea de workload etc., în funcție de furnizorul cloud).
Ați creat o politică pentru accesarea KMS-ului.
Ați atribuit identității OpenAI permisiunea de a accesa politica.
Dacă doar creați KMS-ul fără a parcurge toți acești pași, OpenAI nu are acces.
Trebuie să îmi stochez cheia principală în cloudul meu?
Nu — depinde de dvs. cum vă gestionați cheia principală. Puteți folosi o soluție gestionată în cloud sau una externă, în care cheia este stocată separat. OpenAI trebuie doar să poată apela operațiunile de criptare/decriptare pe KMS-ul dvs.; modul în care cheia principală efectuează efectiv criptarea/decriptarea este un detaliu de implementare opac pentru noi.
Ciclul de viață al cheilor
Rotația DEK/eDEK (controlată de OpenAI)
Cât de des sunt rotite DEK-urile/eDEK-urile?
La fiecare 24 de ore pe fluxul de criptare (solicitarea unei perechi de chei DEK/eDEK)
La fiecare 1 oră pentru fluxul cheii de decriptare (DEK -> eDEK)
Trebuie să fac ceva când se schimbă DEK-ul?
Nu — rotația DEK/eDEK se face în cadrul OpenAI. Atât timp cât cheia dvs. principală rămâne validă, orice eDEK criptat cu cheia principală poate continua să fie decriptat într-un DEK, care este apoi folosit pentru a vă decripta datele.
Rotația și revocarea cheii principale (controlate de dvs.)
Cât de des au loc rotația și revocarea cheilor?
Acest lucru este stabilit de dvs., deoarece OpenAI nu are vizibilitate asupra cheii dvs. principale.
Care este diferența dintre rotația cheii și revocarea cheii?
Revocarea cheii elimină accesul la datele criptate cu chei mai vechi. Rotația cheii criptează datele folosind o cheie nouă, dar menține accesul de citire la datele mai vechi.
Ce se întâmplă dacă îmi revoc cheia principală?
Dacă o cheie este revocată sau permisiunile sunt eliminate, spațiul de lucru va deveni în cele din urmă nefuncțional după expirarea cheilor din cache. În acel moment, OpenAI nu mai poate decripta datele stocate sau cripta date noi. Practic, datele sunt „distruse”.
Cât de repede intră în vigoare revocarea?
OpenAI păstrează DEK-urile în cache, în memorie, pentru performanță și reziliență. Revocarea intră de obicei în vigoare în decurs de o oră, după ce cheile din cache expiră și revalidarea eșuează.
Revocarea poate fi testată în siguranță?
Testarea revocării într-un spațiu de lucru de producție nu este recomandată, deoarece va face datele existente permanent inaccesibile. Totuși, clienții pot (și ar trebui să) testeze revocarea într-un mediu sandbox pentru a verifica comportamentul corect și a-și valida ipotezele de încredere.
Dacă o cheie este revocată permanent, spațiul de lucru poate fi recuperat prin atașarea unei chei noi?
Nu. După pierderea cheii, datele sunt irecuperabile prin proiectare. Singura soluție este să creați un spațiu de lucru nou.
Ce ar trebui să facem dacă un spațiu de lucru devine inaccesibil din cauza modificărilor de cheie?
Soluția așteptată este să creați un spațiu de lucru nou. Actualizarea KMS-ului nu va recupera datele existente.
Care este planul de revenire dacă decidem să nu mai folosim CMEK?
În prezent, nu există un plan de revenire. După ce un spațiu de lucru este creat cu CMEK, toate datele asociate sunt criptate folosind chei gestionate de client și nu pot fi accesate fără acestea. Singura modalitate de a întrerupe utilizarea CMEK este să creați un spațiu de lucru nou — datele criptate existente vor rămâne permanent inaccesibile.
Ce se întâmplă când îmi rotesc cheia principală?
Va fi generat material criptografic nou pentru criptare, astfel încât noile solicitări de criptare vor folosi noua cheie. Totuși, identificatorul KMS (ARN sau numele cheii) rămâne același, iar datele vechi pot fi în continuare decriptate. Mulți furnizori cloud oferă rotație automată a cheilor (AWS, GCP, Azure).
Recriptează OpenAI datele mai vechi când îmi rotesc cheia principală?
Nu. Noul material criptografic va fi folosit doar pentru criptarea datelor noi.
Cât durează până când rotația sau revocarea unei chei intră în vigoare?
1 oră. Acest lucru se datorează faptului că DEK/eDEK-urile sunt păstrate în cache în memorie, iar noi revalidăm aceste intrări cu KMS-ul dvs. o dată pe oră.
Schimbarea identificatorului KMS
Schimbarea identificatorului KMS reprezintă o revocare a cheii sau o rotație a cheii?
Revocare a cheii. O cheie nu poate decripta date criptate cu altă cheie.
Mă poate ajuta OpenAI să schimb identificatorul KMS pentru un spațiu de lucru ChatGPT?
Dacă confirmați că intenția este să vă revocați cheia, vă putem ajuta să faceți acest lucru pentru un spațiu de lucru ChatGPT. Rețineți că, atunci când ARN-ul KMS este actualizat, datele mai vechi vor rămâne inaccesibile, astfel că după schimbare veți avea un amestec de date inaccesibile și accesibile.
Mă poate ajuta OpenAI să schimb identificatorul KMS pentru un proiect API?
Dacă folosiți API-ul, acesta facilitează arhivarea și crearea de proiecte noi; prin urmare, arhivați proiectul ale cărui date oricum nu sunt accesibile, înregistrați o nouă configurație EKM la OpenAI și creați un nou proiect API cu noua cheie KMS.
Ce se întâmplă dacă vreau să schimb periodic identificatorul KMS pe cont propriu?
Acest lucru nu este recomandat, deoarece probabil nu doriți să vă revocați cheia în mod regulat. Totuși, puteți face acest lucru dacă folosiți un furnizor cloud care acceptă un alias de cheie KMS (exemplu AWS). Puteți înregistra acel alias de cheie KMS la OpenAI, iar apoi, la furnizorul dvs. cloud, puteți înlocui oricând identificatorul KMS de bază către care indică aliasul pentru a declanșa o revocare a cheii.
Comportamentul în beta față de GA
Există riscuri cunoscute sau modificări la nivel de sistem atunci când se folosește beta de criptare în producție?
Mediul beta este echivalent funcțional cu GA și nu sunt așteptați pași de migrare. Riscul principal este ca unele funcționalități de cazuri-limită să nu accepte încă conținut criptat din cauza unor fluxuri de cod incomplete. Aceste cazuri sunt rare și sunt remediate activ. Datele sunt complet criptate și protejate, indiferent de aceste posibile probleme.
Vor exista pași de migrare de la beta la GA?
Nu. Spațiile de lucru care folosesc beta de criptare vor fi acceptate automat în GA, fără nicio acțiune din partea utilizatorului.
Detalii tehnice suplimentare
Criptare de tip envelope și permisiuni
Trebuie să acordăm OpenAI permisiuni GenerateDataKey pentru EKM?
Nu. OpenAI are nevoie doar de permisiunile Encrypt și Decrypt asupra cheii dvs. KMS. Permisiunea GenerateDataKey nu este necesară pentru integrarea EKM.
Folosește OpenAI criptare de tip envelope pentru datele clienților?
Da. OpenAI folosește un model de criptare de tip envelope:
KMS-ul clientului: gestionează Key Encryption Keys (KEK-uri). OpenAI nu vede și nu stochează niciodată KEK-urile.
Infrastructura OpenAI: generează și gestionează Data Encryption Keys (DEK-uri). Fiecare DEK este criptat (împachetat) cu KEK-ul dvs. înainte de stocare.
Fluxul datelor:
Datele clientului sunt criptate cu un DEK.
Acel DEK este criptat cu KEK-ul dvs., producând un eDEK.
eDEK-ul este stocat împreună cu datele criptate.
Pentru a decripta datele, OpenAI solicită KMS-ului dvs. să decripteze eDEK-ul, recuperează DEK-ul și decriptează conținutul.
De ce a ales OpenAI acest model în loc să lase KMS să gestioneze atât KEK-urile, cât și DEK-urile?
Există două abordări obișnuite pentru criptarea de tip envelope:
KEK-uri și DEK-uri gestionate de KMS:
Avantaje: implementare mai simplă, fără necesitatea de a întreține infrastructură de criptare.
Dezavantaje: fiecare solicitare de criptare/decriptare ajunge la KMS, crescând latența și costurile și introducând un punct unic de defectare.
KEK-uri gestionate de KMS / DEK-uri gestionate de OpenAI (abordarea noastră):
Avantaje: latență și costuri semnificativ mai mici, scalabilitate și fiabilitate mai bune și funcționare continuă în timpul întreruperilor parțiale ale KMS-ului (până la TTL-ul cache-ului DEK).
Dezavantaje: implementare puțin mai complexă pe partea OpenAI.
Acest design permite OpenAI să ofere garanții solide de securitate, minimizând în același timp riscul operațional și costurile pentru clienți.
Cât de des sunt rotite DEK-urile?
Fiecare DEK este rotit aproximativ la fiecare 60 de minute. Acest lucru oferă izolare temporală — chiar dacă un DEK ar fi compromis cumva, impactul ar fi limitat la datele criptate în acel interval de o oră.
Volumul solicitărilor KMS și observabilitate
Vedem mult mai puține solicitări KMS decât numărul de mesaje ale utilizatorilor. Ar trebui ca aceste numere să coincidă?
Nu, nu vor fi corelate direct.
Deoarece OpenAI păstrează DEK-urile în cache, în memorie, din motive de performanță, apelurile KMS se fac doar când un DEK trebuie decriptat — nu la fiecare operațiune de criptare sau decriptare. Prin urmare, ar trebui să vă așteptați la:
Mai puține solicitări KMS decât interacțiuni ale utilizatorilor.
Vârfuri ocazionale atunci când DEK-urile din cache expiră (aproximativ la fiecare oră) sau când trebuie accesate date criptate mai vechi.
Apeluri suplimentare la recuperarea datelor istorice, de exemplu când un utilizator continuă o conversație de lungă durată și trebuie încărcate DEK-uri mai vechi.
Numărul exact de solicitări KMS depinde de starea cache-ului, comportamentul utilizatorilor, tiparele de acces la date și lungimea conversațiilor; prin urmare, nu va fi corelat direct cu volumul mesajelor.