Концепти за шифрирање
Тек на високо ниво
Вие контролирате главен клуч во вашиот облак што 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. Исто така, создајте нов клуч во вашиот cloud KMS за OpenAI, наместо повторно да користите постојни клучеви наменети за продукција.
Кога OpenAI добива дозволи за пристап до мојот KMS?
Мора да се преземени сите овие чекори:
Сте го препознале идентитетот на OpenAI (преку trust policy, workload identity итн., зависно од cloud провајдерот).
Сте создале политика за пристап до 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 или име на клуч) останува ист и старите податоци и понатаму може да се дешифрираат. Многу cloud провајдери нудат автоматска ротација на клучеви (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 идентификатор?
Ова не се препорачува, бидејќи веројатно не сакате редовно да го отповикувате вашиот клуч. Сепак, можете да го направите тоа ако користите cloud провајдер што поддржува алијас за KMS клуч (пример од AWS). Можете да го регистрирате тој алијас за KMS клуч кај OpenAI, а потоа кај вашиот cloud провајдер во секое време да го замените основниот KMS идентификатор на кој укажува алијасот за да издадете отповикување на клуч.
Однесување во бета наспроти GA
Дали има познати ризици или промени на системско ниво при користење на бета-шифрирањето во продукција?
Бета-средината е функционално еквивалентна на GA и не се очекуваат чекори за миграција. Главниот ризик е што некои гранични функции можеби сè уште не поддржуваат шифрирана содржина поради нецелосни патеки во кодот. Тие се ретки и активно се решаваат. Податоците се целосно шифрирани и заштитени без оглед на овие потенцијални проблеми.
Дали ќе има чекори за миграција од бета во GA?
Не. Работните простори што ја користат бета-верзијата на шифрирањето автоматски ќе бидат поддржани во GA без никакво дејство од корисникот.
Дополнителни технички детали
Ковертно шифрирање и дозволи
Дали треба да му доделиме GenerateDataKey дозволи на OpenAI за 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 барања зависи од состојбата на кеширањето, однесувањето на корисниците, обрасците на пристап до податоци и должината на разговорот, па затоа нема директно да корелира со обемот на пораки.