アドプライバシーQ&A

Protected Audience API Key-Value Service等との連携における認証・認可・データ整合性の技術的詳細

はじめに

ウェブにおけるユーザープライバシー保護の強化に伴い、サードパーティCookieに依存しない広告技術への移行が進んでいます。Google Chromeを中心に開発が進められているPrivacy Sandbox API群は、ブラウザ内にプライバシー保護機能を組み込むことで、計測やターゲティングの新しいアプローチを提示しています。これらのAPIの多くは、ブラウザ（クライアントサイド）だけでなく、広告エコシステムの関係者（DSP、SSP、広告主など）が運用するサーバーサイドコンポーネントとの連携を必要とします。

例えば、Protected Audience APIでは、オークション中にリアルタイムのキー・バリュー情報を取得するためにKey-Value Serviceとの連携が、Attribution Reporting APIでは、計測レポートの集計処理のためにAggregation Serviceとの連携が発生します。これらのサーバーサイド連携において、通信の安全性を確保し、不正アクセス、データの改ざん、機密情報の漏洩を防ぐことは極めて重要です。本記事では、Privacy Sandbox APIにおける主要なサーバーサイド連携ポイントに焦点を当て、認証、認可、データ整合性確保のための技術的考慮事項について詳細に解説します。

Privacy Sandboxにおける主要なサーバーサイド連携ポイント

Privacy Sandbox API群の中で、サーバーサイドとの連携が特に顕著なのは以下のAPIです。

• Protected Audience API:
  • Key-Value Service: オークション実行中のgenerateBid()およびscoreAd()ワークレットから、リアルタイムのキー・バリュー情報を取得するために使用されます。購入者（Buyer）および販売者（Seller）がそれぞれ運用する可能性があります。主な取得データは、広告予算情報、フリークエンシー情報、コンテクスチュアルな情報などです。
  • Bidding/Scoring Servers (Optional): runAdAuction()のコンフィグレーションによっては、入札ロジックやスコアリングロジックの一部または全部をサーバーサイドで実行することも可能です。この場合、ブラウザ内のワークレットからこれらのサーバーへの通信が発生します。
• Attribution Reporting API:
  • Reporting Endpoint: ブラウザがアトリビューションレポート（イベントレベルまたは集計可能レポート）を送信するエンドポイントです。これは広告主または計測ベンダーが運用します。
  • Aggregation Service: 集計可能なレポート（aggregatable reports）を受信し、特定の処理（ペイロードの復号、署名検証、集計処理）を実行する信頼された実行環境（TEE: Trusted Execution Environment）上のサービスです。これはAdTechベンダーやクラウドプロバイダーが提供し、利用者はそこで集計ジョブを実行します。
• Shared Storage API:
  • Private Aggregation API: Shared Storage Worklet内で実行される集計処理の結果をレポートとして収集し、Aggregation Serviceへ送信します。技術的にはAttribution Reporting APIのAggregation Serviceと同様のバックエンドを利用します。

これらの連携ポイントそれぞれで、通信の発信元（ブラウザ、Worklet、他のサーバーなど）を検証する「認証」、発信元が対象のリソースに対して特定の操作を実行する権限があるかを判断する「認可」、そしてデータが送信中に改ざんされていないことを保証する「データ整合性」の確保が求められます。

主要なセキュリティ課題：認証、認可、データ整合性

Privacy Sandboxのサーバーサイド連携におけるセキュリティ課題は多岐にわたりますが、中心となるのは以下の要素です。

• 認証 (Authentication): 通信の相手が誰であるかを正確に確認することです。ブラウザ内のWorkletからのリクエストが、本当にそのオークションやコンテキストから発生した正当なリクエストであるかを、サーバー側がどう確認できるかという課題があります。
• 認可 (Authorization): 認証されたエンティティが、要求された操作（例: Key-Valueストアからの特定のキーの読み出し、Aggregation Serviceへの特定のレポートの送信）を実行する権限を持っているかを判断することです。プライバシー保護の観点から、認可の粒度は非常に重要になります。
• データ整合性 (Data Integrity): 送信されたデータが、途中経路で改ざんされていないことを保証することです。特に機密性の高い広告データや集計レポートにおいて不可欠です。
• 機密性 (Confidentiality): データが権限のない第三者に傍受されないように保護することです。
• 可用性 (Availability): サービスが要求に応じて適切に応答し、拒否サービス攻撃などによって機能不全に陥らないようにすることです。

これらの要素は相互に関連しており、全体として強固なセキュリティ体制を構築する必要があります。

各連携ポイントにおける認証・認可の技術的考慮事項

Privacy Sandboxの設計思想の一つに、サーバー側が可能な限りユーザーやブラウザの特定情報を取得できないようにするという点があります。このため、従来のサーバーサイド連携で一般的に用いられるユーザーIDベースの認証メカニズムは適用が困難です。代わりに、コンテキストに基づく認可や、ブラウザによって付与される限定的な情報を用いた検証が行われます。

Protected Audience API Key-Value Service

• 認証: Key-Value Serviceへのリクエストはブラウザ内のWorklet（generateBid()またはscoreAd()）から発生します。これらのリクエストに、サーバー側でリクエスト元のWorkletやブラウザインスタンスを厳密に認証するための標準的なメカニズムは、現時点では提供されていません。Key-Value Serviceは、リクエストがProtected Audienceオークションのコンテキストで発生したこと、およびリクエスト元のエンティティ（BuyerまたはSeller）を、HTTPヘッダーやリクエストに含まれる情報から推測・検証することになりますが、強力な認証とは言えません。これは意図的な設計であり、サーバー側がユーザーレベルのトラッキングを試みることを抑制する側面があります。将来的にTrust Token APIなど他のプライバシー保護APIとの連携が検討される可能性もありますが、現時点での認証は限定的です。
• 認可: 認証が限定的であるため、Key-Value Serviceにおけるセキュリティは主に「認可」によって担保されます。サービスは、リクエスト元のエンティティ（eTLD+1ベースで識別されるBuyerまたはSeller）が要求されたキーに対応する値を取得する権限があるかを判断します。これは、サービス側の内部設定や、リクエストに含まれるコンテキスト情報（例: オークションタイプ、参加者）に基づいて行われます。例えば、あるBuyerのKey-Value Serviceは、そのBuyerのオーディエンスグループに関連するキーに対するリクエストのみを許可し、他のBuyerやSellerからの不正なリクエストを拒否する必要があります。キーの構造設計や、アクセス制御リスト（ACL）のような仕組みが実装の鍵となります。

Attribution Reporting API Reporting Endpoint / Aggregation Service

• Reporting Endpoint: ブラウザから直接レポートを受け取るエンドポイントです。イベントレベルレポートと集計可能レポートの両方を受け取ります。
  • 認証・認可: ブラウザからのレポート送信自体には、エンドユーザーに対する強い認証は行われません。Reporting Endpointは、レポートの送信元（通常は広告主またはその計測ベンダーのドメイン）を確認することで、レポートを受け入れるかを判断します。集計可能レポートの場合、ブラウザによってペイロードに付与されるデジタル署名を検証することで、レポートが正規のブラウザによって生成され、Aggregation Serviceへの送信に適格であることを確認できます。この署名検証は、レポートの信頼性を保証する重要な要素です。
• Aggregation Service: 集計可能レポートを処理する信頼された環境です。
  • 認証・認可: Aggregation Serviceへのデータ送信（集計ジョブの開始など）は、Reporting Endpointを経由して行われるか、または別途AdTechベンダーのシステムから行われる可能性があります。サービスは、ジョブを発行するエンティティ（AdTechベンダー）を認証し、そのエンティティがサービスを利用する権限があるかを認可する必要があります。これは、APIキーやOAuth 2.0などの標準的な認証・認可メカニズムを用いて実装されます。また、Aggregation ServiceはTEE内で動作するため、その実行環境自体の認証（例えば、リモートアテステーションによる検証）もセキュリティチェーンの一部となります。さらに、Aggregation Serviceは受信したレポートペイロードに含まれる署名を検証し、不正なレポートを排除する責任も負います。

データ整合性確保の技術

通信経路におけるデータ整合性は、HTTPS/TLSの使用によって基本的なレベルで保証されます。しかし、Privacy Sandbox APIにおいては、アプリケーションレベルでのデータ整合性確保メカニズムが特に重要です。

• レポートのデジタル署名: Attribution Reporting APIの集計可能レポートでは、ブラウザがレポートのペイロードに対してデジタル署名を付与します。Reporting EndpointやAggregation Serviceは、この署名を検証することで、レポートがブラウザによって正しく生成され、送信中に改ざんされていないことを確認できます。署名検証に失敗したレポートは破棄することで、データ整合性を保護します。
• 入力値検証とサニタイゼーション: サーバーサイドコンポーネントは、ブラウザや他のサーバーから受け取る入力データ（例: Key-Valueリクエストのキー、レポートのペイロード）に対して、厳格な検証とサニタイゼーションを行う必要があります。不正な形式のデータや悪意のあるコードが含まれていないかを確認することで、インジェクション攻撃などのリスクを軽減できます。
• Aggregation ServiceのTEE: Aggregation Serviceが信頼された実行環境（TEE）上で動作することは、データ処理の整合性と機密性を確保するための重要な要素です。TEEは、実行中のコードやデータが外部からアクセス・改ざんされないことをハードウェアレベルで保証します。これにより、集計処理自体が仕様通りに実行され、結果が信頼できるものであることを技術的に裏付けます。

実装・運用上の技術的注意点

Privacy Sandbox APIとのサーバーサイド連携を安全に実装・運用するためには、以下の技術的側面に留意する必要があります。

• 秘密鍵/証明書の管理: レポート署名の検証やTLS接続の確立に必要な秘密鍵や証明書は、厳重に管理する必要があります。ハードウェアセキュリティモジュール（HSM）の利用や、クラウドベンダーが提供する鍵管理サービス（KMS）の活用が推奨されます。
• APIクレデンシャルの管理: Aggregation Serviceへのアクセスなどに使用されるAPIキーやシークレットは、漏洩しないように安全に保管・運用する必要があります。ロールベースアクセス制御（RBAC）を適切に設定し、必要な最小限の権限のみを付与します。
• Rate LimitingとDoS対策: 不正な大量リクエストによるサービス停止を防ぐため、Key-Value ServiceやReporting Endpointには適切なRate Limitingを実装する必要があります。
• ゼロトラスト原則の適用: 内部ネットワーク内の通信であっても、すべてを信頼せず、常に認証・認可を要求するゼロトラスト原則に基づいてシステムを設計することは、全体的なセキュリティレベルの向上につながります。
• ブラウザ実装による制約: Privacy Sandbox APIはブラウザに依存するため、ブラウザの実装変更やバージョンアップがサーバーサイド連携の挙動に影響を与える可能性があります。最新の仕様とブラウザの挙動を常に把握し、互換性を維持するためのテスト体制を構築する必要があります。
• 監査ログと監視: すべての通信と処理について詳細なログを取得し、不正なアクセスや異常な挙動を検知するための監視システムを構築することは、セキュリティインシデントの早期発見と対応に不可欠です。

法規制 compliance とセキュリティ設計の関連

GDPRやCCPA/CPRAなどのデータプライバシー規制は、個人データの処理に対するセキュリティ要件を課しています。これらの規制では、技術的および組織的措置を講じることで、不正なまたは違法な処理、偶発的な滅失、破壊または損害から個人データを保護することが求められています（例: GDPR第32条）。Privacy Sandbox APIとの連携における認証、認可、データ整合性、機密性の確保は、これらの法的要件を満たすための技術的な基盤となります。特に、Aggregation ServiceのようなTEEを利用した集計処理は、匿名化された集計結果のみを共有するというプライバシー保護の設計と結びつき、法規制への適合性を高める上で重要な役割を果たします。

今後の展望

Privacy Sandbox API群は依然として進化途上にあり、サーバーサイド連携に関する技術仕様も今後変更される可能性があります。例えば、認証メカニズムの強化、より細粒度な認可制御の導入、新しい暗号技術の活用などが検討されるかもしれません。また、異なるブラウザベンダーや業界団体間での標準化の議論も、今後のセキュリティモデルに影響を与えるでしょう。技術者は、これらの動向を継続的に追跡し、システムの設計や実装を適応させていく必要があります。

まとめ

Protected Audience APIのKey-Value ServiceやAttribution Reporting APIのAggregation Serviceなど、Privacy Sandbox APIにおけるサーバーサイドコンポーネントとの安全な連携は、ポストCookie時代における広告エコシステムの信頼性を維持するために不可欠です。ブラウザ主導のプライバシー保護設計により、従来のIDベースの認証が困難な場面が多い一方、コンテキストに基づく認可、デジタル署名によるデータ整合性の保証、信頼された実行環境の活用といった新しい技術的アプローチが重要になっています。実装においては、鍵管理、アクセス制御、入力検証、監視といった基本的なセキュリティプラクティスを徹底するとともに、法規制の要件を理解し、 Privacy Sandboxの進化に合わせてシステムを継続的にアップデートしていくことが求められます。