Koncepcje szyfrowania

Przepływ na wysokim poziomie

• Kontrolujesz klucz główny w swojej chmurze, którego OpenAI nigdy nie widzi

• Twój klucz główny służy do szyfrowania kluczy szyfrowania danych (DEK) używanych przez OpenAI

• OpenAI używa kluczy DEK do szyfrowania Twoich danych przechowywanych w spoczynku. Klucz DEK jest szyfrowany Twoim kluczem głównym, co generuje eDEK (zaszyfrowany DEK), który jest przechowywany razem z Twoimi danymi

• Aby odczytać dane, OpenAI pobiera eDEK, wysyła do Twojego KMS żądanie jego odszyfrowania do postaci DEK, a następnie odszyfrowuje Twoje dane

Jak działa szyfrowanie EKM?

Aby uzyskać szczegółowe informacje, zapoznaj się z naszym artykułem: Przegląd OpenAI Enterprise Key Management (EKM)

Czy OpenAI przechowuje moje klucze DEK?

Nie — przechowujemy zaszyfrowane klucze DEK (eDEK), które są generowane przez Twój KMS. Aby odszyfrować dane, prosimy Twój KMS o odszyfrowanie eDEK z powrotem do postaci DEK.

Czy OpenAI buforuje moje klucze DEK?

Tak — wyłącznie w pamięci. Ma to na celu poprawę wydajności i uniknięcie odwołań do Twojego KMS przy każdym żądaniu szyfrowania/odszyfrowania danych. Klucze DEK nigdy nie są zapisywane w pamięci trwałej.

Uprawnienia w chmurze

Jakie uprawnienia będzie mieć OpenAI do mojego KMS?

Tylko te uprawnienia, które nam przyznasz za pomocą ustawionej przez siebie polityki. Potrzebujemy co najmniej operacji Encrypt/Decrypt. Utwórz też nowy klucz w swoim chmurowym KMS dla OpenAI zamiast ponownie używać istniejących kluczy wykorzystywanych do celów produkcyjnych.

Kiedy OpenAI uzyskuje uprawnienia dostępu do mojego KMS?

Wszystkie te kroki muszą zostać wykonane: 1. rozpoznano tożsamość OpenAI (przez politykę zaufania, tożsamość obciążenia itp., zależnie od dostawcy chmury), 2. utworzono politykę dostępu do KMS oraz 3. przypisano tożsamości OpenAI uprawnienie dostępu do tej polityki. Jeśli tylko utworzysz KMS bez wykonania wszystkich tych kroków, OpenAI nie będzie mieć dostępu.

Czy muszę przechowywać mój klucz główny w swojej chmurze?

Nie — sposób zarządzania kluczem głównym zależy od Ciebie. Możesz mieć rozwiązanie zarządzane przez chmurę albo zewnętrzne, w którym Twój klucz jest przechowywany osobno. OpenAI musi jedynie wywoływać operacje szyfrowania/odszyfrowania w Twoim KMS — to, jak klucz główny faktycznie realizuje szyfrowanie/odszyfrowanie, jest dla nas nieprzejrzystym szczegółem implementacyjnym.

Cykl życia klucza

Rotacja DEK/eDEK (kontrolowana przez OpenAI)

Jak często rotowane są DEK/eDEK?

Co 24 godziny na ścieżce szyfrowania (żądanie pary kluczy DEK/eDEK)

Co 1 godzinę dla ścieżki klucza odszyfrowywania (DEK -> eDEK)

Czy muszę coś zrobić, gdy zmieni się DEK?

Nie — rotacja DEK/eDEK odbywa się w OpenAI. Dopóki Twój klucz główny pozostaje ważny, wszelkie eDEK zaszyfrowane Twoim kluczem głównym mogą nadal zostać odszyfrowane do postaci DEK, który następnie służy do odszyfrowania Twoich danych.

Rotacja i unieważnianie klucza głównego (kontrolowane przez Ciebie)

Jak często następuje rotacja klucza i unieważnienie klucza?

To zależy od Ciebie, ponieważ OpenAI nie ma wglądu w Twój klucz główny.

Jaka jest różnica między rotacją klucza a unieważnieniem klucza?

Unieważnienie klucza usuwa dostęp do danych zaszyfrowanych przy użyciu starszych kluczy. Rotacja klucza szyfruje dane przy użyciu nowego klucza, ale zachowuje dostęp do odczytu starszych danych.

Co się stanie, jeśli unieważnię mój klucz główny?

Jeśli klucz zostanie unieważniony lub uprawnienia zostaną usunięte, przestrzeń robocza ostatecznie przestanie działać po wygaśnięciu kluczy z pamięci podręcznej. W tym momencie OpenAI nie będzie już mogło odszyfrowywać zapisanych danych ani szyfrować nowych danych. W praktyce dane zostaną „zniszczone”.

Jak szybko unieważnienie zaczyna obowiązywać?

OpenAI buforuje klucze DEK w pamięci ze względów wydajności i odporności. Unieważnienie zwykle zaczyna obowiązywać w ciągu jednej godziny, gdy klucze z pamięci podręcznej wygasną, a ponowna walidacja się nie powiedzie.

Czy można bezpiecznie przetestować unieważnienie?

Testowanie unieważnienia w produkcyjnej przestrzeni roboczej jest niezalecane, ponieważ trwale uniemożliwi dostęp do istniejących danych. Klienci mogą jednak (i powinni) testować unieważnienie w środowisku sandbox, aby zweryfikować poprawność działania i potwierdzić swoje założenia dotyczące zaufania.

Jeśli klucz zostanie trwale unieważniony, czy można odzyskać przestrzeń roboczą przez podłączenie nowego klucza?

Nie. Po utracie klucza odzyskanie danych jest z założenia niemożliwe. Jedynym rozwiązaniem jest utworzenie nowej przestrzeni roboczej.

Co powinniśmy zrobić, jeśli przestrzeń robocza stanie się niedostępna z powodu zmian klucza?

Oczekiwanym działaniem naprawczym jest utworzenie nowej przestrzeni roboczej. Aktualizacja KMS nie przywróci istniejących danych.

Jaki jest plan wycofania, jeśli zdecydujemy się przestać używać CMEK?

Obecnie nie ma planu wycofania. Gdy przestrzeń robocza zostanie utworzona z CMEK, wszystkie powiązane dane są szyfrowane przy użyciu kluczy zarządzanych przez klienta i nie można uzyskać do nich dostępu bez tych kluczy. Jedynym sposobem na zaprzestanie korzystania z CMEK jest utworzenie nowej przestrzeni roboczej — istniejące zaszyfrowane dane pozostaną trwale niedostępne.

Co się dzieje, gdy rotuję mój klucz główny?

Do szyfrowania zostanie wygenerowany nowy materiał kryptograficzny, więc nowe żądania szyfrowania będą używać nowego klucza. Jednak identyfikator KMS (ARN lub nazwa klucza) pozostaje taki sam , a stare dane nadal można odszyfrować. Wielu dostawców chmury oferuje automatyczną rotację kluczy (AWS, GCP, Azure).

Czy OpenAI ponownie szyfruje starsze dane, gdy rotuję mój klucz główny?

Nie. Nowy materiał kryptograficzny będzie używany wyłącznie do szyfrowania nowych danych.

Jak długo trwa, zanim rotacja klucza lub unieważnienie klucza zacznie obowiązywać?

1 godzina. Dzieje się tak, ponieważ DEK/eDEK są buforowane w pamięci, a my co godzinę ponownie walidujemy te wpisy w Twoim KMS.

Zmiana identyfikatora KMS

Czy zmiana identyfikatora KMS to unieważnienie klucza czy rotacja klucza?

Unieważnienie klucza. Jeden klucz nie może odszyfrować danych zaszyfrowanych innym kluczem.

Czy OpenAI może pomóc mi zmienić identyfikator KMS dla przestrzeni roboczej ChatGPT?

Jeśli potwierdzisz, że intencją jest unieważnienie klucza, możemy pomóc Ci to zrobić dla przestrzeni roboczej ChatGPT. Pamiętaj, że po zaktualizowaniu ARN KMS starsze dane pozostaną niedostępne, więc po zmianie będziesz mieć mieszankę danych niedostępnych i dostępnych.

Czy OpenAI może pomóc mi zmienić identyfikator KMS dla projektu API?

Jeśli używasz API, API ułatwia archiwizowanie i tworzenie nowych projektów, więc zamiast tego zarchiwizuj projekt, którego dane i tak nie są dostępne, zarejestruj nową konfigurację EKM w OpenAI i utwórz nowy projekt API z nowym kluczem KMS.

Co jeśli chcę samodzielnie regularnie zmieniać identyfikator KMS?

Nie jest to zalecane, ponieważ prawdopodobnie nie chcesz regularnie unieważniać swojego klucza. Nadal możesz jednak to robić, jeśli korzystasz z dostawcy chmury obsługującego alias klucza KMS (przykład AWS). Możesz zarejestrować ten alias klucza KMS w OpenAI, a następnie u swojego dostawcy chmury w dowolnym momencie podmienić bazowy identyfikator KMS, na który wskazuje alias, aby dokonać unieważnienia klucza.

Zachowanie wersji beta a GA

Czy istnieją jakiekolwiek znane ryzyka lub zmiany na poziomie systemu podczas używania wersji beta szyfrowania w środowisku produkcyjnym?

Środowisko beta jest funkcjonalnie równoważne GA i nie są oczekiwane żadne kroki migracyjne. Główne ryzyko polega na tym, że niektóre funkcje skrajnych przypadków mogą jeszcze nie obsługiwać zaszyfrowanej treści z powodu niekompletnych ścieżek kodu. Są to rzadkie przypadki i są aktywnie usuwane. Dane są w pełni zaszyfrowane i chronione niezależnie od tych potencjalnych problemów.

Czy będą wymagane jakieś kroki migracyjne z wersji beta do GA?

Nie. Przestrzenie robocze korzystające z wersji beta szyfrowania będą automatycznie obsługiwane w GA bez żadnych działań ze strony użytkownika.

Dodatkowe szczegóły techniczne

Szyfrowanie kopertowe i uprawnienia

Czy musimy przyznać OpenAI uprawnienia GenerateDataKey dla EKM?

Nie. OpenAI wymaga tylko uprawnień Encrypt i Decrypt do Twojego klucza KMS. Uprawnienie GenerateDataKey nie jest konieczne do integracji EKM.

Czy OpenAI używa szyfrowania kopertowego dla danych klientów?

Tak. OpenAI używa modelu szyfrowania kopertowego:

• KMS klienta: Zarządza kluczami szyfrowania kluczy (KEK). OpenAI nigdy nie widzi ani nie przechowuje KEK.

• Infrastruktura OpenAI: Generuje i zarządza kluczami szyfrowania danych (DEK). Każdy DEK jest szyfrowany (opakowywany) Twoim KEK przed zapisaniem.

• Przepływ danych:

  • Dane klienta są szyfrowane przy użyciu DEK.

  • Ten DEK jest szyfrowany Twoim KEK, co daje eDEK.

  • eDEK jest przechowywany razem z zaszyfrowanymi danymi.

  • Aby odszyfrować dane, OpenAI wysyła do Twojego KMS żądanie odszyfrowania eDEK, pobiera DEK i odszyfrowuje treść.

Dlaczego OpenAI wybrało ten model zamiast pozwolić KMS zarządzać zarówno KEK, jak i DEK?

Istnieją dwa popularne podejścia do szyfrowania kopertowego:

KEK i DEK zarządzane przez KMS:

Zalety: Prostsza implementacja, brak konieczności utrzymywania infrastruktury szyfrowania.

Wady: Każde żądanie szyfrowania/odszyfrowania trafia do KMS, co zwiększa opóźnienia i koszty oraz wprowadza pojedynczy punkt awarii.

KEK zarządzane przez KMS / DEK zarządzane przez OpenAI (nasze podejście):

Zalety: Znacznie mniejsze opóźnienia i koszty, lepsza skalowalność i niezawodność oraz możliwość dalszego działania podczas częściowych awarii KMS (do czasu TTL pamięci podręcznej DEK).

Wady: Nieco bardziej złożona implementacja po stronie OpenAI.

Taka konstrukcja pozwala OpenAI zapewniać silne gwarancje bezpieczeństwa przy jednoczesnym minimalizowaniu ryzyka operacyjnego i kosztów dla klientów.

Jak często rotowane są klucze DEK?

Każdy klucz DEK jest rotowany mniej więcej co 60 minut. Zapewnia to izolację czasową — nawet gdyby klucz DEK został w jakiś sposób naruszony, wpływ ograniczałby się do danych zaszyfrowanych w tym jednogodzinnym oknie.

Wolumen żądań KMS i obserwowalność

Widzimy znacznie mniej żądań KMS niż wiadomości użytkowników. Czy te liczby powinny się zgadzać?

Nie, nie będą bezpośrednio skorelowane.

Ponieważ OpenAI buforuje klucze DEK w pamięci ze względów wydajnościowych, wywołania KMS są wykonywane tylko wtedy, gdy klucz DEK musi zostać odszyfrowany — nie przy każdej operacji szyfrowania lub odszyfrowania. W rezultacie należy się spodziewać:

• Mniejszej liczby żądań KMS niż interakcji użytkownika.

• Okazjonalnych skoków gdy buforowane klucze DEK wygasają (mniej więcej co godzinę) lub gdy trzeba uzyskać dostęp do starszych zaszyfrowanych danych.

• Dodatkowych wywołań podczas pobierania danych historycznych, na przykład gdy użytkownik kontynuuje długą rozmowę i trzeba załadować starsze klucze DEK.

Dokładna liczba żądań KMS zależy od stanu pamięci podręcznej, zachowania użytkowników, wzorców dostępu do danych i długości rozmowy, dlatego nie będzie bezpośrednio skorelowana z liczbą wiadomości.