Šifravimo sąvokos
Aukšto lygio eiga
Jūs valdote pagrindinį raktą savo debesijoje, kurio OpenAI niekada nemato
Jūsų pagrindinis raktas naudojamas šifruoti duomenų šifravimo raktams (DEK), kuriuos naudoja OpenAI
OpenAI naudoja DEK jūsų ramybės būsenos duomenims šifruoti. DEK užšifruojamas jūsų pagrindiniu raktu, sukuriant eDEK (užšifruotą DEK), kuris saugomas kartu su jūsų duomenimis
Norėdama perskaityti duomenis, OpenAI paima eDEK, paprašo jūsų KMS iššifruoti jį į DEK, o tada iššifruoja jūsų duomenis
Kaip veikia EKM šifravimas?
Išsamią informaciją rasite mūsų straipsnyje: OpenAI įmonių raktų valdymo (EKM) apžvalga
Ar OpenAI saugo mano DEK?
Ne – saugome užšifruotus DEK (eDEK), kuriuos sugeneruoja jūsų KMS. Norėdami iššifruoti duomenis, prašome jūsų KMS iššifruoti eDEK atgal į DEK.
Ar OpenAI talpina mano DEK talpykloje?
Taip – tik atmintyje. Tai daroma dėl našumo, kad jūsų KMS nebūtų pasiekiama per kiekvieną duomenų šifravimo / iššifravimo užklausą. DEK niekada neįrašomi į saugyklą.
Debesijos leidimai
Kokius leidimus OpenAI turės mano KMS?
Tik tuos leidimus, kuriuos mums suteiksite savo nustatyta politika. Mums reikia bent Encrypt / Decrypt operacijų. Taip pat sukurkite naują raktą savo debesijos KMS specialiai OpenAI, užuot pakartotinai naudoję esamus raktus, skirtus gamybiniams tikslams.
Kada OpenAI gauna leidimus pasiekti mano KMS?
Turi būti atlikti visi šie veiksmai:
Esate pripažinę OpenAI tapatybę (per pasitikėjimo politiką, darbo krūvio tapatybę ir pan., priklausomai nuo debesijos teikėjo).
Esate sukūrę prieigos prie KMS politiką.
Esate priskyrę OpenAI tapatybei leidimą pasiekti politiką.
Jei tik sukursite KMS neatlikę visų šių veiksmų, OpenAI prieigos neturės.
Ar turiu saugoti pagrindinį raktą savo debesijoje?
Ne – jūs sprendžiate, kaip valdyti savo pagrindinį raktą. Galite naudoti debesijos valdomą sprendimą arba išorinį sprendimą, kuriame jūsų raktas saugomas atskirai. OpenAI tereikia iškviesti šifravimo / iššifravimo operacijas jūsų KMS; tai, kaip pagrindinis raktas iš tikrųjų atlieka šifravimą / iššifravimą, yra įgyvendinimo detalė, kurios mes nematome.
Rakto gyvavimo ciklas
DEK / eDEK rotacija (valdoma OpenAI)
Kaip dažnai rotuojami DEK / eDEK?
Kas 24 valandas šifravimo kelyje (kai prašoma DEK / eDEK raktų poros)
Kas 1 valandą iššifravimo rakto kelyje (DEK -> eDEK)
Ar turiu ką nors daryti, kai DEK pasikeičia?
Ne – DEK / eDEK rotacija atliekama OpenAI viduje. Kol jūsų pagrindinis raktas galioja, bet kuriuos jūsų pagrindiniu raktu užšifruotus eDEK galima toliau iššifruoti į DEK, kuris tada naudojamas jūsų duomenims iššifruoti.
Pagrindinio rakto rotacija ir atšaukimas (valdoma jūsų)
Kaip dažnai vyksta rakto rotacija ir rakto atšaukimas?
Tai nustatote jūs, nes OpenAI neturi matomumo į jūsų pagrindinį raktą.
Kuo skiriasi rakto rotacija ir rakto atšaukimas?
Rakto atšaukimas panaikina prieigą prie duomenų, užšifruotų naudojant senesnius raktus. Rakto rotacija šifruoja duomenis naudojant naują raktą, bet išlaiko skaitymo prieigą prie senesnių duomenų.
Kas nutiks, jei atšauksiu savo pagrindinį raktą?
Jei raktas atšaukiamas arba leidimai pašalinami, darbo erdvė galiausiai nustos veikti, kai baigs galioti talpykloje laikomi raktai. Tuo metu OpenAI nebegalės iššifruoti saugomų duomenų ar šifruoti naujų duomenų. Iš esmės duomenys bus „susmulkinti“.
Kaip greitai įsigalioja atšaukimas?
OpenAI dėl našumo ir atsparumo laiko DEK atminties talpykloje. Atšaukimas paprastai įsigalioja per vieną valandą, kai baigia galioti talpykloje laikomi raktai ir pakartotinis patvirtinimas nepavyksta.
Ar galima saugiai išbandyti atšaukimą?
Atšaukimo testuoti gamybinėje darbo erdvėje nerekomenduojama, nes esami duomenys visam laikui taps nepasiekiami. Tačiau klientai gali (ir turėtų) išbandyti atšaukimą smėliadėžės aplinkoje, kad patikrintų tinkamą veikimą ir patvirtintų savo pasitikėjimo prielaidas.
Jei raktas atšaukiamas visam laikui, ar darbo erdvę galima atkurti prijungus naują raktą?
Ne. Praradus raktą, duomenys pagal sistemos projektą tampa neatkuriami. Vienintelis sprendimas – paleisti naują darbo erdvę.
Ką turėtume daryti, jei darbo erdvė tampa nepasiekiama dėl rakto pakeitimų?
Numatytas sprendimas – sukurti naują darbo erdvę. KMS atnaujinimas esamų duomenų neatkurs.
Koks yra grįžimo planas, jei nuspręsime nebenaudoti CMEK?
Šiuo metu grįžimo plano nėra. Sukūrus darbo erdvę su CMEK, visi susiję duomenys šifruojami naudojant klientų valdomus raktus ir be jų negali būti pasiekti. Vienintelis būdas nutraukti CMEK naudojimą – sukurti naują darbo erdvę; esami užšifruoti duomenys liks visam laikui nepasiekiami.
Kas nutinka, kai rotuoju savo pagrindinį raktą?
Šifravimui bus sugeneruota nauja kriptografinė medžiaga, todėl naujos šifravimo užklausos naudos naują raktą. Tačiau KMS identifikatorius (ARN arba rakto pavadinimas) lieka tas pats, o seni duomenys vis dar gali būti iššifruoti. Daugelis debesijos teikėjų siūlo automatinę raktų rotaciją (AWS, GCP, Azure).
Ar OpenAI iš naujo užšifruoja senesnius duomenis, kai rotuoju savo pagrindinį raktą?
Ne. Nauja kriptografinė medžiaga bus naudojama tik naujiems duomenims šifruoti.
Per kiek laiko įsigalioja rakto rotacija arba rakto atšaukimas?
Per 1 valandą. Taip yra todėl, kad DEK / eDEK laikomi atminties talpykloje, o šiuos įrašus kas valandą pakartotinai patvirtiname per jūsų KMS.
KMS identifikatoriaus keitimas
Ar KMS identifikatoriaus pakeitimas yra rakto atšaukimas, ar rakto rotacija?
Rakto atšaukimas. Vienas raktas negali iššifruoti duomenų, užšifruotų kitu raktu.
Ar OpenAI gali padėti pakeisti mano KMS identifikatorių ChatGPT darbo erdvei?
Jei patvirtinsite, kad ketinate atšaukti savo raktą, galime padėti tai padaryti ChatGPT darbo erdvėje. Atminkite, kad atnaujinus KMS ARN senesni duomenys liks nepasiekiami, todėl po pakeitimo turėsite ir nepasiekiamų, ir pasiekiamų duomenų.
Ar OpenAI gali padėti pakeisti mano KMS identifikatorių API projektui?
Jei naudojate API, API leidžia lengvai archyvuoti ir kurti naujus projektus, todėl vietoj to archyvuokite projektą, kurio duomenys vis tiek nepasiekiami, užregistruokite naują EKM konfigūraciją OpenAI ir sukurkite naują API projektą su nauju KMS raktu.
Ką daryti, jei noriu reguliariai pats keisti savo KMS identifikatorių?
Tai nerekomenduojama, nes greičiausiai nenorėsite reguliariai atšaukti savo rakto. Vis dėlto tai galite daryti, jei naudojate debesijos teikėją, palaikantį KMS rakto pseudonimą (AWS pavyzdys). Galite užregistruoti tą KMS rakto pseudonimą OpenAI, o tada savo debesijos teikėjo aplinkoje bet kada pakeisti bazinį KMS identifikatorių, į kurį nurodo pseudonimas, kad inicijuotumėte rakto atšaukimą.
Beta ir GA veikimo skirtumai
Ar naudojant šifravimo beta versiją gamybinėje aplinkoje yra žinomų rizikų ar sistemos lygmens pakeitimų?
Beta aplinka funkciniu požiūriu lygiavertė GA, ir migravimo veiksmų nenumatoma. Pagrindinė rizika – kai kurios kraštinių atvejų funkcijos dar gali nepalaikyti užšifruoto turinio dėl nebaigtų kodo kelių. Tokie atvejai reti ir aktyviai sprendžiami. Duomenys yra visiškai užšifruoti ir apsaugoti, nepaisant šių galimų problemų.
Ar pereinant iš beta į GA reikės kokių nors migravimo veiksmų?
Ne. Darbo erdvės, naudojančios šifravimo beta versiją, bus automatiškai palaikomos GA be jokių naudotojo veiksmų.
Papildoma techninė informacija
Vokinis šifravimas ir leidimai
Ar EKM reikmėms turime suteikti OpenAI GenerateDataKey leidimus?
Ne. OpenAI reikia tik Encrypt ir Decrypt leidimų jūsų KMS raktui. GenerateDataKey leidimas EKM integracijai nėra būtinas.
Ar OpenAI naudoja vokinį šifravimą klientų duomenims?
Taip. OpenAI naudoja vokinio šifravimo modelį:
Kliento KMS: valdo raktų šifravimo raktus (KEK). OpenAI niekada nemato ir nesaugo KEK.
OpenAI infrastruktūra: generuoja ir valdo duomenų šifravimo raktus (DEK). Prieš saugojimą kiekvienas DEK užšifruojamas (apgaubiamas) jūsų KEK.
Duomenų srautas:
Kliento duomenys užšifruojami DEK.
Tas DEK užšifruojamas jūsų KEK, sukuriant eDEK.
eDEK saugomas kartu su užšifruotais duomenimis.
Norėdama iššifruoti duomenis, OpenAI paprašo jūsų KMS iššifruoti eDEK, gauna DEK ir iššifruoja turinį.
Kodėl OpenAI pasirinko šį modelį, o ne leido KMS valdyti ir KEK, ir DEK?
Yra du įprasti vokinio šifravimo būdai:
KMS valdomi KEK ir DEK:
Privalumai: paprastesnis įgyvendinimas, nereikia prižiūrėti šifravimo infrastruktūros.
Trūkumai: kiekviena šifravimo / iššifravimo užklausa pasiekia KMS, todėl didėja delsa, kaina ir atsiranda vienas galimo gedimo taškas.
KMS valdomi KEK / OpenAI valdomi DEK (mūsų metodas):
Privalumai: gerokai mažesnė delsa ir kaina, geresnis mastelio keitimas ir patikimumas, taip pat tęstinis veikimas dalinių KMS sutrikimų metu (iki DEK talpyklos TTL pabaigos).
Trūkumai: šiek tiek sudėtingesnis įgyvendinimas OpenAI pusėje.
Ši architektūra leidžia OpenAI užtikrinti tvirtas saugumo garantijas ir kartu sumažinti klientų operacinę riziką bei kaštus.
Kaip dažnai rotuojami DEK?
Kiekvienas DEK rotuojamas maždaug kas 60 minučių. Tai suteikia laikinę izoliaciją: net jei DEK kaip nors būtų pažeistas, poveikis apsiribotų duomenimis, užšifruotais per tą vienos valandos laikotarpį.
KMS užklausų apimtis ir stebimumas
Matome gerokai mažiau KMS užklausų nei naudotojų pranešimų. Ar šie skaičiai turėtų sutapti?
Ne, jie tiesiogiai nekoreliuos.
Kadangi OpenAI dėl našumo laiko DEK atminties talpykloje, KMS iškvietimai atliekami tik tada, kai DEK reikia iššifruoti, o ne per kiekvieną šifravimo ar iššifravimo operaciją. Todėl turėtumėte tikėtis:
Mažiau KMS užklausų nei naudotojų sąveikų.
Retkarčiais pasitaikančių šuolių, kai baigia galioti talpykloje laikomi DEK (maždaug kas valandą) arba kai reikia pasiekti senesnius užšifruotus duomenis.
Papildomų iškvietimų gaunant istorinius duomenis, pavyzdžiui, kai naudotojas tęsia ilgai vykstantį pokalbį ir reikia įkelti senesnius DEK.
Tikslus KMS užklausų skaičius priklauso nuo talpyklos būsenos, naudotojų elgsenos, duomenų prieigos modelių ir pokalbio ilgio, todėl jis tiesiogiai nekoreliuos su pranešimų apimtimi.