Konceptet e enkriptimit
Rrjedha e përgjithshme
Ju kontrolloni një çelës kryesor në cloud-in tuaj, të cilin OpenAI nuk e sheh kurrë
Çelësi juaj kryesor përdoret për të enkriptuar çelësat e enkriptimit të të dhënave (DEK) që përdoren nga OpenAI
OpenAI përdor DEK-të për të enkriptuar të dhënat tuaja në gjendje të ruajtur. Një DEK enkriptohet nga çelësi juaj kryesor, duke gjeneruar një eDEK (DEK të enkriptuar), i cili ruhet bashkë me të dhënat tuaja
Për të lexuar të dhënat, OpenAI merr eDEK-un, i kërkon KMS-së tuaj ta dekriptojë në DEK dhe më pas dekripton të dhënat tuaja
Si funksionon enkriptimi EKM?
Ju lutemi referojuni artikullit tonë për informacion të detajuar: Përmbledhje e OpenAI Enterprise Key Management (EKM)
A i ruan OpenAI DEK-të e mia?
Jo — ne ruajmë DEK-të e enkriptuar (eDEK), të cilët gjenerohen nga KMS-ja juaj. Për të dekriptuar të dhënat, i kërkojmë KMS-së tuaj ta dekriptojë eDEK-un përsëri në DEK.
A i ruan OpenAI DEK-të e mia në cache?
Po — vetëm në memorie. Kjo bëhet për performancë, për të shmangur prekjen e KMS-së tuaj në çdo kërkesë enkriptimi/dekriptimi të të dhënave. DEK-të nuk shkruhen kurrë në ruajtje.
Lejet në cloud
Çfarë lejesh do të ketë OpenAI në KMS-në time?
Vetëm lejet që na jepni përmes politikës që vendosni. Na duhen vetëm të paktën operacionet Encrypt/Decrypt. Ju lutemi krijoni gjithashtu një çelës të ri në KMS-në tuaj cloud për OpenAI, në vend që të ripërdorni çelësa ekzistues që shërbejnë për qëllime prodhimi.
Kur merr OpenAI leje për të aksesuar KMS-në time?
Duhet të jenë kryer të gjitha këto hapa:
Keni njohur identitetin e OpenAI (përmes politikës së besimit, identitetit të ngarkesës së punës etj., në varësi të ofruesit cloud).
Keni krijuar një politikë për aksesimin e KMS-së.
I keni caktuar identitetit të OpenAI lejen për të aksesuar politikën.
Nëse thjesht krijoni KMS-në pa kryer të gjithë këta hapa, OpenAI nuk ka akses.
A duhet ta ruaj çelësin tim kryesor në cloud-in tim?
Jo — ju vendosni si ta menaxhoni çelësin tuaj kryesor. Mund të keni një zgjidhje të menaxhuar në cloud ose një zgjidhje të jashtme ku çelësi juaj ruhet veçmas. OpenAI duhet vetëm të thërrasë operacionet encrypt/decrypt në KMS-në tuaj — mënyra se si çelësi kryesor i kryen realisht encrypt/decrypt është një detaj zbatimi i padukshëm për ne.
Cikli i jetës së çelësave
Rotacioni DEK/eDEK (i kontrolluar nga OpenAI)
Sa shpesh bëhet rotacioni i DEK-ve/eDEK-ve?
Çdo 24 orë në rrugën e enkriptimit (kur kërkohet një çift çelësash DEK/eDEK)
Çdo 1 orë për rrugën e çelësit të dekriptimit (DEK -> eDEK)
A duhet të bëj ndonjë gjë kur ndryshon DEK-u?
Jo — rotacioni DEK/eDEK bëhet brenda OpenAI. Për sa kohë që çelësi juaj kryesor mbetet i vlefshëm, çdo eDEK i enkriptuar nga çelësi juaj kryesor mund të vazhdojë të dekriptohet në DEK, i cili më pas përdoret për të dekriptuar të dhënat tuaja.
Rotacioni dhe revokimi i çelësit kryesor (të kontrolluara nga ju)
Sa shpesh ndodh rotacioni i çelësit dhe revokimi i çelësit?
Kjo përcaktohet nga ju, pasi OpenAI nuk ka dukshmëri mbi çelësin tuaj kryesor.
Cili është ndryshimi midis rotacionit të çelësit dhe revokimit të çelësit?
Revokimi i çelësit heq aksesin te të dhënat e enkriptuara me çelësa më të vjetër. Rotacioni i çelësit enkripton të dhënat me një çelës të ri, por ruan aksesin për lexim te të dhënat më të vjetra.
Çfarë ndodh nëse revokoj çelësin tim kryesor?
Nëse një çelës revokohet ose hiqen lejet, hapësira e punës përfundimisht do të bëhet jofunksionale pasi të skadojnë çelësat në cache. Në atë pikë, OpenAI nuk mund të dekriptojë më të dhënat e ruajtura ose të enkriptojë të dhëna të reja. Në praktikë, të dhënat janë “copëtuar”.
Sa shpejt hyn në fuqi revokimi?
OpenAI i ruan DEK-të në cache në memorie për performancë dhe qëndrueshmëri. Revokimi zakonisht hyn në fuqi brenda një ore, pasi çelësat në cache skadojnë dhe rivalidimi dështon.
A mund të testohet revokimi në mënyrë të sigurt?
Testimi i revokimit në një hapësirë pune prodhimi nuk rekomandohet, sepse do t’i bëjë përgjithmonë të paaksesueshme të dhënat ekzistuese. Megjithatë, klientët mund (dhe duhet) ta testojnë revokimin në një mjedis sandbox për të verifikuar sjelljen e saktë dhe për të validuar supozimet e tyre të besimit.
Nëse një çelës revokohet përgjithmonë, a mund të rikuperohet hapësira e punës duke bashkëngjitur një çelës të ri?
Jo. Pasi çelësi humbet, të dhënat janë të parikuperueshme sipas projektimit. Zgjidhja e vetme është të krijoni një hapësirë pune të re.
Çfarë duhet të bëjmë nëse një hapësirë pune bëhet e paaksesueshme për shkak të ndryshimeve të çelësave?
Zgjidhja e pritshme është të krijoni një hapësirë pune të re. Përditësimi i KMS-së nuk do të rikuperojë të dhënat ekzistuese.
Cili është plani i kthimit pas nëse vendosim të ndalojmë përdorimin e CMEK?
Aktualisht, nuk ka plan kthimi pas. Pasi një hapësirë pune krijohet me CMEK, të gjitha të dhënat e lidhura enkriptohen me çelësa të menaxhuar nga klienti dhe nuk mund të aksesohen pa ta. Mënyra e vetme për të ndërprerë përdorimin e CMEK është të krijoni një hapësirë pune të re — të dhënat ekzistuese të enkriptuara do të mbeten përgjithmonë të paaksesueshme.
Çfarë ndodh kur bëj rotacionin e çelësit tim kryesor?
Do të gjenerohet material i ri kriptografik për enkriptim, prandaj kërkesat e reja të enkriptimit do të përdorin çelësin e ri. Megjithatë, identifikuesi KMS (ARN ose emri i çelësit) mbetet i njëjtë dhe të dhënat e vjetra ende mund të dekriptohen. Shumë ofrues cloud ofrojnë rotacion automatik të çelësave (AWS, GCP, Azure).
A i ri-enkripton OpenAI të dhënat e vjetra kur bëj rotacionin e çelësit tim kryesor?
Jo. Materiali i ri kriptografik do të përdoret vetëm për të enkriptuar të dhëna të reja.
Sa kohë duhet që rotacioni ose revokimi i çelësit të hyjë në fuqi?
1 orë. Kjo ndodh sepse DEK/eDEK ruhen në cache në memorie dhe ne i rivalidojmë këto hyrje me KMS-në tuaj çdo orë.
Ndryshimi i identifikuesit KMS
A është ndryshimi i identifikuesit KMS revokim çelësi apo rotacion çelësi?
Revokim çelësi. Një çelës nuk mund të dekriptojë të dhëna të enkriptuara nga një çelës tjetër.
A mund të më ndihmojë OpenAI të ndryshoj identifikuesin tim KMS për një hapësirë pune ChatGPT?
Nëse konfirmoni se qëllimi është të revokoni çelësin tuaj, mund t’ju ndihmojmë ta bëni këtë për një hapësirë pune ChatGPT. Kini parasysh se kur përditësohet ARN-i i KMS-së, të dhënat më të vjetra do të mbeten të paaksesueshme, ndaj pas ndryshimit do të përfundoni me një përzierje të dhënash të paaksesueshme dhe të aksesueshme.
A mund të më ndihmojë OpenAI të ndryshoj identifikuesin tim KMS për një projekt API?
Nëse përdorni API-në, API-ja e bën të lehtë arkivimin dhe krijimin e projekteve të reja, ndaj ju lutemi arkivoni projektin të dhënat e të cilit gjithsesi nuk janë të aksesueshme, regjistroni një konfigurim të ri EKM me OpenAI dhe krijoni një projekt të ri API me çelësin e ri KMS.
Po nëse dua ta ndryshoj rregullisht vetë identifikuesin tim KMS?
Kjo nuk rekomandohet, pasi me gjasë nuk dëshironi ta revokoni rregullisht çelësin tuaj. Megjithatë, mund ta bëni këtë nëse përdorni një ofrues cloud që mbështet alias të çelësit KMS (shembull AWS). Mund ta regjistroni atë alias të çelësit KMS me OpenAI dhe më pas, te ofruesi juaj cloud, mund të zëvendësoni në çdo kohë identifikuesin bazë KMS ku tregon alias-i, për të kryer revokim çelësi.
Sjellja Beta kundrejt GA
A ka rreziqe të njohura ose ndryshime në nivel sistemi kur përdoret beta e enkriptimit në prodhim?
Mjedisi beta është funksionalisht i barasvlershëm me GA dhe nuk priten hapa migrimi. Rreziku kryesor është që disa veçori të rasteve skajore mund të mos mbështesin ende përmbajtje të enkriptuar për shkak të rrugëve të paplota të kodit. Këto janë të rralla dhe po zgjidhen aktivisht. Të dhënat janë plotësisht të enkriptuara dhe të mbrojtura pavarësisht këtyre problemeve të mundshme.
A do të ketë hapa migrimi nga beta në GA?
Jo. Hapësirat e punës që përdorin beta-n e enkriptimit do të mbështeten automatikisht në GA pa asnjë veprim nga përdoruesi.
Detaje teknike shtesë
Enkriptimi me zarf dhe lejet
A duhet t’i japim OpenAI leje GenerateDataKey për EKM?
Jo. OpenAI kërkon vetëm lejet Encrypt dhe Decrypt në çelësin tuaj KMS. Leja GenerateDataKey nuk është e nevojshme për integrimin EKM.
A përdor OpenAI enkriptim me zarf për të dhënat e klientëve?
Po. OpenAI përdor një model enkriptimi me zarf:
KMS i klientit: Menaxhon çelësat e enkriptimit të çelësave (KEK). OpenAI nuk i sheh dhe nuk i ruan kurrë KEK-të.
Infrastruktura e OpenAI: Gjeneron dhe menaxhon çelësat e enkriptimit të të dhënave (DEK). Çdo DEK enkriptohet (mbështillet) me KEK-un tuaj përpara ruajtjes.
Rrjedha e të dhënave:
Të dhënat e klientit enkriptohen me një DEK.
Ai DEK enkriptohet me KEK-un tuaj, duke prodhuar një eDEK.
eDEK ruhet krahas të dhënave të enkriptuara.
Për të dekriptuar të dhënat, OpenAI i kërkon KMS-së tuaj të dekriptojë eDEK-un, merr DEK-un dhe dekripton përmbajtjen.
Pse OpenAI zgjodhi këtë model në vend që ta lejonte KMS-në të menaxhonte si KEK-të ashtu edhe DEK-të?
Ka dy qasje të zakonshme për enkriptimin me zarf:
KEK dhe DEK të menaxhuar nga KMS:
Përparësi: Zbatim më i thjeshtë, pa nevojë për të mirëmbajtur infrastrukturë enkriptimi.
Mangësi: Çdo kërkesë enkriptimi/dekriptimi prek KMS-në, duke rritur vonesën dhe koston, si dhe duke krijuar një pikë të vetme dështimi.
KEK të menaxhuar nga KMS / DEK të menaxhuar nga OpenAI (qasja jonë):
Përparësi: Vonesë dhe kosto dukshëm më të ulëta, shkallëzim dhe besueshmëri më të mira, si dhe funksionim i vazhdueshëm gjatë ndërprerjeve të pjesshme të KMS-së (deri në TTL-në e cache-it të DEK-ut).
Mangësi: Zbatim pak më kompleks nga ana e OpenAI.
Ky dizajn i mundëson OpenAI të ofrojë garanci të forta sigurie, duke minimizuar njëkohësisht rrezikun operacional dhe koston për klientët.
Sa shpesh bëhet rotacioni i DEK-ve?
Çdo DEK rotacionohet afërsisht çdo 60 minuta. Kjo siguron izolim kohor — edhe nëse një DEK komprometohet disi, ndikimi do të kufizohej te të dhënat e enkriptuara brenda asaj dritareje njëorëshe.
Vëllimi i kërkesave KMS dhe observueshmëria
Shohim shumë më pak kërkesa KMS sesa numri i mesazheve të përdoruesve. A duhet të përputhen këto numra?
Jo, ato nuk do të korrelacionohen drejtpërdrejt.
Për shkak se OpenAI i ruan DEK-të në cache në memorie për arsye performance, thirrjet KMS bëhen vetëm kur një DEK duhet të dekriptohet — jo në çdo operacion enkriptimi ose dekriptimi. Si rezultat, duhet të prisni:
Më pak kërkesa KMS sesa ndërveprime të përdoruesve.
Rritje të herëpashershme kur DEK-të në cache skadojnë (rreth çdo orë) ose kur duhet të aksesohen të dhëna të vjetra të enkriptuara.
Thirrje shtesë kur merren të dhëna historike, si kur një përdorues vazhdon një bisedë të gjatë dhe duhet të ngarkohen DEK-të më të vjetër.
Numri i saktë i kërkesave KMS varet nga gjendja e cache-it, sjellja e përdoruesve, modelet e aksesit të të dhënave dhe gjatësia e bisedës, prandaj nuk do të korrelacionohet drejtpërdrejt me vëllimin e mesazheve.