Pojęcia związane z szyfrowaniem
Ogólny przebieg
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 DEK do szyfrowania Twoich danych w spoczynku. DEK jest szyfrowany Twoim kluczem głównym, co tworzy eDEK (zaszyfrowany DEK), przechowywany razem z Twoimi danymi
Aby odczytać dane, OpenAI pobiera eDEK, prosi Twój KMS o odszyfrowanie go do DEK, a następnie deszyfruje Twoje dane
Jak działa szyfrowanie EKM?
Szczegółowe informacje znajdziesz w naszym artykule: Omówienie OpenAI Enterprise Key Management (EKM)
Czy OpenAI przechowuje moje DEK?
Nie — przechowujemy zaszyfrowane DEK (eDEK), które są generowane przez Twój KMS. Aby odszyfrować dane, prosimy Twój KMS o odszyfrowanie eDEK z powrotem do DEK.
Czy OpenAI buforuje moje DEK?
Tak — tylko w pamięci operacyjnej. Służy to wydajności, aby unikać odwołań do Twojego KMS przy każdym żądaniu szyfrowania/deszyfrowania danych. DEK nigdy nie są zapisywane w pamięci masowej.
Uprawnienia w chmurze
Jakie uprawnienia OpenAI będzie mieć w moim KMS?
Tylko te uprawnienia, które przyznasz nam w ustawionej przez siebie polityce. Potrzebujemy jedynie co najmniej operacji Encrypt/Decrypt. Utwórz też dla OpenAI nowy klucz w swoim chmurowym KMS, zamiast ponownie używać istniejących kluczy przeznaczonych do zastosowań produkcyjnych.
Kiedy OpenAI otrzymuje uprawnienia dostępu do mojego KMS?
Muszą zostać wykonane wszystkie te kroki:
Uznano tożsamość OpenAI (za pośrednictwem polityki zaufania, tożsamości obciążenia itp., zależnie od dostawcy chmury).
Utworzono politykę dostępu do KMS.
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ć klucz główny w swojej chmurze?
Nie — to Ty decydujesz, jak zarządzać swoim kluczem głównym. Możesz korzystać z rozwiązania zarządzanego w chmurze albo zewnętrznego, w którym klucz jest przechowywany oddzielnie. OpenAI musi jedynie wywoływać operacje encrypt/decrypt w Twoim KMS — faktyczny sposób, w jaki klucz główny wykonuje szyfrowanie/deszyfrowanie, 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ę na ścieżce klucza deszyfrowania (DEK -> eDEK)
Czy muszę coś zrobić, gdy zmienia się DEK?
Nie — rotacja DEK/eDEK odbywa się w OpenAI. Dopóki Twój klucz główny pozostaje ważny, każdy eDEK zaszyfrowany Twoim kluczem głównym może nadal zostać odszyfrowany do DEK, który następnie służy do deszyfrowania Twoich danych.
Rotacja i odwołanie klucza głównego (kontrolowane przez Ciebie)
Jak często odbywa się rotacja klucza i odwołanie klucza?
Określasz to Ty, ponieważ OpenAI nie ma wglądu w Twój klucz główny.
Jaka jest różnica między rotacją klucza a odwołaniem klucza?
Odwołanie 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 odwołam swój klucz główny?
Jeśli klucz zostanie odwołany lub uprawnienia zostaną usunięte, przestrzeń robocza z czasem przestanie działać, gdy wygasną klucze z pamięci podręcznej. Wtedy OpenAI nie będzie już mogło odszyfrowywać przechowywanych danych ani szyfrować nowych. W praktyce dane zostaną „zniszczone”.
Jak szybko odwołanie zaczyna obowiązywać?
OpenAI przechowuje DEK w pamięci podręcznej w pamięci operacyjnej ze względu na wydajność i odporność. Odwołanie zwykle zaczyna obowiązywać w ciągu godziny, gdy wygasną klucze w pamięci podręcznej i ponowna walidacja się nie powiedzie.
Czy można bezpiecznie przetestować odwołanie?
Testowanie odwołania w produkcyjnej przestrzeni roboczej nie jest zalecane, ponieważ trwale uniemożliwi dostęp do istniejących danych. Klienci mogą jednak (i powinni) testować odwołanie w środowisku sandbox, aby sprawdzić poprawne działanie i zweryfikować swoje założenia dotyczące zaufania.
Jeśli klucz zostanie trwale odwołany, czy przestrzeń roboczą można odzyskać przez podłączenie nowego klucza?
Nie. Po utracie klucza danych z założenia nie da się odzyskać. Jedynym rozwiązaniem jest uruchomienie nowej przestrzeni roboczej.
Co 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 odzyska istniejących danych.
Jaki jest plan wycofania, jeśli zdecydujemy się przestać używać CMEK?
Obecnie nie ma planu wycofania. Po utworzeniu przestrzeni roboczej 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 zaprzestania używania CMEK jest utworzenie nowej przestrzeni roboczej — istniejące zaszyfrowane dane pozostaną trwale niedostępne.
Co się stanie, gdy zrotuję swó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ę swój klucz główny?
Nie. Nowy materiał kryptograficzny będzie używany tylko do szyfrowania nowych danych.
Ile czasu zajmuje wejście w życie rotacji klucza lub odwołania klucza?
1 godzinę. Wynika to z tego, że DEK/eDEK są buforowane w pamięci operacyjnej, a my co godzinę ponownie walidujemy te wpisy w Twoim KMS.
Zmiana identyfikatora KMS
Czy zmiana identyfikatora KMS jest odwołaniem klucza czy rotacją klucza?
Odwołaniem 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 celem jest odwołanie Twojego klucza, możemy pomóc Ci zrobić to 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 korzystasz z API, interfejs API ułatwia archiwizowanie i tworzenie nowych projektów. Dlatego 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ę regularnie samodzielnie zmieniać identyfikator KMS?
Nie jest to zalecane, ponieważ prawdopodobnie nie chcesz regularnie odwoływać swojego klucza. Możesz jednak nadal to zrobić, 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 dostawcy chmury w dowolnym momencie podmienić bazowy identyfikator KMS wskazywany przez alias, aby odwołać klucz.
Zachowanie w wersji beta a GA
Czy korzystanie z wersji beta szyfrowania w produkcji wiąże się ze znanymi ryzykami lub zmianami na poziomie systemu?
Środowisko beta jest funkcjonalnie równoważne GA i nie są przewidywane żadne kroki migracji. Główne ryzyko polega na tym, że niektóre funkcje brzegowe mogą jeszcze nie obsługiwać zaszyfrowanych treści z powodu niekompletnych ścieżek kodu. Takie przypadki są rzadkie i aktywnie rozwiązywane. Dane są w pełni zaszyfrowane i chronione niezależnie od tych potencjalnych problemów.
Czy będą wymagane jakieś kroki migracji 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ń użytkownika.
Dodatkowe szczegóły techniczne
Szyfrowanie kopertowe i uprawnienia
Czy musimy przyznać OpenAI uprawnienia GenerateDataKey na potrzeby EKM?
Nie. OpenAI wymaga tylko uprawnień Encrypt i Decrypt do Twojego klucza KMS. Uprawnienie GenerateDataKey nie jest potrzebne 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 przed zapisaniem szyfrowany (opakowywany) Twoim KEK.
Przepływ danych:
Dane klienta są szyfrowane za pomocą DEK.
Ten DEK jest szyfrowany Twoim KEK, co tworzy eDEK.
eDEK jest przechowywany razem z zaszyfrowanymi danymi.
Aby odszyfrować dane, OpenAI prosi Twój KMS o odszyfrowanie eDEK, uzyskuje DEK i deszyfruje treść.
Dlaczego OpenAI wybrało ten model zamiast pozwolić KMS zarządzać zarówno KEK, jak i DEK?
Istnieją dwa typowe podejścia do szyfrowania kopertowego:
KEK i DEK zarządzane przez KMS:
Zalety: prostsze wdrożenie, brak konieczności utrzymywania infrastruktury szyfrowania.
Wady: każde żądanie szyfrowania/deszyfrowania 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 ciągłość działania podczas częściowych awarii KMS (do czasu TTL pamięci podręcznej DEK).
Wady: nieco bardziej złożone wdrożenie po stronie OpenAI.
Ten projekt pozwala OpenAI zapewniać silne gwarancje bezpieczeństwa przy jednoczesnym minimalizowaniu ryzyka operacyjnego i kosztów dla klientów.
Jak często rotowane są DEK?
Każdy DEK jest rotowany mniej więcej co 60 minut. Zapewnia to izolację czasową — nawet gdyby DEK został w jakiś sposób naruszony, wpływ ograniczył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ż ze względów wydajnościowych OpenAI przechowuje DEK w pamięci podręcznej w pamięci operacyjnej, wywołania KMS są wykonywane tylko wtedy, gdy DEK trzeba odszyfrować — nie przy każdej operacji szyfrowania lub deszyfrowania. W rezultacie należy oczekiwać:
Mniejszej liczby żądań KMS niż interakcji użytkowników.
Sporadycznych skoków, gdy wygasają DEK w pamięci podręcznej (mniej więcej co godzinę) albo 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 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 wolumenem wiadomości.