Cloud Exchangeよくある質問

Q: What is Netskope Cloud Exchange?

A: Netskope Cloud Exchange 、 Netskope Security Cloudプラットフォームと広範なセキュリティおよび IT エコシステム間の自動データ交換を可能にすることで、セキュリティ体制を強化する強力なプラットフォーム サービスです。 これにより、脅威インテリジェンス、リスク スコア、ログを共有し、サードパーティの SIEM、SOAR プラットフォーム、EDR ソリューション、ITSM ツールなどとセキュリティ ワークフローを自動化できます。

Q: What are the main modules within Cloud Exchange and what data do they handle?

ACloud Exchangeには複数のモジュールが含まれており、それぞれが特定のデータ交換機能向けに設計されています。

• Log Shipper (CLS): Netskopeテナントからログ（アラート、イベント、NSL）を取得し、変換処理を行い、SIEMまたはログ管理プラットフォームと共有します。データは、取得および共有処理中のみCEマシンのディスクに一時的に保存され、永続的に保存されることはありません。
• Threat Exchange (CTE): Netskopeと他のセキュリティツール（脅威インテリジェンスプラットフォーム、EDRなど）との間で、脅威インテリジェンス（ファイルハッシュ、悪意のあるURL/ドメイン、IPアドレスなど）の双方向共有を容易にします。指標をデータベースに保存する。
• Ticket Orchestrator (CTO): Netskopeのアラートに基づいて、ITSMシステムまたはケース管理システム（ServiceNow、Jiraなど）におけるチケットの作成と更新を自動化します。アラートはデータベースに保存されます。
• Risk Exchange (CREv2): 以下に説明する、オリジナルのユーザーリスク交換モジュールとアプリケーションリスク交換モジュールの機能を統合したものです。
• User Risk Exchange (CRE for Users): Netskopeのユーザーおよびエンティティ行動分析（UEBA）から得られるユーザーおよびホストのリスクスコアを他のシステムと共有することで、リスクベースのアクセス制御と適応型セキュリティポリシーを実現します。これらのスコアを保存します。
• Application Risk Exchange (CRE for Applications): アプリケーションのリスクスコア（Netskope Cloud Confidence Index – CCIに基づく）を他のプラットフォームと共有します。これらのアプリケーションリスクスコアを保存します。

Q: Can I revert Cloud Exchange or its plugins to a previous version?

A: いいえ、 Cloud Exchange Cloud Exchangeコアのダウングレードやロールバックをネイティブにサポートしていません。 または個々のプラグインを以前のバージョンに戻すこともサポートしていません。 Netskopeは、アップグレードを実行する前に、Cloud Exchangeの設定をバックアップすることを強く推奨します。特定の古いバージョンを実行する必要がある場合は、通常、そのバージョンを新規にデプロイし、その後、可能で互換性がある場合は構成の復元を行う必要があります。

Q: How are Operating System (OS) updates managed for Cloud Exchange?

A: Cloud Exchange v5.0.1以降、このプラットフォームはNetskope社がPSIRTによるセキュリティ強化とレビューを実施したUbuntu OS上に構築されています。このセキュリティ強化のため、Cloud Exchange自体は、基盤となるOSリポジトリから一般的なOSアップデート通知を受信したり、通知を促したりすることはありません。仮想マシン (VM/OVA) としてデプロイされたCloud Exchangeの場合、基盤となる OS は、 Cloud Exchange公式リリースごとに、最新の強化されレビュー済みのバージョンに更新されます。 お客様自身のホスト上でコンテナ化されたデプロイメントを行う場合、ホストOSの保守とセキュリティ対策はお客様の責任となりますが、NetskopeはCloud Exchangeコンテナ内のOSの保守を担当します。

Q: Why does Cloud Exchange use user ID 1001 for its processes?

A: Cloud Exchange内部ワーカープロセスには、主にセキュリティのベストプラクティスとして、非ルートユーザーID（1001など）を使用します。 これにより、最小権限の原則が保証され、プロセスは必要最低限の権限のみで実行されることになります。このアプローチは、コンテナ化された環境におけるリソース管理を改善し、全体的なデプロイメントのセキュリティ向上に貢献します。これは自動的な内部処理であり、手動での介入は必要ありません。

Q: Are there any rate limits for log pulling or export from Netskope via Cloud Exchange?

A: Netskopeテナントからのログ取り込みは、APIレート制限（API V2経由でエンドポイントごとに1秒あたり4回の呼び出し）の対象となります。 

ログのエクスポートに関して、Cloud Exchangeはレート制限を設けていません。1バッチあたり最大10,000件のアラート、10,000件のイベント、および5MBのウェブトランザクションログを転送でき、配信時間は通常10秒未満です。 これにより、NetskopeのAPI制限内で、効率的かつほぼリアルタイムのログ配信が保証されます。

Q: What steps should be followed to perform server-level changes on the Cloud Exchange server while ensuring data integrity is maintained?

A: Cloud Exchangeサーバー上でデータを失うことなくサーバーレベルの変更を行うには：

1. 環境設定を保存します（ cat .env ）。
2. Cloud Exchangeコンテナを停止します（ sudo ./stop ）。
3. サーバー/システムの変更（例：ディスク、メモリ、OS）を適用します。
4. 変更を適用するには、セットアップ（ sudo ./setup ）を再実行してください。
5. サービスを再起動します（ sudo ./start ）。

このプロセスにより、環境が保全され、データの完全性が維持されます。

Q: Do we need to purchase an additional license to use Cloud Exchange features?

A: 別途ライセンスは必要ありません

Q: Why does the CE web URL display a “Not Secure” warning? Is this related to Cloud Exchange itself?

A: いいえ、この警告はCloud Exchange （CE）アプリケーション自体が原因ではありません。 CE URL の SSL/TLS 証明書がself-signedであるか、ブラウザによって信頼されていないため、ブラウザに「安全ではありません」というメッセージが表示されます。
これは通常
証明書の生成、インストール、または配布方法に起因するもので
、CE によって直接管理されるものではありません。CEをホストするサーバーに、有効で信頼できるSSL/TLS証明書をインストールする。正しく設定すれば、警告は消えます。
証明書の設定を検証し修正するために、社内のIT/セキュリティチームに相談することをお勧めします。

Q: Does Cloud Exchange support Ubuntu with FIPS?

A: いいえ、現在Cloud Exchange FIPS 対応の Ubuntu Pro 22.04 で試用およびテストされていません。 そのため、Cloud Exchangeをデプロイする前にFIPSを無効にすることをお勧めします。

Q: How to enable debug-level logs in Cloud Exchange?

ACloud Exchangeでデバッグレベルのログ記録を有効にするには、以下の手順に従ってください。

1. Cloud Exchange > Settings > General > Logsへ移動
2. By default, the Log Level is set to Info
3. ドロップダウンから選択 Debug
4. 変更を適用するには、ページ下部のSaveをクリックしてください。

Q: We receive this error during a setup script or start script “-bash: ./start: /bin/sh^M: bad interpreter”?

A: このエラーは、ファイルの形式が原因で発生します。ファイル形式を変更するには、このコマンドを使用します。
do2unix setup
do2unix start

Q: Why does Cloud Exchange (CE) UI hang or become unresponsive when Microsoft Defender ATP or CrowdStrike agents are installed on RHEL/Ubuntu VMs?

A: Microsoft Defender ATPとCrowdStrikeのエージェントが、Cloud Exchangeがデプロイされているのと同じRHEL/Ubuntu仮想マシンにインストールされている場合、継続的なスキャンと監視アクティビティにより、かなりのシステムメモリを消費する可能性があります。これによりメモリ不足（OOM）状態が発生し、 Cloud Exchangeユーザーインターフェースがフリーズしたり、場合によってはシステムの再起動が必要になることがあります。

この問題を軽減するために、ディレクトリをホワイトリストに登録することをお勧めします。 Docker (通常は/var ) と VM 上のCloud Exchangeインストールパス。 これにより、不要なスキャンを減らし、過剰なメモリ消費を防ぐことができます。

Q: パブリックIP制限のため、 Cloud Exchange Netskopeテナントと通信できません

Aこの問題を解決するには、Cloud ExchangeサーバーのパブリックIPアドレスがNetskopeテナントの許可リストに追加されていることを確認してください。

手順：

1. Cloud ExchangeサーバーのパブリックIPアドレスを特定します。 不明な場合は、SSH経由で以下のコマンドを実行してください。

   curl -s https://checkip.amazonaws.com

2. Log in to the Netskope tenant.
3. 移動先: Settings > Administration > IP Allowlist 。
4. 特定されたパブリック IP アドレスを以下に追加します NetskopeのIPアドレス.
5. 設定変更を保存します。
6. Cloud Exchangeに戻って再試行してください APIトークンの設定。

パブリックIPアドレスが許可されリストに登録された後、Cloud ExchangeとNetskopeテナント間の通信が復旧し、APIトークンがエラーなく正常に保存されるはずです。

Q: オンプレミス ストリーミング クライアントはCloud Exchange代替として使用できますか？また、 Cloud Exchangeと同じ仮想マシンにデプロイできますか？

AオンプレミスストリーミングクライアントとCloud Exchange （CE）はそれぞれ異なる目的で使用されるため、互換性はありません。

オンプレミスストリーミングクライアントは、NetskopeからSIEMなどの外部システムへのログ転送専用に設計されています。ログの取り込みと転送のためのスタンドアロンソリューションとして機能できるため、ログストリーミングのみの場合はCloud Exchange不要です。 ログストリーミングのみの場合。

しかし、Cloud Exchange（CE）は、ストリーミングクライアントでは処理されないデータエンリッチメント、APIベースの統合、高度なワークフローなどの追加機能を提供します。

導入に関して：

• 共同利用に対応しています。オンプレミスのストリーミングクライアントはCloud Exchangeと同じ仮想マシンにインストールすることはできません。
• 両構成要素の間には、本質的な矛盾が存在する。

Q: Cloud Exchangeプラットフォームは、単一のソースを指す同じプラグイン タイプの複数のアクティブなインスタンスをサポートしていますか?

A: はい、Cloud Exchangeでは同じプラグインの複数インスタンスがサポートされています。ソース側のAPIレート制限によっては、単一インスタンスの場合よりも、複数インスタンスの場合の方が早くAPI制限に達する可能性があります。

Q: Can Cloud Exchange run with lower CPU and RAM than the documented system requirements if my current workload and resource utilization are low?

A: 公開されているCloud Exchangeサイジングガイドラインは、通常のワークロード、ピーク負荷、アップグレード、同期アクティビティ、およびバックグランド処理タスク中に安定した動作を確保するために推奨され、サポートされている構成を示しています。

現在のCPUおよびメモリ使用率は低く見えるかもしれませんが、Cloud Exchangeは、文書化された最小システム要件に対してテストおよび検証済みです。推奨仕様を下回る環境で運用すると、特にアップグレード、同期操作、ログ量の増加、その他のリソースを大量に消費する処理中に、パフォーマンスの低下や予期しない動作が発生する可能性があります。

Cloud Exchangeさまざまな統合やサービス間でのデータ取り込み、同期、共有アクティビティを処理するためのワーカーベースの処理アーキテクチャ。 設定されたワーカープロセスによって、同時に実行できるタスクの数が決まります。

最適なパフォーマンスとシステムの安定性を確保するため、推奨されるワーカープロセスの数は約1.25 times the number of available CPU coresです。このサイズ調整により、Cloud Exchangeはワークロードを効率的に処理し、同時運用を管理し、データ量や統合活動の増加に伴う安定したパフォーマンスを維持することができます。

これらの理由から、Netskopeは現在のリソース利用率が低く見えても、文書化されたシステム要件を維持することを推奨しています。

Q: How to find out the Cloud Exchange installation directory?

A: Cloud Exchangeインストールディレクトリについて知りたい場合は、 デプロイメントの種類に応じて、以下のいずれかの方法を使用してください。

i) コンテナ化 Cloud Exchange 展開の場合:

find / -name "ta_cloud_exchange" 2>/dev/null

ii) Cloud Exchange as VMのデプロイの場合、デフォルトのインストールディレクトリは以下の通りです:

/opt/cloudexchange/cloudexchange

Q: Cloud Exchange (CE) v6.1.0はRHEL 9.7をサポートしていますか？

A： はい。Cloud Exchangeに適格な最低LinuxバージョンはCloud Exchangeシステム要件に記載されています。Cloud Exchange v6.1.0 の場合、RHEL 9.5が最低動作バージョンです。一般的に、最低限限定バージョンを超える新しいマイナーリリースはCloud Exchange展開をサポートすることが期待されています。したがって、Cloud Exchange v6.1.0の展開RHEL 9.7 でのサポートが提供されています。

Q: Cloud Exchangeは複数のNetskopeテナント構成をサポートしていますか?

A: Cloud Exchangeは技術的には複数のNetskopeテナント構成を許可していますが、それは強く推奨されません。複数のテナント構成を同時に実行すると、Cloud Exchangeのパフォーマンスやシステムの安定性が著しく低下する可能性があります。最適な信頼性を確保するためには、デプロイメントごとに単一のテナント構成を維持することを強くお勧めします。

Q: Cloud Exchange関連のサポートケースはどこで開ければよいですか?

Q: Cloud Exchange UIから直接Cloud Exchange SSL証明書を更新することは可能ですか?

A: はい。Cloud Exchange SSL証明書は、CLIアクセスを必要とせずにUIから直接更新できます。

Steps

1. 設定 → 一般 に移動してください。
2. 「証明書の更新」をクリックしてください。
3. SSL証明書は自動的に更新されます。

Note: Cloud Exchangeは警告通知 30 days before the SSL certificate expiresが表示され、証明書の更新を促します。サービスの中断
避けるため、この期間中に証明書
更新することをお勧めします。「証明書の更新」をクリックした後、バックエンド処理が完了するまで5～7分お待ちください。完了後は、Cloud Exchange UIをプライベート/シークレットブラウザウィンドウで開き、更新されたSSL証明書が正常に適用されたか確認してください。

Q: What are the key processor architecture and feature requirements for installing Cloud Exchange?

A: Cloud Exchangeは x86_64アーキテクチャ専用に設計・テストされています。プロセッサに求められる重要な機能の一つは、高度ベクトル拡張（AVX）のサポートである。マシンが安定して動作するためには、x86_64アーキテクチャとAVXサポートの両方を備えている必要があります。

ARM64 Processors are Not Supported: Cloud ExchangeはARM64ベースのプロセッサをサポートしていません。これは、ARM64プロセッサが通常AVXをサポートしていないためであり、AVXはCloud Exchangeの基本的な要件です。 ARM64システム上でCloud Exchangeを実行すると、重要なコンポーネントの故障やパフォーマンスの低下につながる可能性があります。

詳細なシステム要件（CPUコア数、RAM、ディスク容量など、小規模、中規模、大規模といったプロファイルに基づく要件）については、 Cloud Exchangeのシステム要件を参照してください。

Q: How do I configure or update proxy settings for Cloud Exchange after initial setup?

Aコンテナ化されたデプロイメントの場合、セットアップスクリプトを再実行することでプロキシ設定を構成または更新できます。

1. 実行中のCloud Exchangeコンテナを停止します。 sudo ./stop
2. Cloud Exchange のインストールディレクトリ (例: cd /opt/cloudexchange/cloudexchangeまたはcd ta_cloud_exchange ) に移動します。
3. セットアップスクリプトを実行します。sudo python3 ./setup
4. スクリプトの実行中にプロンプトが表示されたら、プロキシの詳細（例： http://proxyserver.example.com:port ）を入力してください。
5. 残りの設定に関する質問に回答してください。
6. スクリプトが完了したら、インストールディレクトリ内の.envファイルcat .envでプロキシ設定を検証できます。CORE_HTTP_PROXYとCORE_HTTPS_PROXY変数を探してください。
7. Cloud Exchangeコンテナを開始します。 sudo ./start

Cloud Exchange UI Option: また、Cloud Exchange UIから設定 >General > Proxyから直接プロキシの詳細を追加・編集できます。ただし、これらの設定がすべてのコンテナ通信に対してシステムレベルで完全に適用されるためには、特にCloud Exchange自体が ホストからの送信接続のプロキシを必要とする場合、環境変数が.envファイルに正しく設定されていることを確認するために、 ./setupスクリプトを再実行する必要がある場合がよくあります。 コンテナランタイムによって。

Q: How can I deploy a specific previous (n-1) containerized version of Cloud Exchange using Git?

A: Cloud Exchangeデプロイメントを Git リポジトリ経由で管理している場合、最新バージョン (n-1 バージョン) より前のバージョンをデプロイするには、次の手順に従ってください。

1. Cloud Exchange Git ディレクトリ (例: ta_cloud_exchange ): cd <your_ce_directory>に移動します。
2. ローカルリポジトリがリモートタグ/ブランチと同期していることを確認してください。 sudo git fetch --all --tags
3. デプロイしたい特定のバージョンタグを確認してください。バージョンタグは通常、 vX.Y.Z : sudo git checkout tags/<version-number>形式です。（例： sudo git checkout tags/v5.1.0 ）
4. このバージョンを設定するには、セットアップスクリプトを実行してください。 sudo ./setup
5. Cloud Exchange開始: sudo ./start

Q: How do I upgrade my containerized Cloud Exchange from an older version to the latest using Git?

A: 古いバージョンから最新のコンテナ化バージョンにアップグレードするには、Git を介して Cloud Exchange を管理している場合:

1. Cloud Exchange Git ディレクトリに移動してください: cd <your_ce_directory> 。
2. メインブランチ（または最新の安定版リリース用に指定されたブランチ、多くの場合「main」または「master」）に切り替えます。 sudo git switch main
3. リポジトリから最新のアップデートを取得します。 sudo git pull
4. 新しいバージョンに合わせて設定変更を適用するには、セットアップスクリプトを実行してください。 sudo ./setup
5. Cloud Exchange開始: sudo ./start

アップグレードを行う前に、必ず新しいバージョンの最新リリースノートを確認し、具体的なアップグレード手順や重要な注意事項を確認してください。

Q: How do I regenerate self-signed SSL certificates for the Cloud Exchange web interface?

A: Cloud Exchangeウェブ サーバーによって使用される自己署名 SSL 証明書を再生成する必要がある場合 (有効期限が切れた場合、よくある名前の詳細を変更したい場合、またはセキュリティ上の理由など)、一般的なコンテナ化された展開の次の手順に従います。

1. メインのCloud Exchangeインストールディレクトリ(/opt/cloudexchange/cloudexchangeやta_cloud_exchangeなど)にアクセスしてください。
2. Cloud Exchangeサービスを停止します。 sudo ./stop
3. SSL証明書が保存されているディレクトリに移動します。通常は次のとおりです。 cd data/ssl_certs
4. 古い証明書とキー ファイル ( cte_cert.crt 、 cte_cert_key.keyなど) を削除またはバックアップします:
   sudo rm -f cte_cert.crt cte_cert_key.key
5. Cloud Exchangeメインインストールディレクトリに戻ります: cd ../.. (データ/ssl_certs にいた場合)
6. セットアップスクリプトを実行します。このスクリプトは、不足している証明書を検出し、新しい証明書の生成手順を案内するか、自動的に生成します。 sudo python3 ./setup
7. Cloud Exchangeサービスの開始: sudo ./start

再生成後、ブラウザに新しい自己署名証明書に関する警告が表示されます。UIにアクセスするには、この警告を承認する必要があります。

Q: What should I do if the Netskope REST API v2 token used by Cloud Exchange expires?

A:APIトークンが期限切れになると、Cloud ExchangeはNetskopeテナントとデータ取得やインテリジェンス共有のための通信能力を失います。Cloud ExchangeのUIには通常、「[テナント名]のNetskopeテナントAPIトークンが期限切れです。」といった警告バナーが表示されます。新しいトークンを生成するか、トークンを再発行してテナント設定を更新し、テナントと Cloud Exchange間の通信を再開Netskope。」 

この問題を解決するには：

1. Netskopeテナントにログインし、 [設定] > [ツール] > [REST API v2]に移動します。
2. Cloud Exchangeインスタンスが設定されている特定のAPI v2トークンを見つけてください。 。
3. トークンの横にある3つの点（省略記号アイコン）をクリックし、「有効期限の変更」を選択します。新しい適切な将来の有効期限を設定します。
4. 同じメニューからトークンを再発行するのも良い方法です。これにより、新しいトークン値が生成されます。この新しいトークン値をコピーしてください。
5. Cloud Exchange UI で、 [設定] > [Netskope テナント]に移動します。
6. テナントの設定を編集し、再発行されたトークンの値を「APIトークン」フィールドに貼り付けてください。
7. 更新されたテナント構成をCloud Exchangeに保存します。

Q: Which virtualization platforms are supported for a Cloud Exchange VM deployment?

A: Netskope 、広く使用されているいくつかの仮想化プラットフォーム用のCloud Exchange VM イメージを提供します。 一般的にサポートされている形式とプラットフォームには次のものがあります。

• VMware vSphere: OVA または Hyper-V – オープン仮想化アプライアンス形式を使用します。 以下は、このメソッドのInstallation Guideです。
• Google Cloud プラットフォーム (GCP): OVA を使用してデプロイ可能なことがよくあります。 以下は、このメソッドのInstallation Guideです。
• Amazon ウェブ サービス (AWS): AMI – Amazon Machine Image 形式を使用します。 以下は、このメソッドのInstallation Guideです。
• Microsoft Azure: VHDX – 仮想ハードディスク形式。 以下は、このメソッドのInstallation Guideです。

導入を予定している Cloud Exchange のバージョンでサポートされているプラットフォームのバージョンとイメージ形式については、必ず最新の Netskope Cloud Exchange ドキュメントを参照してください。

Q: While installing Cloud Exchange as VM using the OVA File and saw a bunch of warnings stating “Your kernel does not support swap limit capabilities or the cgroup is not mounted”. It seemed to install properly but wanted to know if this is something to be concerned about?

Aいいえ、これは心配する必要はありません。メモリの最大制限を設定するには、カーネルでスワップまたはcgroupの制限機能を有効にする必要があります。そのため、Dockerはマシン上でこれをチェックしますが、Ubuntuマシンでは、デフォルトでは有効になっていません。そのため、Dockerはそれを警告として表示します。ただし、理想的には、 Cloud Exchange展開やワークフローに影響を与えるべきではありません。

Q: What to do When a Plugin Is Not Found

Aプラグインリポジトリが古い場合、最新のプラグインが表示されないことがあります。
Solution:

1. Cloud Exchange > Settings > Plugin Repositoryへ移動してください。
2. 「アップデートを確認」（最初のオプション）をクリックしてください。
3. 「プラグインを更新」（3番目のオプション）をクリックしてください。
4. 新しく追加または更新されたプラグインが表示されるようになりました。 必要なプラグインSelect 、 Saveをクリックしてください。

より詳細な情報については、ドキュメント「プラグインリポジトリ」を参照してください。

Q: How to check the health status of Cloud Exchange?

A健康状態は以下の方法で確認できます。

• From Login Page of Cloud Exchange UI: 右隅の情報ツールチップを確認することで、Cloud Exchangeのコンポーネント（コア、UI、MongoDB、RabbitMQ）の現在の状態を確認できます。
• From Cloud Exchange CLI in the machine: Cloud Exchangeをインストールしたパスに移動し、次のコマンドを実行して、Cloud Exchangeの各コンポーネント（Core、UI、MongoDB、RabbitMQ）に関連付けられたコンテナの状態を確認できます。

• sudo docker ps （Ubuntuマシン向け）
• sudo podman ps （RHELマシン向け）

Q: How to create V2 token for Cloud Exchange with RBAC V3 enabled in the Netskope Tenant?

AREST API V2トークンプロビジョニングのワークフローは非推奨となります。今後のトークン プロビジョニングは、RBAC V3 と統合された新しいサービス アカウントの作成および管理プロセスを使用して実行する必要があります。

したがって、v2トークンを作成する手順を説明した以下のドキュメントガイドとそのサブセクション記事をご確認ください。 RBAC V3: /en/managing-administrators-for-rbac-v3

Q: Can the Cloud Exchange Log Shipper pull logs from the Netskope Cloud Proxy through our on-premises proxy?

A： はい。Cloud Exchangeでプロキシ設定が適切に構成されている場合、ログシッパーからNetskopeテナントへのすべての接続はオンプレミスのプロキシを経由してルーティングされ、ログを正常に取得できるようになります。

Q: なぜ git pull や git clone の作戦中に「Git クレデンシャル」を求められるのですか?

Gitが git pull や git clone 操作中にクレデンシャルを要求する場合、それは使うキャッシュや古くなった認証情報がGit クレデンシャルマネージャーに保存されている可能性があります。

キャッシュされたクレデンシャルを消去するには、以下のコマンドを実行します:

git credential reject

キャッシュされたクレデンシャルを削除した後、Git操作を再度試行してください。 Gitは再度認証を促し、正しいクレデンシャルを入力できるようにします。

問題が解決しない場合は、リポジトリのURL、認証方法、およびアクセス権限が正しく設定されていることを確認してください。

Q: Is Cloud Exchange High Availability (HA) supported for both VM and containerized deployments?

Aはい、Cloud Exchange の高可用性機能は、Linux マシン (Ubuntu や RHEL など) 上のスタンドアロン (コンテナ化) デプロイメントだけでなく、仮想マシン (VM/OVA) としてデプロイされた Cloud Exchange でも動作するように設計されています。

Q: Can a Cloud Exchange HA cluster operate with nodes in different data centers (Multi-DC)?

Aはい、Cloud Exchange HAは、インスタンス（ノード）が複数の物理データセンターまたはアベイラビリティゾーンにまたがって実行される構成をサポートしています。

Q: What is the recommended approach for deploying an HA cluster across multiple data centers (Multi-DC)?

A堅牢なマルチデータセンターHA構成を実現するには、以下の点を考慮してください。

• 異なるデータセンターにCloud Exchangeノードを配置すると同時に、参加するすべてのノード間で安定した、信頼性の高い、低遅延のネットワーク接続を確保する。
• Cloud Exchange HA は、共有ストレージ層としてGlusterFSを利用します。GlusterFSのインストールと構成は、 Cloud Exchangeと管理サーバーを通じて管理され、クラスターに共有ストレージと高可用性機能の両方を提供します。
• HA構成プロセス中は、HAクラスタに参加するすべての仮想マシンが必要なGlusterFSリポジトリに接続できることを確認してください。
• 各Cloud Exchangeノードが、データ同期、クラスタの健全性監視、およびフェイルオーバー操作をサポートするために、他のクラスタノードと確実に通信できることを確認してください。
• 最適なHAクラスタの安定性を確保するために、ネットワークパスの冗長性、GlusterFSの可用性、およびネットワーク全体のパフォーマンス（特にレイテンシと帯域幅）を徹底的に検証します。

Q: What are the key network requirements for a Cloud Exchange node in a secondary site  participating in a Multi-DC HA deployment using GlusterFS?

A重要なネットワーク要件は以下のとおりです。

• Reliability & Stability:すべてのCloud Exchange HAノードとGlusterFSクラスタ間のネットワーク接続は、安定していて信頼できるものでなければなりません。ネットワークの中断は、データ同期、クラスタの健全性、および高可用性（HA）の動作に影響を与える可能性があります。
• Low Latency: データセンターをまたがるCloud Exchangeノード間のネットワーク遅延は、可能な限り低く抑えるべきである。 レイテンシが高いと、GlusterFSの同期、共有ストレージへのアクセス、アプリケーションのパフォーマンス、およびフェイルオーバー操作に影響が出る可能性があります。
• Sufficient Bandwidth: Cloud Exchangeのデータ同期、共有ストレージ操作、ログ処理、およびHA関連のアクティビティをサポートするには、十分なネットワーク帯域幅が必要です。帯域幅の要件は、想定されるワークロードとデータ量に基づいて評価する必要があります。
• GlusterFS Connectivity: すべてのCloud Exchange HAノードは、GlusterFSクラスターおよび必要なGlusterFS通信ポートへの安定した接続を維持する必要があります。これにより、共有ストレージへの適切なアクセスと、HA環境全体での同期の成功が保証されます。
• Inter-Site Connectivity Validation: マルチDC HA構成をデプロイする前に、すべてのCloud Exchangeノード間のネットワーク接続性、遅延、パケット損失、ルーティングの安定性、およびGlusterFSへのアクセス可能性を検証し、信頼性の高いHA機能とフェイルオーバーの準備状況を確認してください。

Q: Are performance issues expected if Cloud Exchange HA nodes are deployed in different data centers (Multi-DC)?

A可能性はある。すべてのノードが同じデータセンター内にある（したがって非常に低遅延である）HA構成と比較すると、マルチDC HA構成では、地理的に離れたデータセンター間の固有のネットワーク遅延のために、運用上の遅延がわずかに増加する可能性があります（特定の操作やフェイルオーバーで数秒程度）。

パフォーマンスは以下によって影響を受ける可能性があります。

• データセンター間ネットワークの遅延。
• データセンター間のリンクにおけるパケット損失。
• サイト間の帯域幅制限。

マルチデータセンターHA展開における潜在的なパフォーマンスへの影響を特定し軽減するためには、綿密なネットワーク設計、データセンター間リンクの容量計画、 Cloud Exchangeクラスタの前段における適切な負荷分散戦略、および厳格なフェイルオーバーテストが不可欠です。

Q: How does failover and traffic handling typically work in a Multi-DC HA setup for Cloud Exchange?

A: Cloud Exchange HAは自動フェイルオーバーを前提に設計されています。クラスタ内のアクティブなノードが応答しなくなったり失敗した場合、HA機構はその障害を検知し、他のデータセンターに存在する健康なスタンバイノードをアクティブな運用を引き継ぐよう調整します。新しいアクティブノードへのトラフィックリダイレクトは、外部ロードバランサー、DNS更新、クライアント側の再試行メカニズムなど、統合アプリケーションによるデプロイアーキテクチャに依存します。

マルチデータセンターHA展開の包括的なテストには、通常、以下のシナリオが含まれます。

• ノードの故障をシミュレートします(例:VMの電源オフ、Cloud Exchangeサービスの停止、あるノードのコンテナ再起動など)。
• フェイルオーバー後のすべてのノードおよび GlusterFS 分散ストレージにおけるデータの一貫性と整合性の検証。
• すべてのアクティブおよびスタンバイノードから GlusterFS ボリュームへの読む/write操作をテストしています。
• ボリュームの状態やレプリケーション/同期など、GlusterFSクラスタの健全性を確認します。
• HA同期の状態を確認し、すべてのクラスタノード間の正常な通信を確保します。

Q: Which Cloud Exchange modules (CLS, CTE, CTO, CRE) are typically verified during Multi-DC HA testing?

A検証は一般的に、マルチDC HA構成におけるフェイルオーバーイベント中およびイベント後に、すべての主要な Cloud Exchange モジュールのワークフローが中断されないか、迅速に復旧されることを保証するために実行されます。これには以下が含まれます。

• CLS (Cloud Log Shipper): Netskopeからの継続的なデータ取り込みと、重大なデータ損失や過剰な重複のないサードパーティ製SIEMへの転送を保証します。
• CTE (Cloud Threat Exchange): クラスター全体および統合されたセキュリティツールとの間で、脅威インテリジェンスのシームレスな共有、同期、および適用を検証する。
• CTO (Cloud Ticket Orchestrator): 自動化されたチケット作成、更新、およびITSMシステムとの同期が、誤った重複チケットを作成することなく、引き続き正しく機能することをテストします。
• CRE (Cloud Risk Exchange): ユーザー、ホスト、およびアプリケーションのリスクスコアが引き続き評価、共有され、統合システムで利用できる状態であることを保証する。

Q: What is the procedure of stopping and restarting Cloud Exchange Nodes in HA?

Aシャットダウンと起動の手順は以下のとおりです。

Stopping Cloud Exchange:

1. 各セカンダリノードを1つずつ停止してください。
2. プライマリノードを停止します。

Starting Cloud Exchange:

1. 最初にプライマリ ノードを起動します。
2. 各セカンダリ ノードを 1 つずつ起動します。

Q: Will an NFS server still be required for High Availability (HA) after upgrading to Cloud Exchange 6.x?

A: Cloud Exchange 6.x以降、高可用性(HA)アーキテクチャはもはやNFSサーバーを必要としません。Cloud Exchange 6.1.0にアップグレードする顧客またはそれ以降は、共有ストレージがHAの依存関係ではなくなったため、HA展開からNFSサーバーを削除できます。

Q: How far back can Log Shipper retrieve historical alerts from the Netskope tenant?

A: Netskopeプラットフォームは通常、詳細なアラートをアクティブなデータベースに約 3 か月間保存します。 Log Shipperの履歴取得機能を使用すると、Netskopeテナント内のこの保持期間内からアラートを取得できます。

Q: How can I perform a historical pull of older logs using the Log Shipper module?

ALog Shipperには、過去のアラートおよびイベントデータを取得する機能が含まれています。これを使用するには:

1. Cloud Exchangeのユーザーインターフェースで、メインメニューから「ログシッパー」モジュールに移動します。
2. Log Shipper内で、 SIEMマッピングセクション（またはデータ送信先の設定を担当する同様の名前のセクション）に移動します。
3. SIEMマッピングページで、 「履歴データの取得」を探し、そこで履歴データを取得する日付範囲を選択できます。 SIEMマッピングページ（既存のマッピングまたはルールの一覧付近）にあるアイコンをクリックしてダイアログを開きます。
4. 「履歴データの取得」ダイアログで、ログを取得する開始日と終了日の範囲を選択し、取得プロセスを開始します。

Important Considerations:

• 大量の履歴データを取得するには時間がかかり、 NetskopeテナントとCloud Exchangeインスタンスの両方に負荷がかかる可能性があります。 それに応じて計画を立ててください。
• SIEMの取り込み設定やタイムスタンプの処理方法によっては、過去のデータを取得する際に、既に部分的に取り込まれているログや、進行中のストリーミングと時間範囲が重複している場合、ログの重複が発生する可能性があります。

Q: How can I stop an ongoing historical log pull in Log Shipper if needed?

A： はい。Log Shipperでアクティブな履歴データ取得プロセスを停止する必要がある場合、一般的な方法はCloud Exchangeサービスを再起動することです。これは、Cloud Exchange ホストのコマンドラインインターフェイス (CLI) を使用して、Cloud Exchange のインストールディレクトリに移動し、 sudo ./stopの後にsudo ./startを実行することで実行できます。

Q: What are the types of Alerts and Events that Log Shipper can typically fetch from the Netskope tenant?

ALog Shipperは、Netskope Security Cloud Platformによって生成される包括的な範囲のアラートとイベントを取得できます。よくある例としては次のようなものがあります。

• Alerts: 侵害されたクレデンシャル アラート、ポリシー違反アラート (ウェブ アクセス、クラウド アプリの使用などのさまざまなポリシーに関する)、マルサイト アクセス アラート、マルウェア検出アラート、データ損失防止 (DLP) インシデント、セキュリティ評価の結果 (構成ミス)、隔離アクション、修復イベント、ユーザーおよびエンティティ行動分析 (UBA) の異常とアラート、ウォッチリスト アラート、CTEP、デバイス、および コンテンツ。
• Events: 詳細なページ アクセス イベント、アプリケーション使用状況イベント、監査ログ ( Netskopeプラットフォーム内の管理アクションの追跡)、インフラストラクチャ関連イベント、ネットワーク イベント ( Netskopeサービスに該当する場合)、および関連するアラート/イベント、エンドポイント、およびクライアント ステータス ログをグループ化する包括的なセキュリティ インシデント。

Q: What indicators in Cloud Exchange can help verify the timeliness of logs being pulled from Netskope and sent to external log servers?

Aログが最新かどうかは、Cloud Exchangeのログ記録セクションを確認することで確認できます。

• 「履歴」とラベル付けされたログは、通常、初期同期中、相対的な遅延時、またはバックログ処理中に、古いデータが取り込まれていることを示しています。
• リアルタイムとラベル付けされたログは、システムが最新のデータを処理し、宛先ログサーバーに転送していることを示しています。

Q: What is the Streaming Client Docker? How does it differ from CLS?

A: ストリーミングクライアントDockerは、ウェブTXログのみを受信し、SYSLOG形式で出力してSYSLOG互換SIEMと統合するように設計された軽量のコンテナ化ソリューションです。

主な違い：

Q: If we already have a SIEM capable of receiving TX logs, do we still need to purchase additional public cloud storage?

Aはい、SIEMが直接ログを取り込む場合でも、ストリーミングされたウェブTXログをホストするためには、パブリッククラウドストレージ（S3、GCS、Azure Blobなど）が依然として必要です。

Q: How does Cloud Exchange handle unsent logs if an outward CLS plugin (e.g., Syslog plugin) fails to forward logs due to a network issue (e.g., firewall restrictions, etc.)?

A: Cloud Exchangeがログの転送中にネットワーク問題が発生した場合、ログの再送信を試みup to 3 times。それでも配信が失敗した場合は、ログは破棄されます。

ただし、 “Retry Till Successful Delivery”オプションを有効にすると、配信が成功するまでログが継続的に再試行されるようになります。

さらに、過去の出来事も検索できます。Cloud Exchangeが何らかの問題により特定の時間帯にログを取り込めない場合でも、Netskopeテナント内にログが残っている限り、後でそれらのログを取得することができます（Cloud Exchangeはテナントから直接ログを取得するため）。

Q: BWANログをChronicleに送信できますか？ Cloud Exchangeプラグインは？

Aいいえ、現在のCLS Chronicle v2.2.0プラグインのマッピングは、BWANイベントの取り込みをサポートしていません。ChronicleはUDMマッピングに依存している。回避策として、 Syslogプラグインを使用してBWANログをSyslogサーバーに転送することができます。

Q: What are the validations of log ingestion delay in Cloud Exchange？

A: 理想的には、SIEM で遅延ログを受信しないはずです。 ただし、受信している場合は、 Cloud Exchange Cloud Exchangeからそれを検証するために、ログ取り込みの遅延が過去のログの取得によるものかどうかを確認してください。

1. 例えば、Netskopeテナントからマルウェアアラートを取得した際のログメッセージを以下に示します。

"message":"TENANT Netskope Tenant (Required) [Netskope Tenant Demo]: Pulled 0 Malware alert(s) for tenant Netskope Tenant Demo in JSON format using Netskope Tenant Demo_Malware index, pulled data till 2025-07-21 18:59:58.","type":"info","createdAt":{"$date":"2025-09-06T06:38:45.726Z"}

ここでは、マルウェア警告の取得が過去から行われていることがわかります。これが、あなたが最近数日前のログイベントを受け取った理由です。このようなデータ取得は、過去のデータ取得を手動で行うか、Netskope Log Shipperプラグインの初期範囲として長期間を設定することによって開始できた可能性があります。あるいは、Netskopeテナントからログを取得する際の接続の問題が原因である可能性もありますので、ログセクションでこの点を確認し、ログ取得時に断続的または繰り返し発生するエラーがないか確認してください。

2. ログ取り込みの遅延が、SIEMでのログ取り込み中に発生したエラーによるものかどうかをご確認ください。

例えば、アラート／イベントを希望の宛先に取り込む際に10秒以上かかる場合、以下のログメッセージを参照してください。 

• "message":"Ingested 10000 [events][network] log(s) into configuration <Your-Destination-Configuration> successfully. Time taken: 129 seconds.","type":"info","createdAt":{"$date":"2025-07-25T14:55:19.546Z"}
• "message":"Ingested 8248 [alerts][policy] log(s) into configuration <Your-Destination-Configuration> successfully. Time taken: 114 seconds.","type":"info","createdAt":{"$date":"2025-07-25T14:55:20.622Z"}

CEからSyslog、QRadar、Azureなどの宛先へのアラート、イベント、ウェブトランザクションログのバッチ1つ分の取り込み時間は、10秒未満になると推定しています。 1バッチは約10,000件のアラート、10,000件のイベント、または5MBのウェブトランザクションログに相当します。

ご参考までに、上記の情報を以下のドキュメントに記載しています。/en/Cloud Cloud Exchange system-requirements

したがって、これらの観察結果に基づき、貴社SIEM側からのログ受信の遅延問題についてご確認いただくようお願い申し上げます。

Q: Is there a workaround/alternative to assigning the AWS S3 Bucket permission to the IAM user for the Cloud Log Shipper AWS S3 Alerts Events plugin? 

A: いいえ、AWS S3 Alerts Eventsプラグインは、S3バケットが外部でプロビジョニングされ、プラグインの実行環境とは別に管理されている環境をサポートしていません。

例としては以下のようなものがあります。

• Terraformで管理されるインフラストラクチャ
• CloudFormationで管理されるインフラストラクチャ
• Kubernetes + IaCベースのデプロイメント
• 集中型プラットフォームエンジニアリングまたは共有インフラストラクチャモデル

このような環境では、バケットは通常、インフラストラクチャチームによって事前に作成され、ランタイムIAMロールは、アカウントレベルの検出やインフラストラクチャの作成操作を実行できないように意図的に制限されています。

そのため、既存のプラグインでは、現在のAWSアカウント内で指定されたバケットを見つけることができません。この実装はlist_buckets()に依存しており、 s3:ListAllMyBuckets権限が必要です。設定されたIAMにこの権限が存在しないため バケット検索は失敗するか、必要なバケットが返されません。

本来の設計ロジックでは、バケットが見つからない場合、プラグインは自動的にバケットを作成しようとします。ただし、ランタイムロールにもs3:CreateBucket権限がない場合、プラグインの設定が失敗します。

Q: Why am I seeing a “token expiration or Event Streaming is disabled” banner in the Cloud Exchange console GUI?

A: このエラーは、 旧バージョンのWebTx pluginがGoogle Pub/Subで構成されている場合に発生します。 はサポート終了 (EOL) を迎えています。 これを解決するには、WebTx を新しいNetskope Log Streaming pluginに移行する必要があります。これには、新しいトークンを生成する必要があります。

A: Google SecOpsの公式ガイダンスによると、Chronicle(インジェスションAPI)統合に必要なサービスアカウントおよび対応するクレデンシャルは、顧客が独立して生成してはなりません。 代わりに、これらのクレデンシャルはGoogle SecOpsのサポートチームまたは担当者から直接提供されます。

Q: How should the Service Account Key be generated for the Google Chronicle Plugin integration in Netskope Cloud Exchange?

A: 顧客はGoogle SecOpsチームにコンタクトで正しいサービスアカウントキーを取得することをお勧めします。これにより適切な設定が保証され、認証や取り込みエラーを回避できます。 Netskopeは、顧客のGoogle環境や設定によってプロセスが異なる可能性があるため、鍵作成のためのカスタムステップの作成やドキュメント作成は推奨していません。

詳細については、Googleの公式ドキュメントを参照してください。

Q: Can the Ticket Orchestrator module use Netskope Events (in addition to Alerts) to create tickets in an ITSM system?

Aいいえ、チケットオーケストレーターモジュールの主な設計目的は、Netskopeテナントによって生成されたアラートを処理することです。これらのアラートと、Cloud Exchangeで設定したビジネスルールに基づいて、統合されたITSMシステム（ServiceNow、Jiraなど）に対応するチケットが作成または更新されます。通常は チケットを直接作成するための、 Netskope生イベント（より詳細なアクティビティログ）は使用しません。

Q: How can I prevent Ticket Orchestrator from creating duplicate tickets for the same recurring Netskope alert?

ATicket Orchestratorには、同じセキュリティ問題やアラートに対して複数のITSMチケットが作成されることを回避するためのアラート重複排除メカニズムが含まれています。これらの重複排除設定は、ビジネスルールまたはチケットオーケストレーターモジュールのグローバル設定内で構成できます。これには、特定の警告フィールド（警告名、影響を受けるユーザー/リソース、脅威名など）と時間枠に基づいて基準を定義することが含まれます。新しいアラートが条件に基づいて既存のアラートと一致する場合、Ticket Orchestrator は新しいチケットを作成する代わりに既存のチケットを更新できます。

Q: What is the default retention period for alerts stored locally by Cloud Exchange for the Ticket Orchestrator module, and can this be changed?

Aチケットの追跡と重複排除のため、チケットオーケストレーターモジュールはアラート情報をCloud Exchange内にローカルに保存します。 これらの保存されたアラートのデフォルトの保持期間は通常7日間です。はい、この保持期間は、Cloud Exchange UI の[設定] > [チケットオーケストレーター] (またはモジュール固有の設定の場合は同様のパス) に移動し、アラートの保持期間の値を運用上のニーズに合わせて調整することで変更できます。

Q: Why is the Jira Status field not being updated according to the plugin field mappings?

A：これはJiraの既知の制限事項です。ステータスフィールドはシステム管理フィールドであり、標準のJira REST APIを使用して直接変更することはできません。Jiraのステータス変更は、直接的なフィールド更新ではなく、定義されたワークフローの移行を通じてのみ発生します。

その結果、プラグインで設定されたステータスマッピングは、Jira課題の作成または更新時には適用されません。

ステータスフィールドに加え、Jiraのデプロイメントタイプやワークフロー設定によっては、APIを通じた直接更新が制限される場合があります。

ワークフローベースの更新が必要なフィールドでは、Jiraワークフロートランジションはフィールドマッピングではなく使うにすべきです。

Q: Where in the Cloud Exchange UI can I view the threat indicators (IoCs) received by the Threat Exchange module?

A: Threat Exchange が処理および保存した脅威インジケーターを表示するには、左側のパネルにあるThreat Exchangeに移動し、次にThreat IoCを選択します。このページでは、値、タイプ(URL、MD5、SHA256、IP)、Netskopeヒット数、その他のソースからのヒットを含むIoCを一覧したソート可能かつフィルタ可能な表が表示されます。

Q: How can I identify the original source of a specific Threat IoC listed in Cloud Exchange?

A脅威エクスチェンジ > 脅威IoCページでは、UIにフィルタリング機能が提供されています。特定のソース(例えばProofpointや CrowdStrikeなど)からIoCを見つけるには、使うフィルタービルダーを使うことができます。 基礎となるクエリ言語のフォーマットは[sources.source Like "plugin_identifier"]のようなもので、 ソース フィールドを選択しプラグイン名や識別子を指定することで使うUIのフィルターインターフェースを構築することもよくあります。

Q: How can I create and manage tags for IoCs within the Threat Exchange module?

AタグはIoC（侵害指標）の分類と管理に役立ちます。これらのタグを作成および管理するには、左側のパネルにある「脅威交換」に移動し、 「タグの管理」を選択します。タグ名（例： High_Confidence_Malware_URL ）を入力して追加できます。既存のタグもこのページに一覧表示され、編集または削除するオプションも用意されています。

Q: Which versions of Netskope API tokens are required for the Threat Exchange module to operate correctly?

ANetskope から脅威インテリジェンスを取得する (IoC を生成するポリシー違反など) ことと、外部の脅威インテリジェンスを Netskope にプッシュする (ポリシー適用のため) ことの両方を含む完全な機能を実現するには、Threat Exchange モジュールは通常、Netskope REST API v1 と REST API v2 の両方の API トークンを必要とします。Cloud Exchangeの「設定」>「Netskopeテナント」で、両方が必要な権限で正しく設定されていることを確認してください。

Q: How do I create a deduplication or exception rule in Threat Exchange to prevent processing redundant IoCs?

AIoCの重複処理を防止するルール（特定のIoCを除外したり、特定のソースからのIoCがそれ以上共有されないようにするなど）を作成するには、脅威交換モジュールのビジネスルールでこれを構成できます。

1. Cloud Exchange UI で、 [脅威交換] > [ビジネスルール]に移動します。
2. 新しいビジネスルールを作成するか、既存のビジネスルールを編集してください。
3. ビジネスルールの設定において、IoC選択の主要な基準を定義した後、例外ルールや同様の条件ロジックを追加するオプションを探してください。プライマリルール（URLのみなど）を展開し、例外ルールの横にある「+」アイコンをクリックします。
4. 例外ルールでは、そのビジネスルールのアクションから除外すべきIoC（侵害指標）の基準を定義できます。

Q: Does Threat Exchange fetch IoCs directly from the Netskope tenant UI under Incident > Malware?

A： いいえ。Threat Exchangeモジュールは主に、プラットフォームが生成する特定のアラート、特にSkope ITマルウェア警告やマルウェア警告に基づくNetskopeからのIoCを取得します。通常、一般的な Incident >マルウェア 概要ページから直接IoCを引き出すことはありません。もしそのページが Netskope テナントUI内の異なるデータ集約やビューを表している場合です。 IoC生成のために Cloud Exchange 処理するアラートの種類を見るには、 Netskope テナントのメイン アラート ページにアクセスし、フィルターオプションでアラートタイプを Malsite と マルウェアとして選択し、「 適用」をクリックしてください。

Q: What is the purpose of the Aging Criteria setting in a Threat Exchange plugin configuration?

AThreat Exchange のエイジング基準 (インジケーターの場合は Time To Live または TTL と呼ばれることもあります) は、元のソース プラットフォーム (そのプラグインを介して統合されたサードパーティ ツール) がインジケーターの報告を停止したり削除したりした後、Cloud Exchange がインジケーターをアクティブとみなし続ける期間を決定します。Cloud Exchangeは、IoCを自身のデータベースやNetskopeのポリシーから即座に削除するのではなく、設定された期間（デフォルトは通常90日間）に基づいて、IoCを一定期間経過後に削除します。これにより、送信元が一時的にIoCの送信を停止した場合、または元の送信元がもはやアクティブな脅威とみなしていなくても、履歴コンテキストや保護の延長のために一定期間アクティブな状態を維持したい場合に、IoC
ポリシーに出入りすることを防ぎます。

Q: Why Does the Trend Micro Vision One Plugin Convert Full URLs to Domains?

Aこの動作は設計上の仕様であり、トレンドマイクロ Vision One プラットフォームの要件に準拠しています。このプラグインは、Netskopeからの侵害指標（IOC）を処理し、入力にプロトコル（ http://やhttps://など）が含まれているかどうかを確認します。

• URLにプロトコルが含まれている場合、それはURLタイプのオブジェクトとしてTrend Micro Vision Oneに転送されます。
• URLにプロトコルが含まれていない場合、プラグインはルートドメインを抽出し、それをドメインタイプのオブジェクトとして転送します。

この実装は、トレンドマイクロ Vision One が脅威オブジェクトを処理する方法と一致しています。

• ドメインフィールドはルートドメインのみを受け入れます（例： example.com ）。
• URLフィールドにはプロトコルと完全なURL構造（例： https://example.com/path ）が必要です。

そのため、 Netskopeインジデントの指標にプロトコルが欠落している場合、プラグインはそれがドメイン エントリであると想定し、それに応じて Vision One プラットフォームとの互換性を保つためにフォーマットします。

Q: What are the configurational steps for configuring CTE Abnormal plugin in Cloud Exchange?

A以下のREADMEファイルには、プラグインの設定ガイドの詳細が記載されています。これは、CTE Abnormal Security v1.0.0プラグインのCloud Exchange構成手順を詳しく説明するものです。使用ケースを実現するためにプラグインを確認し、それに応じて設定してください:異常なセキュリティ/docs/README.md

Q: You have received notification of the planned decommission of Detect APIs from Crowdstrike. Are any changes required for Cloud Exchange (CTE), and what is the impact of this change?

A: CrowdStrikeからの通知では、Legacy Detect APIs from Crowdstrikeの2025年9月30日までに廃止(サービス終了)することが発表されています。以前 Cloud Exchange これらのAPIをCTE統合のために使うしていたため、影響を受けるでしょう。

したがって、 Alerts APIを利用するために必要な変更は、 CTE Crowdstrike plugin (v2.3.0)の最新バージョンに既に含まれていることをお知らせします。Cloud Exchangeの観点からすると、CTE CrowdStrikeプラグインのバージョンを更新するだけで済みます。
Note: プラグインのバージョンを更新する前に、 CrowdStrike側でクライアント ID/シークレットに“Detections (read)”スコープが適用されていることを確認してください。 CTE CrowdStrikeプラグインで。 これは、CTEが検出APIからアラートAPIに移行しているため必要です。プラグインのバージョンをv2.3.0にアップデートした後、クライアントID/シークレットから「検出」スコープを削除する必要があります。
Cloud Exchangeのプラグインバージョンを更新する手順については、次のドキュメントを参照してください: /en/update- Cloud Exchange plugins

Q: Cloud Exchange Threat ExchangeでRetrohuntを有効にすると、401クライアントエラーが発生するのはなぜですか？

A脅威交換モジュールでRetrohuntを有効にする際に発生する401クライアントエラーは、通常、API権限の誤りではなく、テナントレベルの前提条件が不足していることが原因です。

正常に Retrohunt API を使用するには、以下の要件を満たしていることを確認してください。

• テナントは、高度な脅威対策のライセンスを取得している必要があります。
• Retrohunt API クエリ機能は、 Netskopeプラットフォーム チームによってテナント上で有効にする必要があります。
• RBAC v3トークン（事前定義されたNetskope Cloud Exchangeロール付き）が必要です。
• 割り当てられた役割には、脅威対策スコープの下でマルウェアへのアクセス権限が有効になっている必要があります。

Resolution Steps:

1. 組織が有効なAdvanced Threat Protectionライセンスを保有していることを確認してください。
2. Retrohunt APIクエリ機能がまだ有効になっていない場合は、カスタマーサクセスマネージャー（CSM）またはテクニカルアカウントマネージャー（TAM）に連絡して有効にしてもらうよう依頼してください。
3. 必ず 適切な役割と権限を持つRBAC v3トークンであることを確認してください。 

Q: ファイルハッシュリストの制限である8MBに近づいた場合、ファイルプロファイルはどのように管理すべきですか？

A: 8MBの制限は、ファイルハッシュリストのAPIペイロード制限です。この制限に達すると、最大8MBのデータのみが処理され、それ以上のIoCはスキップされます。事前に適切に対処しないと、重要な指標を見落とす可能性があります。

取り込みのギャップや手動による介入を避けるため、単一のリストに頼るのではなく、ファイルハッシュリストを分散および分割することが推奨される戦略です。

Best Practices

• Use multiple file hash lists
  以下のような基準に基づいて、IoCを別々のリストに分散します。
  • 重症度（高／中／低）
  • ソース（例：さまざまなフィードやツール）
  • IoCの種類またはカテゴリ（該当する場合）。
• Align configurations accordingly
  個別の共有設定とビジネスルールを作成し、それぞれを専用のファイルハッシュリストにマッピングします。これにより、より適切な制御が可能になり、単一のリストでペイロード制限に達することを回避できます。

Q: 複数の宛先プロファイルを設定できない、または検証エラーが発生するのはなぜですか？ Cloud Exchangeの宛先プロファイルについて

A: これは、現在のCloud Exchange機能における既知の制限事項です。 設定中に 単一の目的地プロファイル 期待どおりに動作し、構成を試みます 複数の宛先プロファイル セットアップ中に検証エラーが発生する可能性があります。

一時的な回避策として、宛先プロファイルを使用するアクションと URL リストを使用するアクションを構成できます。 私推奨される 宛先プロファイルアクションとURLリストアクションには、異なるビジネスルールを設定する このアプローチは、同様の使用ケースに対して効果的に機能することが検証されているためです。

問題が特定されたことを確認しており、現在修正作業を進めております。この修正は、今後のCloud Exchangeバージョンのリリースに含まれる予定です。URLリストは将来的に廃止される予定ですが、サポート終了（EOL）まで6か月以上あるため、これは有効な暫定的な解決策となります。

Q: Why are HTTP/HTTPS URLs not synchronizing to the Destination Profile when using Exact Match?

A: この挙動は想定内です。宛先プロファイルは、マッチタイプが完全一致に設定されている場合、HTTP/HTTPS URLをサポートしません。

HTTP/HTTPS URLを正常に同期させるには、マッチタイプをCloud ExchangeおよびNetskope宛先プロファイルの両方で RegEx として設定する必要があります。

Resolution: 両側で Match Type を RegEx として設定します。Cloud Exchangeで Threat Exchange > Sharingに移動し、関連する共有設定を編集し、「 マッチタイプ 」を RegExに設定します。同様に、Netskopeのテナントでは Destination Profilesに移動し、対応するプロフィールを編集し、 マッチタイプ を RegExに変更します。

両側で設定すれば、HTTP/HTTPS URLは正常に同期されます。

Q: From which part of the Netskope platform does Cloud Exchange’s Risk Exchange module pull user and host risk scores?

ACloud Exchange のリスク交換モジュールは、主に Netskope のユーザーおよびエンティティ行動分析 (UEBA) 機能によって生成されたユーザーおよびホストのリスクスコアを取得します。具体的には、多くの場合、Netskopeテナント内のSkope IT UBAアラートからこの情報を取得します。Netskopeテナントでこれらの種類のアラートを直接表示するには、メインのアラートページに移動し、 フィルターオプションでアラートタイプをUBAに選択し、適用をクリックします。

Q: Is a specific Netskope license required to fetch user risk scores using the Risk Exchange module?

A： はい。Netskope内でユーザーリスクスコアを生成し、 Cloud Exchangeのリスク交換モジュールで取得および共有できるようにするには、通常、 Netskopeテナントに高度なUEBA（ユーザーおよびエンティティ行動分析）ライセンスが必要です。