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 https://apps.rokt-api.com https://apps.roktecommerce.com https://sourcemaps-wsdk.roktinternal.com;
frame-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com;

スクリプトソースは、ランチャーをパートナーページにロードするために必要です。パートナーがファイルを自分でホスティングする場合、この変更は不要です。フレームソースは、Rokt の分離された iframe をロードすることを可能にします。

注記

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

注記

上記の指令は、Rokt 配置を自分のページでホスティングしている パートナー 向けです。Rokt Ads Web SDK を統合している 広告主 またはパートナーサイト上の Rokt 配置内でページが表示される場合は、コンテンツセキュリティポリシー設定 を参照してください。

サブリソースインテグリティ (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はtargetOriginパラメータをpostMessageで使用して、同じドメイン上のiframe間の通信のみを保証することができなくなります。
• allow-popupsは、iframe内のコンテンツがリンク（例：トラフィックキャンペーン、利用規約）を新しいタブで開くことを許可します。
• allow-popups-to-escape-sandboxは、他のサイトへのリンクを含むキャンペーンが正しく機能するようにします。そうでなければ、私たちのiframeと同じサンドボックスルールに制限されることになります。
• allow-formsは、リソースがフォームを送信できるようにします。これはRoktのソリューションには必要ありませんが、広告主の中にはページ上でフォーム送信を必要とする場合があります。

postMessage通信

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

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

プライバシー

データ削除のサポート

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

クッキーオプトアウトのサポート

パートナーは、ユーザーの同意の好みに合わせてRoktの実装を設定し、それに応じて異なる顧客体験を提供することができます。

機能的トラッキング技術: これにより、サイト上でのパーソナライズされた最適化された体験が可能になり、チェックアウト内での機能が強化されます（例えば、アップセルの提示など）。

ターゲティングトラッキング技術: これにより、他のサイトで収集された適切な同意を得た顧客の行動を使用してパーソナライズが拡張されます。

パートナーは、顧客が示した制限レベルを尊重し、それに応じて実装を設定することが推奨されます。

同意管理プラットフォーム（CMP）、クッキーバナー、類似のツールを使用するパートナーをサポートするために、Rokt Web SDKには、特定のセッションに対してブラウザ識別子やトラッキング技術の使用を防ぐためにパートナーが設定できる2つの設定可能なフラグが含まれています。

これらのフラグは、一般的なCMPで使用される用語と一致しており、実装が容易です。

実装

パートナーは、SDKの初期化時にwindow.mParticle.config.launcherOptionsに以下のフラグをブール値として含めることができます。

noFunctional

• trueに設定すると、パートナーはそのセッションに対してデバイス/ブラウザ識別子の使用を無効にするようSDKに指示します。クッキーやブラウザストレージは書き込まれません。
• 既にブラウザトラッキングIDが存在しない場合、SDKは顧客のブラウザに適用可能なブラウザIDを書き込んだり、そのセッション中にRoktシステムに識別子を接続したりしません。
• 1つ以上のトラッキングIDが既に存在する場合、SDKはそれらの識別子を無視し、そのセッション中にRoktシステムと関連付けません。既存のIDはブラウザから削除されませんが、使用されません。
• ユーザーの身元は自動的に確立されません。セッションのユーザー認識を有効にするには、パートナーは初期化時にユーザー識別子（メールアドレスや顧客IDなど）を明示的に渡すか、適切なタイミングでmParticle.Identity.identify()を呼び出す必要があります。識別子が提供されない場合、その訪問のセッションは匿名として扱われます。シングルページアプリケーションの場合、これを一度行うだけで済みますが、マルチページアプリケーション（またはSDKが再ロードされるたびに）では、再度識別する必要があります。

noTargeting

• trueに設定すると、パートナーはクロスサイトターゲティングおよびパーソナライズのためのブラウザ識別子の使用を無効にするようSDKに指示します。
• 機能的識別子は、noFunctionalもtrueに設定されない限り、アクティブなままです。
• 両方のフラグは、独立してまたは一緒に使用して、詳細な同意制御を行うことができます。

注記

これらのフラグは、ブラウザベースの識別子にのみ適用されます。他の識別子（メールアドレスや電話番号など）は、パートナーの裁量で提供されることができ、パートナーの設定に従って使用され続けます。

パートナーがnoFunctionalまたはnoTargetingをfalseに設定した場合、フラグを省略した場合、または他の値を使用した場合、ブラウザ識別子は設定された通りに使用されます。

パートナーは、顧客が同意管理プラットフォーム（CMP）やパートナーが実装した他のオプトアウトメカニズムを通じてトラッキングをオプトアウトした場合にのみ、これらのフラグをtrueに設定する必要があります。

例の実装

// Include this as part of the initialization script
window.mParticle.config.launcherOptions = {
  noFunctional: true,
  noTargeting: true,
};