Концепции за криптиране
Общ процес
Вие контролирате главен ключ във вашия облак, който OpenAI никога не вижда
Вашият главен ключ се използва за криптиране на ключове за криптиране на данни (DEK), използвани от OpenAI
OpenAI използва DEK, за да криптира вашите данни в покой. DEK се криптира с вашия главен ключ, като се генерира eDEK (криптиран DEK), който се съхранява заедно с вашите данни
За да прочете данните, OpenAI взема eDEK, заявява към вашия KMS да го декриптира в DEK и след това декриптира вашите данни
Как работи EKM криптирането?
За подробна информация вижте нашата статия: Общ преглед на OpenAI Enterprise Key Management (EKM)
Съхранява ли OpenAI моите DEK?
Не — съхраняваме криптираните DEK (eDEK), които се генерират от вашия KMS. За да декриптираме данните, заявяваме към вашия KMS да декриптира eDEK обратно в DEK.
Кешира ли OpenAI моите DEK?
Да — само в паметта. Това се прави за производителност, за да се избегне обръщение към вашия KMS при всяка заявка за криптиране/декриптиране на данни. DEK никога не се записват в хранилище.
Разрешения в облака
Какви разрешения ще има OpenAI в моя KMS?
Само разрешенията, които ни предоставите чрез зададената от вас политика. Нуждаем се поне от операциите Encrypt/Decrypt. Моля, създайте и нов ключ във вашия облачен KMS за OpenAI, вместо да използвате повторно съществуващи ключове, предназначени за продукционни цели.
Кога OpenAI получава разрешения за достъп до моя KMS?
Всички тези стъпки трябва да са изпълнени:
Разпознали сте идентичността на OpenAI (чрез trust policy, workload identity и т.н., в зависимост от облачния доставчик).
Създали сте политика за достъп до KMS.
Предоставили сте на идентичността на OpenAI разрешение за достъп до политиката.
Ако само създадете KMS, без да изпълните всички тези стъпки, OpenAI няма достъп.
Трябва ли да съхранявам главния си ключ в моя облак?
Не — вие решавате как да управлявате главния си ключ. Можете да използвате решение, управлявано в облака, или външно решение, при което ключът ви се съхранява отделно. OpenAI трябва само да извиква операции за криптиране/декриптиране към вашия KMS — как главният ключ реално изпълнява криптиране/декриптиране е детайл от реализацията, който остава непрозрачен за нас.
Жизнен цикъл на ключа
Ротация на DEK/eDEK (контролира се от OpenAI)
Колко често се ротират DEK/eDEK?
На всеки 24 часа по пътя на криптиране (при заявяване на двойка ключове DEK/eDEK)
На всеки 1 час по пътя на ключа за декриптиране (DEK -> eDEK)
Трябва ли да правя нещо, когато DEK се промени?
Не — ротацията на DEK/eDEK се извършва в рамките на OpenAI. Докато главният ви ключ остава валиден, всички eDEK, криптирани с него, могат да продължат да се декриптират в DEK, който след това се използва за декриптиране на вашите данни.
Ротация и отнемане на главния ключ (контролира се от вас)
Колко често се случват ротация и отнемане на ключове?
Това се определя от вас, тъй като OpenAI няма видимост към вашия главен ключ.
Каква е разликата между ротация на ключ и отнемане на ключ?
Отнемането на ключ премахва достъпа до данни, криптирани с по-стари ключове. Ротацията на ключ криптира данните с нов ключ, но запазва достъпа за четене до по-старите данни.
Какво се случва, ако отнема главния си ключ?
Ако ключ бъде отнет или разрешенията бъдат премахнати, работното пространство в крайна сметка ще спре да функционира, след като кешираните ключове изтекат. В този момент OpenAI вече не може да декриптира съхранени данни или да криптира нови данни. На практика данните са „унищожени“.
Колко бързо влиза в сила отнемането?
OpenAI кешира DEK в паметта за производителност и устойчивост. Отнемането обикновено влиза в сила в рамките на един час, след като кешираните ключове изтекат и повторната валидация е неуспешна.
Може ли отнемането да се тества безопасно?
Тестването на отнемане в производствено работно пространство не се препоръчва, защото ще направи съществуващите данни трайно недостъпни. Клиентите обаче могат (и трябва) да тестват отнемането в sandbox среда, за да проверят правилното поведение и да валидират предположенията си за доверие.
Ако ключ бъде отнет окончателно, може ли работното пространство да бъде възстановено чрез прикачване на нов ключ?
Не. След като ключът бъде загубен, данните по замисъл са невъзстановими. Единственото решение е да се създаде ново работно пространство.
Какво трябва да направим, ако работно пространство стане недостъпно поради промени в ключа?
Очакваното решение е да се създаде ново работно пространство. Актуализирането на KMS няма да възстанови съществуващите данни.
Какъв е планът за отказ, ако решим да спрем да използваме CMEK?
В момента няма план за отказ. След като работно пространство бъде създадено с CMEK, всички свързани данни се криптират с ключове, управлявани от клиента, и не могат да бъдат достъпени без тях. Единственият начин да прекратите използването на CMEK е да създадете ново работно пространство — съществуващите криптирани данни ще останат трайно недостъпни.
Какво се случва, когато ротирам главния си ключ?
Ще бъде генериран нов криптографски материал за криптиране, така че новите заявки за криптиране ще използват новия ключ. Въпреки това KMS идентификаторът (ARN или име на ключ) остава същият и старите данни все още могат да бъдат декриптирани. Много облачни доставчици предлагат автоматична ротация на ключове (AWS, GCP, Azure).
Прекриптира ли OpenAI по-старите данни, когато ротирам главния си ключ?
Не. Новият криптографски материал ще се използва само за криптиране на нови данни.
Колко време отнема ротацията или отнемането на ключ да влезе в сила?
1 час. Причината е, че DEK/eDEK се кешират в паметта и повторно валидираме тези записи с вашия KMS на всеки час.
Смяна на KMS идентификатора
Смяната на KMS идентификатора отнемане на ключ ли е, или ротация на ключ?
Отнемане на ключ. Един ключ не може да декриптира данни, криптирани с друг ключ.
Може ли OpenAI да ми помогне да сменя KMS идентификатора за работно пространство в ChatGPT?
Ако потвърдите, че намерението е да отнемете ключа си, можем да ви помогнем да направите това за работно пространство в ChatGPT. Имайте предвид, че когато KMS ARN бъде актуализиран, по-старите данни ще останат недостъпни, така че след промяната ще имате комбинация от недостъпни и достъпни данни.
Може ли OpenAI да ми помогне да сменя KMS идентификатора за API проект?
Ако използвате API, API улеснява архивирането и създаването на нови проекти, затова вместо това архивирайте проекта, чиито данни така или иначе не са достъпни, регистрирайте нова EKM конфигурация в OpenAI и създайте нов API проект с новия KMS ключ.
Какво ако искам редовно сам да сменям KMS идентификатора си?
Това не се препоръчва, тъй като вероятно не искате редовно да отнемате ключа си. Все пак можете да го направите, ако използвате облачен доставчик, който поддържа псевдоним на KMS ключ (пример за AWS). Можете да регистрирате този псевдоним на KMS ключ в OpenAI, а след това при вашия облачен доставчик по всяко време да смените базовия KMS идентификатор, към който сочи псевдонимът, за да извършите отнемане на ключ.
Поведение при Beta спрямо GA
Има ли известни рискове или промени на системно ниво при използване на бета версията на криптирането в продукционна среда?
Бета средата е функционално еквивалентна на GA и не се очакват стъпки за миграция. Основният риск е, че някои функции за гранични случаи може все още да не поддържат криптирано съдържание поради непълни кодови пътища. Те са редки и активно се отстраняват. Данните са напълно криптирани и защитени независимо от тези потенциални проблеми.
Ще има ли стъпки за миграция от beta към GA?
Не. Работните пространства, използващи бета версията на криптирането, автоматично ще се поддържат в GA без действия от страна на потребителя.
Допълнителни технически подробности
Envelope криптиране & разрешения
Трябва ли да предоставим на OpenAI разрешения GenerateDataKey за EKM?
Не. OpenAI изисква само разрешения Encrypt и Decrypt за вашия KMS ключ. Разрешението GenerateDataKey не е необходимо за интеграция с EKM.
Използва ли OpenAI envelope криптиране за клиентски данни?
Да. OpenAI използва модел на envelope криптиране:
KMS на клиента: Управлява ключовете за криптиране на ключове (KEK). OpenAI никога не вижда и не съхранява KEK.
Инфраструктура на OpenAI: Генерира и управлява ключове за криптиране на данни (DEK). Всеки DEK се криптира (обвива) с вашия KEK преди съхранение.
Поток на данните:
Клиентските данни се криптират с DEK.
Този DEK се криптира с вашия KEK, като се получава eDEK.
eDEK се съхранява заедно с криптираните данни.
За да декриптира данни, OpenAI заявява към вашия KMS да декриптира eDEK, извлича DEK и декриптира съдържанието.
Защо OpenAI избра този модел, вместо да остави KMS да управлява и KEK, и DEK?
Има два често използвани подхода за envelope криптиране:
KEK и DEK, управлявани от KMS:
Предимства: По-лесна реализация, без нужда от поддръжка на инфраструктура за криптиране.
Недостатъци: Всяка заявка за криптиране/декриптиране достига до KMS, което увеличава латентността и разходите и създава единична точка на отказ.
KEK, управлявани от KMS / DEK, управлявани от OpenAI (нашият подход):
Предимства: Значително по-ниска латентност и разходи, по-добра мащабируемост и надеждност и продължаване на работата при частични прекъсвания на KMS (до TTL на DEK кеша).
Недостатъци: Малко по-сложна реализация от страна на OpenAI.
Този дизайн позволява на OpenAI да предоставя силни гаранции за сигурност, като същевременно минимизира оперативния риск и разходите за клиентите.
Колко често се ротират DEK?
Всеки DEK се ротира приблизително на всеки 60 минути. Това осигурява времева изолация — дори ако DEK по някакъв начин бъде компрометиран, въздействието ще бъде ограничено до данните, криптирани в рамките на този едночасов прозорец.
Обем на KMS заявките & наблюдаемост
Виждаме много по-малко KMS заявки от броя на потребителските съобщения. Трябва ли тези числа да съвпадат?
Не, те няма да корелират пряко.
Тъй като OpenAI кешира DEK в паметта поради съображения за производителност, извиквания към KMS се правят само когато DEK трябва да бъде декриптиран — не при всяка операция за криптиране или декриптиране. В резултат трябва да очаквате:
По-малко KMS заявки от потребителските взаимодействия.
Периодични пикове, когато кешираните DEK изтекат (приблизително на всеки час) или когато трябва да се осъществи достъп до по-стари криптирани данни.
Допълнителни извиквания при извличане на исторически данни, например когато потребител продължи дълъг разговор и трябва да бъдат заредени по-стари DEK.
Точният брой KMS заявки зависи от състоянието на кеша, поведението на потребителите, моделите на достъп до данни и дължината на разговора, поради което няма да корелира пряко с обема на съобщенията.