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

Web SDKのセキュリティ

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

目的​

Roktのセキュリティ目的には以下が含まれます：

  • パートナーがRoktに提供するデータを制御できること
  • パートナーページで悪意のあるコードが偶然または意図的に実行されないこと
  • ホストページに含まれるプライベートな顧客情報に悪意のあるコードが任意にアクセスできないこと

アプローチ​

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

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

  • 最新かつ最新のライブラリおよびフレームワークの依存関係
  • Roktスクリプトの認可されたソースのホワイトリスト化
  • より厳しいContent Security Policy (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週間に一度の頻度で更新されることがあります。バージョンが遅れると、統合が意図した通りに機能せず、アラームが発生し、パフォーマンスやダウンタイムなどの内部メトリクスに影響を与える可能性があります。

この理由から、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を使用して行われます。この通信は、パートナーのページにホストされているRokt統合とRoktプレースメントのiframeの間で行われます。

この通信は、両端にポートがあるパイプのように考えることができます。私たちは、postMessagesを通じてポートの交換を制御するドメインに制限しています。これにより、RoktのiframeのみがLauncherからのメッセージを受信し、相互に通信できるようになります。プレースメントコードがペアのポートを受信した後、すべての通信はこの確立されたチャネルを介して行われます。

プライバシー​

Roktは、異なる顧客体験を提供し、顧客が異なるクッキーの設定を選択できるようにするオプションを提供しています。

データ削除のサポート​

Roktは、パートナーが顧客のリクエストと好みに応じてRoktにデータ削除リクエストを送信する機能を提供しています。

機能追跡技術: 自サイト上で最も関連性が高く最適な顧客体験を提供し、パーソナライズを強化します。また、チェックアウト内の高度な機能（例: アップセルの販売）をサポートします。

ターゲティング追跡技術: 他のサイトでの顧客の同意された行動を含むパーソナライズを拡張します。

Roktが目標を十分に達成するためには、顧客がブロックを示した範囲だけを制限することをお勧めします。例えば、顧客がターゲティングクッキーを受け入れないと示した場合、機能クッキーも制限しないことをお勧めします。

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

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

実装​

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

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

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

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

影響​

Roktのコンバージョンアトリビューション技術は、noTargeting フラグによってブロックされるいくつかの識別子をサポートしているため、このフラグを追加すると特定のトランザクションで表示されるオファーのパフォーマンスを測定する能力に影響を与えます。このフラグがパートナーによって過度に使用されると（例：すべてのトランザクションに適用される場合）、そのパートナーの測定されたパフォーマンスが低下し、広告主のボリュームと入札価格が下がる可能性があります。お客様が特にオプトアウトを希望した場合にのみ、このフラグを使用することを強くお勧めします。

実装例​

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