Šifrēšanas jēdzieni
Augsta līmeņa plūsma
Jūs kontrolējat galveno atslēgu savā mākonī, ko OpenAI nekad neredz
Jūsu galvenā atslēga tiek izmantota, lai šifrētu datu šifrēšanas atslēgas (DEK), ko izmanto OpenAI
OpenAI izmanto DEK, lai šifrētu jūsu datus miera stāvoklī. DEK tiek šifrēta ar jūsu galveno atslēgu, izveidojot eDEK (šifrētu DEK), kas tiek glabāta kopā ar jūsu datiem
Lai nolasītu datus, OpenAI paņem eDEK, pieprasa jūsu KMS to atšifrēt par DEK un pēc tam atšifrē jūsu datus
Kā darbojas EKM šifrēšana?
Detalizētu informāciju skatiet mūsu rakstā: OpenAI uzņēmumu atslēgu pārvaldības (EKM) pārskats
Vai OpenAI glabā manus DEK?
Nē — mēs glabājam šifrētās DEK (eDEK), ko ģenerē jūsu KMS. Lai atšifrētu datus, mēs lūdzam jūsu KMS atšifrēt eDEK atpakaļ par DEK.
Vai OpenAI kešo manus DEK?
Jā — tikai atmiņā. Tas tiek darīts veiktspējas nolūkos, lai nevērstos pie jūsu KMS katrā datu šifrēšanas/atšifrēšanas pieprasījumā. DEK nekad netiek ierakstītas glabātuvē.
Mākoņa atļaujas
Kādas atļaujas OpenAI būs manā KMS?
Tikai tās atļaujas, kuras mums piešķirat ar iestatīto politiku. Mums ir vajadzīgas vismaz Encrypt/Decrypt darbības. Lūdzu, savā mākoņa KMS izveidojiet OpenAI vajadzībām jaunu atslēgu, nevis atkārtoti izmantojiet esošas atslēgas, kas paredzētas produkcijas mērķiem.
Kad OpenAI saņem atļaujas piekļūt manam KMS?
Jābūt izpildītām visām šīm darbībām:
Jūs esat atpazinis OpenAI identitāti (izmantojot uzticēšanās politiku, darba slodzes identitāti utt. atkarībā no mākoņpakalpojumu sniedzēja).
Jūs esat izveidojis politiku piekļuvei KMS.
Jūs esat piešķīris OpenAI identitātei atļauju piekļūt šai politikai.
Ja tikai izveidojat KMS, neveicot visas šīs darbības, OpenAI piekļuves nebūs.
Vai man galvenā atslēga ir jāglabā savā mākonī?
Nē — jūs pats izlemjat, kā pārvaldīt savu galveno atslēgu. Varat izmantot mākoņa pārvaldītu risinājumu vai ārēju risinājumu, kur jūsu atslēga tiek glabāta atsevišķi. OpenAI ir tikai jāvar izsaukt šifrēšanas/atšifrēšanas darbības jūsu KMS; tas, kā galvenā atslēga faktiski veic šifrēšanu/atšifrēšanu, ir ieviešanas detaļa, kas mums nav redzama.
Atslēgas dzīves cikls
DEK/eDEK rotācija (kontrolē OpenAI)
Cik bieži tiek rotēti DEK/eDEK?
Ik pēc 24 stundām šifrēšanas ceļā (pieprasot DEK/eDEK atslēgu pāri)
Ik pēc 1 stundas atšifrēšanas atslēgas ceļā (DEK -> eDEK)
Vai man kaut kas jādara, kad DEK mainās?
Nē — DEK/eDEK rotācija tiek veikta OpenAI ietvaros. Kamēr jūsu galvenā atslēga ir derīga, jebkuras eDEK, kas šifrētas ar jūsu galveno atslēgu, joprojām var atšifrēt par DEK, kas pēc tam tiek izmantota jūsu datu atšifrēšanai.
Galvenās atslēgas rotācija un atsaukšana (kontrolējat jūs)
Cik bieži notiek atslēgu rotācija un atslēgu atsaukšana?
To nosakāt jūs, jo OpenAI nav redzamības jūsu galvenajā atslēgā.
Kāda ir atšķirība starp atslēgas rotāciju un atslēgas atsaukšanu?
Atslēgas atsaukšana noņem piekļuvi datiem, kas šifrēti, izmantojot vecākas atslēgas. Atslēgas rotācija šifrē datus, izmantojot jaunu atslēgu, bet saglabā lasīšanas piekļuvi vecākiem datiem.
Kas notiek, ja atsaucu savu galveno atslēgu?
Ja atslēga tiek atsaukta vai atļaujas tiek noņemtas, darbvieta galu galā pārstās darboties, tiklīdz beigsies kešoto atslēgu derīgums. Tajā brīdī OpenAI vairs nevarēs atšifrēt glabātos datus vai šifrēt jaunus datus. Faktiski dati tiek “sasmalcināti”.
Cik ātri atsaukšana stājas spēkā?
OpenAI veiktspējas un noturības nolūkos kešo DEK atmiņā. Atsaukšana parasti stājas spēkā stundas laikā, kad beidzas kešoto atslēgu derīgums un atkārtota validācija neizdodas.
Vai atsaukšanu var droši testēt?
Atsaukšanas testēšana produkcijas darbvietā nav ieteicama, jo tā neatgriezeniski padarīs esošos datus nepieejamus. Tomēr klienti var (un viņiem vajadzētu) testēt atsaukšanu smilškastes vidē, lai pārbaudītu pareizu darbību un validētu savus uzticēšanās pieņēmumus.
Ja atslēga tiek neatgriezeniski atsaukta, vai darbvietu var atjaunot, pievienojot jaunu atslēgu?
Nē. Kad atslēga ir zaudēta, dati pēc sistēmas uzbūves nav atgūstami. Vienīgais risinājums ir izveidot jaunu darbvietu.
Kas jādara, ja darbvieta kļūst nepieejama atslēgu izmaiņu dēļ?
Paredzētais risinājums ir izveidot jaunu darbvietu. KMS atjaunināšana neatjaunos esošos datus.
Kāds ir atkāpšanās plāns, ja nolemjam pārtraukt izmantot CMEK?
Pašlaik atkāpšanās plāna nav. Kad darbvieta ir izveidota ar CMEK, visi saistītie dati tiek šifrēti, izmantojot klienta pārvaldītas atslēgas, un bez tām tiem nevar piekļūt. Vienīgais veids, kā pārtraukt CMEK izmantošanu, ir izveidot jaunu darbvietu — esošie šifrētie dati paliks neatgriezeniski nepieejami.
Kas notiek, kad rotēju savu galveno atslēgu?
Šifrēšanai tiks ģenerēts jauns kriptogrāfiskais materiāls, tāpēc jaunie šifrēšanas pieprasījumi izmantos jauno atslēgu. Tomēr KMS identifikators (ARN vai atslēgas nosaukums) paliek nemainīgs, un vecos datus joprojām var atšifrēt. Daudzi mākoņpakalpojumu sniedzēji piedāvā automātisku atslēgu rotāciju (AWS, GCP, Azure).
Vai OpenAI atkārtoti šifrē vecākus datus, kad rotēju savu galveno atslēgu?
Nē. Jaunais kriptogrāfiskais materiāls tiks izmantots tikai jaunu datu šifrēšanai.
Cik ilgā laikā stājas spēkā atslēgas rotācija vai atsaukšana?
1 stunda. Tas ir tāpēc, ka DEK/eDEK tiek kešotas atmiņā un mēs šos ierakstus atkārtoti validējam jūsu KMS reizi stundā.
KMS identifikatora maiņa
Vai KMS identifikatora maiņa ir atslēgas atsaukšana vai atslēgas rotācija?
Atslēgas atsaukšana. Viena atslēga nevar atšifrēt datus, kas šifrēti ar citu atslēgu.
Vai OpenAI var palīdzēt nomainīt mana ChatGPT darbvietas KMS identifikatoru?
Ja apstiprināsiet, ka nolūks ir atsaukt jūsu atslēgu, mēs varam palīdzēt to izdarīt ChatGPT darbvietai. Ņemiet vērā: kad KMS ARN tiks atjaunināts, vecākie dati joprojām nebūs pieejami, tāpēc pēc izmaiņām jums būs gan nepieejami, gan pieejami dati.
Vai OpenAI var palīdzēt nomainīt mana API projekta KMS identifikatoru?
Ja izmantojat API, API ļauj viegli arhivēt un izveidot jaunus projektus, tāpēc tā vietā arhivējiet projektu, kura dati tik un tā nav pieejami, reģistrējiet jaunu EKM konfigurāciju pie OpenAI un izveidojiet jaunu API projektu ar jauno KMS atslēgu.
Ko darīt, ja vēlos regulāri pats mainīt savu KMS identifikatoru?
Tas nav ieteicams, jo jūs, visticamāk, nevēlaties regulāri atsaukt savu atslēgu. Tomēr jūs to joprojām varat darīt, ja izmantojat mākoņpakalpojumu sniedzēju, kas atbalsta KMS atslēgas aizstājvārdu (AWS piemērs). Varat reģistrēt šo KMS atslēgas aizstājvārdu pie OpenAI un pēc tam savā mākoņpakalpojumu sniedzējā jebkurā laikā nomainīt pamatā esošo KMS identifikatoru, uz kuru norāda aizstājvārds, lai veiktu atslēgas atsaukšanu.
Beta un GA darbība
Vai pastāv zināmi riski vai sistēmas līmeņa izmaiņas, izmantojot šifrēšanas beta versiju produkcijā?
Beta vide funkcionāli ir līdzvērtīga GA, un migrācijas darbības nav paredzētas. Galvenais risks ir tas, ka dažas robežgadījumu funkcijas nepilnīgu koda ceļu dēļ, iespējams, vēl neatbalsta šifrētu saturu. Šādi gadījumi ir reti, un tie tiek aktīvi novērsti. Dati ir pilnībā šifrēti un aizsargāti neatkarīgi no šīm iespējamajām problēmām.
Vai būs jāveic migrācijas darbības no beta uz GA?
Nē. Darbvietas, kas izmanto šifrēšanas beta versiju, GA tiks automātiski atbalstītas bez lietotāja darbībām.
Papildu tehniskā informācija
Aploksnes šifrēšana un atļaujas
Vai EKM vajadzībām OpenAI jāpiešķir GenerateDataKey atļaujas?
Nē. OpenAI jūsu KMS atslēgai nepieciešamas tikai Encrypt un Decrypt atļaujas. GenerateDataKey atļauja EKM integrācijai nav nepieciešama.
Vai OpenAI klientu datiem izmanto aploksnes šifrēšanu?
Jā. OpenAI izmanto aploksnes šifrēšanas modeli:
Klienta KMS: pārvalda atslēgu šifrēšanas atslēgas (KEK). OpenAI nekad neredz un neglabā KEK.
OpenAI infrastruktūra: ģenerē un pārvalda datu šifrēšanas atslēgas (DEK). Katra DEK pirms glabāšanas tiek šifrēta (ietīta) ar jūsu KEK.
Datu plūsma:
Klienta dati tiek šifrēti ar DEK.
Šī DEK tiek šifrēta ar jūsu KEK, izveidojot eDEK.
eDEK tiek glabāta kopā ar šifrētajiem datiem.
Lai atšifrētu datus, OpenAI pieprasa jūsu KMS atšifrēt eDEK, iegūst DEK un atšifrē saturu.
Kāpēc OpenAI izvēlējās šo modeli, nevis ļāva KMS pārvaldīt gan KEK, gan DEK?
Pastāv divas izplatītas aploksnes šifrēšanas pieejas:
KMS pārvaldītas KEK un DEK:
Plusi: vienkāršāka ieviešana, nav jāuztur šifrēšanas infrastruktūra.
Mīnusi: katrs šifrēšanas/atšifrēšanas pieprasījums nonāk KMS, palielinot aizkavi un izmaksas un radot vienu atteices punktu.
KMS pārvaldītas KEK / OpenAI pārvaldītas DEK (mūsu pieeja):
Plusi: ievērojami mazāka aizkave un izmaksas, labāka mērogojamība un uzticamība, kā arī nepārtraukta darbība daļēju KMS pārtraukumu laikā (līdz DEK kešatmiņas TTL beigām).
Mīnusi: nedaudz sarežģītāka ieviešana OpenAI pusē.
Šis dizains ļauj OpenAI nodrošināt spēcīgas drošības garantijas, vienlaikus samazinot klientu operacionālo risku un izmaksas.
Cik bieži tiek rotēti DEK?
Katra DEK tiek rotēta aptuveni ik pēc 60 minūtēm. Tas nodrošina laika izolāciju — pat ja DEK kaut kādā veidā tiktu kompromitēta, ietekme būtu ierobežota līdz datiem, kas šifrēti šajā vienas stundas periodā.
KMS pieprasījumu apjoms un novērojamība
Mēs redzam daudz mazāk KMS pieprasījumu nekā lietotāju ziņojumu. Vai šiem skaitļiem būtu jāsakrīt?
Nē, tie tieši nekorelēs.
Tā kā OpenAI veiktspējas nolūkos kešo DEK atmiņā, KMS izsaukumi tiek veikti tikai tad, kad DEK ir jāatšifrē, nevis katrā šifrēšanas vai atšifrēšanas darbībā. Tāpēc varat sagaidīt:
Mazāk KMS pieprasījumu nekā lietotāju mijiedarbību.
Neregulārus kāpumus, kad beidzas kešoto DEK derīgums (aptuveni reizi stundā) vai kad jāpiekļūst vecākiem šifrētiem datiem.
Papildu izsaukumus, izgūstot vēsturiskos datus, piemēram, kad lietotājs turpina ilgstošu sarunu un jāielādē vecāki DEK.
Precīzs KMS pieprasījumu skaits ir atkarīgs no kešatmiņas stāvokļa, lietotāju rīcības, datu piekļuves modeļiem un sarunas garuma, tāpēc tas tieši nekorelēs ar ziņojumu apjomu.