アドプライバシーQ&A

Attribution Reporting API集計レポートの暗号化と復号化：Aggregation Serviceの技術的仕組みとセキュリティ考慮事項

Tags: Attribution Reporting API, Aggregation Service, プライバシーサンドボックス, 暗号化, TEE

はじめに

プライバシー保護技術として注目を集めるPrivacy Sandboxの中でも、広告効果測定の中心的なAPIであるAttribution Reporting API（ARA）は、ユーザーのプライバシーを保護しつつ、コンバージョンの計測を可能にすることを目指しています。ARAはイベントレベルレポートと集計レポートの二種類のレポートを提供しますが、特に集計レポートは個人を特定しにくい形で集計データを提供するため、プライバシー保護において重要な役割を担っています。

集計レポートのプライバシー保護は、クライアントサイド（ブラウザ）でのデータの暗号化と、特定の信頼された環境（Aggregation Service）でのみ復号化・集計が行われる技術的な仕組みによって実現されています。本記事では、Attribution Reporting APIにおける集計レポートの暗号化プロセス、Aggregation Serviceでの復号化および集計の技術的仕組み、そしてその基盤となる信頼された実行環境（TEE）の役割とセキュリティに関する考慮事項について、技術的な側面から詳細に解説します。

Attribution Reporting APIの集計レポート概要

Attribution Reporting APIは、ユーザーのアクション（クリックやビュー）とコンバージョンイベントを紐付けることで、広告キャンペーンの効果測定を行います。イベントレベルレポートは個々のコンバージョンに関する限られた情報（例えば、ソースサイトのトップレベルドメインとコンバージョン側のデータ）を遅延を伴って送信しますが、これはプライバシー保護の観点からデータにノイズが付加されるなどの制約があります。

一方、集計レポートは、複数のユーザーからのデータをまとめた形で提供され、より詳細な分析を可能にします。広告主や測定プロバイダーは、この集計レポートをAggregation Serviceに送信し、集計処理を経て最終的な集計レポート（Summary Report）を取得します。このプロセスにおいて、個々のユーザーのデータがAggregation Service以外の第三者に漏洩しないよう、レポートの暗号化が不可欠となります。

集計レポートには、集計キー（Aggregation Key）と集計値（Aggregatable Value）が含まれます。集計キーは、集計したいメトリクス（例: 特定のキャンペーン、地理的地域、プロダクトカテゴリなど）を定義するビットマスクとして表現され、集計値はコンバージョンに関連する数値データ（例: 購入金額）を表します。ブラウザはこれらのデータを含む集計レポートを生成しますが、送信前にこれを暗号化します。

集計レポートの暗号化メカニズム

ブラウザがAttribution Reporting APIのトリガーイベントを受け取り、保存されているソースイベントとのアトリビューションが成功して集計可能なレポートを生成する際、そのレポートペイロードはAggregatable Valueにノイズを加えた上で暗号化されます。この暗号化は、レポートがAggregation Serviceに到達する前に第三者（例えば、レポートを収集・転送する測定プロバイダーや広告技術ベンダー）によって内容が読み取られることを防ぐための重要なセキュリティ対策です。

暗号化には、Hybrid Public Key Encryption (HPKE) と呼ばれる方式が使用されます。HPKEは、公開鍵暗号と共通鍵暗号を組み合わせたハイブリッド暗号システムです。具体的には、受信者（この場合はAggregation Serviceの鍵サーバー）の公開鍵を使用して共通鍵を暗号化し、その共通鍵で実際のデータ（レポートペイロード）を暗号化します。

暗号化プロセスは以下のようになります。

  1. 鍵の取得: ブラウザは、レポートの送信先となるAggregation Service運用者（通常は広告主や測定プロバイダー）が提供する公開鍵を取得します。この公開鍵は、ソース登録時やトリガー登録時、あるいは既知のエンドポイントから取得されることが想定されます。鍵は定期的にローテーションされる可能性があります。
  2. レポートペイロードの準備: ブラウザはアトリビューション結果に基づき、集計キーとノイズが付加された集計値を含むレポートペイロード（プレーンテキストデータ）を生成します。
  3. HPKEによる暗号化:
    • ブラウザは、取得した公開鍵を使用して、一時的な共通鍵ペアを生成します。
    • この一時的な共通鍵を用いてレポートペイロードを暗号化します。
    • 共通鍵自体は、Aggregation Serviceの公開鍵を用いて暗号化されます。
    • 暗号化された共通鍵と、共通鍵で暗号化されたレポートペイロードが組み合わされ、最終的な暗号化レポートとして出力されます。
  4. 暗号化レポートの送信: 暗号化されたレポートは、広告主または測定プロバイダーが指定したレポート収集エンドポイントに送信されます。この収集エンドポイントは、暗号化されたレポートをAggregation Serviceに転送する役割を担います。収集エンドポイントはレポートの内容を復号化することはできません。

この暗号化により、レポート収集サーバーの運用者は暗号文しか見ることができず、個々のレポートに含まれる集計キーや集計値を直接知ることはできません。

Aggregation Serviceでの復号化と集計プロセス

Aggregation Serviceは、暗号化された集計レポートを受信し、プライバシーを保護しながら集計処理を実行するための専用の環境です。Google Cloud上で提供されており、信頼された実行環境 (TEE) 技術を活用しています。

Aggregation Serviceでのプロセスは以下のようになります。

  1. 暗号化レポートの受信: Aggregation Serviceは、レポート収集サーバーから送信された暗号化されたレポートデータを受信します。
  2. 復号化のための鍵取得: Aggregation Serviceは、レポートの復号化に必要な秘密鍵を取得します。この秘密鍵は厳重に管理されており、Aggregation Serviceのインスタンスが鍵サーバー（Key Management Serviceなど）と連携して、正当なリクエストに対してのみ提供されます。この連携もセキュアに行われます。
  3. TEE内での復号化:
    • Aggregation Serviceのインスタンスは、Intel TDX (Trust Domain Extensions) や AMD SEV (Secure Encrypted Virtualization) のような技術に基づいたTEE上で動作します。
    • 受信した暗号化レポートと取得した秘密鍵は、TEEの境界内（信頼された領域）にロードされます。
    • TEE内でHPKEの仕組みを用いてレポートペイロードが復号化されます。TEEは、その領域内で実行されるコードとデータが、TEE外の環境（ホストOS、ハイパーバイザー、さらにはクラウドプロバイダーのインフラ管理者）から覗き見られたり改ざんされたりすることを技術的に困難にする仕組みを提供します。
  4. TEE内での集計:
    • 復号化された複数のレポートペイロード（集計キーと集計値のペア）は、TEE内で集計処理されます。同じ集計キーを持つ集計値が合計されます。
    • この集計プロセスもTEE内で行われるため、集計中の個々のレポートデータがTEE外に漏れるリスクが低減されます。
  5. 差分プライバシーノイズの付加: 集計結果に対して、差分プライバシーの要件を満たすためのノイズが付加されます。これにより、集計結果から特定の個人に関する情報を推測することがさらに困難になります。ノイズの付加は、集計処理が完了し、最終的な集計レポートを生成する直前に行われます。
  6. 集計レポート（Summary Report）の生成: ノイズが付加された集計結果を含む最終的な集計レポートが生成されます。このレポートは暗号化されずに、リクエスター（広告主や測定プロバイダー）に提供されます。

このように、暗号化されたレポートはAggregation ServiceのTEE内でのみ安全に復号化・集計されるため、データが「信頼できる境界」の外でクリアテキストの状態で処理されるリスクを大幅に低減できます。

信頼された実行環境 (TEE) の役割とセキュリティ考慮事項

Aggregation ServiceにおけるTEEの利用は、Attribution Reporting APIのプライバシー保護モデルの根幹をなす要素の一つです。TEEは、CPU内部などに設けられた独立した領域であり、そこで実行されるコードやデータは、その領域外からの不正なアクセスや改ざんから保護されます。

TEEが提供する主なセキュリティ特性は以下の通りです。

しかしながら、TEEも万能ではありません。実装上の脆弱性（サイドチャネル攻撃など）や、ハードウェア自体の信頼性に関する議論は常に存在します。Aggregation Serviceの運用者は、これらのリスクを理解し、最新のセキュリティパッチの適用や監視体制の構築など、適切な対策を講じる必要があります。

実装上の考慮事項と課題

Attribution Reporting APIの集計レポートとAggregation Serviceを活用する上で、技術者やコンサルタントが考慮すべき実装上の課題がいくつか存在します。

  1. 鍵管理の複雑性: レポートの暗号化・復号化には鍵ペアが必要です。鍵の生成、配布、ローテーション、失効といったライフサイクル管理は、セキュリティと可用性の観点から非常に重要です。鍵管理システム（KMS）とのセキュアな連携設計が求められます。
  2. Aggregation Serviceの運用: Aggregation Serviceは単なるAPIエンドポイントではなく、TEE上で動作する特殊な環境です。そのデプロイ、スケーリング、監視、ログ分析（TEE内で何が起きているかの可視化制限がある中で）には、従来のクラウドサービス運用とは異なる知見が必要になる可能性があります。
  3. デバッグと検証の難しさ: 暗号化およびTEEの利用により、個々のレポートデータの内容を途中で確認することが困難です。これにより、集計結果がおかしい場合のデバッグや、システムが期待通りに動作していることの検証が複雑になります。デバッグレポートやローカルでのテスト環境の活用が重要となります。
  4. 差分プライバシーノイズの影響: 集計結果に付加されるノイズは、データの精度に影響を与えます。集計キーの設計やレポート数の閾値など、差分プライバシーメカニズムを理解し、許容できる精度とプライバシーレベルのバランスを取る必要があります。
  5. コスト: Aggregation ServiceおよびTEE環境の利用にはコストが発生します。大量のレポートを処理する場合、コスト効率の良い運用設計が求められます。

将来展望

Attribution Reporting APIおよびAggregation Serviceは比較的新しい技術であり、現在も進化を続けています。Aggregation Serviceの機能拡張（例えば、より複雑な集計処理のサポート）、TEE技術の成熟、鍵管理の標準化などが今後進む可能性があります。また、他のPrivacy Sandbox API（例: Shared Storage APIのPrivate Aggregation Worklet）との連携強化により、集計データの活用範囲が広がることも期待されます。これらの技術動向を継続的に追跡することが、最先端のアドプライバシーソリューションを提供するために不可欠となります。

まとめ

Attribution Reporting APIにおける集計レポートの暗号化とAggregation Serviceでの復号化・集計プロセスは、ポストCookie時代の広告効果測定においてユーザープライバシーを保護するための重要な技術的基盤です。ブラウザによるHPKEを用いたレポートの暗号化、Aggregation ServiceによるTEE内での安全な復号化と集計、そして差分プライバシーによるノイズ付加という一連の仕組みが連携することで、個人の特定リスクを最小限に抑えつつ、有用な集計データを提供しています。

これらの技術を理解し、適切に実装および運用することは、現代のプライバシー重視の広告エコシステムにおいて、企業や個人がデータプライバシー規制を遵守し、かつ効果的な広告戦略を展開するために不可欠となります。鍵管理、Aggregation Serviceの運用、デバッグ、そして差分プライバシーの影響など、技術的な課題は存在しますが、これらの克服が新しい広告技術の可能性を最大限に引き出す鍵となるでしょう。