プライベートRAGシステムは、保存時に復号せず暗号化されたドキュメントを検索できますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Can a Private RAG System Search Encrypted Documents Without Decrypting Them at Rest?

「保存時に復号しない」が、ドキュメントをストレージ上では暗号化したままにし、インデックス作成や取得が必要なときだけ信頼されたプロセス内で復号するという意味であれば、可能です。これはプライベートなホームRAGシステムにとって現実的な設計です。ただし通常のセマンティック検索では、埋め込みモデルに不透明な暗号文をそのまま渡してドキュメントを理解させることはできません。

したがって実用的なアーキテクチャは、保存時の暗号化ストレージ、メモリ内での制御された復号、暗号化またはアクセス制御された派生インデックス、そして厳格な鍵の分離で構成されます。暗号文を直接検索することは、特殊な暗号技術を使えば可能ですが、それらの技術は通常のベクトルデータベースの代替としてそのまま利用できるものではありません。

「保存時に暗号化」されていることは「決して復号されない」ことを意味しない

保存時暗号化は、ファイルがディスク、SSD、バックアップ先、または電源オフのデバイスに保存されている間、ファイルを保護します。正しい鍵を持つプロセスは、正当な処理が必要になったときにデータを復号できます。

ディスク上の暗号化ドキュメント
          |
          | 認証済みの読み取り
          v
信頼されたRAGプロセスのメモリ
  ├─ 復号
  ├─ 解析／チャンク化
  ├─ 埋め込み
  └─ 取得
          |
          v
暗号化インデックス／保護されたデータベース

これは、多くの暗号化データベースやファイルシステムの仕組みに似ています。ストレージ媒体には有用な平文は存在しませんが、アプリケーションは認証後に平文を参照できます。

これは、NAS上のプライベートAIアシスタントと互換性のある設計です。重要なのは、平文の存在を許可する場所と期間を定義することです。

通常のベクトル検索で生の暗号文を検索できない理由

埋め込みモデルには、意味のあるテキスト、画像、または音声の特徴が必要です。従来の暗号化は、暗号文がモデルに必要な意味的関係を保持しないよう、目に見えるパターンを意図的に破壊します。

2つの平文の文が類似している場合、それらを安全に暗号化した暗号文も、都合よく類似して見えてはなりません。そうでなければ、元の内容に関する情報が漏洩します。

したがって、通常のRAG取り込みパスでは次の処理を行います。

プロセスを認証します。
ドキュメントをメモリまたは厳格に管理された一時領域に復号します。
コンテンツを抽出して正規化します。
チャンクと埋め込みを作成します。
派生した検索データは、専用の保護ポリシーの下で保存します。
取り込みが完了したら、一時的な平文を破棄してください。

「暗号化されたドキュメントは保存時も暗号化されたままである」という表現は、このワークフロー全体を通じて依然として真実であり得ます。平文をディスク上の永続ファイルにする必要がないからです。

埋め込みベクトルは元のドキュメントと同じではない――それでも機密性がある

よくある誤りは、PDFを暗号化しながら、埋め込みベクトル、チャンクテキスト、ファイル名、メタデータ、ベクトルデータベースのスナップショットを保護しないことです。これではプライバシーの問題を解決するのではなく、別の場所へ移しているだけです。

アーティファクト	情報を明らかにする可能性があるか？	推奨される取り扱い
元のファイル	はい、直接的に	保存時に暗号化する
抽出されたチャンクテキスト	はい、直接的に	暗号化するか、永続的な平文を避ける
埋め込みベクトル	意味的な派生データとして、場合によっては該当する	機密データとして保護する
ファイル名／タグ	多くの場合	最小限に抑え、アクセス制御を行う
ベクトルインデックス	関係性や所属を明らかにする可能性がある	ストレージを暗号化し、アクセスを制限する
バックアップ／スナップショット	過去のコピーを含む	個別に暗号化する

Qdrantの最新のセキュリティドキュメントでは、セルフホスト型のデプロイを明示的に保護する必要があると強調されています。自己管理環境におけるストレージの暗号化はインフラの責任であり、データベースがローカルにあるからといって当然に安全だと考えるべきではありません。

プライベート検索システムでは、埋め込みベクトルを無害なキャッシュファイルではなく、保護対象のナレッジベースの一部として扱ってください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

復号キーはどこに置くべきか？

復号キーを、暗号化されたドキュメントの隣にある、誰でも読み取り可能な設定ファイルへ保存しないでください。ディスクの盗難やバックアップのコピーだけではデータを復元できないようにすることが目的です。

より強固なホームラボ設計では、以下を分離します。

データボリューム：暗号化されたドキュメントとデータベースファイル；
キーマテリアル：OSのキーリング、ハードウェアで保護された鍵ストレージ、または別途保護されたシークレットストア；
サービスID：RAGプロセスには必要なキーだけを渡す；
バックアップキー：暗号化されたバックアップの唯一のコピーとは別の場所に保管する；

ディスク暗号化だけでは、完全にロック解除された稼働中のサーバーが管理者権限レベルで侵害されるのを防げません。ディスク暗号化が防ぐのは別の脅威、つまり盗難ドライブ、オフラインコピー、廃棄されたハードウェア、バックアップメディアへの不正アクセスです。

平文の一時ファイルを防ぐには？

多くのドキュメントパーサーは、気付かないうちに一時ファイルを作成します。OCRパイプラインはページを展開することがあり、オフィスコンバーターは中間形式を書き出すことがあり、PDFツールは抽出したアセットをキャッシュすることがあります。

取り込み経路を監査し、次の3つのパターンのいずれかを選択してください。

復号したバイト列をパーサーへ直接ストリーミングする。
中間ファイルにはRAMベースの一時ファイルシステムを使用する。
一時ストレージを暗号化ボリューム上に置き、処理直後に削除する。

ログも確認してください。文書本文、プロンプト、取得したチャンク、ツールの引数を出力する「デバッグ」ログは、ナレッジベースの最大の非暗号化コピーになり得ます。

準同型暗号によって、復号せずに文書を検索できるのか？

準同型暗号は、暗号化されたデータに対して計算したいときに、多くの人が最初に検討する技術です。MicrosoftのSEALドキュメントでは、準同型方式を使うと、値を暗号化したまま特定の計算を実行できると説明されています。

ただし、重要な制約も示されています。準同型暗号には大きなパフォーマンスオーバーヘッドがあり、効率的にサポートできる操作も限られています。Microsoft SEALは、暗号化された加算や乗算などの算術演算をサポートしていますが、一般的な比較、ソート、正規表現は、平文計算と同じようには通常実用的ではありません。

CKKSなどの方式を使えば近似距離計算を構築できるため、プライバシー保護型ベクトル検索の研究は実際に進められています。しかし、だからといって、Qdrant、pgvector、Weaviateをインストールして「暗号化クエリ」フラグを有効にするだけで、暗号化された意味検索が実現するわけではありません。

アプローチ	家庭向けRAGの実用性	主なトレードオフ
暗号化ディスク + メモリ内復号	高	実行中のプロセスは平文にアクセスできる
暗号化されたデータベースボリューム	高	ストレージは保護するが、侵害された実行環境は保護しない
検索可能暗号 / 準同型暗号	特殊用途	複雑さ、漏えいモデル、パフォーマンス
暗号文を通常のベクトルDBにアップロード	役に立たない	意味構造は残らない

より安全なプライベートRAG設計

ほとんどの家庭や小規模チームでは、セキュリティと複雑さのバランスが最も良い構成は次のようになります。

暗号化されたNASデータセット
      |
      | サービス専用キー
      v
RAG取り込みコンテナ
      |
      +-- メモリ内のみ平文 / 暗号化された一時データ
      |
      +-- 埋め込み + メタデータ
      v
暗号化されたベクトルDBボリューム
      |
      v
ローカル検索サービス
      |
      | 取得するチャンクの最小数
      v
ローカルモデルまたは承認済みのクラウドモデル

クラウドモデルが関与する場合、ストレージは完全に暗号化されたままでも、検索されたテキストがプロンプト内で自宅の外部に送信される可能性があります。ストレージ暗号化とデータ送信制御は別の問題です。ローカルAIの信頼境界ガイドが役立ちます。データを復号できるコンポーネントに、送信も自動的に許可してはいけません。

プライベートRAG暗号化チェックリスト

ソースドキュメントのボリュームを暗号化してください。
ベクトルデータベースのストレージ、スナップショット、バックアップも保護してください。
鍵は通常のドキュメントディレクトリの外部に保管してください。
RAGサービスには、必要最小限の鍵とパスへのアクセス権だけを付与してください。
平文の抽出キャッシュを永続化しないでください。
OCR、変換、デバッグ用の一時ディレクトリを確認してください。
デフォルトでは、検索されたプライベートなチャンクをログに記録しないでください。
ローカル検索の権限とクラウドへの送信権限を分離してください。
暗号鍵をローテーションまたは削除する前に、復旧をテストしてください。

ドキュメント検索とRAGのガイドは、抽出、チャンク分割、埋め込み、検索にこのセキュリティレイヤーを組み込む方法を整理するのに役立ちます。

よくある質問

ベクトルデータベースでAES暗号化されたPDFを直接インデックス化できますか？

いいえ。通常のテキストまたはマルチモーダル埋め込みモデルが意味を抽出する前に、コンテンツを承認済みのプロセスが復号する必要があります。

フルディスク暗号化で稼働中のRAGサーバーは保護できますか？

一部のみです。ボリュームのロックを解除すると、特権プロセスが読み取れる可能性があります。フルディスク暗号化は、オフラインアクセス、盗難ドライブ、コピーされたメディアへの対策として最も強力です。

埋め込みは暗号化すべきですか？

機密性の高いプライベートな知識については、はい。埋め込みとインデックスを含むストレージを保護し、データベースへのアクセスを制限し、ソースドキュメントと同じセキュリティレビューの対象にこれらのファイルも含めてください。

最終判断

プライベートRAGシステムでは、通常のセマンティック検索を犠牲にせず、保存時のドキュメントを暗号化できます。 現実的な方法は、信頼できるメモリ内で制御された一時的な復号を行うことであり、読めない暗号文を魔法のように検索することではありません。派生した埋め込みとインデックスを保護し、鍵とデータを分離し、平文の一時ファイルを排除し、準同型検索は通常のホームRAG機能ではなく、特殊な暗号設計として扱ってください。