OpenAI
Tato stránka byla přeložena strojově. Zobrazit původní článek v angličtině.

Technické FAQ k EKM

Odpovědi na běžné technické otázky k chování EKM, oprávněním a životnímu cyklu klíčů

Aktualizováno: 2 days ago

Základní pojmy šifrování

Obecný průběh

  • Ve svém cloudu ovládáte hlavní klíč, který OpenAI nikdy nevidí

  • Váš hlavní klíč se používá k šifrování klíčů pro šifrování dat (DEK), které používá OpenAI

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

  • Při čtení dat OpenAI vezme eDEK, požádá váš KMS o jeho dešifrování 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. K dešifrování dat požádáme váš KMS, aby eDEK dešifroval zpět na DEK.

Ukládá OpenAI moje DEK do mezipaměti?

Ano – pouze v paměti. Důvodem je výkon: nechceme zasahovat 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 v mém KMS?

Pouze oprávnění, která nám udělíte prostřednictvím nastavené zásady. Potřebujeme jen alespoň operace Encrypt/Decrypt. Vytvořte prosím pro OpenAI ve svém cloudovém KMS také nový klíč, místo abyste znovu použili existující klíče určené pro produkční účely.

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 (prostřednictvím zásady důvěryhodnosti, identity pracovní zátěže atd. podle poskytovatele cloudu).

  2. Vytvořili jste zásadu pro přístup ke KMS.

  3. Přiřadili jste identitě OpenAI oprávnění k přístupu k této zásadě.

Pokud pouze 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 – záleží na vás, jak budete svůj hlavní klíč spravovat. Můžete použít cloudově spravované řešení nebo externí řešení, ve kterém je klíč uložen samostatně. OpenAI potřebuje pouze volat operace encrypt/decrypt na vašem KMS – to, jak hlavní klíč tyto operace skutečně provádí, je implementační detail, do kterého nevidíme.

Životní cyklus klíčů

Rotace DEK/eDEK (řízená OpenAI)

Jak často se rotují DEK/eDEK?

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

Každou 1 hodinu na cestě dešifrovacího klíče (DEK -> eDEK)

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

Ne – rotace DEK/eDEK probíhá uvnitř OpenAI. Dokud je váš hlavní klíč platný, lze všechny eDEK zašifrované vaším hlavním klíčem nadále dešifrovat na DEK, který se potom použije k dešifrování vašich dat.

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

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

To určujete vy, protože OpenAI nemá do vašeho hlavního klíče viditelnost.

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 ke č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 postupně stane nefunkčním. V té 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 ukládá DEK do mezipaměti v paměti kvůli výkonu a odolnosti. 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 se nedoporučuje, protože trvale znepřístupní stávající data. Zákazníci však mohou (a měli by) odvolání otestovat 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á. Jedinou nápravou je spustit nový pracovní prostor.

Co máme dělat, když se pracovní prostor kvůli změnám klíče stane nedostupným?

Očekávanou nápravou je vytvořit nový pracovní prostor. Aktualizace KMS stávající data neobnoví.

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 šifrována pomocí klíčů spravovaných zákazníkem a bez nich k nim nelze přistupovat. Jediný způsob, jak používání CMEK ukončit, je vytvořit nový pracovní prostor — stávající zašifrovaná data zůstanou trvale nedostupná.

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

Pro šifrování bude vygenerován 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 nadále dešifrovat. Mnoho poskytovatelů cloudu nabízí automatickou rotaci klíčů (AWS, GCP, Azure).

Šifruje OpenAI starší data znovu, když rotuji 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 nebo odvolání klíče projeví?

1 hodinu. Je to proto, že DEK/eDEK jsou ukládány do mezipaměti v paměti a tyto položky každou hodinu znovu ověřujeme u vašeho KMS.

Změna identifikátoru KMS

Je změna identifikátoru KMS odvoláním klíče, nebo rotací klíče?

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

Může mi OpenAI pomoci změnit 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 u pracovního prostoru ChatGPT pomoci. Upozorňujeme, že po aktualizaci ARN KMS zůstanou starší data nedostupná, takže po změně budete mít směs nedostupných a dostupných dat.

Může mi OpenAI pomoci změnit identifikátor KMS pro projekt API?

Pokud používáte API, lze v něm snadno archivovat a vytvářet nové projekty. Proto raději archivujte projekt, jehož data jsou stejně nedostupná, zaregistrujte u OpenAI novou konfiguraci EKM a vytvořte nový projekt API s novým klíčem KMS.

Co když chci svůj identifikátor KMS pravidelně měnit sám?

To se nedoporučuje, 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 pro AWS). Tento alias klíče KMS můžete zaregistrovat u OpenAI a poté u svého poskytovatele cloudu kdykoli vyměnit podkladový identifikátor KMS, na který alias ukazuje, abyste provedli odvolání klíče.

Chování v beta verzi oproti GA

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

Beta prostředí je funkčně ekvivalentní GA a neočekávají se žádné kroky migrace. Hlavním rizikem je, že některé okrajové funkce zatím nemusí podporovat šifrovaný obsah kvůli neúplným cestám v kódu. Tyto případy jsou vzácné a aktivně se řeší. Data jsou plně zašifrovaná a chráněná bez ohledu na tyto potenciální problémy.

Budou potřeba nějaké kroky migrace z beta verze na GA?

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

Další technické podrobnosti

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

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

Ne. OpenAI vyžaduje pro váš klíč KMS pouze oprávnění Encrypt a Decrypt. Oprávnění GenerateDataKey není pro integraci EKM potřeba.

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

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

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

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

  • Tok dat:

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

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

    • eDEK se ukládá společně se zašifrovanými daty.

    • K 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 nechala KMS spravovat KEK i DEK?

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

KEK a DEK spravované službou KMS:

Výhody: Jednodušší implementace, bez nutnosti udržovat šifrovací infrastrukturu.

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

KEK spravované službou KMS / DEK spravované OpenAI (náš přístup):

Výhody: Výrazně nižší latence a náklady, lepší škálovatelnost a spolehlivost a pokračující provoz při částečných výpadcích KMS (až do vypršení 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 rotují DEK?

Každý DEK se rotuje přibližně každých 60 minut. Tím se zajišťuje časová izolace — i kdyby byl DEK nějakým způsobem kompromitován, dopad by byl omezen na data zašifrovaná během daného jednohodinového okna.

Objem požadavků KMS & pozorovatelnost

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

Ne, nebudou spolu přímo korelovat.

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

  • Méně požadavků KMS než uživatelských interakcí.

  • 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 dlouhodobé konverzaci a je nutné načíst starší DEK.

Přesný počet požadavků 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 korelovat s objemem zpráv.

Byl tento článek užitečný?