Cloud Exchangeよくある質問

Q: Netskope Cloud Exchangeとは何ですか？

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

Q: Cloud Exchangeの主なモジュールは何ですか？また、それらはどのようなデータを扱いますか？

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: Cloud Exchangeまたはそのプラグインを以前のバージョンに戻すことはできますか？

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

Q: Cloud Exchangeのオペレーティングシステム（OS）のアップデートはどのように管理されますか？

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: Cloud Exchangeそのプロセスにユーザー ID 1001 を使用するのはなぜですか?

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

Q: NetskopeからCloud Exchange経由でログを取得またはエクスポートする際のレート制限はありますか？

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

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

Q: データの整合性を維持しながら、 Cloud Exchangeサーバー上でサーバーレベルの変更を行うには、どのような手順を踏むべきですか？

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

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

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

Q: Cloud Exchange機能を利用するには、追加のライセンスを購入する必要がありますか？

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

Q: CE ウェブ URL に「安全ではありません」という警告が表示されるのはなぜですか? これはCloud Exchange自体に関係する問題ですか？

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

Q: Cloud ExchangeはFIPS準拠のUbuntuをサポートしていますか？

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

Q: 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: セットアップ スクリプトまたはスクリプト開始「-bash: ./開始:」中にこのエラーが発生します。 /bin/sh^M: 不正なインタプリタ？

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: 現在のワークロードやリソース利用率が低い場合、Cloud Exchangeは文書化されたシステム要件よりも低いCPUとRAMで動作できますか?

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

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

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

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

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

Q: Cloud Exchangeのインストールディレクトリはどうやって見つけますか?

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証明書は自動的に更新されます。

Cloud Exchange に警告通知 30 days before the SSL certificate expires が表示され、証明書の更新を促すメッセージが表示されることに注意してください。サービスの中断を回避するため、この期間中に証明書を更新することを推奨します。

「証明書の更新」をクリックした後、バックエンドの処理が完了するまで 5～7 分ほどお待ちください。完了したら、プライベート/シークレットブラウザウィンドウで Cloud Exchange UI を開き、更新された SSL 証明書が正常に適用されたことを確認してください。

Q: 「https://reporting.netskope.tech… との接続を確立できません」というエラーが表示されるのはなぜですか？コンソールで？

A: URL https://reporting.netskope.tech は、以前は Netskope Analytics Server に分析データを共有するために使用されていました。この URL は古いバージョンの Cloud Exchange で使用されており、現在は非推奨となっています。このエラーは無視しても問題ありません。Cloud Exchange において機能上の問題は発生しません。

Q：Cloud Exchange（CE）ダッシュボードで、カスタムインストール環境のディスク使用量が不正確に表示されるのはなぜですか？

A: デフォルトでは、Cloud Exchangeのユーザーインターフェースは、プライマリルートディレクトリ（/）に基づいてディスク使用量を計算します。デプロイメントが別のファイルシステムまたは専用のマウントポイントでホストされている場合、ダッシュボードに表示されるストレージメトリクスがカスタムインストールパスを反映していない可能性があります。

これはシステムパフォーマンスに影響しますか？

No.これはUI上の純粋な視覚的レポートの不一致であり、Cloud Exchangeの運用パフォーマンスや機能には影響しません。

正確なディスク使用量を確認するにはどうすればよいですか？

ターミナルで以下のコマンドを実行することで、いつでもデプロイメントディレクトリの実際の使用可能ストレージを確認できます。

df -h <path-to-your-mount-point> 

Note: Replace <path-to-your-mount-point> with the actual directory path where Cloud Exchange is installed

Q: 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: 初期設定後、Cloud Exchange のプロキシ設定を構成または更新するにはどうすればよいですか？

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: Cloud Exchangeの特定の以前の (n-1) コンテナ化バージョンをデプロイするにはどうすればよいですか？ 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: コンテナ化されたCloud Exchange古いバージョンから最新のバージョンにアップグレードするにはどうすればよいですか？ 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: Cloud Exchangeウェブインターフェース用の自己署名SSL証明書を再生成するにはどうすればよいですか？

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: Netskope REST API v2トークンの有効期限が切れた場合はどうすればよいですか？ Cloud Exchangeによるトークンの有効期限が切れた場合はどうすればよいですか？

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: Cloud Exchange VMの展開でサポートされている仮想化プラットフォームはどれですか？

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: Cloud Exchange VMとしてインストールしているときに OVAファイルで、「カーネルがスワップ制限機能をサポートしていないか、cgroupがマウントされていません」という警告が多数表示されました。 インストールは正常に完了したように見えますが、これは何か問題になるのでしょうか？

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

Q: プラグインが見つからない場合はどうすればよいですか？

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

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

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

Q: 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: NetskopeテナントでRBAC V3が有効になっている場合、Cloud Exchange用のV2トークンを作成するにはどうすればよいですか？

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

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

Q: Cloud Exchange Log Shipperは、オンプレミスのプロキシ経由でNetskope Cloud Proxyからログを取得できますか？

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

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

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

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

git credential reject

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

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

質問：アップグレードの前にCEのバックアップを取得する必要がありますか？CE UI を介してバックアップを実行できますか？

A: はい、アップグレードを実行する前はrecommended to take a backupです。このバックアップは、アップグレード中またはその後に問題が発生した場合の環境の復元に役立ちます。

ただし、Cloud ExchangeのバックアップはCE UIを通じてcannotことに注意してください。バックアップ手順については、ドキュメントを参照してください：/en/backup-cloud-exchange。

Q: Cloud Exchangeの高可用性（HA）は、VMとコンテナ化されたデプロイメントの両方でサポートされていますか？

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

Q: Cloud Exchange HA クラスターは、異なるデータセンター（マルチデータセンター）にあるノードで動作できますか？

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

Q: 複数のデータセンターにまたがるHAクラスタ（マルチDC）をデプロイするための推奨されるアプローチは何ですか？

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

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

Q: マルチDC HA展開に参加するセカンダリサイトのCloud Exchangeノードに必要な主要なネットワーク要件は何ですか？ 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: Cloud Exchange HAノードを異なるデータセンター（マルチDC）に展開した場合、パフォーマンスの問題が発生する可能性はありますか？

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

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

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

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

Q: Cloud Exchangeのマルチ DC HA 構成では、フェイルオーバーとトラフィック処理は通常どのように機能しますか？

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

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

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

Q: マルチデータセンターHAテストでは、通常、どのCloud Exchangeモジュール（CLS、CTE、CTO、CRE）が検証されますか？

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: HA構成のCloud Exchangeノードを停止および再起動する手順を教えてください。

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

Stopping Cloud Exchange:

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

Starting Cloud Exchange:

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

Q: Cloud Exchange 6.xにアップグレードした後も、高可用性(HA)にはNFSサーバーが必要ですか?

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

質問：HA構成でプライマリノードを停止し、HAクラスターに再度追加するにはどうすればよいですか？

A: 次の手順に従って、プライマリノードを安全に停止し、HAクラスターに再参加させます：

1. ノードはエラーなくクラスターに再参加します。ダウンタイム中は、セカンダリノードのいずれかが自動的にプライマリノードの役割を引き継ぎます。
2. セカンダリCE UIのいずれかにログインして、プライマリノードを停止します。
3. プライマリノード上で必要な操作を実行してください。
4. 古いプライマリノードでCEを起動する前に、以下のコマンドを実行して管理サーバーサービスが実行されていることを確認してください。 sudo systemctl status cloud-exchange
5. 開始 主ノードを 活動中のセカンダリノードの CE UI から 使う 一般的な設定のノード構成の「再起動」オプションを使います。

Q: Log ShipperはNetskopeテナントから過去のアラートをどのくらい遡って取得できますか？

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

Q: 過去のログを履歴的に取得するにはどうすればよいですか？ Log Shipper モジュールで？

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

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

Important Considerations:

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

Q: Log Shipperで進行中の過去のログの引き出しを必要に応じて停止するにはどうすればよいですか？

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

Q: Log ShipperがNetskopeテナントから取得できるアラートとイベントの種類にはどのようなものがありますか？

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

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

Q: Cloud Exchangeのどの指標を使えば、Netskopeから取得され外部ログサーバーに送信されるログの適時性を検証できますか？

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

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

Q: ストリーミングクライアントのDockerとは何ですか？CLSとはどう違うのですか？

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

主な違い：

Q: 既にTXログを受信できるSIEMを導入している場合でも、追加のパブリッククラウドストレージを購入する必要はありますか？

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

Q: ネットワークの問題（ファイアウォールの制限など）により、送信側のCLSプラグイン（Syslogプラグインなど）がログの転送に失敗した場合、Cloud Exchangeは未送信のログをどのように処理しますか？

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: 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: Cloud Log Shipper AWS S3 Alerts Eventsプラグインで、IAMユーザーにAWS S3バケットのアクセス許可を割り当てるための回避策や代替手段はありますか？ 

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

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

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

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

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

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

Q: Cloud Exchange コンソールの GUI に「トークンの有効期限切れまたはイベント ストリーミングが無効になっています」というバナーが表示されるのはなぜですか？

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

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

Q: Netskope Cloud ExchangeのGoogle Chronicle Plugin統合でサービスアカウントキーはどのように生成すべきですか?

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

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

Q: Ticket Orchestrator モジュールはNetskope Events (アラートに加えて) を使用して ITSM システムでチケットを作成できますか?

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

Q: Ticket Orchestrator が、同じ Netskope の定期アラートに対して重複したチケットを作成しないようにするにはどうすればよいですか？

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

Q: Ticket OrchestratorモジュールのCloud Exchangeによってローカルに保存されるアラートのデフォルトの保持期間はどれくらいですか？また、この期間は変更できますか？

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

Q: Jiraのステータスフィールドがプラグインのフィールドマッピングに従って更新されないのはなぜですか？

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

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

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

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

Q: Cloud Exchange UI のどこで、脅威交換モジュールが受信した脅威指標 (IoC) を確認できますか？

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

Q: Cloud Exchangeに掲載されている特定の脅威IoCの元の発生源を特定するにはどうすればよいですか？

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

Q: Threat Exchangeモジュール内でIoCのタグを作成および管理するにはどうすればよいですか？

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

Q: 脅威交換モジュールを正しく動作させるには、Netskope APIトークンのどのバージョンが必要ですか？

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

Q: Threat Exchangeで重複したIoCの処理を防止するための重複排除ルールまたは例外ルールを作成するにはどうすればよいですか？

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

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

Q: Threat Exchangeは、NetskopeテナントUIの「インシデント」>「マルウェア」から直接IoCを取得しますか？

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

Q: Threat Exchangeプラグインの設定における「エイジング基準」設定の目的は何ですか？

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

Q: Trend Micro Vision Oneプラグインは、なぜ完全なURLをドメインに変換するのですか？

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: Cloud ExchangeでCTE Abnormalプラグインを設定するための手順を教えてください。

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

Q: CrowdStrikeから Detect API の廃止予定に関する通知を受け取りました。 Cloud Exchange (CTE) に変更が必要ですか？また、その変更による影響は何ですか？

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: なぜHTTP/HTTPSのURLが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: Cloud Exchangeの Risk Exchange モジュールは、 Netskopeプラットフォームのどの部分からユーザーとホストのリスク スコアを取得しますか?

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

Q: ユーザーのリスクスコアを取得するには、 Netskope特定のライセンスが必要ですか？ リスク交換モジュール？

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