メインコンテンツまでスキップ

Web SDK セキュリティ

Rokt は、Web SDK 統合が安全であることを確保することに努め、製品にセキュリティをゼロから組み込むよう努力しています。また、クライアントデータが厳密な管理のもとで取り扱われるよう、あらゆる予防措置を講じています。これは継続的な取り組みであり、プロセス、管理方法、および技術を徐々に改善し、より高いセキュリティを目指しています。

目的​

Rokt のセキュリティ目標は以下を含みます:

  • パートナーが Rokt に対して利用可能なデータを管理できる
  • 悪意のあるコードが偶発的または意図的にパートナーページ上で実行されない
  • 悪意のあるコードがホストページに含まれるプライベートな顧客情報に勝手にアクセスできない

アプローチ​

Rokt は、親ページ上での表面積を最小限にするために、大部分の機能をサンドボックス化されたクロスオリジンの iframe にプッシュします。親ページには、非常に最小限の依存関係を持つ Rokt インテグレーションランチャーを含める必要があります。これらの依存関係は一緒に Rokt アセットのオーケストレーションを管理し、親ページへのすっきりとした最小限のインターフェースを提供します。これにより統合が容易になりますが、親ページ上で実行される Rokt コードに一定の信頼が必要です。

この信頼を構築するために、Rokt は次の技術を採用しています:

  • モダンかつ最新のライブラリおよびフレームワークの依存関係
  • Rokt スクリプトの許可されたソースのホワイトリスト化
  • より厳しいコンテンツセキュリティポリシー (CSP) 設定のサポート、特に「unsafe-eval」および「unsafe-inline」を不許可にする
  • 原点制御メッセージパッシングを使用した postMessage によるサンドボックス化された iframe コンテンツ

セキュリティ機能​

コンテンツセキュリティポリシー (CSP)​

Rokt の Web SDK は、スクリプト内でのインラインスクリプトや eval の使用を防ぐ推奨された CSP 設定をサポートしています。また、パートナーページに機能をできるだけ少なく読み込むことを目指しています。このアプローチにより、パートナーの CSP 設定への変更を最小限に抑えることができます。必要な CSP ディレクティブは、許可リストに次のドメインを追加することです:

script-src https://apps.rokt.com;
frame-src https://apps.rokt.com;

スクリプトソースは、ランチャーをパートナーページに読み込むために必要です。パートナーがファイルを自分でホストしている場合、この変更は必要ありません。フレームソースは、Rokt の分離された iframe を読み込むことを可能にします。

注記

CSP を使用していない場合、または script-src や frame-src ディレクティブを使用していない場合、これらの変更だけを追加するとページに悪影響を及ぼす可能性があります。詳細については、MDN ドキュメンテーションに関する CSP をご覧ください。

サブリソースインテグリティ (SRI)​

注記

Rokt は Web SDK のための SRI 統合をサポートしていません。

サブリソースインテグリティ (SRI) は、ブラウザが取得しているリソース（例：コンテンツ配信ネットワークから）が予期しない操作を受けずに提供されることを検証できるセキュリティ機能です。

なぜ Rokt は Web SDK のための SRI 統合をサポートしないのか?​

最新バージョンの Web SDK を保持することは重要で、これは私たちが常にセキュリティ、パフォーマンス、および互換性を改善することを目指しているためです。パートナーが Rokt スクリプトに SRI を適用することを決定した場合、その統合の特定のバージョンに固定されることになります。その場合、私たちは最新バージョンへの手動での更新をパートナーに依存することになり、更新は2週間に1回の頻度で行われることがあります。バージョンが古くなると、統合が意図したとおりに機能しない可能性があり、アラームが発生し、パフォーマンスやダウンタイムなどの内部メトリクスに影響を与える可能性があります。

このため、Facebook、Stripe、PayPal などのサービスは、固定バージョンや SRI 統合をサポートしていません。

Rokt によって提供されるコードが操作されずに到着することを保証するために、ネットワーク転送から内部エンジニアリングプロセスまで多層のセキュリティを採用しています。一般的に、https 経由で rokt.com からファイルを取得することは、SSL プロトコルがファイルが内部サービスからであることを保証するため、最大限の保護を確保するのに十分です。

内部ネットワーク内からファイルが改ざんされないようにするために、Rokt は効果的なサービスセキュリティを管理するための関連基準を遵守しています。

私たちは、情報セキュリティ管理のための主要な国際標準である ISO/IEC 27001 に準拠しています。私たちの組織的な慣行は、内部サービスが外部攻撃にさらされないようにすることを保証しています。他の慣行とともに、ソースコードへのアクセスには多要素認証 (MFA) が必要であり、更新は展開される前に厳格なレビューと監査プロセスを受けます。

サンドボックス化されたiframeと同一オリジンポリシー​

Roktのソリューションは、クロスオリジンのiframeの使用に大きく依存しています。私たちのiframeはapps.rokt.comのエンドポイントからロードされ、自動的に同一オリジンポリシーを強制します。これにより、パートナーのコードがRoktのiframeコンテンツと相互作用することを防ぎ、逆もまた然り、つまり両方のコンテキスト間での隔離が強制されます。

さらに、我々はiframeにsandbox属性を使用しています。sandbox属性はiframe内で許可される機能を大幅に制限します。Roktは、iframeの正常な動作を確保するために例外リストを維持する必要があるため、自動的にsandbox属性を適用します。プレースメントのiframeの場合、次の例外リストが使用されます：

  • allows-scriptsは、iframe内のコンテンツがJavaScriptファイルを実行できるようにし、パートナーが期待する機能をRoktが提供できるようにします。
  • allow-same-originは、iframeがそのオリジン情報を保持できるようにします。これはpostMessageによる安全な通信を実現するために使用されます。これが提供されない場合、iframeはオリジン情報を剥奪され、RoktはpostMessageのtargetOriginパラメータを使用して、私たちのドメイン内のiframe間でのみ通信を確保できなくなります。
  • allow-popupsは、iframe内のコンテンツがリンク（例：トラフィックキャンペーン、利用規約）を新しいタブで開くことを許可します。
  • allow-popups-to-escape-sandboxは、他のサイトへのリンクを持つキャンペーンが正常に機能するようにします。これがないと、我々のiframeと同じサンドボックスルールに制限されます。
  • allow-formsは、リソースがフォームを送信することを許可します。これはRoktのソリューションには必須ではありませんが、一部の広告主がそのページでフォーム送信を要求する場合があります。

postMessage 通信​

必要な通信は、postMessageとMessageChannelを使用して行われます。MessageChannelは、一対のポートを含む構造です。この通信は、パートナーのページにホストされているRoktの統合とRoktプレースメントのiframe間で行われます。

この通信は、両端にポートがあるパイプと考えることができます。私たちはpostMessageを通じてポートの交換を、私たちが管理するドメインに限定しています。これにより、RoktのiframeのみがLauncherからのメッセージや互いの間でメッセージを受け取ることが保証されます。プレースメントコードがペアのポートを受け取った後は、すべての通信がこの確立されたチャネルを通じて行われます。

プライバシー​

Roktは、実装に組み込むことができるオプションを提供しており、異なる顧客体験を提供したり、顧客が異なるクッキープリファレンスを決定したりすることができます。

データ削除のサポート​

Roktは、パートナーが顧客の要求やプリファレンスを支持するために、Roktにデータ削除リクエストを送信する機能を提供しています。

機能トラッキング技術: あなたのサイトで最も関連性のある最適な顧客体験を提供し、個別化を強化します。また、チェックアウト内の高度な機能を支えるのにも役立ちます（例えば、アップセルの販売）。

ターゲティングトラッキング技術: 他のサイトでの顧客の同意された行動を含めて、個別化を拡張します。

Roktが適切にあなたの目標を達成するためには、顧客がブロックを指示する範囲だけ制限することをお勧めします。

多くのパートナーがコンセント管理プラットフォーム（CMP）、「クッキーバナー」、またはブラウザトラッキングをオプトアウトするための他のツールを採用しているため、Roktは特定のセッションでブラウザ識別子の使用を停止するよう指示するフラグ（noFunctional）をWeb SDKに実装しました。

これを簡単に実装できるようにするために、Roktは一般的なCMPの用語を使用しています。

実装​

フラグ、noFunctional、はRokt.createLauncher呼び出しの一部として含めることができるブール値です。

  • Roktがこのフラグを: trueとして受け取ると、デバイス識別子の使用を適切なユースケースに対応するために防ぎます。
  • ブラウザにトラッキングIDが存在しない場合、適用可能なブラウザIDを顧客のブラウザに書き込んだり、Roktのシステムと統合したりしません。
  • 一つ以上のブラウザトラッキングIDが存在する場合、許可されていない既存のIDを無視し、そのセッション内での識別にRoktのシステムと統合しません。Roktは既に存在するIDを削除しませんが、セッション中に無視します。
注記

これらのフラグはブラウザIDにのみ影響します。emailやphone numberなどの他の識別子は、パートナーの裁量で提供され、通常通り使用されます。

RoktがnoFunctionalまたはnoTargetingを: falseまたはその他の値として受け取る場合、またはフラグが属性ペイロードに含まれていない場合は、通常通りブラウザIDを使用し続けます。顧客がCMPなどを通じて追跡のオプトアウトを選択した場合にのみ、フラグを: trueに設定することをお勧めします。

例の実装​

await window.Rokt.createLauncher({
  accountId: "rokt-account-id",
  noFunctional: true,
});
この記事は役に立ちましたか？