Концепции за шифроване

Общ преглед на потока

• Вие управлявате главен ключ във вашия облак, който 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?

Всички тези стъпки трябва да са изпълнени: 1. разпознали сте идентичността на OpenAI (чрез trust policy, workload identity и т.н. в зависимост от облачния доставчик), 2. създали сте политика за достъп до KMS и 3. присвоили сте на идентичността на 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?

Това не се препоръчва, тъй като вероятно не искате редовно да отнемате ключа си. Въпреки това можете да го правите, ако използвате облачен доставчик, който поддържа alias за KMS ключ (пример с AWS). Можете да регистрирате този alias за KMS ключ в OpenAI, а след това при облачния си доставчик можете по всяко време да сменяте базовия идентификатор на KMS, към който сочи alias, за да извършите отнемане на ключ.

Поведение в Beta спрямо GA

Има ли известни рискове или промени на системно ниво при използване на beta шифроването в продукция?

Средата beta е функционално еквивалентна на GA и не се очакват стъпки за миграция. Основният риск е, че някои функции в гранични случаи може все още да не поддържат шифровано съдържание поради непълни кодови пътища. Това е рядко и активно се отстранява. Данните са напълно шифровани и защитени независимо от тези потенциални проблеми.

Ще има ли стъпки за миграция от beta към GA?

Не. Работните пространства, използващи beta шифроването, автоматично ще бъдат поддържани в GA без каквото и да било действие от страна на потребителя.

Допълнителни технически подробности

Пликово шифроване & разрешения

Трябва ли да дадем на OpenAI разрешения GenerateDataKey за EKM?

Не. OpenAI изисква само разрешения Encrypt и Decrypt за вашия KMS ключ. Разрешението GenerateDataKey не е необходимо за интеграцията с EKM.

Използва ли OpenAI пликово шифроване за клиентски данни?

Да. OpenAI използва модел на пликово шифроване:

• Клиентски KMS: Управлява ключовете за шифроване на ключове (KEK). OpenAI никога не вижда и не съхранява KEK.

• Инфраструктура на OpenAI: Генерира и управлява ключове за шифроване на данни (DEK). Всеки DEK се шифрова (обвива) с вашия KEK преди съхранение.

• Поток на данните:

  • Клиентските данни се шифроват с DEK.

  • Този DEK се шифрова с вашия KEK, като се получава eDEK.

  • eDEK се съхранява заедно с шифрованите данни.

  • За да дешифрова данните, OpenAI заявява на вашия KMS да дешифрова eDEK, извлича DEK и дешифрова съдържанието.

Защо OpenAI избра този модел, вместо да остави KMS да управлява и KEK, и DEK?

Има два често срещани подхода за пликово шифроване:

Управлявани от KMS KEK и DEK:

Плюсове: По-проста имплементация, няма нужда от поддържане на инфраструктура за шифроване.

Минуси: Всяка заявка за шифроване/дешифроване достига до KMS, което увеличава латентността, разходите и въвежда единична точка на отказ.

Управлявани от KMS KEK / управлявани от OpenAI DEK (нашият подход):

Плюсове: Значително по-ниска латентност и разходи, по-добра мащабируемост и надеждност и продължаване на работата при частични прекъсвания на KMS (до TTL на кеша на DEK).

Минуси: Малко по-сложна имплементация от страна на OpenAI.

Този дизайн позволява на OpenAI да предоставя силни гаранции за сигурност, като същевременно минимизира оперативния риск и разходите за клиентите.

Колко често се ротират DEK?

Всеки DEK се ротира приблизително на всеки 60 минути. Това осигурява времева изолация — дори ако DEK по някакъв начин бъде компрометиран, въздействието ще бъде ограничено до данните, шифровани в рамките на този едночасов прозорец.

Обем на заявките към KMS & наблюдаемост

Виждаме много по-малко заявки към KMS от броя на потребителските съобщения. Трябва ли тези числа да съвпадат?

Не, те няма да корелират директно.

Тъй като OpenAI кешира DEK в паметта поради съображения за производителност, извиквания към KMS се правят само когато DEK трябва да бъде дешифрован — не при всяка операция по шифроване или дешифроване. В резултат на това трябва да очаквате:

• По-малко заявки към KMS от потребителските взаимодействия.

• Случайни пикове, когато кешираните DEK изтекат (приблизително на всеки час) или когато трябва да се достъпят по-стари шифровани данни.

• Допълнителни извиквания, когато се извличат исторически данни, например когато потребител продължи дълъг разговор и трябва да бъдат заредени по-стари DEK.

Точният брой заявки към KMS зависи от състоянието на кеша, поведението на потребителите, моделите за достъп до данни и дължината на разговорите и следователно няма да корелира директно с обема на съобщенията.