Koncepty šifrování

Tok na vysoké úrovni

• Ve svém cloudu spravujete hlavní klíč, který OpenAI nikdy nevidí

• Váš hlavní klíč se používá k šifrování datových šifrovacích klíčů (DEK), které používá OpenAI

• OpenAI používá DEK k šifrování vašich neaktivních dat. DEK je zašifrován vaším hlavním klíčem, čímž vzniká eDEK (zašifrovaný DEK), který se ukládá spolu s vašimi daty

• Pro čtení dat OpenAI vezme eDEK, požádá váš KMS o jeho dešifrování zpět na DEK a poté dešifruje vaše data

Jak funguje šifrování EKM?

Podrobné informace najdete v našem článku: Přehled OpenAI Enterprise Key Management (EKM)

Ukládá OpenAI moje DEK?

Ne — ukládáme zašifrované DEK (eDEK), které generuje váš KMS. Abychom mohli data dešifrovat, požádáme váš KMS, aby eDEK dešifroval zpět na DEK.

Uchovává OpenAI moje DEK v mezipaměti?

Ano — pouze v paměti. Je to kvůli výkonu, abychom nemuseli oslovovat váš KMS při každém požadavku na šifrování/dešifrování dat. DEK se nikdy nezapisují do úložiště.

Cloudová oprávnění

Jaká oprávnění bude mít OpenAI k mému KMS?

Pouze ta oprávnění, která nám udělíte prostřednictvím zásad, které nastavíte. Potřebujeme minimálně operace Encrypt/Decrypt. V cloudovém KMS také prosím vytvořte pro OpenAI nový klíč namísto opětovného použití jakýchkoli existujících klíčů, které slouží produkčním účelům.

Kdy OpenAI získá oprávnění k přístupu k mému KMS?

Musí být provedeny všechny tyto kroky: 1. rozpoznali jste identitu OpenAI (pomocí zásad důvěry, identity úlohy apod. podle poskytovatele cloudu), 2. vytvořili jste zásadu pro přístup ke KMS a 3. přiřadili jste identitě OpenAI oprávnění k přístupu k této zásadě. Pokud jen vytvoříte KMS bez provedení všech těchto kroků, OpenAI přístup nemá.

Musím svůj hlavní klíč ukládat ve svém cloudu?

Ne — je na vás, jak budete svůj hlavní klíč spravovat. Můžete mít řešení spravované cloudem nebo externí řešení, kde je váš klíč uložen odděleně. OpenAI jen potřebuje volat operace šifrování/dešifrování na vašem KMS — jak hlavní klíč ve skutečnosti šifrování/dešifrování provádí, je detail implementace, do kterého nevidíme.

Životní cyklus klíčů

Rotace DEK/eDEK (řízená OpenAI)

Jak často se DEK/eDEK rotují?

Každých 24 hodin na cestě šifrování (při vyžádání páru klíčů DEK/eDEK)

Každou 1 hodinu pro cestu dešifrovacího klíče (DEK -> eDEK)

Musím něco dělat, když se DEK změní?

Ne — rotace DEK/eDEK probíhá v rámci OpenAI. Dokud váš hlavní klíč zůstává platný, lze jakékoli eDEK zašifrované vaším hlavním klíčem nadále dešifrovat na DEK, který se pak používá k dešifrování vašich dat.

Rotace a odvolání hlavního klíče (řízené vámi)

Jak často dochází k rotaci klíče a odvolání klíče?

Určujete to vy, protože OpenAI nemá přehled o vašem hlavním klíči.

Jaký je rozdíl mezi rotací klíče a odvoláním klíče?

Odvolání klíče odebere přístup k datům zašifrovaným pomocí starších klíčů. Rotace klíče šifruje data pomocí nového klíče, ale zachovává přístup pro čtení starších dat.

Co se stane, když odvolám svůj hlavní klíč?

Pokud je klíč odvolán nebo jsou odebrána oprávnění, pracovní prostor se po vypršení platnosti klíčů v mezipaměti nakonec stane nefunkčním. V tu chvíli už OpenAI nemůže dešifrovat uložená data ani šifrovat nová data. Data jsou tím fakticky „skartována“.

Jak rychle se odvolání projeví?

OpenAI kvůli výkonu a odolnosti uchovává DEK v paměťové mezipaměti. Odvolání se obvykle projeví do jedné hodiny, jakmile vyprší platnost klíčů v mezipaměti a opětovné ověření selže.

Lze odvolání bezpečně otestovat?

Testování odvolání v produkčním pracovním prostoru nedoporučujeme, protože tím trvale znepřístupníte existující data. Zákazníci však mohou (a měli by) testovat odvolání v sandboxovém prostředí, aby ověřili správné chování a potvrdili své předpoklady důvěry.

Pokud je klíč trvale odvolán, lze pracovní prostor obnovit připojením nového klíče?

Ne. Jakmile je klíč ztracen, data jsou záměrně neobnovitelná. Jediným řešením je vytvořit nový pracovní prostor.

Co bychom měli dělat, pokud se pracovní prostor stane kvůli změnám klíče nepřístupným?

Očekávaným řešením je vytvoření nového pracovního prostoru. Aktualizace KMS neobnoví existující data.

Jaký je plán návratu, pokud se rozhodneme přestat používat CMEK?

V současnosti žádný plán návratu neexistuje. Jakmile je pracovní prostor vytvořen s CMEK, všechna související data jsou zašifrována pomocí zákazníkem spravovaných klíčů a bez nich k nim nelze přistupovat. Jediný způsob, jak přestat CMEK používat, je vytvořit nový pracovní prostor — existující zašifrovaná data zůstanou trvale nepřístupná.

Co se stane, když otočím svůj hlavní klíč?

Pro šifrování se vygeneruje nový kryptografický materiál, takže nové požadavky na šifrování budou používat nový klíč. Identifikátor KMS (ARN nebo název klíče) však zůstává stejný a starší data lze stále dešifrovat. Mnoho poskytovatelů cloudových služeb nabízí automatickou rotaci klíčů (AWS, GCP, Azure).

Přešifruje OpenAI starší data znovu, když otočím svůj hlavní klíč?

Ne. Nový kryptografický materiál se použije pouze k šifrování nových dat.

Jak dlouho trvá, než se rotace klíče nebo odvolání klíče projeví?

1 hodinu. Důvodem je, že DEK/eDEK jsou ukládány v paměťové mezipaměti a tyto položky znovu ověřujeme u vašeho KMS každou hodinu.

Přepnutí identifikátoru KMS

Je přepnutí identifikátoru KMS odvolání klíče, nebo rotace klíče?

Odvolání klíče. Jeden klíč nemůže dešifrovat data zašifrovaná jiným klíčem.

Může mi OpenAI pomoci přepnout identifikátor KMS pro pracovní prostor ChatGPT?

Pokud potvrdíte, že záměrem je odvolat váš klíč, můžeme vám s tím pro pracovní prostor ChatGPT pomoci. Upozorňujeme, že při aktualizaci ARN KMS zůstanou starší data nepřístupná, takže po změně budete mít kombinaci nepřístupných a přístupných dat.

Může mi OpenAI pomoci přepnout identifikátor KMS pro projekt API?

Pokud používáte API, API usnadňuje archivaci a vytváření nových projektů, proto místo toho archivujte projekt, jehož data stejně nejsou přístupná, zaregistrujte u OpenAI novou konfiguraci EKM a vytvořte nový projekt API s novým klíčem KMS.

Co když chci pravidelně přepínat svůj identifikátor KMS sám?

To nedoporučujeme, protože pravděpodobně nechcete svůj klíč pravidelně odvolávat. Přesto to můžete udělat, pokud používáte poskytovatele cloudu, který podporuje alias klíče KMS (příklad AWS). Tento alias klíče KMS můžete zaregistrovat u OpenAI a pak můžete u svého poskytovatele cloudu kdykoli vyměnit podkladový identifikátor KMS, na který alias ukazuje, a tím provést odvolání klíče.

Chování beta vs. GA

Existují při používání beta verze šifrování v produkci nějaká známá rizika nebo změny na úrovni systému?

Prostředí beta je funkčně ekvivalentní GA a nepředpokládají se žádné migrační kroky. Hlavním rizikem je, že některé funkce okrajových případů zatím nemusí podporovat zašifrovaný obsah kvůli neúplným částem kódu. Tyto případy jsou vzácné a aktivně je řešíme. Data jsou bez ohledu na tyto potenciální problémy plně zašifrovaná a chráněná.

Budou při přechodu z beta verze do GA nutné nějaké migrační kroky?

Ne. Pracovní prostory používající beta verzi šifrování budou v GA automaticky podporovány bez jakékoli akce uživatele.

Další technické podrobnosti

Obálkové šifrování a oprávnění

Musíme OpenAI pro EKM udělit oprávnění GenerateDataKey?

Ne. OpenAI vyžaduje na vašem klíči KMS pouze oprávnění Encrypt a Decrypt. Oprávnění GenerateDataKey není pro integraci EKM nutné.

Používá OpenAI pro zákaznická data obálkové šifrování?

Ano. OpenAI používá model obálkového šifrování:

• Zákaznický KMS: Spravuje klíče pro šifrování klíčů (KEK). OpenAI KEK nikdy nevidí ani neukládá.

• Infrastruktura OpenAI: Generuje a spravuje datové šifrovací klíče (DEK). Každý DEK je před uložením zašifrován (zabalen) vaším KEK.

• Tok dat:

  • Zákaznická data jsou zašifrována pomocí DEK.

  • Tento DEK je zašifrován vaším KEK, čímž vznikne eDEK.

  • eDEK je uložen spolu se zašifrovanými daty.

  • Pro dešifrování dat OpenAI požádá váš KMS o dešifrování eDEK, získá DEK a dešifruje obsah.

Proč OpenAI zvolila tento model místo toho, aby KMS spravoval jak KEK, tak DEK?

Existují dva běžné přístupy k obálkovému šifrování:

KMS spravuje KEK i DEK:

Výhody: Jednodušší implementace, není nutné udržovat šifrovací infrastrukturu.

Nevýhody: Každý požadavek na šifrování/dešifrování zasahuje KMS, což zvyšuje latenci, náklady a zavádí jeden bod selhání.

KMS spravuje KEK / OpenAI spravuje DEK (náš přístup):

Výhody: Výrazně nižší latence a náklady, lepší škálovatelnost a spolehlivost a pokračování provozu během částečných výpadků KMS (až do TTL mezipaměti DEK).

Nevýhody: O něco složitější implementace na straně OpenAI.

Tento návrh umožňuje OpenAI poskytovat silné bezpečnostní záruky a zároveň minimalizovat provozní riziko a náklady pro zákazníky.

Jak často se DEK rotují?

Každý DEK se rotuje přibližně každých 60 minut. To poskytuje časovou izolaci — i kdyby byl DEK nějak kompromitován, dopad by byl omezen na data zašifrovaná v tomto hodinovém okně.

Objem požadavků na KMS a pozorovatelnost

Vidíme mnohem méně požadavků na KMS než je počet zpráv uživatelů. Měla by se tato čísla shodovat?

Ne, přímo korelovat nebudou.

Protože OpenAI z výkonnostních důvodů uchovává DEK v paměťové mezipaměti, volání KMS se provádějí pouze tehdy, když je potřeba DEK dešifrovat — ne při každé operaci šifrování nebo dešifrování. V důsledku toho byste měli očekávat:

• Méně požadavků na KMS než interakcí uživatelů.

• Občasné špičky, když vyprší platnost DEK v mezipaměti (přibližně každou hodinu) nebo když je potřeba přistupovat ke starším zašifrovaným datům.

• Další volání při načítání historických dat, například když uživatel pokračuje v dlouhotrvající konverzaci a je nutné načíst starší DEK.

Přesný počet požadavků na KMS závisí na stavu mezipaměti, chování uživatelů, vzorcích přístupu k datům a délce konverzace, a proto nebude přímo odpovídat objemu zpráv.