OpenAI

EKM 技術に関するよくあるご質問

EKM の動作、権限、キーのライフサイクルに関するよくある技術的な質問への回答

更新日: 2 days ago

暗号化の概念

大まかな流れ

  • お客様は、ご自身のクラウド内のマスターキーを管理しており、OpenAI がそれを目にすることはありません

  • お客様のマスターキーは、OpenAI が使用するデータ暗号化キー(DEKs)を暗号化するために使用されます

  • OpenAI は保存時にお客様のデータを暗号化するために DEK を使用します。DEK はマスターキーで暗号化され、eDEK(暗号化された DEK)が生成され、データとともに保存されます

  • データを読み取るために、OpenAI は eDEK を取得し、お客様の KMS にリクエストして DEK に復号し、その後データを復号します

EKM 暗号化はどのように機能しますか?

詳細については、次の記事をご覧ください:OpenAI Enterprise Key Management(EKM)の概要

OpenAI は私の DEK を保存していますか?

いいえ:保存しているのは、お客様の KMS によって生成される暗号化された DEK(eDEK)です。データを復号するために、お客様の KMS に eDEK を DEK に復号するよう依頼します。

OpenAI は私の DEK をキャッシュしますか?

はい。ただし、メモリ内にのみキャッシュされます。これは、データの暗号化/復号化リクエストのたびに KMS へアクセスすることを避け、パフォーマンスを向上させるためです。DEK がストレージに書き込まれることはありません。

クラウド権限

OpenAI は私の KMS に対してどのような権限を持ちますか?

お客様が設定したポリシーを通じて当社に付与される権限のみです。少なくとも暗号化/復号操作が必要です。新しいキーをクラウド KMS で作成し、本番用途の既存のキーを再利用するのではなく、OpenAI 用のキーとして使用してください。

OpenAI は私の KMS にアクセスする権限をいつ取得しますか?

以下の手順をすべて実施している必要があります。1. OpenAI のアイデンティティを認識する(信頼ポリシー、ワークロードアイデンティティなど、クラウドプロバイダーに応じた方法で)。2. KMS にアクセスするためのポリシーを作成する。3. そのポリシーにアクセスする権限を OpenAI のアイデンティティに付与する。これらの手順をすべて実行せずに KMS を作成しただけでは、OpenAI はアクセスできません。

マスターキーをクラウドに保存する必要はありますか?

いいえ。マスターキーの管理方法はお客様にお任せします。クラウド管理のソリューション、またはキーを別途保管する外部ソリューションを選択できます。OpenAI はお客様の KMS で暗号化/復号化操作を呼び出すだけです。実装上の詳細として、マスターキーが実際にどのように暗号化/復号化を行うかは、当社からは分かりません。

鍵のライフサイクル

DEK/eDEK ローテーション(OpenAI によって管理)

DEK/eDEK はどのくらいの頻度でローテーションされますか?

暗号化経路で24時間ごと(DEK/eDEK キーペアをリクエスト)

復号鍵パスについて1時間ごと(DEK -> eDEK)

DEK が変更された場合、何かする必要がありますか?

いいえ、DEK/eDEK のローテーションは OpenAI 社内で行われます。マスターキーが有効である限り、マスターキーで暗号化された eDEK は引き続き DEK に復号され、その DEK を使用してデータが復号されます。

マスターキーのローテーションおよび無効化(お客様による管理)

キーのローテーションやキーの無効化はどのくらいの頻度で行われますか?

これは、お客様のマスターキーを OpenAI が把握していないため、お客様が決定します。

キーのローテーションとキーの無効化の違いとは何でしょうか?

キーの無効化により、古いキーを使用して暗号化されたデータへのアクセスが無効になります。キーのローテーションでは、新しいキーを使用してデータを暗号化しますが、古いデータへの読み取りアクセスは維持されます。

マスターキーを取り消した場合、どうなりますか?

キーが取り消された場合や、権限が削除された場合、キャッシュされたキーの有効期限が切れると、ワークスペースは最終的に機能しなくなります。その時点で、OpenAI は保存されたデータを復号することも、新しいデータを暗号化することもできなくなります。実質的に、データは「断片化」されています。

無効化はどのくらいの時間で有効になりますか?

OpenAI は、パフォーマンスとレジリエンスのために、DEK をメモリ内にキャッシュします。キャッシュされたキーの有効期限が切れ、再検証が失敗すると、通常、無効化は1時間以内に有効になります。

無効化は安全にテストできますか?

本番環境のワークスペースで無効化をテストすることは、既存のデータに永久にアクセスできなくなるため、推奨されません。ただし、顧客は、正しく動作することを確認し、信頼に関する前提を検証するために、サンドボックス環境で無効化をテストできます(また、テストすべきです)。

キーが永久に無効化された場合、新しいキーを関連付けることでワークスペースを復旧することは可能ですか?

いいえ。キーが失われると、設計上、データを復元することはできません。唯一の対処法は、新しいワークスペースを作成することです。

キーの変更が原因でワークスペースにアクセスできなくなった場合は、どうすればよいですか?

想定される対処は、新しいワークスペースを作成することです。KMS を更新しても、既存のデータは復元されません。

CMEK の使用を停止することにした場合、ロールバック計画はどうなりますか?

現在、ロールバック計画はありません。ワークスペースが CMEK で作成されると、関連するすべてのデータは顧客管理のキーを使用して暗号化され、それらのキーなしではアクセスできません。CMEK の使用を停止する唯一の方法は、新しいワークスペースを作成することです。既存の暗号化されたデータには今後永久にアクセスできなくなります。

マスターキーを変更するとどうなりますか?

暗号化用の新しい暗号化マテリアルが生成されるため、新しい暗号化リクエストでは新しいキーが使用されます。ただし、KMS 識別子(ARN またはキー名)は変わりません。また、古いデータも引き続き復号できます。多くのクラウドプロバイダーでは、自動キーローテーション(AWSGCPAzure)を提供しています。

マスターキーをローテーションした場合、OpenAI は古いデータを再暗号化しますか?

いいえ。新しい暗号化情報は、新しいデータの暗号化にのみ使用されます。

キーのローテーションまたはキーの無効化が反映されるまで、どのくらい時間がかかりますか?

1時間です。これは、DEK/eDEK がメモリ内にキャッシュされており、1時間ごとにお客様の KMS を使用してこれらのエントリを再検証するためです。

KMS 識別子の切り替え

KMS 識別子を切り替えるのは、キーの無効化(取り消し)ですか、それともキーのローテーションですか?

キーの無効化。1つのキーで、別のキーで暗号化されたデータを復号することはできません。

OpenAI は ChatGPT ワークスペースの KMS 識別子を変更するのに役立ちますか?

キーの無効化をご希望の場合は、ChatGPT ワークスペースでその手続きをお手伝いします。注:KMS ARN が更新されると、古いデータには引き続きアクセスできないため、変更後はアクセスできるデータとアクセスできないデータが混在することになります。

OpenAI は API プロジェクトの KMS 識別子を切り替えるのを支援できますか?

API を使用している場合、API を使うとプロジェクトのアーカイブや新しいプロジェクトの作成が簡単に行えます。そのため、データにアクセスできないプロジェクトをアーカイブし、OpenAI に新しい EKM config を登録して、新しい KMS key を使用して新しい API プロジェクトを作成してください。

KMS 識別子を自分で定期的に切り替えたい場合はどうすればよいですか?

これはお勧めしません。おそらく定期的にキーを失効させたいとは思わないためです。ただし、KMS キーエイリアスをサポートするクラウドプロバイダーを使用する場合は、これを行うことは可能です(AWS の例)。その KMS キーエイリアスを OpenAI に登録しておけば、クラウドプロバイダー側で、そのエイリアスが参照する基盤となる KMS 識別子をいつでも切り替えて、キーの無効化を実行できます。

ベータ版と GA(一般公開)の動作

暗号化ベータ版を本番環境で使用する場合、既知のリスクやシステムレベルの変更はありますか?

ベータ環境は GA と機能的に同等で、移行手順は不要となる見込みです。主なリスクは、コードパスが未整備なため、一部のエッジケースでは暗号化されたコンテンツがまだサポートされない可能性があることです。これらはまれで、現在も積極的に解消を進めています。こうした潜在的な問題にかかわらず、データは完全に暗号化され保護されています。

ベータ版から GA 版への移行手順はありますか?

いいえ。暗号化ベータ版を利用しているワークスペースは、ユーザーによる操作なしで、GA でも自動的にサポートされます。

追加の技術詳細

エンベロープ暗号化と権限

EKM のために OpenAI に GenerateDataKey のアクセス許可を付与する必要がありますか?

いいえ。OpenAI が必要とするのは、お使いの KMS キーに対する Encrypt 権限と Decrypt 権限のみです。EKM 連携には、GenerateDataKey 権限は必要ありません。

OpenAI は顧客データにエンベロープ暗号化を使用しますか?

はい、OpenAI はエンベロープ暗号化モデルを使用しています。

  • Customer KMSキー暗号化キー(KEK)を管理します。OpenAI が KEK を見ることも保存することもありません。

  • OpenAI インフラストラクチャデータ暗号化キー(DEK)を生成し、管理します。各 DEK は、保存前にお客様の KEK で暗号化(ラップ)されます。

  • データフロー

    • 顧客データは DEK を使用して暗号化されます。

    • そのDEKはお客様のKEKで暗号化され、eDEK が生成されます。

    • eDEK は、暗号化されたデータとともに保存されます。

    • データを復号するために、OpenAI はお客様の KMS に eDEK の復号をリクエストし、DEK を取得してコンテンツを復号します。

OpenAI が KMS に KEK と DEK の両方を管理させるのではなく、このモデルを選んだのはなぜですか?

一般的なエンベロープ暗号化方式は2つあります。

KMS によって管理される KEK と DEK:

利点:実装が簡単で、暗号化インフラを維持する必要がありません。

欠点:すべての暗号化/復号リクエストが KMS に送られるため、レイテンシーとコストが増加し、単一障害点も生じます。

KMS 管理の KEK / OpenAI 管理の DEK(当社のアプローチ):

利点:レイテンシーとコストを大幅に削減し、スケーラビリティと信頼性を向上させ、KMS の部分的な障害時でも継続運用が可能です(DEK キャッシュの TTL まで)。

欠点:OpenAI 側での実装がやや複雑です。

この設計により、OpenAI は、顧客にとっての運用リスクとコストを最小限に抑えながら、強力なセキュリティ保証を提供できます。

DEK はどのくらいの頻度で交換されますか?

各 DEK は約60分ごとにローテーションされます。これにより時間的分離が実現され、万が一 DEK が侵害されたとしても、影響はその1時間の枠内で暗号化されたデータに限定されます。

KMS リクエスト数&可観測性

KMS リクエストの数は、ユーザーメッセージの数よりも大幅に少ないです。これらの数値は一致するべきですか?

いいえ、直接相関することはありません。

OpenAI はパフォーマンス上の理由から DEK をメモリ内にキャッシュしているため、KMS の呼び出しは、DEK を復号する必要がある場合にのみ行われ、すべての暗号化または復号操作のたびに行われるわけではありません。その結果、次のことが予想されます:

  • ユーザー操作より少ない KMS リクエスト。

  • キャッシュされた DEK の有効期限が切れるとき(約1時間ごと)、または古い暗号化データにアクセスする必要がある場合に発生する一時的なスパイク

  • 履歴データを取得する際、たとえばユーザーが長時間にわたる会話を継続し、古い DEK を読み込む必要がある場合の追加の呼び出し

KMS リクエストの正確な数は、キャッシュの状態、ユーザーの行動、データアクセスパターン、会話の長さによって左右されるため、メッセージ量と直接相関するわけではありません。

この記事は役に立ちましたか?