ネット上のプライバシーを強化する Oblivious HTTP

Senior Manager、Infrastructure Services, Fastly

2023年3月15日

インターネットユーザーの間では、自分たちの個人情報は誰に収集されているのか、そしてそのような情報を利用して、自分のオンライン (もしくは現実の世界) での活動の様子が他者に見えてしまうのではないかという懸念が高まっています。同時に、ほとんどの人が便利で実用的なWebサイトやモバイルアプリがもたらす恩恵を受けており、プライバシーの保護を理由にそれらすべてを諦め、インターネットとのつながりを断って今の社会で暮らすことは簡単ではありません。

インターネットサービスを提供する企業は、サービスの有用性とプライバシーの確保という競合する優先事項の間で、どのようにバランスを取るべきかという点において厳しい選択を迫られています。企業は、通常のサービスの運用を通じてエンドユーザーに関するデータを受信するだけでも、厳しいコンプライアンス要件と規制当局からの圧力に晒されます。サービスが成功を収めるほどに、これらへの対応は困難になるのです。

Fastly は、インターネット上でビジネスを展開する世界の大手ブランドに信頼性の高いエッジ配信サービスを提供しています。私たちは今後も最先端のテクノロジーやプロダクトを通じて、お客様がユーザーのプライバシーを保護しながらビジネスをスケールアップできるようサポートし続けます。プライバシーの保護を目的とする Fastly の最新プロダクト「Fastly OHTTP リレー」のベータ版が、一部のパートナーの皆様を対象に公開されました。Fastly OHTTP リレーは、Oblivious HTTP アーキテクチャのコンポーネントのひとつで、個人を特定する不要なメタデータが削除された状態で、エンドユーザーから重要なリクエストデータを受信することを可能にします。

プライバシーが考慮されていない HTTP

エンドユーザーから HTTP リクエストを受信すると、特別に追加されたヘッダーやリクエスト本文に個人を特定できる情報がなくても、実際の人物のオンライン ID を明確に特定または推測できてしまうメタデータが必然的に含まれます。User-Agent や Accept などのヘッダーに含まれるブラウザデータ、AS や IP アドレスなどネットワークに関する情報をつなぎ合わせる</u>ことで、エンドユーザーの ID を覗き込むことができます。このようなメタデータがログされたり、データウェアハウスに送信されたりしていなくても、エンドユーザーからこれらのデータが送信され、サービスのオリジンサーバーによって受信されるため、今後これらがログされる可能性が十分にあります。最終的にエンドユーザーは、サービスのプロバイダーや、収集されたデータをそのプロバイダーから引き継ぐ組織や政府機関が、安心して情報を託せるデータ管理人であると信頼することを求められます。しかし、これらの組織が同じレベルのプライバシーポリシーを順守しているとは必ずしも限りません。

既存の HTTP サービスに手を加えてプライバシーが保護されるようにすることは可能ですが、その場合は通常、標準化や反復可能なプラクティスの欠如といった問題が生じます。その結果、サービスの作成と維持の両方において、エンジニアリング作業が増え、誤って機密性の高い情報が漏えいするリスクも高まります。さらに、HTTP サービスのプロバイダーは、自社のプライバシー保護ソリューションを顧客と業界関係者に説明し、そのソリューションが意図されたとおりに機能するという信頼を構築しなければならず、大きな負担を抱えることになります。

エンドユーザーのプライバシーを保護しながら HTTP リクエストを API エンドポイントに送信する標準化されたメカニズムを導入することで、これらの問題を克服できます。新たに登場した Oblivious HTTP 標準</u>は、API ドリブンのさまざまなユースケースにデプロイ可能なメカニズムです。これにより、反復可能なサービスを構築し、徹底的にテストして動作を深く理解することができます。この標準はまだ進化の途中にありますが、プライバシーが保護されたインターネットサービスの実現に貢献する重要なテクノロジーのコンポーネントとして期待されています。

Oblivious HTTP の役割と仕組み

Oblivious HTTP (OHTTP) は、メッセージのやり取りと高レベルのサービスアーキテクチャのための仕様です。OHTTP を併用すると、HTTP サービスプロバイダーは標準の HTTP オリジンで特別な HTTP クライアントからメッセージを受信し、不要で望ましくないリクエストやネットワークレベルのメタデータを受け取ることがなくなります。OHTTP サービスでは2つのレイヤーが存在します。エンドユーザーの特定を可能にするメタデータを処理するレイヤー (リレー) と、エンドユーザーのリクエストデータを処理するレイヤー (ゲートウェイ) です。OHTTP サービスで実行されるこの二重の匿名化は、ユーザープライバシーの保護に不可欠です。これらの2つのレイヤーはやり取りしますが、それぞれ独立して機能します。

OHTTP アーキテクチャは以下の4つのレイヤーで構成されています。

1. OHTTP クライアント

OHTTP クライアントは特別な HTTP クライアントで、OHTTP ターゲット向けの HTTP リクエストをカプセル化し、暗号化して OHTTP リレーに送信します。現行バージョンの OHTTP クライアントは、事前設定された既知の特定の OHTTP サービスに適しています。暗号化キーとカプセル化されるリクエスト形式はサービスに固有のものであり、事前に認識されている必要があるためです。

2. OHTTP リレー

OHTTP リレーは、OHTTP アーキテクチャの中核で2重の匿名化を担う2つのサービスのうち、先に実行されるものです。

OHTTP リレーは、標準の HTTP リクエストヘッダーとネットワーク接続に関する情報と一緒に、カプセル化されたリクエストを OHTTP クライアントから直接受け取ります。そのため、必然的にクライアントの特定が可能な情報も取得しますが、これらの情報を削除してから OHTTP ゲートウェイにリクエストを転送します。

カプセル化されたリクエストはキーを使用して暗号化されており、OHTTP リレーはそのキーを持っていないため、クライアントがターゲットに送信したデータの内容を知りません。

3. OHTTP ゲートウェイ

OHTTP アーキテクチャの中核で2重の匿名化を担う2つ目のサービスは OHTTP ゲートウェイです。

OHTTP ゲートウェイは匿名化されたバージョンのクライアントリクエストを OHTTP リレーから受け取り、中にあるリクエストを復号化してカプセル化を解除します。その後、このリクエストを OHTTP ターゲットに転送します。

外側のリクエストは匿名化されているため、OHTTP ゲートウェイはクライアントを特定できるメタデータを持っていません。

4. OHTTP ターゲット

OHTTP ターゲットは標準の HTTP サービスで、クライアントから送信された元のカプセル化されたリクエストをカプセル化が解除された形式で受け取り、このようなリクエストは通常の HTTP リクエストと機能的には変わりません。注目すべき点は、OHTTP リレーを通じて渡された HTTP リクエストヘッダーと、OHTTP クライアントによってカプセル化されたリクエストに挿入されたデータを除き、OHTTP ターゲットはクライアントを特定する情報を一切持たないということです。

OHTTP ターゲットはこのようなリクエストを処理し、(クライアントを特定できる情報の受け取りや処理をすることなく) クライアントに返す JSON API レスポンスを提供するなどの動作を行い、レスポンスはゲートウェイによってカプセル化され、OHTTP サービススタックを通じて返されます。

OHTTP をサポートするサービスの提供に Fastly がどう役立つか？　

HTTP サービスのプロバイダーが OHTTP アーキテクチャのすべてのレイヤー (クライアント、リレー、ゲートウェイ、ターゲット) を実装して運用することは、技術的に可能です。各レイヤーは密接に連携して OHTTP をサポートするサービスを提供するため、これらを一緒に行うのは一理あります。OHTTP をこのような形で使用することは、一見プライバシー保護が保証されているように見えますが、単一の組織が OHTTP の2つの二重匿名化サービス (OHTTP リレーとゲートウェイ) の両方を行う場合、プライバシーを保護するという目標を満たす OHTTP の機能が損なわれます。その結果、信頼性を失う動作が発生する運用上のリスクが生じるだけでなく、信頼性において妥協しているという姿勢が見られるだけでも、プライバシーを保護するサービスとして、あってはならないことです。

重要なリクエストパスではプライバシーが保護されていますが、オペレーターは簡単にサイドチャネルを利用してリレーのみが知っている情報 (クライアントリクエストのメタデータとネットワーク情報) とゲートウェイのみが知っている情報 (カプセル化されたリクエストの本文) を組み合わせ、OHTTP アーキテクチャが提供するプライバシー保護の仕組みをうまくかわすことができます。

これを実装する実際のステップが存在しなくても、これが可能であるという認識だけでも、プロバイダーと OHTTP をサポートするサービスに対するユーザーの信頼が損なわれます。最終的にユーザーは、OHTTP の仕様が適切に設計されていること、そしてプライバシー保護を実際に保証できる形でプロバイダーがそのアーキテクチャを実装していることの両方を確信できなければなりません。

そのためにも、OHTTP リレーは HTTP サービスプロバイダー自身が担当するのではなく、スケーラブルで安全性に優れたインフラストラクチャを使用した可用性の高いサービスで定評のある信頼できるパートナーに委ねるのが理想的です。私たちはパートナーとして、お客様がプライバシーを保護するサービスを構築するのをサポートし、インターネット全体を通じたユーザーエクスペリエンスの向上に貢献できるのを楽しみにしています。

Fastly による OHTTP リレー

先日、私たちは Fastly のグローバルなエッジ・コンピューティング・プラットフォームを利用する OHTTP リレーサービスを構築しました。高い拡張性を誇り、瞬時にスケールできる同プラットフォームは、お客様のサービスのあらゆるニーズに応えることが可能です。Fastly は以下を含むさまざまな OHTTP のユースケースをサポートします。

定期的にクラッシュログを API エンドポイントに送るモバイルアプリ (通常、レイテンシが問題にならず、ペイロードが大きい)
接続の確立を許可する前に攻撃者データの API を使用してクライアントリクエストを検証する Web ブラウザ (レイテンシの影響が大きく、ペイロードが非常に小さい)
匿名化されたログ配信、トークン認証など、カスタムサービスロジックを実装するために OHTTP の標準仕様をさらに応用する場合

Fastly が OHTTP をサポートする最初のサービスは、Google Chrome の FLEDGE サービス</u>です。リリース時、このサービスは Fastly の OHTTP リレーのみを使用し、サードパーティ Cookie を利用することなく、k-匿名性を満たす形で</u>行動ターゲティング広告を配信できるようにします。このサービスの運用において Fastly は以下を行います。

Google Chrome クライアントから OHTTP リクエストを受信。
これらのリクエストが実際に OHTTP リクエストであることを確認するために特定の検証プロセスを実行。
許可リストに含まれていないすべての HTTP ヘッダー (最初は Content-Type、Content-Length、Host) を削除。
リクエストを明示的に指定された Google バックエンドに転送。
さらに、サービスレベルのメトリクスのみを Google に提供。Google は OHTTP リレーサービスの設定にアクセスしたり、未加工のリクエスト情報 (リクエストログを含む) を確認したりすることはできません。

今後の展開

Fastly OHTTP リレーがベータ版で利用可能になりました。プライバシーが保護されたインターネットサービスを構築または検討している方は、ぜひご連絡ください。ユーザーのプライバシーを保護するベストプラクティスを実施しながら、トップクラスのエクスペリエンスを提供できるサービスの構築、運用、スケールアップの方法をご紹介します。