CrowdStrikeとNetskopeの統合ソリューションガイド

Zero Trust Risk Framework: Building Adaptive Policy with CrowdStrike Context

セキュリティアーキテクトおよびポリシー管理者のための戦略的・運用的統合ガイド

1. はじめに

ゼロトラストは戦略であり、スイッチではありません。アクセスを「許可」または「ブロック」という2つの状態で制御することは、複雑な脅威環境において、セキュリティチームにとって不十分な手段となります。現実世界のポリシーは、現実世界のリスクと一致している必要があります。たとえば、午前9時に標準的なSaaSツールにアクセスする、完全にパッチが適用された健全な企業用ラップトップを使用しているユーザーの場合などです。は、セキュリティ体制が低下したデバイスを使用して、通常とは異なる場所から機密性の高いクラウドワークロードにアクセスする同じユーザーとは、異なるエクスペリエンスを受けるべきです。

NetskopeのZero Trust Engineは、Netskope Oneプラットフォームの中核に位置しています。すべてのトランザクションをリアルタイムでデコードおよび復号し、50以上のコンテキスト変数を継続的に評価してきめ細かなリスクプロファイルを構築した上で、そのプロファイルに一致する正確なポリシーを適用します。CrowdStrikeは、Netskope単独では把握できないエンドポイント、アイデンティティレイヤー、および脅威インテリジェンスネットワークからの高精度なシグナルを使用して、そのプロファイルを拡張します。

本書では、ゼロトラストリスクフレームワークと完全な統合マップについて説明します。これには、プラグインバージョン、必要なAPIスコープ、ライセンスの前提条件、2つのインジデントの指標共有方法の比較、トラブルシューティングの参照先、サポートのエスカレーションパス、CrowdStrike側のコンソールから直接Netskopeアクションをトリガーできるようにする逆方向の統合（セクション4.11）、Falcon次世代SIEMへのAI SecOpsイベントパイプライン（セクション4.9.3）、デバイス Tags APIを使用したフィールド構築型のSOARパターン（セクション4.11.3）、および既存の機能を別の名前で再パッケージ化したマーケットプレイスリストに関する注記（セクション4.12）が含まれます。

Intended Audience

NetskopeとCrowdStrikeの共同展開を構築または改善するセキュリティアーキテクト、ゼロトラストプログラムリード、およびポリシー管理者。本書全体でリンクされている個別の統合ガイドは、正確な設定手順に関する信頼できる情報源であり、UI画面が本書の記載と異なる場合に最初に確認すべき場所です。NetskopeのCloud ExchangeプラグインUIは、リリースごとに変更されます。

1.1 用語集

この文書全体で略語が使用されています。本文では初回使用時に完全な形式が記載されています。完全なリストは参照のために以下に記載します。

Term	正式名称／定義
ZTA	ゼロトラスト評価 — CrowdStrikeの継続的なデバイスヘルススコア
ZTNA	ゼロトラストネットワークアクセス — アプリケーション単位のID認識型リモートアクセス（Netskope Private Access）
上羽	ユーザーおよびエンティティ行動分析（UEBA） — Netskopeの行動リスクスコアリングエンジン
CCI	Cloud Confidence Index — クラウドアプリケーションに対するNetskopeのリスク評価
DLP	DLP - 情報漏洩対策
IOC	侵害の指標（悪意のあるハッシュ、ドメイン、IPなど）
IOA	攻撃の指標（Indicator of Attack） — アクティブな攻撃手法の行動上の証拠
IOM	設定ミスの指標 — 攻撃対象領域を拡大するクラウドリソースの設定
CVE	Common Vulnerabilities and Exposures（CVE） — 既知のソフトウェア脆弱性に対する公開識別子
SCIM	System for Cross-domain Identity Management (SCIM) — テナント間でユーザーやグループを同期するために使用されるプロトコル
XDR	拡張版の検出と対応（XDR）
SIEM	セキュリティ情報イベント管理（SIEM）
RTR	Real-Time Response — CrowdStrikeのリモートホストアクセスおよびスクリプト実行機能
CE	Cloud Exchange — Netskopeのローコード統合ブローカ
CRE	Cloud Risk Exchange — Cloud Exchangeの統合リスクモジュール。Cloud Exchange v4.1.0以降、CREは、以前は別々であったUser Risk Exchange（URE）およびApplication Risk Exchange（ARE）サブモジュールを、デバイス、ユーザー/ホスト、ID、およびアプリケーションのリスクスコアをまとめて取り込む1つのRisk Exchangeモジュールに統合します。Netskopeナレッジポータルの個々のサードパーティプラグインリストには、名称にレガシーな「(URE)」サフィックスが付いている場合がありますが、すべてこの単一の現行世代のRisk Exchange（CRE）モジュールで構成および実行されます。本書でのグループ化については、セクション3.2を参照してください。
URE	User Risk Exchange — ユーザー/ホストリスクサブモジュールの旧名称。現在は CRE に統合されています（上記の CRE を参照）。特定のプラグインの正式名称に含まれる場合にのみ、このドキュメントに残しています。
CSPM	クラウドセキュリティポスチャ管理
NPA	Netskope Private Access
SSE	Security Service Edge（SSE）
SASE	セキュアアクセスサービスエッジ
MTTR	平均応答/解決時間
RBAC	ロールベースのアクセス制御（RBAC）
CASB	Cloud Access Security Broker
SOAR	セキュリティオーケストレーション、自動化、レスポンス（SOAR）
ECS	Elastic Common Schema — 正規化されたフィールド命名規則（event.action、event.severity、など）であり、CrowdStrikeのnetskope-sseパーサーがNetskopeイベントをFalcon Next-Gen SIEM内にマッピングします。
HEC	HTTP Event Collector — HTTP経由でWebhook配信されたイベントを受信するFalcon次世代SIEMコネクタタイプ

2. Netskopeゼロトラストリスクフレームワーク

2.1 Zero Trust Engine

Zero Trust Engineは、Netskopeのインライン・ポリシー適用およびリスク評価ファブリックです。これは、Netskopeがレイヤー8と呼ぶ従来のネットワークスタックの上位で動作し、誰がどこに接続しているかだけでなく、何をしているか、どのデータを使用しているか、どのアプリケーションインスタンスで、どのようなリスク条件下にあるかを把握します。すべてのトランザクションは、ポリシーの結果が適用される前に、この完全なコンテキストに基づいて評価されます。

エンジンは継続的な適応型信頼度を適用します。セッション確立時に一度だけアクセス判断を下して終了するわけではありません。リスクテレメトリは継続的に収集され、リスクプロファイルが変化した場合はセッションの途中でポリシーが変更される可能性があります。

2.2 リスクコンテキストの5つの次元

Netskopeのポリシーは、5つの次元にわたるリスクを同時に評価します。各次元は、CrowdStrikeからのシグナルを含む外部シグナルによって強化できます。

Dimension	Netskopeが評価するもの
ユーザー	ユーザーとは誰か？彼らの行動リスクスコア（UEBA：ユーザーおよびエンティティの行動分析）はどの程度か？ピアグループと比較して異常があるか？リスクグループとしてフラグが立てられているか？
デバイス	デバイスは管理対象ですか、それとも非管理対象ですか？そのセキュリティポスチャ（エージェントのインストール、OSのパッチ適用、ディスクの暗号化、証明書の有効性など）はどうなっていますか？そのデバイスで脅威は検出されましたか？
応用	どのアプリケーションにアクセスしていますか？そのCCI（Cloud Confidence Index）リスクスコアはいくつですか？ユーザーは個人用インスタンスと企業用インスタンスのどちらにアクセスしていますか？これは承認されたアプリケーションですか？
Data	関連するデータの機密性はどの程度ですか？DLP（データ損失防止）プロファイル（PII、ソースコード、財務データ、規制対象コンテンツなど）に一致しますか？どのようなアクティビティが実行されていますか（閲覧、アップロード、共有、ダウンロード、印刷など）？
ネットワーク / 場所	ユーザーはどこから接続していますか？送信元IPまたは場所は、通常の動作と一致していますか？宛先は既知の悪意のあるドメインまたはIPですか？

2.3 ポリシーアクション：成果のスペクトル

Zero Trust Engineは5つの次元すべてを統合して評価するため、ポリシーの結果は、許可/ブロックの二者択一の決定よりもはるかに正確になります。以下の結果を利用でき、リスクスコアのしきい値に基づいて組み合わせたり、条件付きでトリガーしたりできます。

アクション	使用するタイミング
Allow	制限なしのフルアクセス。低リスクかつ高信頼性の取引のために予約されています。
警告	アクセスが許可されます。セキュリティイベントがログに記録され、SIEM（セキュリティ情報およびイベント管理）アラートをトリガーする可能性があります。
Coach/Justify	ユーザーに警告が表示されます。ユーザーは、操作を続行する前に、その操作を承認または正当化する必要があります。ワークフローを中断することなく、境界リスクの状況に対して有効です。
アクティビティを制限する	アプリケーションへのアクセスは許可しつつ、その中の特定のアクティビティをブロックします。例：表示とダウンロードは許可し、アップロード、共有、印刷はブロックします。
ステップダウンアクセス	リスクの増加に応じてアクセス範囲を縮小します。デバイスリスクスコアが中程度のユーザーは読み取り専用アクセス権が付与される可能性があり、スコアが高いユーザーはアクセス権が付与されない可能性があります。
Remote Browser Isolation	ユーザーが高リスクの宛先にアクセスする場合、セッションを境界付きの中継点であるリモートブラウザ経由でルーティングし、コンテンツがローカルで実行されないようにします。完全にブロックすべきではない、未検証またはリスクのあるサイトに対して有効です。
検疫	ファイルのアップロードまたはダウンロードをインターセプトし、レビューのために隔離場所にルーティングします。
Block	アクセスを完全に拒否します。リスクが定義されたしきい値を超える場合、または宛先が悪意のあるものであることが判明している場合に適用されます。
デバイスの再分類	デバイスの管理/非管理ステータスをリアルタイムで変更し、別のポリシー階層を自動的にトリガーします。
ユーザーをグループに移動	ユーザーをアクセス制限グループに自動的に割り当て、より制限の厳しいポリシーセットを適用します。
ユーザー通知	ITSM、電子メール、またはSlack経由で、ユーザーとそのマネージャーに通知をトリガーします。

3. 統合戦略：CrowdStrikeがNetskopeポリシーを強化する方法

CrowdStrikeは、インラインのトラフィック検査だけではZero Trust Engineが導き出せない4つのカテゴリのシグナル（デバイスの健全性、ユーザーIDのリスク、脅威インテリジェンス、クラウドワークロードのポスチャ）を提供します。各カテゴリは、セクション2で説明されている5つのリスク次元の1つ以上に反映され、手動介入が必要となるようなポリシーの結果を自動化します。

統合には主に2つのチャネルが使用されます：

• Netskope Cloud Exchange (CE)：Risk Exchange (CRE)、Threat Exchange、Log Shipper、およびITSMワークフロー用のプラグインをホストする、ローコードのセルフホスト型統合プラットフォームです。
• CrowdStrike Falcon Foundry：Direct to Zero Trust Appをホストするネイティブアプリケーションフレームワーク。IOC（侵害指標）を正規化および重複排除してから、NetskopeのURLリストおよびファイルリストにプッシュします。

3.1 アーキテクチャの概要

以下の図は、Netskope Zero Trust EngineとCrowdStrike Falconプラットフォームの間で2つのチャネルがどのように配置されているかを示しています。Cloud Exchangeは顧客が運用するブローカ（顧客がセットアップおよび保守するVM）です。一方、Falcon FoundryのDirect to Zero Trust AppはCrowdStrikeがホストするネイティブアプリであり、個別のインフラストラクチャは不要です。どちらも最終的には同じNetskopeポリシーサーフェス（URLリスト、ファイルハッシュリスト、デバイス分類、ユーザーグループ）に書き込みます。各双方向フローは並列の矢印ペアとして描かれ、逆方向のSOAR/XDRフロー（セクション4.11）は右端に沿って独自のパスを持っています。

3.2 統合から成果へのマッピング

この表の前の用語に関する注記：現在のCloud Exchangeリリース（v4.1.0以降）デバイス、ユーザー/ホスト、ID、およびアプリケーションのリスクスコアを1つのリスクエンジンに取り込む、Cloud Risk Exchange（CRE）と呼ばれる単一の統合されたRisk Exchangeモジュールを使用します。これは、User Risk Exchange（URE）とApplication Risk Exchange（ARE）が、デバイスに焦点を当てたRisk Exchangeと並んで個別のモジュールとして配置されていた以前のアーキテクチャに代わるものです。そのような以前の分割が、Netskopeナレッジポータルの一部の個別のプラグインリストにおいて、製品名にレガシーなURE）というサフィックスが残っている理由です。このプラグインは、現在では単一の現世代Risk Exchange（CRE）モジュールの下で構成および実行されるようになっていますが、名前は変更されていません。

実用的な観点から言えば、これはRisk Exchangeにデータを提供する以下の行が、いずれか1つを選択するような競合する代替手段ではないことを意味します。これらは、それぞれ異なるスコアタイプ（デバイスの健全性、ホスト/ユーザーリスク、IDリスク）を同じCREエンジンに提供する補完的なプラグインであり、一般的な導入環境ではこれらを一度に複数実行し、単一のビジネスルール内でスコアを組み合わせます。以下のグループ分けは、各統合が提供するシグナルの種類に基づいて表を整理したものであり、モジュール名に基づいたものではありません。これにより、各行の役割が明確になり、個別のシステム間で選択する必要がないことがわかります。

Integration	貢献したスコアタイプ	主要なポリシーの成果	プラグイン/アプリのバージョン	Module
Device Risk — Endpoint Health
CrowdStrike ZTA スコア	デバイスの健全性	「管理対象」から「非管理対象」への再分類。スコアしきい値に基づいてアクセスを段階的に制限またはブロックします。	CRE v1.1.0+	リスクエクスチェンジ（CRE）
User and Host Risk
CrowdStrikeホストリスク（User Risk Exchange）	ユーザーとホストのリスク	ユーザーを制限付きグループに移動、アップロードを制限、ZTNA（ゼロトラストネットワークアクセス）セッションのスコープを縮小	以前はURE v1.2.0とラベル付けされていましたが、現在のCloud ExchangeではCREの下で実行されます	リスクエクスチェンジ（CRE）
Falcon Identity Protection	アイデンティティリスク	侵害されたクレデンシャルまたは異常なID行動を持つユーザーのアクセスをブロックまたは制限します	以前はURE v1.0.0（netskope-ce-4.1.0-ure-crowdstrike_identity_protect）とラベル付けされていました；現在のCloud ExchangeではCREの下で実行されます	リスクエクスチェンジ（CRE）
Cloud Workload and Vulnerability Risk
Falcon Cloud Security	クラウドワークロードのリスク（IOA/IOM）	クラウドワークロードのIOA（攻撃の指標）およびIOM（設定ミスの指標）をNetskopeのリスクポスチャにフィードし、CSPM対応のポリシーを実現します	CRE（現在のGA — プラグインストアで確認してください）	リスクエクスチェンジ（CRE）
Falcon Spotlight	デバイスの脆弱性（CVE）	脆弱性スコアがデバイスリスクに反映され、CVE値が高いデバイスにはより制限の厳しいアクセスが適用されます	CRE v1.0.0	リスクエクスチェンジ（CRE）
Threat Intelligence (IOC Sharing)
Threat Exchange（インジデントの指標共有）	該当なし — インジデントの指標データ（リスクスコアではありません）	既知の悪意のあるドメイン/IP/URLへのアクセスをブロックし、悪意のあるファイル転送を隔離またはブロックします	CTE v2.3.0	脅威交換
ゼロトラストアプリへの直接アクセス (Falcon Foundry)	該当なし — インジデントの指標データ（リスクスコアではありません）	CrowdStrikeの検知からNetskopeのURLおよびファイルリストへのインジデントの指標の自動取り込み	Falcon Foundry ネイティブアプリ（CrowdStrike 管理のバージョン管理）	Falcon Foundry（ネイティブ）
Incident Response and Visibility
XDR統合 (SCIM + アラート共有)	該当なし — ID同期 + アラート相関	検出時の自動グループ再割り当て、双方向のインシデントエンリッチメント	該当なし (ネイティブSCIM 2.0 + REST API v2/RBAC v3トークン)	ネイティブXDR + SCIM
LogScale/NG-SIEM (Log Shipper)	該当なし — ログデータであり、リスクスコアではありません	統合されたSOC調査のために、NetskopeのウェブトランザクションログをCrowdStrikeに集約する	Log Shipperプラグイン / ネイティブS3ストリーミング	Cloud Exchangeまたはネイティブ
Netskope SOAR アクション（Falcon Fusion SOAR）	該当なし — アクションのトリガー、逆方向	Falcon Fusion SOARプレイブックから直接Netskopeアクション（例：制限付きグループへのユーザーの追加/削除、クラウドガバナンス設定の適用など）をトリガーします	CrowdStrike Marketplace リスト（CrowdStrike製コネクタ）	Falcon Fusion SOAR（ネイティブ）
Falcon Insight XDR向けのNetskope応答アクション	該当なし — アクションのトリガー、逆方向	Fusionワークフローを完全に構築することなく、検知時にFalcon Insight XDRコンソールから直接Netskope SSEのレスポンスアクションをトリガーします。	CrowdStrike Marketplace リスト（CrowdStrike製コネクタ）	Falcon Insight XDR（ネイティブ）
Netskope AI SecOpsイベントからFalcon次世代SIEMへの送信（アウトバウンドWebhook）	該当なし — ケース、ユーザーリスク、およびAIリスクのイベントデータであり、リスクスコアではありません	AI SecOpsケース、ユーザーリスク、およびAIリスクイベントを、SOCでの相関分析と検索のためにECSフィールドへ事前解析した上で、Falcon Next-Gen SIEM (LogScale) にほぼリアルタイムで配信します。	NetskopeネイティブのOutbound Webhook + Falcon HEC/HTTPイベントコネクタ、netskope-sseパーサーパッケージ	ネイティブ（Webhook）+ Falcon Next-Gen SIEM

プラグインのバージョン番号は頻繁に変更されます。Netskopeは、各Cloud Exchangeプラグインに対して増分アップデートを個別に提供しています。デプロイ前に、必ずご自身のCloud Exchangeテナント内の「Settings > Plugin Store」で現在のバージョンを確認してください。

最後のグループにある2つのFalcon Fusion SOAR / Insight XDRの行は、この表の他のすべての行とは逆方向に流れます。つまり、CrowdStrikeのシグナルがNetskopeのポリシーに供給されるのではなく、アナリストまたは自動化されたCrowdStrike側のワークフローが、直接Netskopeのアクションを呼び出します。詳細については、セクション4.11をご覧ください。

4. 統合の徹底解説

以下の各セクションでは、統合によってどのようなシグナルが提供されるか、それがどのようにNetskopeポリシーエンジンに入力されるか、セットアップにかかるコスト（ライセンスおよび前提条件）、およびそれによってどのような成果が得られるかを説明します。各セクションの最後には、APIスコープの要件、トラブルシューティングのクイックリファレンス、および完全な実装ガイドへのポインタが記載されています。

セクション3.2で述べたように、以下のセクション4.1から4.3は、選択すべき3つの別個のシステムではありません。これらは、すべて異なるスコアタイプで単一の現行世代のRisk Exchange（CRE）モジュールにフィードする3つのプラグインです。一般的な本番環境のデプロイメントでは、これら3つすべてを同時に実行し、ビジネスルールでスコアを組み合わせます。各セクションを分けているのは、それぞれ個別に理解しておくべき異なる前提条件、APIスコープ、スコア変換動作があるためです。

4.1 デバイスリスク：Risk Exchange（CRE）経由のCrowdStrike ZTAスコア

CrowdStrike Zero Trust Assessment (ZTA) スコアは、センサーから得られるデバイスの健全性に関する継続的な評価です。OSのパッチレベル、セキュリティエージェントの健全性、ディスク暗号化の状態、ファイアウォールのステータス、およびアクティブな脅威の存在を評価します。CrowdStrikeのネイティブスコアは0～100の範囲です（100が最も健全）。

Score scale. Read this before configuring 4.1 and 4.2 together.

セクション4.1（デバイスの健全性）とセクション4.2（ホスト/ユーザーリスク）は同じRisk Exchange（CRE）モジュールに供給されますが、どちらもCrowdStrikeのホストデータに由来しているにもかかわらず異なる変換ロジックを使用しており、その違いが重要となります。

• ZTAデバイススコア（4.1）：Netskope Cloud Risk Exchange正規化スコア = CrowdStrikeホスト評価の総合スコア × 10。CrowdStrike ZTAの76は、Netskopeスコアの760になります。両方のスケールは同じ方向に機能します。つまり、どちらのシステムでも数値が高いほど健全であり、リスクが低いことを示します。
• ホスト/ユーザーリスクスコア、Falcon Identity Protection（4.2 / 4.3）：CrowdStrike の Identity Protection リスクスコアは 0～1 であり、一部の CrowdStrike サーフェスでは 1 が最小リスク、0 が最大リスクとなります。しかし、Netskope Cloud Exchange のドキュメントでは、この特定のプラグインについて、受信する CrowdStrike のスケールを 0 = 最小リスク、1 = 最大リスクと定義しており、これは ZTA スコアの慣習とは逆になっています。Risk Exchange で使用される変換式は次のとおりです：

Netskope Cloud Risk Exchangeスコア = |(1 − CrowdStrike Identity Protectionリスクスコア)| × 1000。

• 正味の影響：2つのプラグインのCrowdStrike側の生スコアが同じCREモジュールに格納されるからといって、それらが同じ方向に動くと想定しないでください。ビジネスルールのしきい値を記述する前に、必ずCloud Exchange > Plugin Activityで各プラグイン独自の変換メモを確認し、本番環境で自動再分類を有効にする前に既知のテストホストで検証してください。

What this adds to Netskope policy

ZTAスコアがない場合でも、Netskopeはデバイスの管理ステータス（管理対象か非管理対象か）を評価し、Netskopeクライアント証明書の有無を確認できます。ZTAスコアにより、Netskopeはデバイスの健全性を継続的かつ数値的に測定できるようになり、それをポリシー階層に直接マッピングできます。

• CREは、ブール論理とZTAスコアに基づいてNetskope内にデバイスタグを適用できます。このタグは、デバイスリスクに対するきめ細かなアプローチのために、インラインポリシーのデバイス分類マッチングで使用できます。これにより、ZTAスコアを含む複数の要素を使用して一致を定義できるようになります。
• あるいは、ZTA スコアが定義されたしきい値を下回ったデバイスは、Netskope 内で自動的に「管理対象」から「非管理対象」に再分類され、より制限の厳しいポリシー階層に移行させることができます。スコアが回復すると、デバイスは自動的に「管理対象」に再分類され、手動による介入なしでアクセスが復元されます。
• スコアのしきい値は個別のポリシー階層にマッピングされます。800以上はフルアクセス、500～800は読み取り専用、500未満はブロックとなり、組織ごとに設定可能です。

Prerequisites and licensing

• テナントプラグインとRisk Exchange (CRE) プラグインがすでに構成されているNetskope Cloud Exchangeテナント。
• CREによって作成および適用されたデバイスラベルを使用するように構成されたNetskopeデバイス分類ポリシー。
• ペアリングされたビジネスルールがNetskope CREプラグインを介してNetskopeデバイス分類ルールに書き戻す必要がある場合は、Netskope RBAC v3（またはSCIM）トークンが必要です。
• API Clientから生成されたCrowdStrikeインスタンスのクレデンシャル（Client ID、Client Secret）。
• Put RTRスクリプトを使用する場合は、CrowdStrike Real-Time Response (RTR) 管理者ロールが必要です。各対象プラットフォーム（Windows、Mac）には、Real-Time Response（高リスクコマンド）が有効になっている応答ポリシーが必要です。ただし、RTRスクリプトではなく、デバイスのタグ付け方法を推奨します。

API scopes/setup path

• CrowdStrike: サポートとリソース > APIクライアントとキー > APIクライアントの作成。最低限、Zero Trust Assessment（読み取り）およびHosts（読み取り）スコープを設定してください。RTRアクションを使用する場合は、Real Time Response（読み取り/書き込み）を追加してください。
• Cloud Exchange：設定 ＞ プラグインストア ＞ CrowdStrike v1.1.0（CRE）以降 ＞ クライアントID/シークレットおよびベースURLを入力します。
• Netskopeサービスアカウント：設定 > 管理 > デバイス分類 > 新しいデバイス分類ルール（プラグインによって書き込まれたファイル/タグと照合されます）。新しいロール > NS Client > デバイス、デバイス分類

Troubleshooting quick reference

• プラグイン構成時の403エラー：Client ID/Secretが正しいこと、および上記のスコープが含まれていることを確認してください。また、CrowdStrikeのIP許可リスト管理ページで設定されている場合は、Cloud ExchangeのパブリックIPがそこに含まれていることを確認してください。
• ホストが取得されません：CrowdStrike側の「Host Setup and Management」にホストが実際に存在すること、およびプラグインのエンティティ構成でHost IDフィールドがマッピングされていることを確認してください。
• 一部のホストのスコアが欠落しています：プラグインの「Maximum Score（最大スコア）」設定パラメータを確認してください（プラグインは、スコアがその値以下のホストのみをプルします）。また、overallAssessmentScoreがマッピングされていることを確認してください。
• 500エラー：一時的なCrowdStrike APIの問題です。少し待ってから再試行してください。

→ Implementation guide (Risk Exchange plugin, v1.1.0): Risk Exchange 用 CrowdStrike プラグイン

→ Implementation guide (v1.0.0, superseded): ユーザーリスク交換用のCrowdStrikeプラグイン

→ Community walkthrough: Netskope Cloud Risk ExchangeとCrowdStrike ZTA

知っておくべきDIYの代替案：上記のRisk Exchange（CRE）プラグインだけが、ZTAスコアをNetskopeのポリシーアクションに変換する唯一の方法ではありません。セクション4.11.3では、Cloud Exchangeを完全にスキップし、NetskopeのDevice Tags REST APIを直接呼び出す手動構築のFalcon Fusion SOARワークフローを通じて、同じ結果（デバイスリスクの階層化）を実現するフィールド構築パターンについて説明しています。

4.2 ユーザーおよびホストのリスク：Risk Exchange（CRE）経由のCrowdStrikeホストリスク

このプラグインは CrowdStrike プラットフォームからホストレベルのリスクスコアを収集し、セクション 4.1 と同じ Risk Exchange（CRE）モジュール下で Netskope のユーザーリスクスコアにマッピングします（このプラグインを ZTA プラグインと併用して設定する前に、そちらのスコアスケールに関する注記を参照してください）。Netskope ナレッジポータルにおいて、このプラグインの製品リストには依然として旧名称の「User Risk Exchange（URE）」が記載されています。これは、Cloud Exchange が User Risk Exchange と Application Risk Exchange を単一の CRE モジュールに統合する前の名称の名残です。これは 4.1 とは別のシステムではなく、異なるスコアタイプ（デバイスの健全性ではなくホスト/ユーザーリスク）で同じリスクエンジンにデータを提供する別のプラグインです。

What this adds to Netskope policy

• ホストリスクスコアが高いユーザーは、Netskope内のアクセス制限グループに自動的に移動されます。
• そのグループに適用されるポリシーにより、アップロードの制限、機密アプリケーションへのアクセスブロック、またはZTNAセッションスコープの縮小を行うことができます。
• ホストのリスクスコアが低下すると、ユーザーは自動的に標準グループに戻すことができます。

Prerequisites and licensing

• TenantプラグインおよびRisk Exchange (CRE) プラグインが既に構成されているNetskope Cloud Exchangeテナント。
• Risk Exchange が取得および共有するユーザーリスクスコアを生成するには、通常、Netskope テナントで Advanced UEBA（ユーザーおよびエンティティ行動分析）ライセンスが必要です。パッケージは時間の経過とともに変更される可能性があるため、現在のライセンス範囲についてはNetskopeアカウントチームにご確認ください。
• CrowdStrike APIクライアントのクレデンシャル（クライアントID/シークレット）。

API scopes/setup path

• CrowdStrike: Hosts（読み取り）およびZero Trust Assessment（読み取り）スコープを持つAPIクライアント（このプラグインは、4.1のZTAプラグインと同じホスト評価エンドポイントを再利用しますが、前述の通り変換方法が異なります）。
• Cloud Exchange：設定 > プラグイン > CrowdStrikeホストリスクプラグインを検索（v1.2.0としてリストされ、以前は「(URE)」とラベル付けされていました） > クレデンシャルを入力 > スコア範囲をNetskopeユーザーグループにマッピングするビジネスルールを構成。

Troubleshooting quick reference

• スコアが期待値に対して反転しているように見える場合：これはほぼ確実に 4.1 と 4.2 の比較によるものです。スケールの方向性に関する問題。ZTA プラグインとの同等性を前提とせず、プラグインのドキュメントに記載されている変換式を再確認してください。
• ユーザーがグループに移動しない場合：Netskope CREプラグインで使用されているSCIM（System for Cross-domain Identity Management）またはREST API v2トークンに、Netskopeグループへの書き込みアクセス権があること、およびビジネスルールの照合条件がマッピングされたスコアフィールドに対して評価されていることを確認してください。

→ Implementation guide: ユーザーリスク交換用のCrowdStrikeプラグイン

4.3 IDリスク：Risk Exchange（CRE）を介したFalcon Identity Protection

CrowdStrike Falcon Identity Protectionは、パスワードスプレー、ゴールデンチケットの悪用、横方向の移動、異常な認証パターンといった、クレデンシャルベースの攻撃を検出します。この検出データに基づいて各ユーザーにアイデンティティリスクスコアを割り当てます。これは4.2のホストベースのスコアとは異なる、4.1および4.2で説明されているのと同じRisk Exchange (CRE) モジュールに供給される3つ目の補完的なスコアタイプです。

What this adds to Netskope policy

• IDリスクスコアは高いもののデバイスが健全なユーザーは、機密性の高いアプリケーションにアクセスする前に、ステップアップ認証を経由させることができます。
• IDリスクとホストリスクの両方が高いユーザーは、機密データへのアクセスを完全にブロックできます。
• IDリスクを使用して、特権クラウドワークロードに対するジャストインタイムアクセス（JITアクセス）ポリシーを適用できます。

Prerequisites and licensing

• CrowdStrike Falcon Identity Protectionモジュールライセンス（基本のFalconエンドポイントライセンスとは別）。
• TenantプラグインおよびRisk Exchange (CRE) プラグインが既に構成されているNetskope Cloud Exchangeテナント。
• CrowdStrikeインスタンスのクレデンシャル：ベースURI、クライアントID、クライアントシークレット。正しいベースURIは、ご利用のCrowdStrikeクラウドリージョンによって異なります：commercial (api.crowdstrike.com)、US-2 (api.us-2.crowdstrike.com)、EU (api.eu-1.crowdstrike.com)、またはGovCloud (api.laggar.gcw.crowdstrike.com)。

API scopes/setup path

• CrowdStrike: 「Support and Resources」 > 「API Clients and Keys」 > 「Add New API Client」を選択し、プラグインに必要なIdentity Protectionスコープを設定します（CrowdStrikeはリリースごとにIDスコープの名前を変更しているため、リンク先のガイドで正確なスコープ名を確認してください）。
• Cloud Exchange：プラグインストアで「CrowdStrike Falcon Identity Protection」プラグインを検索します（以前は netskope-ce-4.1.0-ure-crowdstrike_identity_protect-v1.0.0 としてパッケージ化されていましたが、パッケージ名に関係なく現在のCREモジュールで実行されます）。

Score conversion (see also 4.1)

Netskopeリスクスコアのスケール：0～1000（0 = 最大リスク、1000 = 最小リスク）。CrowdStrike Identity Protectionのリスクスコアのスケール：0～1（このプラグインの規約では、0 = 最小リスク、1 = 最大リスク）。計算式：Netskopeスコア = |(1 − CrowdStrikeスコア)| × 1000。Netskope Cloud Risk Exchangeに表示される正規化されたスコアは、CrowdStrike Identity Protectionコンソールに表示される数値とは一致しません。これは想定内の動作です。

Troubleshooting quick reference

• ユーザースコアが取得されません：ユーザーが存在し、CrowdStrike Identity Protection > Users でアーカイブ解除されていることを確認してください。アーカイブ解除されたユーザーのみが取得されます。
• ユーザーがサイレントスキップされました：APIレスポンスのemailAddressesフィールドが空であるか、複数のアドレスが含まれているかを確認してください。どちらのケースも、現在はマッピングされず、プラグインによってドロップされます。
• 権限が不足しています：API Clientのスコープが、プラグインのドキュメントに記載されている「Permissions」セクションと完全に一致していることを再確認してください。

→ Implementation guide: CrowdStrike Falcon User Risk Exchange用ID保護プラグイン 

4.4 脅威インテリジェンス：Threat Exchange用CrowdStrikeプラグイン

CrowdStrike Threat Exchangeプラグインにより、両プラットフォーム間で双方向のインジデントの指標共有が可能になります。CrowdStrikeはドメイン、IPv4、MD5、SHA-256のインジケーターをNetskopeと共有し、Netskopeは悪意のあるサイトおよびマルウェアのアラートデータをCrowdStrikeに共有します。セクション4.1～4.3とは異なり、このプラグインはRisk Exchange（CRE）には一切データを供給しません。これは別のCloud ExchangeモジュールであるThreat Exchangeに属しており、リスクスコアではなくインジケーターデータを共有します。

What this adds to Netskope policy

• CrowdStrikeのドメインおよびIPv4 IOCがNetskopeのURLリストに反映され、リアルタイム保護ポリシーが即座にそれらに対応します。
• CrowdStrike の MD5 および SHA-256 ファイルハッシュが Netskope のファイルハッシュリストに反映され、既知の悪意あるファイル転送のブロックや隔離が可能になります。
• Netskopeの悪意のあるサイトおよびマルウェアのアラートはCrowdStrikeにフィードバックされ、SOC（セキュリティオペレーションセンター）にエンドポイントのテレメトリと併せてクラウド層の脅威コンテキストを提供します。

Prerequisites and licensing

• TenantプラグインおよびRisk Exchange (CRE) プラグインが既に構成されているNetskope Cloud Exchangeテナント。
• 完全な双方向機能（Netskope が生成した IOC の取得と、外部 IOC の適用に向けたプッシュ）には、通常、Netskope REST API v1 と v2 の両方の API トークンが必要です。Netskope は API サーフェスを段階的に v2/RBAC v3 へ移行しているため、リンク先のガイドで現在の要件を確認してください。
• Netskope Advanced Threat Protectionライセンスに加え、Retrohuntベースの遡及的マッチングを使用する場合は、Netskopeプラットフォームチームによって有効化されたRetrohunt APIクエリ機能が必要です。

API scopes/setup path

• CrowdStrike：サポートとリソース > API クライアントとキー > API クライアントの作成。プラグイン v2.3.0 以降、CrowdStrike は、Detect API から Alerts API へ移行しています。CrowdStrike の廃止通知に従い、アップグレード前に Detections（読み取り）スコープを適用し、v2.3.0 へのアップグレード完了後に削除してください。
• CrowdStrikeのIP許可リストが構成されている場合は、「Host Setup and Management」>「Falcon Users」>「IP Allowlist Management」の下にCloud ExchangeのパブリックIPを追加してください。

Version and scale notes

• 現在のドキュメント化されたプラグインバージョン：CTE v2.3.0。
• CrowdStrikeは、IoC管理ページへの最大1,000,000個のIOCの共有のみをサポートしています。上限に達すると、既存のIOCがクリアされるまで、それ以上のIOCは共有されません。
• CrowdStrike で能動的に防御をトリガーするのはファイルハッシュの IOC のみです。ドメイン、IPv4、および IPv6 の IOC は検出/調査のコンテキストとして保存されますが、それ自体が CrowdStrike 側でトラフィックをブロックすることはありません。

Troubleshooting quick reference

• 403エラー：クライアントID/シークレットの有効性を確認し、必要なスコープを確認し、上記のIP許可リストのエントリを確認してください。
• 古いプラグインバージョンからのアップグレードエラー：アップグレード前にクライアントID/シークレットの権限を更新し（上記の「Detect-to-Alerts API」の注記を参照）、その後、不要になったDetectionsスコープを削除してください。
• Retrohunt有効化時の401エラー：通常はテナントレベルの前提条件の欠如であり、APIスコープの誤りではありません。NetskopeによってRetrohunt APIクエリ機能が有効になっていること、有効なAdvanced Threat Protectionライセンスがあること、および使用中のトークンがThreat Protectionスコープ下のマルウェア権限を持つRBAC v3であることを確認してください。
• CrowdStrike側でタイプ／値フィールドが欠落しているIOCは、プル時に警告なしでスキップされます。これはプラグインの予期された動作であり、エラー状態ではありません。

→ Implementation guide: Threat Exchange用CrowdStrikeプラグイン

→ Cloud Exchange FAQs (Detect→Alerts API transition, Retrohunt, file hash 8MB limit): Cloud Exchangeよくある質問

4.5 脅威インテリジェンス：Netskope Direct to Zero Trust App (Falcon Foundry)

Direct to Zero Trust Appは、インジデントの指標管理のためのCloud Exchange Threat Exchangeプラグインに代わる、より自動化されたスケーラブルな手段を提供するCrowdStrike Falcon Foundryネイティブアプリケーションです。CrowdStrikeの検知からIOCを抽出し、正規化および重複排除を行った上で、Netskope APIを介してNetskopeのURLリストおよびファイルリストに直接プッシュします。

What this adds to Netskope policy

• Falconの検知からドメインおよびIPv4のIOCが抽出され、Netskope URLリストに自動的にプッシュされます。
• Falconのマルウェア検出によるMD5およびSHA-256ハッシュが、Netskopeのファイルハッシュリストをほぼリアルタイムで更新します。
• Netskopeからの不正サイトおよびマルウェアのアラートがFalcon Foundryに取り込まれ、脅威インテリジェンスループが完了します。

Prerequisites and licensing

• CrowdStrike Falcon Foundryの資格（標準のFalconエンドポイントライセンスとは異なる機能）。CrowdStrikeのアカウントチームにご確認ください）。
• URLリストおよびファイルハッシュリストへの書き込み権限を持つNetskope APIクレデンシャル。
• Falcon Foundryが自動化をネイティブにホストするため、このパスにCloud Exchangeサーバーは不要です。

→ Implementation guide (Community): Netskope Direct to Zero Trustアプリ

4.5.1 2 つのインジデントの指標（IOC）共有方法の選択

Consideration	Threat Exchange プラグイン (4.4、Cloud Exchange)	ゼロトラストアプリへの直接アクセス（4.5、Falcon Foundry）
Infrastructure	顧客が運用およびパッチ適用を行うセルフホスト型の Cloud Exchange サーバー（VM）が必要です	ネイティブのCrowdStrikeホスト型アプリ。実行のための個別のインフラストラクチャは不要です
Directionality	完全な双方向：CrowdStrikeのIOCをNetskopeに取り込み、Netskopeが検出した悪意のあるサイト/マルウェアのアラートをCrowdStrikeにプッシュします	主に一方向の自動化です：CrowdStrikeのIOCを抽出してNetskopeにプッシュします。NetskopeのアラートはFoundryに取り込まれますが、Cloud Exchangeのビジネスルールよりもワークフローの柔軟性は低くなります。
ホストに対するアクション	ホストの隔離/修復アクションおよびインジデントの指標の取り消し（プルおよびプッシュ）を主要なプラグイン機能としてサポート	インジデントの指標の正規化/重複排除およびリストプッシュの自動化に重点を置いており、汎用的なホストアクションフレームワークではありません。
Latency	プラグインで設定された同期間隔（スケジュールされたポーリング）によって管理されます	新しく検出されたインジデントの指標を検出から数分以内にNetskopeへプッシュするように設計されており、設計段階から低レイテンシを実現しています
Customization	高 — Cloud Exchangeのビジネスルールにより、インジデントの指標が共有される前に任意のフィルタリング、タグ付け、およびマルチプラグイン相関が可能	より低い — ロジックはFoundryアプリ内に存在し、カスタムフィルタリングへの露出が少なくなります
最適な適合	他のプラグイン（Risk Exchange、Log Shipper）で既にCloud Exchangeを運用している組織、または取り消し/隔離・修復アクションや詳細なビジネスルール制御を必要とする組織	Cloud Exchange インフラストラクチャを構築または維持することなく、最も高速でシンプルな自動インジデントの指標フィードを求める組織

同じNetskope URL/ファイルリストに対して両方を実行することはサポートされていますが、本番環境への展開前に重複エントリの処理についてテストを行う必要があります。

4.6 Extended Detection and Response：CrowdStrike XDR統合

CrowdStrike XDR統合は、Netskope SSE（Security Service Edge）とFalcon XDRプラットフォームを接続し、エンドポイント、ネットワーク、クラウド間を移動する脅威の単一ビューを提供します。これは、SCIMベースのユーザーおよびグループ同期と、双方向の脅威アラート共有という2つのメカニズムを組み合わせたものです。

SCIM-based user and group management

• CrowdStrikeでユーザーを「制限付き」グループに追加すると、そのグループに対するNetskopeポリシーが直ちに適用されます。
• インシデントが解決したらユーザーをグループから削除します → フルアクセスが自動的に復元されます。
• CrowdStrike に追加された新しいユーザーは、正しいグループメンバーシップとともに Netskope に自動的にプロビジョニングされます。

Bidirectional alert sharing

CrowdStrike XDRは、Netskopeのウェブトランザクションデータとアラートデータを取り込み、エンドポイントのテレメトリと組み合わせることで、両方のレイヤーにまたがる脅威を浮き彫りにします。CrowdStrikeによってすでに侵害されていると見なされているエンドポイント上のクラウドアプリを通じてユーザーがデータを流出させることは、どちらか一方のシグナル単体とは全く異なるインシデントです。

Prerequisites and licensing

• Netskope SCIM（クロスドメインID管理システム）統合が構成され、到達可能であること。Netskope SCIMのレガシーなDirectory Tool + OAuthトークン方式は非推奨となっていることに注意してください。現在のガイダンスでは、特定の統合ガイドで求められるフローに応じて、サービスアカウント（設定 > ツール > REST API v3）経由で生成されたNetskope RBAC v3トークン、またはREST API v2トークンを使用することを推奨しています。
• CrowdStrike Falcon XDRモジュールライセンス。
• 初期の信頼関係を構成するために、両方のテナントへの管理者アクセス権が必要です。

Setup path (high level)

• 認証設定：Netskopeトークンを生成します（サービスアカウント経由のRBAC v3、またはリンクされたガイドの現在の手順に従ったREST API v2）。
• ディレクトリ/SCIM セットアップ：CrowdStrike と Netskope 間でユーザー属性とグループ属性をマッピングするチャネルを構成します。
• アラート共有の設定：サードパーティ統合ガイドに従い、Falcon XDRをNetskope SSEのログ/アラートソースに接続します。

Troubleshooting quick reference

• SCIM同期がグループの変更を反映していない場合：使用しているトークンの有効期限が切れておらず、セットアップ時に付与されたスコープが保持されていることを確認してください。RBAC v3トークンとレガシーOAuthトークンには互換性がなく、移行後にこれらを混在させることが、同期がサイレントに失敗する一般的な原因となります。
• 大規模なプロビジョニングエラー（ユーザー/グループの一括作成）：Netskope SCIM APIはページネーションを行います。一括操作をスクリプト化する際は、1回の呼び出しですべてのセットが返されると想定せず、startIndexおよびcountパラメータを使用してページングを行ってください。

→ Implementation guide — XDR integration: CrowdStrike XDR 統合

→ Third-party integration guide — Netskope SSE: CrowdStrike XDR サードパーティ統合：Netskope SSE

→ Netskope SCIM / RBAC v3 provisioning guide: ユーザーのプロビジョニングと認証

4.7 クラウドワークロードリスク：Risk Exchange (CRE) 用 Falcon Cloud Securityプラグイン

Falcon Cloud Securityプラグインは、2つのカテゴリのCrowdStrikeクラウドデータを取得し、セクション4.1～4.3で使用されているのと同じRisk Exchange (CRE) モジュールを介してNetskopeのリスクポスチャにフィードします：クラウドIOA（攻撃の指標：クラウドワークロードに対するアクティブな攻撃手法の証拠）およびIOM（設定ミスの指標：攻撃対象領域を拡大させるクラウドのリソース設定ミスをフラグ付けするもの）。

What this adds to Netskope policy

• アクティブに侵害されたワークロードからのIOAは、それらのワークロードに対するNetskopeトラフィックの検査強化やブロックをトリガーする可能性があります。
• IOMデータは、構成が修正されるまで誤って構成されたクラウドソースへのアクセスを制限できるリスク信号を提供します。
• NPA（Netskope Private Access）のポリシー自動化により、リスクのあるワークロードのアプリケーション定義を、制限付きアクセスオブジェクトへ自動的に移動できます。

Prerequisites and licensing

• CrowdStrike Falcon Cloud Security（CSPM — Cloud Security Posture Management）モジュールライセンス。
• TenantプラグインおよびRisk Exchange (CRE) プラグインが既に構成されているNetskope Cloud Exchangeテナント。
• クラウドセキュリティデータ用にスコープ設定されたCrowdStrike APIクライアントのクレデンシャル（Falcon Cloud Securityのスコープ命名はCrowdStrikeプラットフォームのリリースごとに変更されているため、現在のプラグインガイドで正確なスコープ名を確認してください）。

Troubleshooting quick reference

• 4.1の他のRisk Exchangeプラグインで文書化されているものと同じ403/IP許可リストパターンに従ってください：まずクライアントID/シークレットスコープを確認し、構成されている場合はIP許可リスト管理を確認します。

→ Implementation guide: Risk Exchange用 CrowdStrike Cloud Securityプラグイン

4.8 脆弱性のコンテキスト：Risk Exchange (CRE) 用 Falcon Spotlight プラグイン

Falcon Spotlightは、エンドポイント層で継続的な脆弱性管理を提供します。Spotlightプラグインは、Risk Exchange（CRE）を介して管理対象ホストの脆弱性スコアをNetskopeのデバイスリスクコンテキストに取り込み、実際のCVE（Common Vulnerabilities and Exposures）の露出データでZero Trust Engineのデバイスディメンションを強化します。

What this adds to Netskope policy

重大な未修正のCVEを持つデバイスは自動的に格下げされ、脆弱性が修復されるまで機密データへのアクセスが制限されます。

Prerequisites and licensing

• CrowdStrike Falcon Spotlightモジュールライセンス。
• TenantプラグインおよびRisk Exchange (CRE) プラグインが既に構成されているNetskope Cloud Exchangeテナント。
• Vulnerabilities (read) スコープを持つ CrowdStrike API クライアント。これは、このプラグインのユーザーおよびアプリケーションのレコードを取得するために必要な特定の権限です。

API scopes/setup path

• CrowdStrike: サポートとリソース > APIクライアントとキー > Vulnerabilities (read) スコープを持つ新しいAPIクライアントを追加します。
• Cloud Exchange：CrowdStrike Falcon Spotlight v1.0.0 (CRE) プラグイン；ベースURLは、リージョン固有のCrowdStrike APIホスト（https://api.crowdstrike.com など）です；初期範囲（日数）は、最初の同期で取得する履歴データの量を制御するもので、0～200日の間で指定する必要があります。

Troubleshooting quick reference

• 脆弱性が取得されませんでした：テナントのFalcon Spotlight側に実際に脆弱性が存在することを確認し、プラグイン設定中にエンティティとソースのマッピングが完了していることを確認してください。
• 403 エラー：クライアント ID/シークレットの有効性と、特に Vulnerabilities（読み取り）スコープを確認してください。その後、CrowdStrike 側で設定されている場合は IP 許可リスト管理を確認してください。
• 500エラー：一時的なサーバー側の問題です。しばらく待ってから再試行してください。

→ Implementation guide: Risk Exchange 用 CrowdStrike Falcon Spotlight プラグイン

4.9 可視性の一元化：LogScaleおよびNG-SIEM

NetskopeデータをCrowdStrikeのSIEMレイヤーに送信するための統合パスは2つあります。NetskopeのCloud Exchange Log Shipperモジュール用のCrowdStrike LogScaleプラグインと、Falconが取り込むAWS S3バケットへのNetskopeネイティブのログストリーミングを使用したCrowdStrike NG-SIEM（次世代SIEM）サードパーティ統合です。

これが追加するもの

これらの統合は、Netskopeのインラインポリシーの決定を直接的に左右するものではありません。その価値は、調査のスピードと検出の精度にあります。CrowdStrikeのアナリストがエンドポイントのインシデントを調査する際、同じFalconコンソール内でユーザーのクラウドアプリケーションでのアクティビティ全体を確認できるため、将来のポリシー調整にフィードバックできる初期のインジケーターを明らかにすることができます。

Prerequisites

• Cloud Exchange経由のLogScaleの場合：テナントおよびLog Shipperプラグインが構成され、さらにCrowdStrike LogScaleの取り込み用クレデンシャルが必要です。
• ネイティブなS3ベースのNG-SIEMストリーミングの場合：Netskopeのログストリーミング構成とCrowdStrikeのNG-SIEM取り込みの両方からアクセス可能なAWS S3バケットで、両側に適切なIAM権限が設定されている必要があります。

→ LogScale plugin guide: CrowdStrike LogScale Log Shipper用プラグイン

→ NG-SIEM third-party integration guide: CrowdStrike次世代SIEMのサードパーティ統合 

→ Log streaming setup: CrowdStrikeへのストリームログ

Netskope AI SecOpsイベントからFalcon次世代SIEMへの送信（アウトバウンドWebhook）

上記のログ送信統合とは異なる、より新しいパスです。一般的なWebトランザクションログをストリーミングするのではなく、この統合では、Netskope Outbound WebhookとFalcon HEC（HTTP Event Collector）/ HTTP Event Connectorを使用して、Netskope AI SecOpsのケース、ユーザーリスク、およびAIリスクのイベントを、ほぼリアルタイムでFalcon Next-Gen SIEM（LogScale）に直接配信します。イベントは解析済みの状態で到着します。netskope-sseパーサーパッケージ（Netskopeの他のSSEアラートおよびイベントストリームを正規化するものと同じパッケージ）は、AI SecOpsのエンベロープ形状を認識し、取り込み時に自動的にフィールドをECS（Elastic Common Schema）に昇格させるため、クエリ時に作成する別のパーサーは不要です。

Prerequisites

• AI SecOpsが有効で、Outbound Webhookを構成するための管理者アクセス権を持つNetskopeテナント（AI SecOps > Configuration > Integrations）。
• データコネクタを作成する権限を持つ CrowdStrike Falcon Next-Gen SIEM テナント。
• Falcon NG-SIEMリポジトリで利用可能なnetskope-sseパーサーパッケージ（CrowdStrike-Partnersパッケージレジストリからインストール）。

Setup path (high level)

• Falcon Next-Gen SIEMで、新しいHEC/HTTPイベントコネクタ（ベンダー：Generic）を作成し、netskope-sseパーサーを選択します。オプションで、Falcon独自の資産およびIDデータに対するホスト/ユーザーエンリッチメントを有効にできます。
• コネクタのAPIキーを生成し、そのAPI URLをコピーします。これらは、Netskope側におけるwebhookのベアラートークンおよび送信先URL（…/services/collector/rawのように /raw が付加されます）となります。
• Netskope AI SecOpsで、新しいアウトバウンドWebhookを作成します：前のステップで取得した宛先URLとベアラートークンを設定し、配信するイベントタイプを選択します（ケース、User Risk、AI Riskはすべて1つのWebhookを共有可能 — 16のイベントタイプが一貫したECSフィールドセットに正規化されます）。また、ラッピングモードとしてEnvelope（署名付きラッパー）を選択します。
• 実際のテストイベント（case.createdなど）を送信し、解析されたフィールド（event.action）とともにFalconリポジトリに格納されることを確認します。event.category[0]、event.severity、organization.id、rule.id、url.、user.name — Vendor.dataの下に保持された完全な生のペイロードとともに。

Data structure notes

• 重大度は、event.severityにおいて、critical/high/medium/low/informationalを数値スコア90/70/50/30/10にマッピングします。
• event.kind、event.category、および event.type はイベントタイプによって異なります。特定のイベントタイプに存在しないフィールドは、単に表示されません。
• 「Payload」タブでは、Core以外にどのオプションのフィールドグループ（ケースメタデータ、調査、エンティティ、ファイル系統、リスク詳細）を含めるかを制御します。一部にはPIIマーカーが含まれているため、データ処理ポリシーに従ってグループを有効にしてください。

Troubleshooting quick reference

• 取り込み時に401または403エラーが発生する場合：FalconコネクタでAPIキーを再生成し、Webhookのトークンフィールドを更新してください。
• イベントが解析されずに取り込まれる場合（@rawstring のみ）：コネクタの Parsers フィールドが netskope-sse に設定されていることを確認してください。
• @rawstring が空です：宛先URLに /raw サフィックスがありません。

→ Implementation guide (Community): Netskope AI SecOpsイベントをCrowdStrike Falcon次世代SIEMに送信

4.10 エンドポイントの共存：クライアントレベルの相互運用性

これはデータ共有の統合ではなく、運用上の統合です。両方のエージェントが同じエンドポイント上で実行されるため、正しく設定されていないと互いに干渉する可能性があります。

• CrowdStrikeはNetskope ClientプロセスにDLLを注入してAPIレベルでアクティビティを監視しますが、これにより不安定になることがあります。
• 推奨される緩和策：CrowdStrike側でNetskope Clientのプロセス除外を追加し、NetskopeのSteering Configuration（Settings > Security Cloud Platform > Steering Configuration > Default tenant config > Exception > 新しい Exception > Certificate Pinned Applications）でCertificate Pinned Applicationの例外を追加して、CrowdStrikeのトラフィックがNetskopeの検査をバイパスするようにします。

Troubleshooting/validation

例外を適用した後に CrowdStrike Falcon Sensor が機能していることを検証するには、良性の検出テスト（Windows コマンドプロンプトから choice /M crowdstrike_sample_detection を実行）を行い、Falcon コンソールの「Activity」>「Detections」に検出が表示されることを確認します。

→ Coexistence best-practices guide: CrowdStrike

4.11 逆方向の自動化：CrowdStrikeからNetskopeのアクションをトリガーする

セクション4.1から4.9までのすべての統合は一方向に流れます。CrowdStrike由来のシグナル（デバイスの健全性、IDリスク、インジデントの指標、脆弱性スコア、ログ）がNetskope Zero Trust Engineに供給され、そこでポリシーの結果が決定されます。2つのCrowdStrikeマーケットプレイスのリストは逆方向に流れます。これらは、CrowdStrike側のコンソールまたはプレイブックから直接Netskopeのアクションを呼び出せるようにします。これにより、Falconでトリアージを行い、コンソールを切り替えることなくNetskopeでアクションを実行したいSOCチームのループが完結します。

4.11.1 Netskope SOAR アクション（Falcon Fusion SOAR）

Falcon Fusion（CrowdStrikeのノーコードSOAR（セキュリティオーケストレーション、自動化、レスポンス）ワークフロービルダー）用のCrowdStrike製コネクタ。制限付きグループへのユーザーの追加や削除、クラウドガバナンス設定の適用といったNetskopeのアクションをFusionプレイブック内のステップとして公開することで、人間がNetskopeコンソールを操作することなく、両プラットフォームにまたがる完全自動化されたレスポンスワークフローを実現します。

• 自動化されたユーザーアクセス管理：Fusion ワークフロー内からユーザーロールとグループを自動的に管理することで、クラウドアクセスを制御します。
• クラウドガバナンスの簡素化：コンプライアンスポリシーとクラウドセキュリティ設定を、手動タスクではなくワークフローのステップとして適用します。
• インシデント対応の迅速化：Fusionワークフローは、クラウドのアクティビティシグナルを監視し、CrowdStrike内でNetskopeの修復アクションをエンドツーエンドで即座にトリガーできます。

Prerequisites and licensing

• CrowdStrike Falcon次世代SIEM（Falcon Fusion SOARはこのモジュールの一部として提供されます）。
• ユーザー/グループのメンバーシップおよびワークフローが影響を与える関連ガバナンス設定を変更する権限を持つ、Netskope側のAPIクレデンシャル。

Setup path

• CrowdStrike Falconコンソールから、CrowdStrike MarketplaceのNetskope SOAR Actionsリストに移動し、「Get Started/Contact Partner」を選択してコネクタのセットアップを開始します。その後、公開されているNetskopeアクションをワークフローステップとして使用し、Falcon Fusionワークフローを構築または拡張します。

How this differs from Section 4.6’s SCIM Sync

セクション 4.6では、常時接続の関係であるSCIM（System for Cross-domain Identity Management）を介して、NetskopeのグループメンバーシップをCrowdStrikeと継続的に同期させます。この統合はプレイブック主導かつ条件付きです。Fusionワークフローが明示的に呼び出した場合にのみ動作し、継続的な同期に依存するのではなく、ワークフロー作成者がトリガー条件を設計する必要があるという代償はありますが、グループメンバーシップを超えたより広範な単発アクションを実行できます。

→ Marketplace listing: Netskope SOARアクション

→ Solution guide (shared with other Netskope/CrowdStrike listings): このソリューションガイド

4.11.2Falcon Insight XDRに対するNetskopeの応答アクション

上記のSOAR Actionsコネクタの、より限定的なXDR専用の兄弟コネクタです。Fusionワークフローを作成する必要はなく、Falcon Insight XDRのお客様は、Insight XDRコンソールから直接Netskope SSE（Security Service Edge）応答アクションをトリガーできます。例：特定の検知や不審なアクティビティのアラートに対応する場合など、完全なプレイブックを構築するよりもセットアップのオーバーヘッドが少なくなります。

• 対応の自動化と運用の簡素化：XDR検知をトリガーとした、一貫性のある反復可能な自動アクション（制限付きグループへのユーザーの追加/削除など）。
• より迅速なクロスドメイン対応：Falcon Insight XDRのアナリストは、Netskopeへのコンテキスト切り替えやFusionワークフローの事前作成を行うことなく、検出のトリアージを行っている同じコンソールから、その場でNetskopeのアクションを呼び出すことができます。

Prerequisites and licensing

• CrowdStrike Falcon Insight XDRおよびFalcon Preventモジュール。
• 有効化された特定の応答アクション（通常はグループ/ロールメンバーシップの変更）に対してスコープ設定された、Netskope側のAPIクレデンシャル。

Setup path

このリストのCrowdStrike Falcon Storeエントリから直接構成します（Falconコンソール内からアクセス可能）。これにより、Cloud Exchangeを別途デプロイすることなく、2つのプラットフォームがリンクされます。

Choosing between 4.11.1 and 4.11.2

SOCがすでにFusion SOARプレイブックを構築しており、より広範な自動応答チェーンにおける複数のステップの1つとしてNetskopeアクションを組み込みたい場合は、SOAR Actions（4.11.1）を使用してください。XDRアナリストがトリアージ中に検出から直接Netskopeアクションをトリガーするための、迅速かつセットアップが容易な方法を優先する場合は、Falcon Insight XDR向けのResponse Actions（4.11.2）を使用してください。この2つは、相互に排他的なものではありません。一部の組織では、異なるペルソナ（自動化を構築するSOCエンジニアと、その場でトリアージを行うアナリスト）向けに、同じ基盤となるNetskopeアクションを両方のインターフェースで公開しています。

→ Marketplace listing: Falcon Insight XDR向けのNetskope応答アクション 

4.11.3フィールド構築パターン：Fusion SOAR + Netskope Device Tags API（マーケットプレイスコネクタは不要）

セクション4.11.1のNetskope SOAR Actionsマーケットプレイスコネクタの代替案：パッケージ化されたコネクタをインストールするのではなく、このパターンでは、Falcon Fusion SOARの組み込みCloud HTTP RequestアクションとNetskopeのDevice Tags REST APIという2つのネイティブプリミティブを使用して統合を直接構築します。トリガーからポリシーまでのロジック全体が単一のビジュアルワークフローで可視化され、FoundryアプリやCloud Exchangeの展開は不要です。

How it works

• このワークフローは、CrowdStrikeのZero Trust Assessment > Host assessment change > Overall assessmentイベントでトリガーされ、ホストの集計ZTAスコアが変更されるたびに実行されます。
• 3つの連鎖条件により、デバイスは3つのティアのいずれかにルーティングされます（Fusion SOAR にはネイティブのマルチウェイ分岐がないため、これは2つのネストされたバイナリ条件となります）：0～49 → crowdstrike-zta-high-risk、50～75 → crowdstrike-zta-med-risk、76～100 → crowdstrike-zta-low-risk。各タグは、独自の Netskope デバイス分類ルールおよびリアルタイム保護ポリシーにマッピングされます。
• CrowdStrikeとNetskopeはデバイス識別子を共有していないため、Cloud HTTP Requestは、ホスト名でサーバーサイドフィルタリングされ、orderbys=timestamp descでソートされたNetskopeのクライアントステータス検索エンドポイント（GET /api/v2/events/datasearch/clientstatus）にクエリを実行します。単一のホスト名に複数の過去のクライアントステータスレコードが存在する可能性があるため、ソートは重要です。明示的なソートを行わない場合、APIは最新のレコードを最初に返すことを保証しません。
• Fusion SOARのデータ参照構文では配列のインデックスを直接指定できないため、小さなPythonスクリプトアクションで最初の配列項目（nsdeviceuidおよびuserkey）を抽出します。
• 最終的なアクションとして、解決されたデバイスIDとブランチのターゲットタグを使用して、Netskopeの一括タグ置換エンドポイント（/api/v2/devices/device/tags/bulkreplace）にPOSTします。このエンドポイントはタグを追加するのではなく完全なタグリストを置き換えるため、デバイスを別の階層に移動すると、古い階層のタグは自動的に削除されます。個別のクリーンアップロジックは不要です。

Gotchas worth knowing before you build this yourself

• 「Content-Type:」（末尾にコロンが付いたもの）という手入力のヘッダーが原因で、不可解な400「execution failed host」エラーが発生しました。コロンはHTTPヘッダー名では使用できないため、リクエストがNetskopeに到達する前にプラットフォームのHTTPクライアントが失敗しました。Cloud HTTPリクエストが詳細な情報なしに失敗した場合は、実行レコードの完全に解決されたリクエスト（ヘッダーを含む）を確認してください。
• userkeyはデバイスUIDとは異なります。一般的に参照される例ではこれらを同等としていますが、それは誤りです。userkeyは、登録ごとに個別の不透明な識別子です。これにデバイスUIDを渡すと、APIは成功を返しながらも、サイレントにファントムタグの関連付けを作成してしまうため、間違いを見落としやすくなります。
• 単一のアクションを分離してテストする場合、テナント全体でそのトリガーが次に実際に発生するのを待機します。特定のデバイスを対象とするものではなく、UI 上での意図的なモック実行と見分けがつきません。代わりに、明示的なモックペイロードを使用して完全なワークフローをテストし、ライブでエンドツーエンドの実行を行ってください。

Verification approach

1台のテストデバイスを3つのスコア帯すべてで循環させ、ワークフローキャンバス上の緑色のチェックマークに頼るのではなく、Netskopeで実際のデバイス状態を確認しながら、毎回タグのみが変更されることを確認します。

Generalizes beyond ZTA scores

「IDの解決 → タグの適用 → デバイス分類による決定」という同じパターンは、CrowdStrikeだけでなく、アウトバウンドWebhookを呼び出したり、ネイティブのSOARトリガーを発火させたりできるあらゆるシステムで機能します。

→ Implementation guide (Community): CrowdStrikeのゼロトラストスコアをNetskopeの自動ポリシー応答に変換する

4.12 関連するマーケットプレイスリスト（同じ機能、異なるパッケージング）

さらに2つのCrowdStrike Marketplaceエントリは、本書の他の場所で異なる名称で既にカバーされている機能を示しています。技術的な詳細を重複させることなく、このリファレンスを完全なものにするためにここに記載します：

• Falcon LogScale向け Netskope CASB (Cloud Access Security ブローカ)：セクション4.9のLogScaleログ送信パスをCrowdStrike Marketplace向けにパッケージ化したもので、CASBのアクティビティ、アラート、検出用のFalcon LogScaleダッシュボードが組み込まれています。セクション4.9で説明されている以外の、個別の技術統合はありません。ダッシュボードがその付加価値となります。
• Netskope Data Connector（Falcon Insight XDR向けデータ取り込み）：セクション4.6の双方向アラート共有で説明されているNetskope SSEからXDRへのログ/アラート取り込みをCrowdStrike Marketplace向けにパッケージ化したもので、Falconコンソール内での統合的なトリアージ用に構築済みのダッシュボードが付属しています。

調達目的でNetskope関連のCrowdStrike Marketplaceのリストを個別にカウントしている場合、これら2つは4.6および4.9で既にカバーされている機能の代替ストアフロントであり、追加の統合メカニズムではないことに注意してください。

5. ポリシーのシナリオ例

以下のシナリオは、複数の CrowdStrike シグナルが Netskope ポリシー内でどのように組み合わさり、単一のシグナルやバイナリの許可/ブロックロジックだけでは不可能な結果を生み出すかを示しています。

シナリオ1：デバイスがアクティブな攻撃を受けている場合 — クラウドデータへのアクセスを制限する

CrowdStrikeが管理対象のラップトップでマルウェアを検出します。ZTAスコアが200に低下します。ホストリスクプラグイン（セクション4.2）は、Netskope内のデバイス分類を数分以内に「管理対象」から「管理対象外」に更新します。ユーザーのセッションは、標準的なSaaSアプリケーションへの閲覧のみのアクセスを許可し、機密（Sensitive）とタグ付けされたアプリケーションへのアップロード、ダウンロード、およびアクセスをブロックするポリシーに即座に一致します。ユーザーは、デバイスがフラグ付けされたことを説明し、ITサポートへ誘導するコーチングメッセージを受け取ります。SOCアナリストがNetskopeポリシーに触れる必要はありません。

シナリオ2：クレデンシャルの侵害 — クラウドアクセス前のステップアップ認証

Falcon Identity Protectionは、ユーザーアカウントに対するクレデンシャルスタッフィング活動を検出します。IDリスクスコアが定義されたしきい値を超えて上昇しました。NetskopeのRisk Exchange（CRE）は、Falcon Identity Protectionプラグインを介して更新されたスコアを受信し、ユーザーを「high-identity-risk（高IDリスク）」グループに移動させます。そのグループのポリシーでは、CCI < 70と評価された、またはファイル共有サービスとしてタグ付けされたクラウドアプリケーションにアクセスする前に、MFAによる再認証が必須となります。ユーザーは、これまで通りの生産性向上ツールを摩擦なく利用し続けることができます。

シナリオ3：エンドポイント群で新しいインジデントの指標を検出 — 全ユーザーベースにURLブロックを展開

CrowdStrikeは、Falconの検出機能において新しいコマンド＆コントロールドメインを検知します。Direct to Zero Trustアプリは、ドメインをインジデントの指標として抽出し、数分以内にNetskopeのURLリストにプッシュします。Netskopeのリアルタイム保護ポリシーは、そのドメインが公開脅威フィードに表示される前に、Webブラウザ、クラウドアプリ、管理対象デバイスなど、全フリートにわたってすべてのユーザーがそのドメインにアクセスすることを即座にブロックします。

シナリオ4：高い脆弱性の露出 — 機密データアクセスのスロットリング

Falcon Spotlightは、パッチが適用されていない重大なCVEを持つアプリケーションを実行しているデバイスを特定します。Spotlightプラグインは、Risk Exchange（CRE）を介して脆弱性スコアをNetskopeのデバイスリスクコンテキストに取り込みます。Netskopeポリシーは、PIIまたは財務DLPプロファイルがタグ付けされたデータへのデバイスからのアクセスを制限し、アプリケーションのパッチ適用を促すコーチメッセージを表示します。パッチが適用され、SpotlightがCVEを解決済みとして報告すると、通常のアクセスが自動的に復元されます。

シナリオ 5：デバイスとアイデンティティのリスクの組み合わせ — SOC アラートによる完全ブロック

デバイスのZTAスコアが150（アクティブなマルウェア）に低下すると同時に、Falcon Identity Protectionが同じユーザーの異常なクレデンシャル使用をフラグ付けします。両方のシグナルは、それぞれのプラグインを介して同じRisk Exchange（CRE）モジュールに送られます。Cloud Exchangeのビジネスルールが両方のスコアを評価し、合計リスクがセッションを完全に終了させるためのしきい値を超えていると判断します。Netskopeはセッションを完全にブロックし、SCIM経由でユーザーを隔離グループに移動させ、SIEMに優先度の高いアラートを送信します。SOCは、エンドポイント検出とNetskopeセッションデータの両方を表示する単一のFalcon XDRインシデントを開きます。

シナリオ6：リスクの高いクラウドワークロード — インシデント調査担当者のアクセスを制限する

Falcon Cloud Securityは、以前は準拠していたクラウドワークロードに重大な構成ドリフトが発生したことを検出します。セキュリティグループルールの開放、過度に寛容なIAMポリシー、無効化されたログ記録などがIOMとして表面化します。Falcon Cloud Securityプラグインは、Risk Exchange（CRE）を介して、高まったリスクシグナルをNetskopeに送信します。NetskopeはNPAアプリケーション定義を更新し、ワークロードを標準のプライベートアプリケーショングループから、専用の「Under Investigation（調査中）」オブジェクトに移動します。そのオブジェクトに対するポリシーでは、指定されたセキュリティエンジニアおよびクラウド運用スタッフのみにアクセスを許可します。その他のすべてのユーザーには、コンテキストメッセージと共にブロックが適用されます。Falcon Cloud Securityが設定ミスが解決されたことを確認すると、ワークロードは自動的に標準のアプリケーショングループに戻ります。手動でのポリシー編集は不要です。

シナリオ 7：Falcon Insight XDR検知に基づくアナリスト主導の封じ込め

Insight XDRの検出機能が、ユーザーのエンドポイントにおける疑わしいラテラルムーブメントの動作にフラグを立て、Falconセンサーのアラートと異常な認証試行を関連付けます。アナリストはNetskopeコンソールに切り替えることなく、検出カードから直接Falcon Insight XDR用のNetskopeレスポンスアクション（セクション4.11.2）をトリガーし、ワンクリックでユーザーを制限付きのNetskopeグループに移動させます。そのグループに対するNetskopeポリシーにより、ユーザーのZTNAセッションスコープが即座に縮小され、アップロード/共有アクティビティがブロックされます。その間、アナリストはインシデントから目を離すことなく、Falconでエンドポイントの調査を継続します。

シナリオ8：Falcon Fusion SOARによる完全自動化されたクロスプラットフォームの封じ込め

Falcon Fusion SOARプレイブックは、特定の検出の組み合わせ（重大な深刻度のマルウェア検出と、同じ時間内に新しい未知の地域からのログイン）を監視するように構成されています。同じユーザーに対して両方の条件がトリガーされると、プレイブックは自動的にNetskope SOAR Actionsコネクタ（セクション4.11.1）を呼び出してユーザーを隔離グループに追加し、並行してSOCのITSMシステムでチケットを開きます。初期の封じ込めステップにおいて、アナリストは介入しません。SOCはチケットとリンクされたFalconおよびNetskopeの証拠を合わせて確認し、調査によってユーザーの安全が確認されたら手動でアクセスを復元します。このシナリオはシナリオ7との違いを示しています。ここではトリガーとアクションの両方が完全に自動化されており、アナリストは封じ込めが完了した後にのみ関与します。

シナリオ 9: リバース方向のアクションとフォワードフィードのリスクスコアの組み合わせ

中程度のデバイスの健全性の問題が検出された後、ユーザーのCrowdStrike ZTAスコア（セクション4.1）が読み取り専用ティア（500～800）に低下します。これは、それ単体ではアクセスを完全にブロックするほど深刻ではありません。その直後、関連のないFalconテレメトリをレビューしていたSOCアナリストが、ユーザーのより広範なリスクプロファイルに関する判断に基づいて、Falcon Insight XDR用のNetskope応答アクション（セクション4.11.2）を手動でトリガーし、自動ZTAベースのティアが適用するよりも制限の厳しいグループにユーザーを移動させます。手動のグループ割り当てと自動のデバイスベースの分類は同時に有効になる可能性があるため、ポリシー管理者は、2つのうちより制限の厳しい方が常に優先されるようにビジネスルールとグループの優先順位を設計する必要があります。また、両方を本番環境で有効にする前に、それらが競合した場合にどちらのメカニズム（自動リスクスコアまたは手動のアナリストアクション）が優先されるかを文書化してください。

シナリオ10：統合されたLogScaleダッシュボードによる既存の調査の加速

CrowdStrikeのアナリストは、エンドポイント検出を調査する際、Falconコンソールを離れることなく、Falcon LogScale（セクション4.12）内の構築済みのNetskope CASBダッシュボードを開いて、同じユーザーの最近のクラウドアプリケーションアクティビティを確認します。ダッシュボードには、エンドポイント検出が作動する前の1時間に、ユーザーが未認可の個人用クラウドストレージアプリに大量のファイルをアップロードしたことが表示されます。このコンテキストは、個別のNetskopeログインや手動でのログ検索を必要とせず、数分で確認できるため、アナリストはインシデントを日常的なマルウェアのクリーンアップからデータ流出の疑いがあるケースへとエスカレーションし、次回のスケジュール同期を待たずにセクション4.2のホストリスクスコアを直ちに確認するよう要求することができます。

6. 始める

すべての統合を一度に展開する必要はありません。推奨される手順では、最も価値の高いシグナルと最も実装が容易なものから順に、段階的に機能を構築します。

ステップ1 — ログストリーミング（即時の可視性）

LogScaleプラグインをデプロイするか、S3ログストリーミングを設定して、NetskopeのウェブトランザクションログをCrowdStrike NG-SIEMに取り込みます。これにより、ポリシーを変更することなく、即座に調査価値を提供します。参照：セクション4.9。

ステップ2 — 脅威インテリジェンス（高インパクト、低摩擦）

Threat ExchangeプラグインまたはDirect to Zero Trustアプリをデプロイして、双方向のインジデントの指標共有を開始します。ご使用の環境に適したものを選択するには、セクション 4.5.1を参照してください。これにより、NetskopeのURLポリシーおよびファイルハッシュポリシーが即座に強化されます。参照：セクション 4.4および4.5。

ステップ3 — ZTAスコアによるデバイスの体制

CrowdStrike ZTAスコア統合を使用して、Risk Exchange（CRE）プラグインをデプロイします。スコアのしきい値とデバイスの再分類ロジックを定義します。自動再分類を有効にする前に、アラートのみのモードから開始してしきい値を調整してください。参照：セクション4.1。

ステップ 4 — ユーザーとアイデンティティのリスク

ステップ3ですでに展開されている ZTA プラグインに加えて、ホストリスクプラグイン（4.2）と Falcon Identity Protection（4.3）をレイヤー化します。これら3つすべてが同じ Risk Exchange（CRE）モジュールにフィードされるため、このステップは追加的なものであり、個別のロールアウトではありません。リスクスコアの範囲をNetskopeユーザーグループおよび各グループに適用されるポリシーにマッピングするビジネスルールを定義します。しきい値を設定する前に、セクション 4.1 のスコア方向に関する注記を再確認してください。

ステップ5 — XDRおよびSCIM

CrowdStrike XDRをNetskope SSEに接続し、非推奨となったOAuth Directory Toolフローではなく、現在のRBAC v3トークン方式を使用してSCIMグループ同期を構成します。これにより、両プラットフォーム間で自動化されたインシデント応答ワークフローが可能になります。参照：セクション4.6。

ステップ6 — クラウドワークロードと脆弱性のコンテキスト

Falcon Cloud SecurityおよびFalcon Spotlightプラグイン（同じRisk Exchange（CRE）モジュールへの2つの追加コントリビューター）を追加して、デバイスリスクとワークロードアクセスのための追加のリスクピラーコンテキストを有効にします。この段階では、どちらか一方、または両方を展開できます。参照：セクション 4.7および4.8。

7. サポート、エスカレーション、および継続的なメンテナンス

このセクションでは、ベンダーが文書化した一般的なエスカレーションガイダンスを提供します。特定のSLA時間や応答時間のコミットメントについては、各組織のNetskopeおよびCrowdStrikeのサポートティアによって異なり、各ベンダーのアカウントチームに直接確認する必要があるため、意図的に記載していません。

7.1 ヘルプの入手先

• Netskopeナレッジポータル：セクション4にリンクされているすべての実装ガイドの信頼できる継続的に更新されるソースです。Netskopeはリリース間でプラグインのUIを更新するため、本書のUI手順が実際の画面と一致しない場合は、まずこちらを確認してください。
• Netskope Cloud Exchange コミュニティフォーラム：アクティブなコミュニティスレッド（セクション4全体で引用）は、正式なドキュメントにはまだ記載されていないエッジケースをカバーしていることが多く、他の共同顧客による現場で検証済みのウォークスルーも含まれています。
• NetskopeサポートポータルおよびNetskopeカスタマーサクセスマネージャー（CSM）/テクニカルアカウントマネージャー（TAM）：ライセンスに関する質問（現在の契約にAdvanced UEBAやAdvanced Threat Protectionが含まれているかどうかの確認など）や、ドキュメントやコミュニティで解決できない問題に対する適切なエスカレーションパスです。
• APIクライアントスコープに関する質問、Falcon Foundry/Direct to Zero Trust Appの権限に関する質問、およびCrowdStrike側のエラーコードについては、CrowdStrikeサポートおよびCrowdStrikeアカウントチームにお問い合わせください。

7.2 メンテナンスの頻度

• Cloud Exchangeプラグインは独立して頻繁に更新されます。本書のバージョンが最新であると想定するのではなく、「Settings」>「Plugin Store」>「Check for Updates」から定期的に（毎月など）確認してください。
• CrowdStrike API スコープはリリースごとに名前が変更され、分割されています（4.4で言及されている Detect→Alerts API への移行を参照してください）。プラグインのアップグレードを計画する際は、適用前に必ず API クライアントスコープを再検証してください。
• Risk Exchange（CRE）モジュールに影響を与えるプラグインのアップグレード後は、スコアのしきい値を再テストしてください（セクション4.1）。過去のリリースにおいて、スケールやフィールド名の変更によりスコアリングの動作が変更されています。

8. 統合リファレンスインデックス

すべての統合実装ガイドは、Netskopeナレッジポータルで管理されています。コミュニティリンクはNetskopeのユーザーコミュニティによって管理されており、現場で検証された詳細情報として役立ちますが、公式ドキュメントではありません。

→ ZTA Score — Risk Exchange Plugin (v1.1.0): Risk Exchange 用 CrowdStrike プラグイン

→ ZTA Score — Risk Exchange Plugin (v1.0.0, superseded): ユーザーリスク交換用のCrowdStrikeプラグイン

→ Host Risk Plugin (v1.2.0, listed as User Risk Exchange): ユーザーリスク交換用のCrowdStrikeプラグイン

→ Falcon Identity Protection Plugin (listed as User Risk Exchange): CrowdStrike Falcon User Risk Exchange用ID保護プラグイン

→ Threat Exchange Plugin (v2.3.0): Threat Exchange用CrowdStrikeプラグイン

→ Direct to Zero Trust App (Falcon Foundry): Netskope Direct to Zero Trustアプリ

→ XDR Integration — native guide: CrowdStrike XDR 統合

→ XDR Integration — Netskope SSE third-party guide: CrowdStrike XDR サードパーティ統合：Netskope SSE

→ Falcon Cloud Security — Risk Exchange Plugin: Risk Exchange用 CrowdStrike Cloud Securityプラグイン

→ Falcon Spotlight — Risk Exchange Plugin: Risk Exchange 用 CrowdStrike Falcon Spotlight プラグイン

→ LogScale — Log Shipper Plugin: CrowdStrike LogScale Log Shipper用プラグイン

→ NG-SIEM Third-Party Integration: CrowdStrike次世代SIEMのサードパーティ統合

→ Log streaming setup: CrowdStrikeへのストリームログ

→ AI SecOps events to Falcon Next-Gen SIEM (Outbound Webhooks): Netskope AI SecOpsイベントをCrowdStrike Falcon次世代SIEMに送信

→ Endpoint coexistence best practices: CrowdStrike

→ Netskope SOAR Actions (Falcon Fusion SOAR) — Marketplace listing: Netskope SOARアクション

→ Netskope Response Actions for Falcon Insight XDR — Marketplace listing: Falcon Insight XDR向けのNetskope応答アクション

→ Netskope CASB for Falcon LogScale — Marketplace listing: Falcon LogScale向けNetskope Cloud Access Security ブローカ 

→ Netskope Data Connector (Data Ingestion for Falcon Insight XDR) — Marketplace listing: Falcon Insight XDR向けNetskopeデータ取り込み 

→ Netskope Transaction Logs Data Connector — Marketplace listing: Netskopeトランザクションログデータコネクタ 

→ EDR remediation integration (in-tenant, retiring Dec 1, 2025 — migrate to Threat Exchange): EDRのためのCrowdStrikeの統合

→ Field-built Fusion SOAR + Device Tags API pattern: CrowdStrikeのゼロトラストスコアをNetskopeの自動ポリシー応答に変換する

→ Netskope SCIM / RBAC v3 user provisioning guide: ユーザーのプロビジョニングと認証

→ Cloud Exchange FAQs (licensing, Retrohunt, API transitions, troubleshooting, CRE consolidation): Cloud Exchangeよくある質問

→ Netskope Zero Trust Engine: Zero Trust Engine

→ Netskope + CrowdStrike Solution Brief: NetskopeとCrowdStrike

URLとバージョン番号は、本改訂時点（2026年7月）で公開されているドキュメントを反映しています。デプロイ前に、NetskopeナレッジポータルおよびCrowdStrikeのアカウントチームに確認し、最新のバージョン、スコープ、ライセンス条項をご確認ください。