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週間に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は、2つのポートを含む構造です。この通信は、パートナーのページにホストされているRokt統合とRoktプレースメントのiframe間で行われます。

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

プライバシー

データ削除のサポート

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

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

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

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

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

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

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

このフラグは、一般的なCMPで使用される用語に合わせており、実装が容易です。

実装

パートナーは、Rokt.createLauncher 呼び出しで noFunctional フラグをブール値として含めることができます。

• true に設定すると、パートナーはそのセッションでデバイス/ブラウザ識別子の使用を無効にするようにSDKに指示します。
• 既にブラウザのトラッキングIDが存在しない場合、SDKは顧客のブラウザに適用可能なブラウザIDを書き込んだり、そのセッションでRoktシステムに識別子を接続したりしません。
• 1つ以上のトラッキングIDが既に存在する場合、SDKはそれらの識別子を無視し、そのセッション中にRoktシステムと関連付けません。既存のIDはブラウザから削除されませんが、使用されません。

注記

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

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

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

実装例

await window.Rokt.createLauncher({
  accountId: "rokt-account-id",
  noFunctional: true,
});