設計段階からのプライバシー
データベースで強制される分離、ユーザーごとの鍵によるフィールドレベル暗号化、そしてエンドツーエンド層が何を与え、何を与えないかについての正直な説明。
このページは検証されることを前提に書かれています。他人の法務・移民・医療の案件を扱うなら、以下の主張はいずれあなたのクライアントが裏付けを求めてくるものです。
2つの独立した境界
同じ行に対する2つの独立した保証 — どちらも他方が成立していることに依存しません。
分離はアプリケーションコードではなく、データベースによって強制されます。 行レベルセキュリティ（Row-level security）により、フィルターを忘れたクエリは他人の行ではなく、何も返しません。アプリケーションレベルのスコープ制御は、WHERE を1つ忘れればデータ漏洩まで一歩です。これはまったく別種の保証であり、プラットフォームが境界をそこに置いている理由です。
暗号化はそれとは独立しています。 データベースにアクセスできても、会話とドキュメントの内容は暗号文です。
エンベロープ
暗号化されたフィールドは固定のレイアウトで保存されます。
Not to scale. 実際には暗号文が大半を占め、ヘッダーのフィールドはわずか数バイトです。
この形から2つの帰結が生まれます。
鍵はマイグレーションなしでローテーションできます。 バージョンが暗号文とともに移動するので、1人のユーザーが複数のデータ暗号化鍵を同時に保持できます。新規の書き込みはアクティブな鍵を使い、読み取りはその暗号文が書かれた鍵を選びます。ローテーションは全停止のイベントではなく、段階的な再暗号化になります。これは重要です。ダウンタイムを要するローテーション方式は、結局一度も実行されない傾向があるからです。
暗号文は移し替えられません。 AEADの追加認証データ（AAD）が、各値をその (tenant, user, space, field) に束縛します。暗号文を別の行、別のフィールド、別のテナントのレコードにコピーすると、内容を静かに明かすのではなく、復号に失敗します。だからデータベースレベルの改ざんの試みがデータ漏洩になることはありません。
鍵の在り処
各ユーザーのデータ暗号化鍵は、鍵暗号化鍵（KEK）でラップされ、鍵プロバイダーの抽象化の背後にあります。現在の実装はアプリケーションのシークレットからKEKを読み取ります。この継ぎ目が存在するのは、KMS、ボールト、あるいはテナントごとのbring-your-own-keyを、データモデルや呼び出し側のコードを変えずに、設定だけで導入できるようにするためです。
現状について正確に言えば、今日KEKを保持しているのはアプリケーションです。それは現在のデプロイには適切ですが、顧客管理鍵と同じものではありません。
あらゆるホスト型エージェントの限界と、その対処
機微な会話にはエンドツーエンド層を追加できます。クライアントが一時的なECDH（P-256）公開鍵を送り、サーバーがECDHとHKDFでセッション鍵を導出し、ストリーミングされる各チャンクがAES-GCMで暗号化され、ブラウザで復号されます。これはTLSに加えて、ストリーミング層での露出を減らします。
これはゼロ知識ではなく、どんなホスト型エージェントもゼロ知識にはなり得ません。 これは実装ではなく問題そのものの性質なので、はっきり述べる価値があります。ナレッジベースから検索するには、サーバーがあなたのコンテンツを埋め込んで比較しなければならず、回答するには、取得した一節から生成しなければなりません。素材を読めないシステムは、それを検索することも、それに基づいて回答することもできません。「ゼロ知識のナレッジベース」は矛盾であり、その両方を提供すると謳うベンダーは、どちらかをいい加減に説明しています。
だから正直な捉え方は、運営者がコンテンツを読めるかどうかではなく、運営者が誰なのかです。
私たちのクラウドでは、露出を最小化します
- コンテンツはユーザーごとの鍵で保存時に暗号化されます。データベースのダンプからは読めるものは何も得られません。
- 分離はアプリケーションコードではなく、データベースによって強制されます。
- モデルへ渡るのは、現在のメッセージ、そのために取得された一節、そのエンドユーザーのメモリだけです。ナレッジベースをまとめて渡すことも、他のユーザーのデータを渡すこともありません。
- エンドツーエンド層が応答ストリームを保護します。
これは露出の意味ある削減です。しかしそれは、私たちが会話を読めないということと同じではありません。それをクライアントの監査人からではなく、私たちから聞いてほしいのです。
要件が絶対的なら、自分で運用してください
コンテンツが本当に第三者に届いてはならないという義務があるなら、答えはより強力な暗号化の主張ではなく、私たちが経路にいないデプロイです。
このプラットフォームは、**あなたが管理するインフラ（あなた自身のクラウドアカウントを含む）**にデプロイでき、モデルのエンドポイントをあなたがホストするモデルに向けられます。その構成では、あなたのドキュメントと会話はネットワークから決して外に出ず、アクセスできる運営者はあなたです。共有キャパシティより費用はかかります。それがトレードオフです。コンプライアンスは形容詞ではなくインフラで買うものなのです。
専用デプロイのスコープ・運用・課金の仕組みについてはエンタープライズプランをご覧ください。
モデルへ渡るもの
メッセージへの回答時にモデルへ送られるのは、そのメッセージ、そのために取得された一節、そしてそのエンドユーザーについて取得されたメモリです。ナレッジベース全体ではなく、他のユーザーのデータでもありません。検索は、何かが組み立てられる前にスペースへスコープされています。
自前のモデルプロバイダーを設定した場合、コンテンツはあなたとそのプロバイダーとの取り決めのもとでそのプロバイダーへ渡り、彼らの保持・学習の条件が適用されます。それは私たちではなくあなたの契約であり、読んでおく価値があります。
削除
ドキュメントを削除すると、派生したメモリへの寄与も取り除かれます。元ソースより長生きしたメモリを通じて内容が復元可能なまま残ることはありません。保持期間とアカウント閉鎖時の削除経路はプライバシーポリシーに、法人顧客向けの処理に関するコミットメントはDPAにあります。
これが実務上意味すること
- クエリのバグが他の顧客の会話を露出させることはできません。データベースが拒否するからです。
- 盗まれたデータベースのダンプから、読めるコンテンツは得られません。
- 鍵は通常運用の中でローテーションできるので、ローテーションが実際に行われます。
- エンドツーエンドの選択肢は本物ですが、限界があります。要件が絶対的な場合は、共有デプロイについてより強い主張をするのではなく、デプロイモデルこそが答えです。