Поняття шифрування
Загальний процес
Ви контролюєте головний ключ у своїй хмарі, який 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 (через політику довіри, ідентичність робочого навантаження тощо — залежно від хмарного провайдера).
Ви створили політику для доступу до KMS.
Ви призначили ідентичності OpenAI дозвіл на доступ до політики.
Якщо ви просто створите KMS, не виконавши всі ці кроки, OpenAI не матиме доступу.
Чи маю я зберігати свій головний ключ у своїй хмарі?
Ні — спосіб керування головним ключем визначаєте ви. Ви можете використовувати рішення під керуванням хмари або зовнішнє рішення, де ключ зберігається окремо. OpenAI потрібно лише викликати операції encrypt/decrypt у вашому KMS; те, як головний ключ фактично виконує шифрування й дешифрування, є деталлю реалізації, непрозорою для нас.
Життєвий цикл ключів
Ротація DEK/eDEK (керується OpenAI)
Як часто ротуються DEK/eDEK?
Кожні 24 години на шляху шифрування (запит пари ключів DEK/eDEK)
Кожну 1 годину для шляху ключа дешифрування (DEK -> eDEK)
Чи потрібно мені щось робити, коли DEK змінюється?
Ні — ротація DEK/eDEK виконується всередині OpenAI. Поки ваш головний ключ залишається дійсним, будь-які eDEK, зашифровані вашим головним ключем, і надалі можна дешифрувати в DEK, який потім використовується для дешифрування ваших даних.
Ротація та відкликання головного ключа (керується вами)
Як часто відбуваються ротація ключів і відкликання ключів?
Це визначаєте ви, оскільки OpenAI не має видимості вашого головного ключа.
У чому різниця між ротацією ключа та відкликанням ключа?
Відкликання ключа прибирає доступ до даних, зашифрованих старішими ключами. Ротація ключа шифрує дані новим ключем, але зберігає доступ для читання старіших даних.
Що станеться, якщо я відкличу свій головний ключ?
Якщо ключ відкликано або дозволи видалено, робочий простір зрештою перестане працювати після завершення строку дії кешованих ключів. У цей момент OpenAI більше не зможе дешифрувати збережені дані або шифрувати нові. Фактично дані буде «знищено».
Як швидко відкликання набирає чинності?
OpenAI кешує DEK у пам’яті для продуктивності та стійкості. Відкликання зазвичай набирає чинності протягом однієї години, коли завершується строк дії кешованих ключів і повторна перевірка не проходить.
Чи можна безпечно протестувати відкликання?
Тестувати відкликання у виробничому робочому просторі не рекомендується, оскільки це назавжди зробить наявні дані недоступними. Однак клієнти можуть (і повинні) тестувати відкликання в середовищі пісочниці, щоб перевірити правильну поведінку й підтвердити свої припущення щодо довіри.
Якщо ключ відкликано назавжди, чи можна відновити робочий простір, додавши новий ключ?
Ні. Після втрати ключа дані неможливо відновити за задумом системи. Єдиний спосіб виправлення — розгорнути новий робочий простір.
Що робити, якщо робочий простір став недоступним через зміни ключа?
Очікуваний спосіб виправлення — створити новий робочий простір. Оновлення 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, він дає змогу легко архівувати й створювати нові проєкти. Тому натомість заархівуйте проєкт, дані якого все одно недоступні, зареєструйте нову конфігурацію EKM в OpenAI і створіть новий API-проєкт із новим ключем KMS.
Що, якщо я хочу регулярно самостійно змінювати ідентифікатор KMS?
Це не рекомендується, оскільки ви, ймовірно, не хочете регулярно відкликати свій ключ. Однак ви все одно можете це зробити, якщо користуєтеся хмарним провайдером, який підтримує псевдонім ключа KMS (приклад AWS). Ви можете зареєструвати цей псевдонім ключа KMS в OpenAI, а потім у свого хмарного провайдера будь-коли замінити базовий ідентифікатор KMS, на який указує псевдонім, щоб виконати відкликання ключа.
Поведінка в бета-версії порівняно з GA
Чи є відомі ризики або зміни на рівні системи під час використання бета-версії шифрування у виробничому середовищі?
Бета-середовище функціонально еквівалентне GA, і кроків міграції не очікується. Основний ризик полягає в тому, що деякі граничні функції можуть ще не підтримувати зашифрований вміст через незавершені шляхи коду. Такі випадки рідкісні, і ми активно їх усуваємо. Дані повністю зашифровані й захищені незалежно від цих потенційних проблем.
Чи будуть якісь кроки міграції з бета-версії до GA?
Ні. Робочі простори, які використовують бета-версію шифрування, автоматично підтримуватимуться в 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?
Є два поширені підходи до конвертного шифрування:
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 залежить від стану кешу, поведінки користувачів, шаблонів доступу до даних і довжини розмов, тому вона не корелюватиме напряму з обсягом повідомлень.