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

Web SDKのセキュリティ

Roktは、Web SDKの統合が安全であることを確保することに取り組んでおり、製品にセキュリティを組み込むことを目指しています。また、クライアントのデータが最も厳格な管理下で管理されるように、あらゆる注意を払っています。これは継続的な取り組みであり、セキュリティを向上させるために、プロセス、コントロール、および技術を継続的に改善することを目指しています。

目標​

Roktのセキュリティの目標は以下の通りです：

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

アプローチ​

Roktは、親ページの表面積を最小限に抑えるために、ほとんどの機能をサンドボックス化されたクロスオリジンのiframeに配置しています。親ページにはRokt Integration Launcherを含める必要がありますが、これには非常に少ない依存関係があります。これらの依存関係は、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の分離されたiframesを読み込むために使用されます。

注記

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

サブリソース整合性（SRI）​

注記

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

サブリソース整合性（SRI）は、ブラウザが取得するリソース（たとえば、コンテンツ配信ネットワークから）が予期しない操作なしで配信されていることを確認するためのセキュリティ機能です。

なぜRoktはWeb SDKのSRI統合をサポートしていないのですか？​

当社のWeb SDKの最新バージョンを使用することは重要です。なぜなら、セキュリティ、パフォーマンス、互換性を継続的に向上させているからです。パートナーがRoktスクリプトにSRIを適用する場合、その特定のバージョンにロックされることになります。その後、更新がリリースされるたびに、パートナーが最新バージョンに手動で更新することに頼る必要があります。更新は2週間に1回の頻度で行われることもあります。バージョンが遅れると、統合が意図した通りに機能せず、アラームが発生し、パフォーマンスやダウンタイムなどの内部メトリックに影響を与える可能性があります。

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

Roktが提供するコードが改ざんされずに配信されることを保証するために、ネットワーク転送から内部エンジニアリングプロセスまで、多層のセキュリティを採用しています。広く言えば、rokt.comからのファイルをhttps経由で取得することは、SSLプロトコルによってファイルが当社の内部サービスから発信されていることを保証するため十分です。

内部ネットワーク内からの改ざんを防ぐために、Roktは効果的なサービスセキュリティを規定する関連する標準に準拠しています。

当社はISO/IEC 27001に準拠しており、これは情報セキュリティの管理に関する国際的な主要な標準です。当社の組織のプラクティスにより、内部サービスが外部攻撃にさらされることはありません。その他のプラクティスとともに、ソースコードへのアクセスにはマルチファクタ認証（MFA）が必要であり、更新は展開される前に堅牢なレビューと監査プロセスの対象となります。

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

Roktのソリューションは、クロスオリジンのiframesの使用に大きく依存しています。当社のiframesは、エンドポイントapps.rokt.comから読み込まれ、同一オリジンポリシーが自動的に適用されます。これにより、パートナーのコードとRoktのiframedコンテンツが相互に干渉することはなくなり、つまり、2つのコンテキスト間の分離が強制されます。

さらに、当社はiframesにsandbox属性を使用しています。sandbox属性は、iframesで許可される機能を大幅に制限します。Roktは、iframesが正しく機能するために必要な例外のリストを維持するため、sandbox属性を自動的に適用します。配置のiframeの場合、次の例外のリストが使用されます。

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

postMessage通信​

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

この通信は、2つのエンド（2つのポート）を持つパイプと考えることができます。ポートの交換をpostMessageを介して制限し、制御するドメインのみがメッセージを受信できるようにします。これにより、Roktのiframesのみがランチャーからメッセージを受信し、お互いにメッセージをやり取りできるようになります。配置コードがペアのポートを受け取った後、すべての通信はこの確立されたチャネルを介して行われます。

プライバシー​

Roktは、実装に含めることができるオプション性を提供しており、異なる顧客体験を提供し、お客様に異なるクッキーの設定を決定させることができます。

機能追跡技術: お客様自身のサイトで最も関連性の高く最適な顧客体験を提供することができ、パーソナライズが強化されます。また、チェックアウト内の高度な機能（例：アップセルの販売）にも役立ちます。

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

Roktがお客様の目標を適切に満たすためには、お客様がブロックすることを示すだけ制限することをお勧めします。たとえば、お客様がターゲティングクッキーを受け入れないと示す場合、機能クッキーも制限しないことをお勧めします。

多くのパートナーが同意管理プラットフォーム（CMP）、"クッキーバナー"、またはその他のツールを採用してブラウザのトラッキングをオプトアウトすることを許可するため、私たちはWeb SDKに2つのフラグ（noFunctionalおよびnoTargeting）を実装しました。これにより、特定のセッションでRoktにブラウザ識別子を特定の方法で使用しないようにパートナーが指示できます。

これを簡単に実装するために、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、他の値、またはフラグが属性ペイロードに含まれていない場合、Roktは通常どおりブラウザのIDを使用し続けます。お客様がCMPまたはその他のオプトアウトプロセスを介してトラッキングをオプトアウトした場合にのみ、フラグをtrueに設定することをお勧めします。

影響​

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

実装の例​

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