Mga Konsepto sa Encryption
High-level na daloy
Ikaw ang kumokontrol sa master key sa iyong cloud na hindi kailanman nakikita ng OpenAI
Ginagamit ang master key mo para i-encrypt ang data encryption keys (DEKs) na ginagamit ng OpenAI
Ginagamit ng OpenAI ang mga DEK para i-encrypt ang iyong data at rest. Ini-encrypt ng iyong master key ang isang DEK, na lumilikha ng eDEK (encrypted DEK), na iniimbak kasama ng iyong data
Para basahin ang data, kinukuha ng OpenAI ang eDEK, hinihiling sa iyong KMS na i-decrypt ito bilang DEK, at pagkatapos ay dine-decrypt ang iyong data
Paano gumagana ang EKM encryption?
Tingnan ang aming artikulo para sa detalyadong impormasyon: Pangkalahatang-ideya ng OpenAI Enterprise Key Management (EKM)
Ini-store ba ng OpenAI ang mga DEK ko?
Hindi — ini-store namin ang mga encrypted DEK (eDEK), na ginagawa ng iyong KMS. Para i-decrypt ang data, hinihiling namin sa iyong KMS na i-decrypt ang eDEK pabalik sa DEK.
Kina-cache ba ng OpenAI ang mga DEK ko?
Oo — sa memory lang. Para ito sa performance, upang maiwasang tawagin ang iyong KMS sa bawat data encrypt/decrypt request. Hindi kailanman isinusulat sa storage ang mga DEK.
Mga Pahintulot sa Cloud
Anong mga pahintulot ang magkakaroon ang OpenAI sa KMS ko?
Tanging ang mga pahintulot na ibibigay mo sa amin sa pamamagitan ng policy na ise-set mo. Kailangan lang namin ng kahit Encrypt/Decrypt operations man lang. Gumawa rin ng bagong key sa cloud KMS mo para sa OpenAI sa halip na muling gamitin ang anumang kasalukuyang key na ginagamit sa production.
Kailan nagkakaroon ng mga pahintulot ang OpenAI para i-access ang KMS ko?
Dapat nagawa na ang lahat ng hakbang na ito:
Nakilala mo na ang identity ng OpenAI (sa pamamagitan ng trust policy, workload identity, atbp., depende sa cloud provider).
Nakagawa ka na ng policy para sa pag-access sa KMS.
Na-assign mo na sa identity ng OpenAI ang pahintulot na i-access ang policy.
Kung gagawa ka lang ng KMS nang hindi ginagawa ang lahat ng hakbang na ito, walang access ang OpenAI.
Kailangan ko bang i-store ang master key ko sa cloud ko?
Hindi — ikaw ang bahala kung paano pamamahalaan ang master key mo. Maaari kang gumamit ng cloud-managed solution o external na solusyon kung saan hiwalay na naka-store ang key mo. Kailangan lang ng OpenAI na tumawag ng encrypt/decrypt operations sa iyong KMS — ang aktuwal na paraan ng master key sa pag-encrypt/decrypt ay detalye ng implementasyon na hindi namin nakikita.
Lifecycle ng Key
DEK/eDEK Rotation (Kontrolado ng OpenAI)
Gaano kadalas ini-rotate ang mga DEK/eDEK?
Bawat 24 na oras sa encryption path (humihiling ng DEK/eDEK key pair)
Bawat 1 oras para sa decryption key path (DEK -> eDEK)
May kailangan ba akong gawin kapag nagbago ang DEK?
Wala — ginagawa ang DEK/eDEK rotation sa loob ng OpenAI. Hangga’t valid ang master key mo, patuloy na made-decrypt bilang DEK ang anumang eDEK na na-encrypt ng master key mo, at iyon ang gagamitin para i-decrypt ang iyong data.
Master Key Rotation at Revocation (Kontrolado mo)
Gaano kadalas nangyayari ang key rotation at key revocation?
Ikaw ang nagtatakda nito dahil walang visibility ang OpenAI sa iyong master key.
Ano ang pagkakaiba ng key rotation at key revocation?
Inaalis ng key revocation ang access sa data na na-encrypt gamit ang mga mas lumang key. Ini-encrypt ng key rotation ang data gamit ang bagong key, pero pinananatili ang read access sa mas lumang data.
Ano ang mangyayari kung i-revoke ko ang master key ko?
Kung na-revoke ang isang key o inalis ang mga pahintulot, kalaunan ay hindi na gagana ang workspace kapag nag-expire ang mga naka-cache na key. Sa puntong iyon, hindi na made-decrypt ng OpenAI ang naka-store na data o makakapag-encrypt ng bagong data. Sa praktikal na epekto, “na-shred” ang data.
Gaano kabilis magkakabisa ang revocation?
Nagka-cache ang OpenAI ng mga DEK sa memory para sa performance at resilience. Karaniwang nagkakabisa ang revocation sa loob ng isang oras, kapag nag-expire ang mga naka-cache na key at nabigo ang re-validation.
Ligtas bang i-test ang revocation?
Hindi inirerekomenda ang pag-test ng revocation sa production workspace dahil permanenteng hindi na maa-access ang kasalukuyang data. Gayunpaman, maaari (at dapat) i-test ng mga customer ang revocation sa sandbox environment para tiyaking tama ang gawi at ma-validate ang kanilang mga palagay sa trust.
Kung permanenteng na-revoke ang isang key, mare-recover ba ang workspace sa pamamagitan ng pag-attach ng bagong key?
Hindi. Kapag nawala na ang key, hindi na mababawi ang data ayon sa disenyo. Ang tanging remedyo ay gumawa ng bagong workspace.
Ano ang dapat naming gawin kung hindi na ma-access ang isang workspace dahil sa mga pagbabago sa key?
Ang inaasahang remedyo ay gumawa ng bagong workspace. Hindi mare-recover ng pag-update sa KMS ang kasalukuyang data.
Ano ang backout plan kung magpasya kaming ihinto ang paggamit ng CMEK?
Sa kasalukuyan, walang backout plan. Kapag nagawa ang isang workspace gamit ang CMEK, lahat ng kaugnay na data ay naka-encrypt gamit ang customer-managed keys at hindi maa-access kung wala ang mga ito. Ang tanging paraan para ihinto ang paggamit ng CMEK ay gumawa ng bagong workspace — mananatiling permanenteng hindi maa-access ang kasalukuyang naka-encrypt na data.
Ano ang mangyayari kapag ni-rotate ko ang master key ko?
Gagawa ng bagong cryptographic material para sa encryption kaya gagamitin ng mga bagong encryption request ang bagong key. Gayunpaman, mananatiling pareho ang KMS identifier (ARN o pangalan ng key) at made-decrypt pa rin ang lumang data. Maraming cloud provider ang nag-aalok ng automatic key rotation (AWS, GCP, Azure).
Muling ini-encrypt ba ng OpenAI ang mas lumang data kapag ni-rotate ko ang master key ko?
Hindi. Gagamitin lang ang bagong cryptographic material para i-encrypt ang bagong data.
Gaano katagal bago magkabisa ang key rotation o key revocation?
1 oras. Ito ay dahil naka-cache sa memory ang mga DEK/eDEK at nire-revalidate namin ang mga entry na ito sa iyong KMS bawat oras.
Pagpapalit ng KMS Identifier
Ang pagpapalit ba ng KMS identifier ay key revocation o key rotation?
Key revocation. Hindi made-decrypt ng isang key ang data na na-encrypt ng ibang key.
Matutulungan ba ako ng OpenAI na palitan ang KMS identifier ko para sa isang ChatGPT workspace?
Kung kukumpirmahin mong ang layunin ay i-revoke ang iyong key, matutulungan ka naming gawin ito para sa isang ChatGPT workspace. Tandaan na kapag na-update ang KMS ARN, mananatiling hindi naa-access ang mas lumang data, kaya magkakaroon ka ng halo ng hindi naa-access at naa-access na data pagkatapos ng pagbabago.
Matutulungan ba ako ng OpenAI na palitan ang KMS identifier ko para sa isang API project?
Kung ginagamit mo ang API, pinapadali ng API ang pag-archive at paggawa ng mga bagong project, kaya i-archive na lang ang project na hindi rin naman maa-access ang data, magrehistro ng bagong EKM config sa OpenAI, at gumawa ng bagong API project gamit ang bagong KMS key.
Paano kung gusto kong regular na palitan nang mag-isa ang KMS identifier ko?
Hindi ito inirerekomenda dahil malamang ay ayaw mong regular na i-revoke ang iyong key. Gayunpaman, magagawa mo pa rin ito kung gumagamit ka ng cloud provider na sumusuporta sa KMS key alias (halimbawa sa AWS). Maaari mong irehistro ang KMS key alias na iyon sa OpenAI, at pagkatapos sa iyong cloud provider ay maaari mong palitan anumang oras ang underlying KMS identifier na itinuturo ng alias para mag-isyu ng key revocation.
Gawi sa Beta kumpara sa GA
Mayroon bang anumang kilalang panganib o system-level na pagbabago kapag ginagamit ang encryption beta sa production?
Functionally equivalent sa GA ang beta environment, at walang inaasahang migration steps. Ang pangunahing panganib ay maaaring hindi pa sinusuportahan ng ilang edge-case feature ang encrypted content dahil hindi pa kumpleto ang ilang code path. Bihira ang mga ito at aktibong inaayos. Ganap na naka-encrypt at protektado ang data sa kabila ng mga posibleng isyung ito.
Magkakaroon ba ng anumang migration steps mula beta patungong GA?
Wala. Awtomatikong susuportahan sa GA ang mga workspace na gumagamit ng encryption beta nang walang anumang aksyon mula sa user.
Karagdagang Teknikal na Detalye
Envelope Encryption at Mga Pahintulot
Kailangan ba naming magbigay ng GenerateDataKey permissions sa OpenAI para sa EKM?
Hindi. Encrypt at Decrypt permissions lang sa iyong KMS key ang kailangan ng OpenAI. Hindi kailangan ang GenerateDataKey permission para sa EKM integration.
Gumagamit ba ang OpenAI ng envelope encryption para sa data ng customer?
Oo. Gumagamit ang OpenAI ng modelo ng envelope encryption:
Customer KMS: Pinamamahalaan ang Key Encryption Keys (KEKs). Hindi kailanman nakikita o ini-store ng OpenAI ang mga KEK.
OpenAI Infrastructure: Lumilikha at namamahala ng Data Encryption Keys (DEKs). Ini-encrypt (wini-wrap) ang bawat DEK gamit ang iyong KEK bago i-store.
Daloy ng Data:
Ini-encrypt ang data ng customer gamit ang isang DEK.
Ini-encrypt ang DEK na iyon gamit ang iyong KEK, na lumilikha ng eDEK.
Ini-store ang eDEK kasama ng naka-encrypt na data.
Para i-decrypt ang data, hinihiling ng OpenAI sa iyong KMS na i-decrypt ang eDEK, kinukuha ang DEK, at dine-decrypt ang content.
Bakit pinili ng OpenAI ang modelong ito sa halip na hayaang pamahalaan ng KMS ang parehong KEK at DEK?
May dalawang karaniwang paraan ng envelope encryption:
Mga KEK at DEK na Pinamamahalaan ng KMS:
Mga kalamangan: Mas simpleng implementasyon, hindi kailangang magpanatili ng encryption infrastructure.
Mga kahinaan: Bawat kahilingan sa pag-encrypt/decrypt ay dumadaan sa KMS, kaya tumataas ang latency at gastos, at nagkakaroon ng iisang point of failure.
Mga KEK na Pinamamahalaan ng KMS / Mga DEK na Pinamamahalaan ng OpenAI (Aming Paraan):
Mga kalamangan: Mas mababang latency at gastos, mas mahusay na scalability at reliability, at patuloy na operasyon sa panahon ng bahagyang KMS outages (hanggang sa DEK cache TTL).
Mga kahinaan: Bahagyang mas kumplikadong implementasyon sa panig ng OpenAI.
Pinapayagan ng disenyong ito ang OpenAI na magbigay ng matitibay na garantiya sa seguridad habang pinapaliit ang operational risk at gastos para sa mga customer.
Gaano kadalas ini-rotate ang mga DEK?
Ini-rotate ang bawat DEK humigit-kumulang bawat 60 minuto. Nagbibigay ito ng temporal isolation — kahit pa sa anumang paraan ay makompromiso ang isang DEK, malilimitahan ang epekto sa data na na-encrypt sa loob ng isang oras na iyon.
Dami ng KMS Request at Observability
Mas kaunti ang nakikita naming KMS requests kaysa sa bilang ng mga mensahe ng user. Dapat bang magtugma ang mga numerong ito?
Hindi, hindi sila direktang magko-correlate.
Dahil nagka-cache ang OpenAI ng mga DEK sa memory para sa performance, ginagawa lang ang KMS calls kapag kailangang i-decrypt ang isang DEK — hindi sa bawat encryption o decryption operation. Bilang resulta, asahan ang:
Mas kaunting KMS requests kaysa sa mga interaction ng user.
Paminsan-minsang pagtaas kapag nag-expire ang mga naka-cache na DEK (humigit-kumulang bawat oras) o kapag kailangang i-access ang mas lumang naka-encrypt na data.
Karagdagang calls kapag kumukuha ng historical data, gaya kapag ipinagpapatuloy ng user ang matagal nang pag-uusap at kailangang i-load ang mas lumang mga DEK.
Nakadepende ang eksaktong bilang ng KMS requests sa caching state, gawi ng user, mga pattern ng data access, at haba ng pag-uusap, kaya hindi ito direktang magko-correlate sa dami ng mensahe.