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

Web SDKのセキュリティ

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

目標​

Roktのセキュリティ目標には次のものが含まれます:

  • パートナーはRoktに提供されるデータを管理できるべきである
  • 悪意のあるコードがパートナーのページ上で unintentionally または intentionally 実行されることはない
  • 悪意のあるコードがホストページに含まれるプライベート顧客情報に自由にアクセスできることはない

アプローチ​

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の孤立した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コンテンツと相互作用できず、逆もまた然り、つまり2つのコンテキスト間の隔離が強制されます。

さらに、私たちは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間で発生します。

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

プライバシー​

Roktは、あなたの実装に含めることができるオプションを提供し、異なる顧客体験を提供できるようにし、顧客が異なるクッキープリファレンスを決定できるようにします。

データ削除のサポート​

Roktは、パートナーがお客様のリクエストとプリファレンスを遵守するためにデータ削除リクエストをRoktに送信する機能を提供します。

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

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

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

私たちの多くのパートナーが同意管理プラットフォーム（CMP）、"クッキーバナー"、または顧客がブラウザー追跡からオプトアウトできるようにする他のツールを採用しているため、当社のWeb SDKには、Roktに特定のセッションでブラウザー識別子の使用を停止させるように指示できる2つのフラグ（noFunctional と noTargeting）を実装しました。

これを実装しやすくするために、Roktは一般的なCMPと同じ用語を使用しています。

実装​

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

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

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

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

影響​

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

実装例​

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