Vaulted
更新日

サーバーサイド暗号化 vs. クライアントサイド暗号化：どちらのモデルを信頼すべきか？

著者

サーバーサイド暗号化は、平文を受信した後にサーバー上でデータを暗号化する方式で、サービスプロバイダーへの信頼が必要になる。クライアントサイド暗号化は、送信前にブラウザ内でデータを暗号化するため、サーバーが平文を見ることはない。シークレット共有においては、クライアントサイド暗号化の方が安全だ。サービス自体を信頼ポイントから排除できるため、たとえサーバーが侵害されてもデータは読まれない。

この記事では両方のアプローチを比較する：それぞれの仕組み、何を信頼することが求められるか、そして本当のトレードオフがどこにあるか。これはどちらかを推奨する議論ではなく、自分の脅威モデルに合ったモデルを評価するためのフレームワークだ。

クライアントサイド暗号化がなぜ重要かの概要は以前の記事を参照してほしい。Vaultedの具体的な実装の詳細については、ゼロ知識ディープダイブを参照してほしい。

サーバーサイド暗号化の仕組み

サーバーサイドモデルでは、サービスがユーザーに代わって暗号化を処理する。典型的なフローは以下のとおりだ：

  1. ブラウザにシークレットを入力する
  2. ブラウザが平文をTLS経由でサーバーに送信する
  3. サーバーが自身が管理する鍵を使ってデータを暗号化する
  4. 暗号文がデータベースに保存される
  5. 受信者がシークレットを要求すると、サーバーが復号して平文を返す

暗号化鍵はサーバーから外に出ることはない。ハードウェアセキュリティモジュール（HSM）、クラウドの鍵管理サービス（KMS）、または設定ファイルに保存されることもあるが、いずれにせよサーバーが完全に制御している。

サーバーサイドの信頼モデル

サーバーサイド暗号化では、以下を信頼することになる：

  • サービス事業者がデータを読まないこと（暗号化・復号の際にメモリ上で鍵と平文の両方を保持している）
  • インフラが侵害されないこと（サーバーが侵害されると鍵とデータの両方が漏洩する）
  • 事業者の従業員がアクセスを悪用しないこと（サーバーにアクセスできる人は誰でも潜在的にシークレットを読める）
  • 法的管轄が開示を強制しないこと（事業者は鍵を保持しているため、データの提出を強制される可能性がある）
  • サーバーログと監視が平文を記録しないこと（ロギングフレームワークが誤って機密データを記録することがある）

これが必ずしも悪いモデルというわけではない。多くのサービスが成功裏に使用している — クラウドストレージ、メールプロバイダー、データベースサービスはいずれもサーバーサイド暗号化に依存している。問題は、そのトレードオフが自分のユースケースに合っているかどうかだ。

クライアントサイド暗号化の仕組み

クライアントサイドモデルでは、データがサーバーに届く前にブラウザ内で暗号化が行われる。フローは異なる：

  1. ブラウザにシークレットを入力する
  2. ブラウザが暗号化鍵を生成し、ローカルでデータを暗号化する
  3. サーバーには暗号文のみが送信される
  4. 暗号化鍵は別のチャンネル（通常はURLフラグメント）を通じて受信者に渡される
  5. 受信者のブラウザがローカルで暗号文を復号する

サーバーは平文を見ることがなく、暗号化鍵を保持することもない。暗号化されたデータを保存・取得するだけだ — それ以上でも以下でもない。

Vaultedはこのモデルを採用している。各シークレットには新鮮なAES-256-GCM鍵が生成される。鍵はRFC 3986に従いブラウザがHTTPリクエストに含めることのないURLフラグメント（#）に置かれる。サーバーは保存用に暗号文と12バイトのランダムIVを受け取るが、鍵は送信者と受信者の間で共有されるリンクの中にのみ存在する。

クライアントサイドの信頼モデル

クライアントサイド暗号化では、以下を信頼することになる：

  • ブラウザが暗号処理を正しく実装していること（Web Crypto APIはBoringSSLやNSSといったネイティブ暗号エンジンに委譲する）
  • アプリケーションコードが実際にクライアントサイドで暗号化を行っていること（ネットワークリクエストを検査することで確認できる）
  • リンクの配送チャンネルが安全であること（フラグメントを含む完全なURLを持つ人は誰でもシークレットを復号できる）
  • 受信者のデバイスが侵害されていないこと（復号後、マルウェアや画面キャプチャが平文にアクセスできる）

サーバー、サービス事業者、その従業員、法的管轄は信頼しなくてよい。サーバーは、自分では読めない暗号化データのストレージリレーにすぎない。

トレードオフの比較

どちらのモデルが普遍的に優れているわけではない。それぞれがセキュリティ、使いやすさ、機能の豊富さの間で異なるトレードオフをしている。

セキュリティ特性

特性サーバーサイドクライアントサイド
サーバー侵害時の漏洩範囲鍵 + 暗号文が漏洩暗号文のみ漏洩（鍵がなければ無意味）
事業者がデータを読めるか可能（鍵を保持している）不可能（鍵を保持していない）
法的強制開示のリスク事業者は応じられる（アクセス手段を持つ）事業者は応じられない（アクセス手段を持たない）
リンク傍受のリスク該当なし（リンクに鍵が含まれない）完全なURL = 完全なアクセス（パスフレーズで軽減可能）
中間者攻撃TLSが通信を保護するが、サーバーは平文を見るTLSが暗号文を保護し、フラグメント内の鍵は送信されない

使いやすさの特性

特性サーバーサイドクライアントサイド
鍵管理の負担ユーザーには不要（サーバーが処理する）ユーザーがリンクを安全に共有する必要がある
パスワードの回復可能（サーバーが鍵を保持）不可能（鍵はリンクにのみ存在）
検索とインデックスサーバーが平文を検索できる復号なしには不可能
共有の柔軟性サーバーが新しい受信者向けに再暗号化できる受信者ごとに新しいリンクが必要
オフラインアクセス復号にサーバー接続が必要暗号文と鍵がローカルにキャッシュされていれば可能

機能のトレードオフ

機能サーバーサイドクライアントサイド
コンテンツの監査ログ可能不可能（サーバーがコンテンツを読めない）
コンテンツベースのポリシー可能（DLP、コンプライアンススキャン）復号なしには不可能
鍵のローテーションサーバーが新しい鍵で再暗号化できるリンクの再生成と再共有が必要
複数者へのアクセス制御サーバーがユーザーごとの鍵を管理できる各受信者に鍵を直接渡す必要がある
ゼロ知識保証なしあり

サーバーサイド暗号化が許容される場面

サーバーサイド暗号化が合理的な選択になるのは次のような場合だ：

  • サービス事業者とそのセキュリティ慣行を信頼できる
  • 検索、共有、コンプライアンススキャンなどサーバーサイドのデータアクセスが必要な機能が求められる
  • データの機密性がクライアントサイド暗号化の使い勝手のコストを正当化しない
  • 規制された環境で運用しており、ゼロ知識保証よりも事業者のコンプライアンス認証の方が重要
  • 鍵管理の複雑さをユーザーではなくサービスに任せる必要がある

クラウドストレージサービス、エンタープライズメール、マネージドデータベース暗号化はいずれもこのモデルを効果的に使用している。

クライアントサイド暗号化が必要な場面

クライアントサイド暗号化が必要になるのは次のような場合だ：

  • サービス事業者にデータを預けることができない、または預けるべきでない
  • サーバーが侵害されても平文が漏洩してはならないほどデータが機密性を持つ
  • ゼロ知識保証 — サーバーがデータを読めないという数学的証明 — が必要
  • 法律やコンプライアンス要件により、サービス事業者がコンテンツにアクセスできてはならない
  • サービスプロバイダーの内部脅威に対する保護が必要

シークレット共有はクライアントサイド暗号化の最も強力なユースケースの一つだ。データは本質的に機密性が高く（パスワード、APIキー、認証情報）、共有は一時的（閲覧回数制限、期限付き）であり、信頼関係は最小限だ（サービス事業者を知らない、または信頼していない場合もある）。

Vaultedのアプローチ

Vaultedはクライアントサイド暗号化のみを使用している。すべてのシークレットは、データがサーバーに届く前にブラウザ内で新鮮なAES-GCM鍵で暗号化される。鍵はURLフラグメントにのみ存在し、オプションのパスフレーズ保護はPBKDF2鍵導出とAES-KW鍵ラッピングによる第二の保護レイヤーを追加する。

サーバーは有効期限と閲覧カウンターを持つ暗号化された暗号文を保存する。コンテンツの復号、検索、検査はできない。データベース全体が侵害されても得られるのは暗号化されたデータのみだ — 共有リンクにのみ存在する鍵がなければ計算上は無意味だ。

完全な暗号技術の詳細 — 鍵生成、IV処理、パスフレーズラッピング、正確なWeb Crypto APIの呼び出し — についてはゼロ知識暗号化ディープダイブを参照してほしい。

選択の判断基準

適切な暗号化モデルは、何を保護するか、そして誰を信頼する意思があるかによって決まる。

検索、回復、または一元化された鍵管理といった機能が必要なら、サーバーサイド暗号化が実用的な選択だ。誰も — サービスも、その従業員も、裁判所命令も — データを読めないという保証が必要なら、クライアントサイド暗号化がそれを提供できる唯一のモデルだ。

シークレットの共有については、答えは明確だ：データは機密性が高く、やり取りは短く、平文にアクセスできる当事者が少ないほど良い。

ゼロ知識暗号化でシークレットを共有する準備はできた？ Vaultedでシークレットを作成する — データは暗号化されないままブラウザを離れることはない。

関連記事