Concepte de criptare
Flux general
Tu controlezi o cheie principală în cloudul tău, pe care OpenAI nu o vede niciodată
Cheia ta principală este folosită pentru a cripta cheile de criptare a datelor (DEK) utilizate de OpenAI
OpenAI folosește DEK-urile pentru a cripta datele tale în repaus. Un DEK este criptat de cheia ta principală, generând un eDEK (DEK criptat), care este stocat împreună cu datele tale
Pentru a citi datele, OpenAI ia eDEK-ul, solicită KMS-ului tău să îl decripteze într-un DEK, apoi îți decriptează datele
Cum funcționează criptarea EKM?
Te rugăm să consulț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), care sunt generate de KMS-ul tău. Pentru a decripta datele, solicităm KMS-ului tău să decripteze eDEK-ul înapoi într-un DEK.
OpenAI păstrează în cache DEK-urile mele?
Da - doar în memorie. Acest lucru este pentru performanță, pentru a evita apelarea KMS-ului tău la fiecare cerere de criptare/decriptare a datelor. DEK-urile nu sunt niciodată scrise în stocare.
Permisiuni cloud
Ce permisiuni va avea OpenAI pe KMS-ul meu?
Doar permisiunile pe care ni le acorzi prin politica pe care o configurezi. Avem nevoie doar de operațiunile Encrypt/Decrypt cel puțin. Te rugăm, de asemenea, să creezi o cheie nouă în KMS-ul cloudului tău pentru OpenAI în loc să refolosești chei existente care au scopuri de 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: 1. ai recunoscut identitatea OpenAI (prin trust policy, workload identity etc., în funcție de furnizorul de cloud), 2. ai creat o politică pentru accesarea KMS-ului și 3. ai atribuit identității OpenAI permisiunea de a accesa politica. Dacă doar creezi KMS-ul fără să parcurgi toți acești pași, OpenAI nu are acces.
Trebuie să îmi stochez cheia principală în cloudul meu?
Nu - depinde de tine cum îți gestionezi cheia principală. Poți avea o soluție gestionată de cloud sau una externă, în care cheia ta este stocată separat. OpenAI trebuie doar să poată apela operațiunile de criptare/decriptare pe KMS-ul tău - 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 calea de criptare (solicitarea unei perechi de chei DEK/eDEK)
La fiecare 1 oră pentru calea 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 ta principală rămâne validă, orice eDEK-uri criptate cu cheia ta principală pot continua să fie decriptate într-un DEK, care este apoi folosit pentru a-ți decripta datele.
Rotația și revocarea cheii principale (controlate de tine)
Cât de des au loc rotația și revocarea cheii?
Acest lucru este stabilit de tine, deoarece OpenAI nu are vizibilitate asupra cheii tale principale.
Care este diferența dintre rotația cheii și revocarea cheii?
Revocarea cheii elimină accesul la datele criptate folosind 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 aflate în cache. În acel moment, OpenAI nu va mai putea 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ă.
Poate fi testată revocarea în siguranță?
Testarea revocării într-un spațiu de lucru de producție nu este recomandată, deoarece va face permanent inaccesibile datele existente. Totuși, clienții pot (și ar trebui să) testeze revocarea într-un mediu sandbox pentru a verifica funcționarea corectă și a-și valida presupunerile de încredere.
Dacă o cheie este revocată permanent, poate fi recuperat spațiul de lucru prin atașarea unei chei noi?
Nu. Odată ce cheia este pierdută, datele nu mai pot fi recuperate prin design. Singura remediere este să creezi un nou spațiu de lucru.
Ce ar trebui să facem dacă un spațiu de lucru devine inaccesibil din cauza modificărilor cheii?
Remedierea preconizată este crearea unui nou spațiu de lucru. 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. Odată 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ă creezi un nou spațiu de lucru — 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 cereri de criptare vor folosi noua cheie. Cu toate acestea, identificatorul KMS (ARN sau numele cheii) rămâne același iar datele vechi pot fi în continuare decriptate. Mulți furnizori de cloud oferă rotație automată a cheilor (AWS, GCP, Azure).
OpenAI recryptează datele mai vechi când îmi rotesc cheia principală?
Nu. Noul material criptografic va fi folosit doar pentru a cripta date 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 și revalidăm aceste intrări cu KMS-ul tău la fiecare oră.
Schimbarea identificatorului KMS
Schimbarea identificatorului KMS este o revocare de cheie sau o rotație de cheie?
Revocare de cheie. O cheie nu poate decripta date criptate de o altă cheie.
Poate OpenAI să mă ajute să schimb identificatorul KMS pentru un spațiu de lucru ChatGPT?
Dacă confirmi că intenția este de a-ți revoca cheia, te putem ajuta să faci acest lucru pentru un spațiu de lucru ChatGPT. Reține că atunci când ARN-ul KMS este actualizat, datele mai vechi vor rămâne inaccesibile, așa că vei ajunge să ai un amestec de date accesibile și inaccesibile după schimbare.
Poate OpenAI să mă ajute să schimb identificatorul KMS pentru un proiect API?
Dacă folosești API-ul, API-ul facilitează arhivarea și crearea de proiecte noi, așa că te rugăm în schimb să arhivezi proiectul ale cărui date nu mai sunt accesibile oricum, să înregistrezi o nouă configurație EKM la OpenAI și să creezi un nou proiect API cu noua cheie KMS.
Ce se întâmplă dacă vreau să îmi schimb regulat singur identificatorul KMS?
Acest lucru nu este recomandat, deoarece probabil nu vrei să îți revoci cheia în mod regulat. Totuși, poți face acest lucru dacă folosești un furnizor de cloud care acceptă un alias pentru cheia KMS (exemplu AWS). Poți înregistra acel alias al cheii KMS la OpenAI, iar apoi, la furnizorul tău de cloud, poți schimba oricând identificatorul KMS subiacent către care indică aliasul pentru a emite o revocare a cheii.
Comportament Beta vs. GA
Există riscuri cunoscute sau modificări la nivel de sistem atunci când se folosește versiunea beta a criptării în producție?
Mediul beta este echivalent funcțional cu GA și nu sunt așteptați pași de migrare. Riscul principal este că unele funcții de caz-limită pot să nu accepte încă conținut criptat din cauza unor căi de cod incomplete. Aceste cazuri sunt rare și sunt rezolvate 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 versiunea beta a criptării 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 pe cheia ta 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ă cheile de criptare a cheilor (KEK). OpenAI nu vede și nu stochează niciodată KEK-urile.
Infrastructura OpenAI: Generează și gestionează chei de criptare a datelor (DEK). Fiecare DEK este criptat (împachetat) cu KEK-ul tău înainte de stocare.
Fluxul de date:
Datele clientului sunt criptate cu un DEK.
Acel DEK este criptat cu KEK-ul tău, producând un eDEK.
eDEK-ul este stocat alături de datele criptate.
Pentru a decripta datele, OpenAI solicită KMS-ului tău să decripteze eDEK-ul, recuperează DEK-ul și decriptează conținutul.
De ce a ales OpenAI acest model în loc să lase KMS-ul să gestioneze atât KEK-urile, cât și DEK-urile?
Există două abordări comune pentru criptarea de tip envelope:
KEK-uri și DEK-uri gestionate de KMS:
Avantaje: Implementare mai simplă, fără nevoie de a întreține infrastructură de criptare.
Dezavantaje: Fiecare cerere de criptare/decriptare ajunge la KMS, crescând latența, costul și introducând un punct unic de eșec.
KEK-uri gestionate de KMS / DEK-uri gestionate de OpenAI (abordarea noastră):
Avantaje: Latență și cost semnificativ mai mici, scalabilitate și fiabilitate mai bune și operare continuă în timpul unor întreruperi parțiale ale KMS-ului (până la TTL-ul cache-ului DEK).
Dezavantaje: Implementare puțin mai complexă din partea OpenAI.
Acest design permite OpenAI să ofere garanții solide de securitate, minimizând în același timp riscul operațional și costul 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 acea fereastră de o oră.
Volum de cereri KMS și observabilitate
Vedem mult mai puține cereri KMS decât numărul de mesaje ale utilizatorilor. Ar trebui ca aceste numere să corespundă?
Nu, nu se vor corela direct.
Deoarece OpenAI păstrează DEK-urile în cache în memorie din motive de performanță, apelurile KMS sunt făcute doar atunci când un DEK trebuie decriptat — nu la fiecare operațiune de criptare sau decriptare. Prin urmare, ar trebui să te aștepți la:
Mai puține cereri 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, cum ar fi atunci când un utilizator continuă o conversație de durată și trebuie încărcate DEK-uri mai vechi.
Numărul exact de cereri KMS depinde de starea cache-ului, comportamentul utilizatorilor, modelele de acces la date și lungimea conversației și, prin urmare, nu se va corela direct cu volumul mesajelor.