Netskope Cloud Exchange（CE）ナレッジベース記事ページへようこそ！このページでは、Cloud Exchangeの理解、インストール、構成、管理、および使用に関するよくある質問に回答します。当社の目標は、必要な情報を迅速に見つけられるよう支援することです。ここに記載されていない質問については、FAQまたはトラブルシューティングガイドを参照してください。

最新かつ詳細な情報を得るために、必ず最新のNetskope Cloud Exchangeリリースノートや製品ドキュメントをご参照ください。

アーキテクチャ設計、設置、ホスティング

Cloud Exchange 6.0.0 より前のバージョンにおける高可用性 (HA) 設定

Cloud Exchange高可用性

このドキュメントでは、Cloud Exchangeにおける高可用性（HA）の仕組みについて説明します。アーキテクチャ図の機能一覧、前提条件、およびサイジングガイドラインを確認した後、Cloud Exchange に HA をデプロイします。導入に関するセクションの後には、移行、アップグレード、セキュリティ強化、既知の制限事項、トラブルシューティングについて説明するセクションがあります。

HAアーキテクチャ

Features

Cloud Exchangeノードのアクティブ/アクティブ構成により、システムの可用性と耐障害性が向上します。
- Netskope CE Coreコンテナは、複数のタスクを同時に処理できる専用ワーカーとして機能するように設計されています。中規模のシステムでは10個のタスクを処理でき、大規模なシステムでは20個のタスクを処理できます。これらのタスクには、ポーリング、データ取り込み、心拍数モニタリングなどの操作が含まれる場合があります。3つのノードで構成される高可用性（HA）クラスタでは、処理能力が実質的に3倍になり、システムの実行能力が向上します。
- タスクの割り当てはRabbitMQを介して調整され、RabbitMQはコアコンテナのワーカーの現在の負荷と、ワーカーがアクティブに処理しているタスクの数に基づいて、タスクをワーカーに分配します。コアコンテナの再起動やノード障害が発生した場合、データの損失を防ぐため、変換および取り込みタスクは再キューイングされます。一方、データ取得タスクは、通常、障害発生から5分以内に、新しいノードのワークロードに応じて、別のノードに再割り当てされます。
- 要約すると、コアコンテナは、継続的な運用とデータの整合性を確保するために、タスクレベルとノードレベルの両方で高可用性（HA）を備えるように設計されています。
クラスター環境では、MongoDBとRabbitMQのインスタンスが複数存在することになります。いずれかのノードがダウンしても、他のノードがリクエストの処理を継続するため、ダウンタイムは発生しません。
Netskope CEの複数の同一ノードは同時に稼働します。そしてそれら全てが、プラグインのタスクを同時に積極的に処理している。

Cloud Exchange HAに関するビデオをご覧になるには、再生ボタンをクリックしてください。

クラスターステータスのUIダッシュボード

Cloud Exchangeのホームページで、現在のクラスタの状態を確認してください。

コアサービスはUIサービスに依存していることに注意してください。セキュリティ上の理由から、コアサービスは一般公開していません。コアサービスはUIサービスを通じてアクセス可能となり、内部ネットワーク経由でアクセスされます。UIサービスがダウンしている場合、コアはダッシュボードに不明なステータスを表示します。

Linux上でのHA展開の前提条件

HA構成に進む前に、スタンドアロン構成の前提条件を満たしている必要があります。
必要なマシン上でNFS（ネットワークファイルシステム）ボリュームを設定し、マウントします。NFSサーバー上のファイルの閲覧、書き込み、およびアクセス権限の変更を行う権限があることを確認してください。このNFSボリュームは、以下のような重要な資産の共有ストレージリポジトリとして機能します。
- Mongo認証キー
- SSL証明書
- 環境変数
- プラグインとカスタムプラグイン
- Repositories
Netskope CEを導入するマシンは少なくとも3台の設置を強く推奨します。クラスターに必要な最小稼働ノード数については、「クラスターノード数要件」を参照してください。
（参照： https ://www.mongodb.com/docs/manual/core/replica-set-members/）
Netskope CEのすべてのインスタンスが、CPU、RAM、ディスク容量などの物理リソースを同一に割り当てていることを確認してください。この均一性は、アクティブ/アクティブ構成による高可用性と、クラスタ全体における一貫したパフォーマンスを実現するために不可欠です。
デプロイメントスクリプトを実行する前に、SELinuxを無効にする必要があります。これは、ローカルマシンからNFSボリュームにアクセスするために必要です。
Python3の依存関係をインストールしてください。
- 5.1.0の場合、Pythonモジュールをインストールするには、以下のコマンドを実行してください。 pipパッケージマネージャーを使用します。
```
$ sudo pip3 install "pyyaml>=6.0.0" 
$ sudo pip3 install "python-dotenv>=0.20.0,<=1.0.0" 
$ sudo pip3 install "pymongo>=4.1.1,<=4.3.3"
```
- 5.1.1の場合、Pythonモジュールをインストールするには、以下のコマンドを実行してください。 pipパッケージマネージャーを使用します。
```
$ sudo pip3 install "pyyaml>=6.0.0"
$ sudo pip3 install "python-dotenv>=0.20.0,<=1.0.0"
$ sudo pip3 install "pymongo>=4.6.3,<=4.7.3"
```
すべてのマシンが、マシン自身を含め、下記のポートに接続できることを確認してください。現在のマシンを含める理由は、API呼び出しがサーバーのIPアドレスに対して行われ、API呼び出しはDockerコンテナ内から行われるためです。したがって、ポートの接続性 IPアドレスは許可されている必要があります。ファイアウォール下記のポートとすべてのマシンに対して、マシン間のシームレスな接続を確保するために設定する必要があります。
- 4369 (RabbitMQ ノードと CLI ツールによって使用されるピア検出サービス)
- 5672 (TLS を使用しない AMQP 0-9-1 および AMQP 1.0 クライアントによって使用される)
- 15672 (TLSを使用しないHTTP APIクライアント、管理UI、およびrabbitmqadmin)
- 25672 (ノード間および CLI ツール通信に使用)
- 35672 (CLI ツール通信に使用)
- 27017（mongodおよびmongosインスタンスのデフォルトポート）
- 選択されたUIポート（デフォルトはHTTPSの場合は443、HTTPの場合は80）（UIおよびノード間ヘルスチェックへのアクセス用）
注記

CEをVMとして実行している場合、firewalldは既にインストールされており、デフォルトで無効になっています。 以下のコマンドを実行してファイアウォールを有効にし、dockerサービスを再起動する必要があります。
```
$ sudo systemctl enable firewalld
$ sudo systemctl start firewalld
$ sudo systemctl restart docker
```
443 ポートを使うファイアウォールを開くサンプルコマンド:
```
$ sudo firewall-cmd --permanent --add-port=443/tcp
```
これらのポートは MongoDBおよびRabbitMQサービスのクラスタリングに使用されます。また、UIポートはすべてのマシンからヘルスチェックを実行するために必要です。
スタンドアロン構成から高可用性 (HA) 構成に移行する場合は、メンテナンスパスワードを知っておく必要があります。これは、Mongo データを新しい構成に移行するために必要です。メンテナンスパスワードは、既存のスタンドアロン構成ファイルに記載されています。
CEをVMとして実行している場合は、この点を確認し、ホスト名を適切に変更してください。
すべてのマシンに異なるホスト名を設定してください。特定のマシンのホスト名を変更するには、以下のコマンドを使用します。
```
$ sudo hostnamectl set-hostname <new_hostname>
```

サイズガイド

NFSサーバーには、最低5GB 、最大80GBの空きディスク容量が必要です。
その他の要件は、スタンドアロン展開の場合と同じです。

Cloud ExchangeにHAをデプロイする

Netskope CEが展開されるすべてのマシンに netskopeoss/ta_cloud_exchange Githubリポジトリをクローンしてください:
```
$ mkdir netskope
$ cd netskope
$ git clone https://github.com/netskopeoss/ta_cloud_exchange
$ cd ta_cloud_exchange
```
既にリポジトリをクローンしている場合は、ローカルでの変更をすべて削除し、最新バージョンをプルしてください。
```
$ git reset --hard
$ git pull
```
注記

CEをVMとして実行している場合、リポジトリは/opt/cloudexchange/cloudexchangeパスで利用できます。現在のディレクトリをcloudexchangeディレクトリに変更してください。
```
$ cd /opt/cloudexchange/cloudexchange
```
プライマリノードでセットアップスクリプトを実行し、セットアップに必要な情報を入力してください。
```
$ sudo python3 ./setup
```
- 高可用性（HA）パラメータの入力を求められたら「はい」と答えてください。その後、HA関連の追加パラメータが求められます。
- スクリプトは、共有ボリュームのパス、IPリスト、現在のノードのIPアドレスなど、HA関連のパラメータをさらに要求します。
  NOTE:スタンドアロンからHAへの移行の場合、IPリストの最初にプライマリノードのIPアドレスが記載され、その後にセカンダリノードが記載されていることを確認してください。
- スタンドアロン構成から高可用性（HA）構成に移行する場合は、以前の構成と同じメンテナンスパスワードを維持することが必須です。パスワードを紛失した場合、データは保持されません。
残りのノードで、-location オプションを指定してセットアップスクリプトを実行してください。–location オプションに、NFS マウントされたディレクトリのパスを指定してください。そして、現在使用しているマシンのIPアドレスを入力してください。
```
$ sudo python3 ./setup --location /path/to/mounted/directory
```
スタンドアロンからHAに移行する場合、カスタムプラグインやカスタムリポジトリがある場合は、プラグインを共有ディレクトリにコピーしてください。前の手順が完了すると、reposディレクトリとcustom_pluginsディレクトリが作成されます。
```
$ cp <standalone>/data/custom_plugins/ <shared-storage>/custom_plugins
$ cp <standalone>/data/repos/ <shared-storage>/repos
```
まずプライマリノードでCloud Exchangeを起動してください。スクリプトは移行が完了するまで待機します。次に、残りのノードでCloud Exchangeを起動してクラスターに参加させます。
```
$ sudo ./start
```
UIは、クラスタに参加しているすべてのIPアドレス（ https://<ip> ）からアクセスできる必要があります。負荷をすべてのマシンに分散させるために、外部ロードバランサーをIPアドレスのリストに追加できます。CE UI に TLSv1.3 の設定がある場合は、 TLSv1.3 をサポートしているロードバランサーを HAProxy (またはその他のロードバランサー) からリダイレクトする必要があります。ロードバランサーがTLSv1.3をサポートしていることを確認してください。

注記

SSL証明書を追加したい場合は、 <path-to-shared-volume>/config/ ssl_certsディレクトリに追加してください。証明書ファイルの名前はcte_cert.crtとcte_cert_key.keyである必要があります。

スタンドアロンからHAへの移行

移行オプションを確認するには、こちらをご覧ください。

クラスターに新しいノードを追加する

プライマリノードでセットアップスクリプトを実行し、IPリストを更新してください。
```
$ sudo python3 ./setup
```
残りのマシンでセットアップスクリプトを実行して、接続情報を追加してください。
```
$ sudo python3 ./setup --location /path/to/mounted/directory
```
まずプライマリノードで開始スクリプトを実行し、次に残りのマシンに対しても開始スクリプトを実行します。最後に、新しいノードで開始スクリプトを実行します。
```
$ sudo ./start
```

注記

既存ノードの再起動が必要です。そうしないと、UIダッシュボードとヘルスチェックの間で不整合が発生します。

クラスターからノードを削除する

クラスターが正常であることを確認してください。すべてのサービスが起動して稼働している必要があります。そうしないと、クラスターからノードを削除する際にエラーが発生する可能性があります。
ノード上で./stopスクリプトを実行すると、クラスターからMongoDBノードとRabbitMQノードが削除されます。MongoDBクラスタの新しいプライマリノードを特定し、共有構成ファイルを更新します。完了したら、実行中のサービスを停止してください。

注記

環境変数で利用可能なHAプロキシリストに従って、ダッシュボードにはステータスにすべてのIPアドレスが表示されます。

UIダッシュボードからもノードを完全に削除したい場合は、残りのノードでセットアップスクリプトを実行し、HAパラメータからIPを削除してから、再度開始スクリプトを実行する必要があります。これにより、現在のノード上のすべてのサービスが再起動され、IPアドレスリストが更新されます。

HAのアップグレード

HAを下位互換性のあるバージョンにアップグレードする（ローリングアップグレード）

Docker Composeリポジトリの最新バージョンを取得します。
包括的なセットアップセクションに記載されている手順に従って、セットアップスクリプトを実行してください。
開始スクリプトを起動します。
クラスター内の残りのすべてのノードに対して、上記の手順を繰り返してください。

HAを後方互換性のないバージョンにアップグレードする（完全アップグレード）

Docker Composeリポジトリの最新バージョンを取得します。
プライマリノードを除くすべてのノードを停止します。
包括的なセットアップセクションに記載されている手順に従って、セットアップスクリプトを実行してください。
プライマリノードで始めるスクリプトを実行します。
残りのノードでもセットアップとスクリプト開始の手順を繰り返して、構成が均一になるようにします。

注記

このプロセス中、CE（カスタマーエクスペリエンス）が一時的に停止またはダウンする期間が発生する可能性があることを認識しておくことが重要です。アップグレード作業中は、短いメンテナンス時間を確保することをお勧めします。

硬化ガイドライン

様々なマシン上のDockerサービス間の必要な接続を確立し、ノードをクラスタに統合しやすくするために、Dockerサービスから以下のポートを公開しました。Netskope CE HAの導入を予定しているすべてのマシンから、これらのポートにアクセスできる状態を維持することが不可欠です。セキュリティ対策を強化するため、これらのポートへのアクセスを他のIPアドレスから制限することも推奨されます。
以下のポートは MongoDBおよびRabbitMQサービスのクラスタリングに使用されます。また、UIポートはすべてのマシンからヘルスチェックを実行するために必要です。
- 4369 (RabbitMQ ノードと CLI ツールによって使用されるピア検出サービス)
- 5672 (TLS を使用しない AMQP 0-9-1 および AMQP 1.0 クライアントによって使用される)
- 15672 (TLSを使用しないHTTP APIクライアント、管理UI、およびrabbitmqadmin)
- 25672 (ノード間および CLI ツール通信に使用)
- 35672 (CLI ツール通信に使用)
- 27017（mongodおよびmongosインスタンスのデフォルトポート）
- 選択されたUIポート（デフォルトはHTTPSの場合は443、HTTPの場合は80）（UIおよびノード間ヘルスチェックへのアクセス用）
共有ストレージにNFSを使用しているため、Netskope CEインスタンスのみがアクセスできるようにNFSボリュームを設定することが重要です。この予防措置は、セキュリティ対策を強化するために極めて重要である。

クラスタノード数の要件

障害発生時の MongoDb レプリケーションおよび RabbitMQ ミラーリング要件の一部として、HA クラスターが引き続き動作するようにすることが不可欠です。 majority CEノードのうち、アクティブ/オンライン状態のもの。奇数個のCEノードを持つHAクラスタは、偶数個のCEノードを持つクラスタよりも、動作状態を維持できる可能性が高い。

HAクラスタ内のCEノードの総数	HAクラスタが正常に動作するために必要な、任意の時点でのアクティブ/オンラインCEノードの最小数
3	2
4	3
5	3
6	4
7	4
8	5
9	5

制限事項

NFSボリュームの可用性を確保する必要があります。
Netskope CEの冗長インスタンスを複数実行するには、追加のハードウェアとコンピューティングリソースが必要です。
場合によっては、HA構成では、データの複製やアクティブなインスタンス間の調整が必要となるため、レイテンシが増加する可能性があります。
IPアドレスやノード関連の設定に変更があった場合は、変更がクラスタ全体に適切に反映され同期されるように、システム内のすべてのマシンでセットアップスクリプトと開始スクリプトの両方を実行する必要があります。必要なマシンはすべて一度に追加し、マシンに固定IPアドレスを割り当てることをお勧めします。
ノードの大部分を常に稼働状態に維持することが極めて重要です。そうしないと、クラスタの障害につながります。つまり3ノードクラスタでは、常に少なくとも2つのノードが稼働している必要があります。同様に、5ノードクラスタでは、少なくとも3つのノードが稼働している必要があります。より大きなクラスターにおいても、同様の傾向が続く。これは、このような状況下ではMongoDBがプライマリー選挙プロセスを開始しないためです。さらに、ネットワーク分断によって引き起こされる不整合に伴う課題を軽減するために、RabbitMQに「pause_minority」オプションを実装しました。ノードが復旧してクラスターに再接続すれば、この問題は解消されるはずです。クラスターに必要な最小稼働ノード数については、「クラスターノード数要件」を参照してください。
参照: https://www.mongodb.com/docs/v5.0/core/replica-set-elections/#network-partition| https://www.rabbitmq.com/partitions.html#options
まれなケースとして、クラスタでノード障害が連続して発生すると、キューが頻繁にリーダーとミラーの状態になるため、RabbitMQでデータ損失が発生する可能性があります。このような場合、他のノードはまだ同期されていないデータを失う可能性があります。
参照： https ://www.rabbitmq.com/ha.html#behaviour
SSOでは、リダイレクトURLとして1つのノードのIPアドレスのみを追加できます。オプションとして、ロードバランサーをすべてのIPアドレスに対して構成し、ロードバランサーのIPアドレスを使用してSSOを構成することもできます。そして、リクエストは利用可能なノードにリダイレクトされます。
現在、HA構成からスタンドアロン構成への移行はサポートされていません。

Cloud Exchange の HA のトラブルシューティング

HAを実行する前に、SE Linuxを無効にする必要があります。これは、マシンからNFSサーバーにアクセスするために必要です。SE Linuxではそれは許可されません。
HA環境の./stopスクリプトは、クラスターからMongoDBノードとRabbitMQノードを削除します。そして、その特定のマシン上のサービスを停止してください。./stop を実行する際は、サービスが稼働している状態であることが非常に重要です。スクリプト。そうしないと、スクリプトがノードを削除するためのMongoクライアントを作成できないため、スクリプトが失敗する可能性があります。
NFSサーバーに対して、読み取りと書き込みの両方の権限が付与されていることを確認してください。新しいファイルを作成できるかどうか、またファイルのアクセス権限を変更できるかどうかを確認してください。
移行中にノード名の変更で問題が発生した場合は、前提条件を確認し、手順1で作成したバックアップを復元してください。次に、2番目の手順から移行を再試行してください。
```
$ sudo rm -rf <path-to-ta_cloud_exchange>/data/mongo-data/data/* 
$ sudo cp -R <temp-mongo-path>/* 
<path-to-ta_cloud_exchange>/data/mongo-data/data/
```
docker/podmanサービスが実行されていることを確認してください。そうでない場合は、このコマンドを使用してサービスを実行します
```
$ sudo systemctl restart docker
```
UI上でいずれかのコンテナが長時間ダウン状態と表示された場合は、コンテナの状態を確認し、必要に応じて再起動を実行してください。該当する場合はどこでも podman を使用します。
- コンテナの状態を確認してください。すべてのサービスが稼働している場合は、ステップ2に進んでください。それ以外の場合は、開始スクリプトを再度実行してコンテナを回復します。
```
$ docker ps
```
- MongoDBクラスタの状態を確認してください。以下のコマンドを実行して、MongoDBコンテナ内でコマンドを実行してください。
```
$ docker compose exec -- mongodb-primary bash 
$ mongosh -u root -p $MONGO_INITDB_ROOT_PASSWORD 
$ rs.status()
```
  ステータスが長期間にわたってPRIMARYまたはSECONDARY以外の状態を示す場合は、このコマンドを実行して特定のマシン上のコンテナを再起動してください。
```
$ docker compose restart mongodb-primary
```
- RabbitMQクラスタの状態を確認してください。RabbitMQコンテナ内でコマンドを実行するには、以下のコマンドを実行してください。
```
$ docker compose exec -- rabbitmq-stats bash 
$ rabbitmqctl cluster_status
```
  出力結果の「実行中のノード」セクションを確認し、接続されているノードと実行中のノードを特定してください。必要に応じて、RabbitMQコンテナを再起動してください。
```
$ docker compose restart rabbitmq-stats
```
ワーカーがRabbitMQに接続されていないなど、いずれかのノードでワーカー喪失エラーが発生した場合は、該当するコアコンテナを再起動してワーカーを復旧してください。この問題は、RabbitMQクラスタが長時間停止した場合に発生する可能性が高いです。
```
$ docker compose restart core
```

Proxmox上にCloud Exchangeをデプロイする

Proxmox Serverの前提条件

VMsphearクライアント側チェックリスト

CPU Settingsへ移動（ Edit Settings > CPU > Hardware virtualization内）。
ゲストOSへのハードウェア支援仮想化の公開オプションを有効にします。

ハードウェア要件

CPU推奨コア数：最低8コア
RAM最低16GB
Disk最低250GB（SSD推奨）
CPU FeatureAVXをサポートする必要があります
VirtualizationIntel VT-x / AMD-VがBIOSで有効になっています
Command
```
lscpu | grep virtualization
```

Proxmox設定チェックリスト

Proxmox VE がインストールされ、ウェブ UI からアクセス可能。
ストレージの設定（ローカルLVMやカスタムストレージなど）
Command
```
pvesm status
```
ネットワークブリッジが設定されました（例：vmbr0）
Command: brctl show
十分な空きリソースがあります：CPU / RAM / ディスク容量

Proxmoxの設定

こちらの指示に従って最新のCE OVA
ローカルマシンにダウンロードしてください。
ローカルマシンから、Cloud ExchangeをデプロイするProxmoxサーバーに.ovaファイルを転送してください。
OVAファイルを抽出します。
Command
```
tar -xvf cloud-exchange-6.0.1-20260127.ova
```
このコマンドを実行すると、 .vmdkファイルを完全に抽出するのに 20～30 分かかります。
Output
Cloud Exchange VMを作成します。.ovfファイルが存在することを確認したら、このコマンドを実行してください。30～35分かかる場合があります。
```
qm importovf 102 cloud-exchange.ovf local-lvm --format raw
```
Explanation

パラメータ Meaning
102 VM ID
cloud-exchange.ovf OVFマニフェストファイル
local-lvm Proxmoxストレージ
–format raw Disk format
Proxmox UIにログインしてください。
102 VMが正常に作成されたことが確認できるはずです。
ネットワークデバイスを追加してください。新しい VM 102 Select。必要に応じてSelect Hardware > Add > Network Deviceして設定してください(モデル「Intel E1000」は動作します)。
プロセッサの種類を「ホスト」に設定してください。Hardware Select 、 Processorsダブルクリックして、タイプをホストに変更します（リストの一番下にあるかもしれません）。

仮想マシンをシャットダウンします。
◇ Proxmox で VM を開始します。

VMの起動後に、以下のエラーが表示される場合があります。
```
TASK ERROR: KVM virtualization configured, but not available. Either disable in VM configuration or enable in BIOS.
```
このエラーを解決するには、Vsphereサーバーの以下のチェックリストを確認する必要があります:
Enable Virtualization in vSphere
VM > Edit Settings > CPUに行け。
このオプションを有効にする: ハードウェア支援仮想化をゲストOSに公開する
Add Advanced Parameter (上記の方法がうまくいかない場合は試す)
Go to VM > Edit Settings > VM Options > Advanced > Edit Configuration。
新しいパラメータを追加する:
```
vhv.enable = TRUE
```
Verify CPU Virtualization on the ESXi Host
物理ESXiホストのCPUは、VT-x（Intel）またはAMD-Vをサポートしている必要があります。
Proxmox VM 102 を開始すると、出力に次の内容が表示されます。
Console .
をクリックしてください
これにより、ログイン名とパスワードを入力するためのシェルが開きます。
CEログイン： cteadmin
パスワード： Cl0ud3xc4ang3!
Cloud Exchange ディレクトリに移動してください。
```
cd /opt/cloudexchange/cloudexchange/
```
cloudexchange設定ファイルをコピーして編集します。
```
sudo cp cloudexchange.config.example cloudexchange.config
sudo vi cloudexchange.config
```
メンテナンスパスワードとJWTシークレットを追加してください。
セットアップスクリプトを実行してください。
```
sudo python3 ./setup
```
Cloud Exchangeを起動します。
```
sudo ./start
```
5～10分待ってから、 Cloud Exchangeにアクセスしてください。 VMのIPアドレス（https:// <ip> ）

パラメータ	Meaning
102	VM ID
cloud-exchange.ovf	OVFマニフェストファイル
local-lvm	Proxmoxストレージ
–format raw	Disk format

デフォルトのユーザーログイン

デフォルトでは、以下のクレデンシャルで管理機能を持つ単一のユーザーが作成されます:
ユーザー名: admin
パスワード: admin
アプリケーションに対して管理者レベルのアクセス権が必要です。書き込み権限を持ち、新しいユーザーも作成できます。
初回ログイン時にこれらのクレデンシャルを変更する必要があります。その後、使うあなたの新しいクレデンシャルにログインしてください。

Azure Blob Storage を使用した Linux ノード上の Cloud Exchange の高可用性 (HA) セットアップガイド

このセクションでは、Linuxノード上のCloud Exchangeの高可用性（HA）環境を構成する方法について説明します。共有ストレージのNFS（ネットワークファイルシステム）としてAzure Blob Storageを使用します。

Cloud Exchangeシステムの要件は以下に記載されています。

前提条件

HAノードのシステム要件

16個のCPUコア（演算負荷の高いF16sシリーズ）
32GB RAM
CEをインストールする場所に120GBの空きディスク容量が必要です。例： /home/root/
コンテナストレージ用に、 /var/libに20GBの空き容量があります。

Azure Blob Storage を使用した NFS のセットアップ

次のページにアクセスしてください: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-quick-create-use-linux#create-an-nfs-azure-file-share

ネットワーク構成

Linux マシンは HA ノードとして扱われ、すべてのノードとストレージアカウントは同じ仮想ネットワーク/サブネットおよび同じ Azure リージョン/ゾーンにある必要があります。NFS ファイル共有を構成したら、以下の手順を参照して NFS 共有をマウントしてください。

Cloud Exchangeの高可用性（HA）構成、前提条件の検証

必要なポートを確認してください。各ノードで以下のポートが開いていて使用可能であることを確認してください。

4369 RabbitMQ通信ポート
5672 AMQP通信ポート
15672 RABBITMQ 管理コンソール
25672 RabbitMQ内部ポート
35672 CLI通信のために使う
27017 MongoDB Port
443 サービス健全性チェック
ネットワーク構成：仮想ネットワークは、すべてのノードで共通である必要があります。
RAM、ディスク容量、CPUを検証してください。
```
sudo df -h
sudo free -h
sudo nproc
```
Gitパッケージ、curlパッケージ、zipパッケージ：
```
sudo yum install -y git curl zip
```
Install nfs-utils.
```
sudo yum install -y nfs-utils
```

Python3とpip。

sudo yum install -y python3 python3-pip python3-devel

Podman と podman-compose (参照: https://podman.io/docs/installation#rhel8)）

sudo yum module enable -y container-tools:rhel8
sudo yum module install -y container-tools:rhel8
sudo yum install -y podman-plugins
sudo pip3 install podman-compose
sudo chmod +x /usr/local/bin/podman-compose
sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose

Podmanとpodman-composeのバージョンを確認してください。
```
podman-compose —-version
podman –-version
```

必要なPythonパッケージ：

pip3 install "pyyaml>=6.0.0"
pip3 install "python-dotenv>=0.20.0,<=1.0.0"
pip3 install "pymongo>=4.1.1,<=4.3.3

Azure Blob Storage で NFS を構成する

次のページにアクセスしてください: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-quick-create-use-linux#create-an-nfs-azure-file-share

各ノードにNFSストレージをマウントする

NFSファイル共有の概要ページへ移動してください。
マウントパスに記載されているようにマウントディレクトリを作成します（NFSファイル共有概要ガイドからも取得できます）。このコマンド：
```
sudo mkdir -p <mount_path>
```
下記のように/etc/fstabファイルとマウントされた構成を編集します。
cestorageha.file.core.windows.net:/cestorageha/shared-storage-nfs /mount/cestorageha/shared-storage-nfs nfs default 0 0
- cestorageha.file.core.windows.net:/cestorageha/shared-storage-nfs Azure Blob Storage NFS File shareに存在するソースNFSディレクトリは、Home > それぞれのストレージアカウント>ファイル共有>新たに作成されたNFSファイル共有>概要から取得されます。
- /mount/cestorageha/shared-storage-nfs マウントパスと作成されるディレクトリになります。
- 残りの部分はNFSの設定です。
このコマンドを実行してください。
```
sudo mount -a
```

インストールパッケージをダウンロードしてください

各ノードで、 Cloud Exchangeインストールパッケージをダウンロードします。このコマンドを実行してください。

git clone https://github.com/netskopeoss/ta_cloud_exchange

プライマリノードでセットアップスクリプトを実行します。

Cloud Exchange ディレクトリに移動してください。プライマリノードで、以下のコマンドを使用してセットアップスクリプトを実行します。

sudo ./setup

セカンダリノードでセットアップスクリプトを実行します。

各セカンダリノードで、Cloud Exchangeディレクトリに移動します。セットアップスクリプトを実行します次のコマンドを実行し、 <mounting_dir> NFS マウントディレクトリへのパスに置き換えてください。

sudo ./setup --location <mounting_dir>

Enable the CSV index

各ノードで、Podman Compose HA構成ファイルを編集してCSVインデックス作成を有効にします。
```
$ vi podman-compose-ha.yml
```
コアセクションを見つけて、ネットワークイベントストリーミングを有効にするために、次の環境変数を追加してください。
```
ITERATOR_EVENT_NETWORK=stream_network_events_rollsroyce
```

RabbitMQとMongoDBのタグを更新します

ラビットMQ:
```
index.docker.io/
```
各ノードについて、 podman-compose-ha.ymlファイルを開きます。
```
$ vi podman-compose-ha.yml
```
RabbitMQおよびMongoDBサービスイメージタグを以下のように更新してください。
MongoDB:
```
index.docker.io/
```

コアタグとUIタグを更新します

NFSストレージに移動します。
.envファイルを編集します:
```
$ vi config/.env
```

CORE_TAG変数とUI_TAG変数を以下のように更新してください。

CORE_TAG=crestsystems/cloudexchange:core-5.0.1-csv-hotfix
UI_TAG=crestsystems/cloudexchange:ui-5.0.1-csv-hotfix

Backup `podman-compose-ha.yml`

各ノードで、 podman-compose-ha.ymlファイルのバックアップを作成します。

$ cp podman-compose-ha.yml podman-compose-ha.yml.backup

プライマリノードでCloud Exchange開始する

プライマリノードで開始スクリプトを実行します。
```
$ sudo ./start
```
次のステップに進む前に、移行完了メッセージが表示されるまでお待ちください。

セカンダリノードでのCloud Exchange開始

プライマリノードで移行完了メッセージを受信したら、残りのノードで開始スクリプトを実行してください。

$ sudo ./start

Azure Sentinelプラグインをアップロードして構成する

CEで Settings > Plugin Repositoryに移動し、プラグインのアップロード（⬆）ボタンをクリックします。
サポートケースを通じて共有されたZipファイルSelect 、アップロードボタンをクリックしてください。
プラグインのアップロードが正常に完了したら、[設定] > [プラグイン] に移動して、アップロードしたプラグインをバージョン 3.0.2 に設定してください。

RHEL マシンの再起動時にCloud Exchange自動開始する

ユーザーは、マシンの再起動時にCloud Exchange Podman コンテナを自動的に起動するために、以下の手順に従うことができます。

systemdサービスファイルを作成する

nano や vim などのテキストエディタを使用して、 Cloud Exchange用の新しい systemd サービスファイルを作成します。

$ sudo nano /etc/systemd/system/netskope-cloud-exchange.service

2. Add the Service Configuration

以下の設定をファイルに貼り付けてください。

Remember to replace <ta-cloud-exchange-path> with the absolute path to your cloud_exchange directory.

[Unit]
 

 
Description=Cloud Exchange Podman Containers
 

 
After=network.target
 

 
[Service]
 

 
Type=oneshot
 

 
RemainAfterExit=yes
 

 
WorkingDirectory=<ta-cloud-exchange-path>
 

 
ExecStart=<ta-cloud-exchange-path>/start
 

 
ExecStop=<ta-cloud-exchange-path>/stop
 

 
TimeoutStartSec=0
 

 
[Install]
 

 
WantedBy=multi-user.target

ファイルを保存してエディタを終了します。
nano を使う場合は、Ctrl+X を押してから、Y を押して Enter を押します。
VIM を使用している場合は、ESC キーを押してから :wq!と入力してください。

3. Save and Reload systemd

systemdデーモンを再読み込みして、新しいサービスファイルを認識させてください。

$ sudo systemctl daemon-reload

4. Enable the Service

起動するたびにサービスが自動的に開始されるようにします。

$ sudo systemctl enable netskope-cloud-exchange.service

シンボリックリンクが作成されたことを示す確認メッセージが表示されるはずです。

◇マシンが再起動すると、 Cloud Exchangeの開始スクリプトが実行されます。

Cloud Exchange導入タイプを特定する方法

現在のCloud Exchange導入タイプを特定する方法は複数あります。

Using the Cloud Exchange UI
- Cloud Exchange のホームページで、 System Status > System Specificationsに移動し、[デプロイメントタイプ] と [フレーバー] フィールドを確認してください。ダッシュボードを探索する – Netskopeナレッジポータル

Using the .env file
- CEの作業ディレクトリに移動し、次のコマンドを実行します。
  grep '^CE_AS_VM=' .env
- 出力がCE_AS_VM=Falseの場合、デプロイメントタイプはコンテナ化デプロイメントです。
- 出力がCE_AS_VM=Trueの場合、デプロイメントタイプはCloud Exchange as a VM デプロイメント (CEasVM)です。

SSHユーザー名の確認
- あなたがcteadminユーザーの場合、デプロイメントタイプはCloud Exchange as a VM Deployment (CEasVM)です。
- あなたがcteadmin以外のユーザー名の場合、デプロイメントタイプはコンテナ化デプロイメントです。
CE作業ディレクトリの確認
- CE 作業ディレクトリが/opt/cloudexchange/cloudexchangeの場合、デプロイメントタイプはCloud Exchange as a VM デプロイメント (CEasVM)です。
- 作業ディレクトリが/opt/cloudexchange/cloudexchangeと異なる場合、デプロイメントタイプはコンテナ化されたデプロイメントになります。

SELinuxの無効化、許容、強制モードのCloud Exchange展開ガイド

Cloud Exchange Installation with SELinux Disabled

Cloud ExchangeはSELinuxを有効にした状態で公式にテストされていません。インストール、アップグレード、実行時の問題を避けるために、NetskopeはCloud Exchangeを展開またはアップグレードする前にSELinuxを無効化することを推奨しています。

Verify SELinux Status

以下のコマンドを実行してください。

sestatus

出力に以下が表示される場合：

SELinux status: enabled

以下の手順に従ってください。

Cloud Exchangeサービスを停止する

Cloud Exchangeのインストールディレクトリに移動し、すべてのサービスを停止してください:

./stop

SELinuxを永久に無効化する

SELinux設定ファイルを編集します。

sudo vi /etc/selinux/config

Modify the following parameter:

SELINUX=disabled

ファイルを保存して終了します。

サーバーを再起動してください

設定変更を適用します。

sudo reboot

SELinuxが無効になっていることを確認してください。

サーバーが再起動したら、以下を実行してください。

sestatus

期待される出力:

SELinux status: disabled

始める Cloud Exchange

Cloud Exchangeインストールディレクトリにアクセスし、サービスを始める:

./start

サービスステータスの検証

すべてのCloud Exchangeコンテナとサービスが正常に動作しているか確認してください。

Cloud Exchange Installation with SELinux Permissive Mode

このセクションでは、RHEL 9.xのスタンドアロン環境でCEを実行する方法について説明します。SELinux Permissive Modeは、ポリシー違反を強制せずにログログを記録しながらSELinuxを有効にし続けることを可能にします。このモードは、組織のポリシーでSELinuxを無効にできない場合に使うことができます。

現在のSELinuxの状態を確認する

sestatus

Cloud Exchangeサービスを停止する

Cloud Exchangeのインストールディレクトリにアクセスしてください:

./stop

SELinuxをパーミッシブモードに設定する

SELinuxを一時的にパーミッシブモードに変更します。

sudo setenforce 0

確認する：

sestatus

期待される出力:

Current mode: permissive

Cloud Exchangeの設定を実行する

セットアップスクリプト使うを実行する:

./setup --ignore-failures

始める Cloud Exchange

./start

サービスステータスの検証

すべてのCloud Exchangeコンテナとサービスが正常に動作しているか確認してください。

Cloud Exchange Installation with SELinux Enforcing Mode

Cloud Exchange SELinuxをEnforcecing Modeで動作させるRHEL 9.xシステムに展開可能です。ただし、SELinuxコンテキストの追加変更が必要です。

重要

カスタムSELinuxポリシーは Cloud Exchange 機能に影響を与える可能性があります。サポートされているのはデフォルトのSELinuxポリシーのみです。

Verify SELinux Status

sestatus

SELinuxが有効になっていて、以下の環境で動作していることを確認してください。

Current mode: enforcing

Cloud Exchangeサービスを停止する

Cloud Exchangeのインストールディレクトリへ移動してください:

./stop

必要な SELinux コンテキストを構成する

セットアップを実行する前に、以下の SELinux コンテキストを適用してください。

chcon -t bin_t /Install_Path_of_CloudExchange/start_management_server

Note: コマンドを実際のCloud Exchangeインストールパスに置き換えてください。インストールパスが不明な場合は、次のコマンドを実行してください。

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

Cloud Exchangeの設定を実行してください

./setup --ignore-failures

マウントされたボリュームのアクセス許可を設定する

必要なSELinuxコンテキストをCloud Exchangeのデータディレクトリに適用します:

chcon -Rt svirt_sandbox_file_t ./data/

これにより、コンテナはマウントされたボリュームに対して読むや書き込みが可能になります。

始める Cloud Exchange

./start

サービスステータスの検証

すべてのCloud Exchangeコンテナとサービスが正常に動作しているか確認してください。

Linuxホスト（仮想マシンとしてのCE）上のネットワーク構成（IPアドレス、サブネットマスク、ゲートウェイ、DNS）を更新する方法

この記事では、Netplan を利用して Linux サーバー上のネットワーク構成パラメータを更新する方法について、一般的な手順を追って説明します。サーバーの移行、IPアドレスの再割り当て、またはサブネットの変更により、以下のパラメータのいずれかを変更する必要がある場合は、次の手順に従ってください。

静的IPアドレス
サブネットマスク / プレフィックス
デフォルトゲートウェイ
DNSネームサーバー

前提条件

ホストマシン上での管理者権限（sudoまたはrootアクセス）が必要です。
ターゲットネットワークの設定詳細(新しいIPアドレス、ゲートウェイ、サブネットマスク、DNSIPアドレス)を準備完了。

設定手順

ディレクトリ内のインターフェース設定ファイルを一覧表示します。
```
ls -la /etc/netplan/
```
安全なバックアップコピーを作成します（netskope_netplan_sample.yaml を、ディレクトリ内で見つかった正確なファイル名に置き換えてください）。
```
sudo cp /etc/netplan/netskope_netplan_sample.yaml /etc/netplan/netskope_netplan_sample.yaml.bak
```
ターゲットのYAML設定ファイルを開いて、使う preferredテキストエディタをご利用ください:
```
sudo vi /etc/netplan/netskope_netplan_sample.yaml
```
各インターフェイス名（例：eth0）の下にあるパラメータを変更します。以下の汎用テンプレート構造を使用して、特定のネットワークパラメータ値を動的に更新できます。
```
network: 
 
 
 ethernets: 
 
 
 eth0: 
 
 
 addresses: 
 
 
 - 10.168.67.57/24 # <-- Change IP Address and Subnet Mask here
 
 
 gateway4: 10.156.67.254 # <-- Change Default Gateway here
 
 
 nameservers: 
 
 
 addresses: 
 
 
 - 10.156.67.21 # <-- Change Primary DNS here
 
 
 - 10.156.67.22 # <-- Change Secondary DNS here
 
 
 search: [] 
 
 
 version: 2
```
Important Formatting Note: YAMLファイルは、構造的なインデントに厳密にスペースに依存しています。Do not use tabs. 箇条書き (-) が上記の正確な間隔構造と一致していることを確認してください。
システムネットワーク管理エンジンを再起動します。
```
sudo systemctl restart systemd-networkd
```
変更をコミットして有効化します。
```
sudo netplan apply
```
オペレーティングシステムが新しいネットワークターゲットを反映したことを確認するために、以下の検証コマンドを実行してください。
```
ip a
 
 
ip route
 
 
cat /etc/resolv.conf
```

アップグレード、移行、ライフサイクル

Cloud Exchange v3.x のアップグレード手順またはv4.xコンテナ化からCloud Exchange v5.0.1コンテナ化

重要

CE のインストール、展開、設定、アップグレード・移行について質問がある場合は、コンタクトを SE やAMにしてください。

ホストマシン/OSが変更されておらず、最新のアップグレードパッケージを取得するためのGitHubおよびDocker Hubへの接続環境がある場合のアップグレード方法。

ホストマシンが変更される場合は、移行方法を変更する必要があります。現在、 CEをVMとして展開する場合、ホストマシンをOVA/AMI/VHDX経由でデプロイするため、移行のみがサポートされています。ホストマシンはOVA/AMI/VHDX経由で展開されます。スタンドアロンからHAに移行する場合は、 HA要件に従って複数のホストマシンを設定する必要があるため、移行方法も検討する必要があります。

アップグレード作業を進める前に、必ずバックアップを取ってください。

前提条件

アップグレードまたは移行を開始する前に、インスタンスがCloud Exchangeのシステム要件を満たしていることを確認してください。
このプロセスの一部のステップを完了するにはメンテナンスパスワードが必要になりますので、すぐに使えるように準備しておいてください。

重要

メンテナンスパスワードを紛失した場合、データは保持されません。

注記

現在、HA構成からスタンドアロン構成への移行はサポートされていません。RabbiMQのデータ移行は、キューの種類がクラシックキューからクォーラムキューに変更されたためサポートされていません。

バージョン5.0.1にアップグレードする

5.0.1スタンドアロン版にアップグレードする

3.x、4.x、または5.0.xからスタンドアロン

アップグレードを進める前に、すべてのNetskopeテナントに対して、すべてのデータエクスポートエンドポイントにアクセスできるV2トークンを更新する必要があります。

先に進む前に、すべての前提条件が満たされていることを確認してください。これらの要件を事前に確認しておくことは、プロセス中に発生する可能性のある問題を回避するために不可欠です。
docker-compose.ymlファイルがある既存のta_cloud_exchangeディレクトリに移動します。Cloud Exchangeコンテナを停止します。
```
sudo ./stop
```
- If the output of the ./stop command is ./stop: No such file or directory, execute the following command.
```
sudo docker compose down -v
```
If you have made any local changes to the docker-compose.yml file, reset those using (you might need sudo).
```
sudo git reset --hard
```
Cloud Exchange v5.0.1 をご確認ください。
```
sudo git checkout v5.0.1
```
最新の変更を取り込む。
```
sudo git pull origin v5.0.1
```
セットアップスクリプトを実行してください。
```
sudo python3 ./setup
```
Cloud Exchangeを起動します。
```
sudo ./start
```
チェックアウトCloud Exchangeメイン
```
sudo git checkout main
```
Cloud Exchangeのブラウザインスタンスをすべて閉じ、シークレットモードで再度ログインするか、ログインする前にブラウザのキャッシュをクリアしてください。

Cloud ExchangeUIは今、システムのIPアドレス(http(s)://<ip>でアクセス可能です。

Cloud Exchangeがバージョン5.0.1で稼働したら、推奨されるアップグレード手順に従ってバージョン5.1.1へのアップグレードを進めることができます。

Cloud Exchange v5.0.1またはv5.1.0のアップグレード手順Cloud Exchange v5.1.1 にコンテナ化コンテナ化された

重要

CE のインストール、展開、設定、アップグレード・移行について質問がある場合は、コンタクトを SE やAMにしてください。

アップグレード作業を進める前に、必ずバックアップを取ってください。

前提条件

アップグレードまたは移行を開始する前に、インスタンスがCloud Exchangeのシステム要件を満たしていることを確認してください。
このプロセスの一部のステップを完了するにはメンテナンスパスワードが必要になりますので、すぐに使えるように準備しておいてください。

重要

メンテナンスパスワードを紛失した場合、データは保持されません。

注記

現在、HA構成からスタンドアロン構成への移行はサポートされていません。RabbiMQのデータ移行は、キューの種類がクラシックキューからクォーラムキューに変更されたためサポートされていません。

5.1.1にアップグレードするコンテナ化された

5.1.1にアップグレードするコンテナ化されたスタンドアロン

バージョン5.0.1または5.1.0以降スタンドアロン

先に進む前に、すべての前提条件が満たされていることを確認してください。これらの要件を事前に確認しておくことは、プロセス中に発生する可能性のある問題を回避するために不可欠です。
docker-compose.ymlファイルがある既存のta_cloud_exchangeディレクトリに移動します。Cloud Exchangeコンテナを停止します。
```
sudo ./stop
```
- If the output of the ./stop command is ./stop: No such file or directory, execute the following command.
```
sudo docker compose down -v
```
If you have made any local changes to the docker-compose.yml file, reset those using (you might need sudo).
```
sudo git reset --hard
```
Cloud Exchange 5.1.1 を確認してください。
```
sudo git checkout 5.1.1
```
最新の変更を取り込む。
```
sudo git pull origin 5.1.1
```
セットアップスクリプトを実行してください。
```
sudo python3 ./setup
```
Cloud Exchangeを起動します。
```
sudo ./start
```
チェックアウトCloud Exchangeメイン
```
sudo git checkout main
```
Cloud Exchangeのブラウザインスタンスをすべて閉じ、シークレットモードで再度ログインするか、ログインする前にブラウザのキャッシュをクリアしてください。

Cloud ExchangeUIは今、システムのIPアドレス(http(s)://<ip>でアクセス可能です。

Cloud Exchangeがバージョン5.1.1で稼働したら、推奨されるアップグレードおよび移行手順に従って、最新バージョンへのアップグレードまたは移行を進めることができます。

Cloud Exchange v5.0.1またはv5.1.0のアップグレード手順VMスタンドアロンデプロイメント（ Cloud Exchange向け）v5.1.1 VMスタンドアロンデプロイメント

アップグレード作業を進める前に、必ずバックアップを取ってください。

先に進む前に、すべての前提条件が満たされていることを確認してください。これらの要件を事前に確認しておくことは、プロセス中に発生する可能性のある問題を回避するために不可欠です。
cloudexchangeディレクトリに移動し、スタンドアロンデプロイメントを停止してください。
```
cd /opt/cloudexchange/cloudexchange 
sudo ./stop
```
Cloud Exchangeの公開鍵を信頼できるGPG鍵として読み込みます。スタンドアロン構成から高可用性（HA）構成にアップグレードする場合、既存のスタンドアロンノードがHA構成におけるプライマリノードとして機能することに注意してください。
```
curl -fsSL https://cloud-exchange-store.s3.us-east-1.amazonaws.com/cloudexchange/upgrade-packages/cloud-exchange-public.gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/cloud-exchange.gpg
```

debパッケージのソースとしてS3 URLを追加します。

echo "deb https://cloud-exchange-store.s3.us-east-1.amazonaws.com/cloudexchange/upgrade-packages stable main" | sudo tee /etc/apt/sources.list.d/cloud-exchange.list

情報源を更新してください。
```
sudo apt update
```
Cloud Exchangeをアップグレードし、処理が完了するまでお待ちください。
```
sudo apt install cloud-exchange=5.1.1-2
```
注記

ステップ7を実行する前に、対象バージョンに必要なすべての前提条件が満たされていることを確認してください。
以下のコマンドでセットアップスクリプトを実行してください。
```
sudo python3 ./setup
```
以下のコマンドを使用して開始スクリプトを実行します。
```
sudo ./start
```
Cloud Exchangeのブラウザインスタンスをすべて閉じ、シークレットモードで再度ログインするか、ログインする前にブラウザのキャッシュをクリアしてください。
Cloud Exchange UI は現在、システムの IP アドレスを使用してアクセスできます: http(s):// <ip> 。

Cloud Exchangeがバージョン5.1.1で稼働し始めたら、推奨されるアップグレードおよび移行手順に従って、最新バージョンへのアップグレードまたは移行を進めることができます。

VM 上の Cloud Exchange の基盤となる OS をアップグレードする

VM 上の Cloud Exchange を Ubuntu 20.04 から Ubuntu 22.04 にアップグレードするには、記載されている前提条件を満たした後、以下の手順を実行してください。これらの手順では、VMマシンとしてCloud Exchangeを再起動する必要があるため、それに応じてアップグレード計画を立ててください。手順は、再起動前と再起動中の2つの部分に分かれています。

前提条件

スクリプト内のコマンドを実行するには、sudo権限が必要です。
以下のURLへのインターネット接続状況：
- Ubuntu公式リポジトリ：
  - http://archive.ubuntu.com/ubuntu
  - http://security.ubuntu.com/ubuntu
- その他の情報源：
  - https://download.docker.com/linux/ubuntu
  - https://cloud-exchange-store.s3.us-east-1.amazonaws.com
- Ubuntuリリースアップグレードサーバー：
  - http://changelogs.ubuntu.com
  - http://archive.ubuntu.com
- Pythonパッケージインデックス（PyPI）：
  - https://pypi.org
  - https://files.pythonhosted.org
- 基礎となる OS を 20 から 22 にアップグレードするには、ルートクレデンシャルが必要です。以下は OVA のルートクレデンシャルです。
  - ユーザー名: root
  - パスワード: M5#w6V+.T^8gv?%、

再起動する前に

非対話モードの設定

スクリプトは、環境変数を設定することで開始し、対話型のプロンプトが実行を妨げないようにします。

cd /opt/cloudexchange/cloudexchange 
sudo ./stop

export DEBIAN_FRONTEND=noninteractive

追加のAPTソースを無効にする

sudo sed -i 's/^/#/' /etc/apt/sources.list.d/*.list

システムの更新とアップグレード

sudo apt update 
sudo apt-get -o Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-confdef" -y upgrade 
sudo apt-get -o Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-confdef" -y dist-upgrade 
sudo apt autoremove -y

リリースアップグレードの準備

sudo apt install -y update-manager-core

システムの再起動

sudo reboot

ディストリビューションのアップグレードを実行中

export DEBIAN_FRONTEND=noninteractive 
sudo do-release-upgrade -f DistUpgradeViewNonInteractive

不完全なパッケージ構成の修正

sudo apt update 
sudo dpkg --configure -a

Pythonパッケージのインストール

sudo pip3 install "pyyaml>=6.0.0" 
sudo pip3 install "python-dotenv>=0.20.0,<=1.0.0" 
sudo pip3 install "pymongo>=4.6.3,<=4.7.3"

APTソースの再有効化と最終アップグレード

sudo sed -i -e 's/^#//' -e 's/focal/jammy/g' /etc/apt/sources.list.d/*.list 
sudo apt update 
sudo apt upgrade -y 
sudo apt autoremove -y

システムを再起動してください

sudo reboot

既存のCloud Exchangeあるマシンから別のマシンに移行する

もしあなたがコンテナ化されたスタンドアロン環境で、別のコンテナ化されたスタンドアロン環境に移行する場合。

コンテナを停止します。
- sudo ./stop
Cloud Exchangeフォルダ用のzipファイルを作成します。
- sudo zip -r ce_backup.zip ta_cloud_exchange
ce_backup.zipフォルダを新しいマシンに転送します。
フォルダを解凍してください。
- unzip ce_backup.zip
セットアップスクリプトを実行します。
- sudo ./setup
コンテナを停止します。
- sudo ./start

テナント内EDR統合の廃止と、すべてのEDR統合におけるCloud Exchangeへの移行。

Netskopeは今後、 Netskope Threat Exchangeとのエンドポイント検出および対応統合のみをサポートします。テナント内EDR統合機能は、2025年12月1日以降は利用できなくなります。
Cloud Exchangeの導入と継続的な改善により、EDRおよび脅威インテリジェンス統合においてより高度なプラットフォームとなっています。
Netskope Cloud Threat Exchange (CTE) はCloud Exchangeの一部であり、既存のセキュリティツール間で悪意のあるURLやファイルのハッシュなどの脅威データを簡単かつ安全に共有できます。

脅威情報交換モジュールは、複数のサードパーティ製セキュリティベンダーとの連携をサポートしています。

CTE を使用すると、脅威データをほぼリアルタイムで自動的に送受信できるため、エンドポイント、ファイアウォール、ウェブゲートウェイ、クラウドセキュリティツールの保護が強化されます。

Get started with EDR Integrations in Cloud Exchange

1. Cloud Exchangeを展開するには専用システム(VM)が必要です。Cloud Exchangeは複数のプラットフォームでの展開をサポートしています。展開ガイドはこちらをクリックしてください
2. 展開後はCloud Exchangeのウェブコンソールにアクセスし、Cloud Threat Exchange(CTE)モジュールを有効にすることができます。詳細については「モジュールを有効にする」を参照してください。
3. Netskopeテナントの設定
4. 始める使う脅威交換モジュール。

Business Rules in Threat Exchange ビジネスルールによって、共有されるデータが決まります。脅威データ内の特定のフィールドに基づいて、これらのルールをカスタマイズできます。ビジネスルールの例を以下に示します。

Illumio Threat Exchangeモジュール用プラグインの非推奨化

Netskope Cloud Exchangeの脅威情報交換モジュール用のIllumioプラグインは、2026年半ば頃にサポートが終了する予定です。本ドキュメントを参照して、リスクエクスチェンジを通じてIllumioのサポートを継続する方法をご確認ください。

推奨交換部品

現在、脅威交換にこのプラグインを使用しているユーザーはケースは、機能を維持するために、リスク交換用のIllumioプラグインに移行する必要があります。

ワークフローの例：プライベートアプリを更新するためのワークロードの取得

以前に Threat Exchange Illumio プラグインを使用してワークロード (IP アドレス、ホスト名) を取得し、 Netskope Threat Exchange プラグイン経由でプライベートアプリでそれらを更新したことがある場合は、この新しいワークフローに従って Risk Exchange モジュールを使用してください。

Netskope Risk Exchangeプラグインを設定します。これはNetskope Threat Exchangeプラグインを置き換えるものです。プラグインガイドはこちらです。
Risk Exchange 用の Illumio プラグインを設定します。これはThreat Exchange Illumioプラグインを置き換えるものです。プラグインガイドはこちらです。
ワークフローを再開するには、リスクエクスチェンジプラグインの「プライベートアプリにホストを追加」アクションに必要な設定を確立してください。詳細は前述のプラグインガイドに記載されています。

注記

Risk Exchange 用の Illumio プラグインは、IoC 撤回をサポートしていません。

この移行やワークフローに関するご質問は、コンタクト Netskope サポートまでお問い合わせください。

Microsoft Azure Sentinel プラグインのログシッパーモジュールの非推奨化

マイクロソフトは、カスタムログ用のAzure MonitorデータコレクターAPIの非推奨化を発表しました。既存のNetskope Cloud Exchange Microsoft Azure Sentinel プラグインを使用している場合、構成はこれらの非推奨のデータコレクタ API に依存しており、Microsoft が基盤となる API のサポートを継続している間のみ機能します。 Microsoft の最新の Log Ingestion API を使用する新しいMicrosoft Azure Log Analytics Workspaceプラグインへの移行を計画する必要があります。

Microsoft Azure Log Analytics Workspaceプラグインの構成/移行については、次のドキュメントMicrosoft Azure Log Analytics Plugin for Log Shipperを参照してください。

Microsoft データコレクター API は非推奨となり、2026 年 9 月 14 日以降はサポートされなくなります。 MicrosoftがこれらのAPIを完全に廃止すると、既存のMicrosoft Azure Sentinelプラグインのサポートは終了します。

マイクロソフトの非推奨に関するお知らせはこちらをご覧ください。

何が変わるのか？

マイクロソフトは、Azure Monitor LogsおよびMicrosoft Sentinelを基盤とするLog Analyticsワークスペースへのカスタムログ取り込みに関して、従来のデータコレクターAPIモデルから新しいログ取り込みAPIモデルへの移行を進めています。
Microsoft がサポートするアーキテクチャに合わせるため、Netskope はMicrosoft Azure Log Analytics Workspaceという名前の新しい Cloud Exchange Log Shipper 宛先プラグインを導入します。このプラグインは、Microsoftの最新のログ取り込みAPIに基づいて構築されており、以下の両方の用途で統一された取り込みエクスペリエンスを提供します。

既存の Microsoft Azure Sentinel を使うケース
現在のMicrosoft Azure Monitor統合ワークフロー

顧客への影響

既存のMicrosoft Azure Sentinelプラグインを削除した場合、Microsoft が基盤となるデータコレクター API をサポートしている限り、引き続き機能します。
Microsoftが非推奨APIを完全に廃止すると、現在お使いのMicrosoft Azure Sentinelプラグイン構成のサポートは終了します。
MicrosoftのAPI廃止日までに、新しいMicrosoft Azure Log Analytics Workspaceプラグインに移行することをお勧めします。
移行スケジュールはお客様自身で管理でき、API廃止前にご自身のペースで移行を進めることができます。

推奨される行動

現在のCloud Exchange Log Shipper の設定を確認してください Microsoft Azure Sentinel プラグイン。
新しい Microsoft Azure Log Analytics ワークスペースプラグインへの移行を計画します。
ログ取り込みAPIベースの取り込みに必要な、対象のLog Analyticsワークスペース、データ収集エンドポイント、データ収集ルール、テーブル構成、およびMicrosoft Entraアプリケーションのアクセス許可を検証します。
非本番環境または管理された環境で、新しいプラグインを使用したデータ取り込みテストを実施してください。
事前に、本番ログ転送を新しいプラグインに移動してください。

以下の表は、利用可能なAzureの宛先オプションを比較し、どのプラグインがお客様のデータ取り込み要件に最適かを理解するのに役立ちます。これらの比較によって、統合テーブルが必要か、データタイプごとにテーブルを分ける必要があるか、現在のMicrosoftの取り込みAPIが必要か、あるいはJSON、CEF、アラート、イベント、WebTxなどの特定のログ形式のサポートが必要かを判断します。

テーブル構成オプションの比較

Option	ログ分析	Azure Monitor	Azure Sentinel
すべてをoneテーブルに送信してください	✅	✅	❌
各データタイプをseparateテーブル（アラート/イベント/Webトランザクション）に送信します。	✅	❌	✅
取り込むデータタイプを選択するオプション	✅	❌	❌
Netskopeフィールドごとに1列	✅ (in per-data-type mode)	❌	❌

比較概要

Capability	ログ分析	Azure Monitor	Azure Sentinel
Microsoft の現在の取り込み API を使う	✅	✅	❌ 非推奨のデータコレクター API を使用する
アラートを送信する	✅	✅	✅
イベントを送信	✅	✅	✅
Netskopeの新しいアラート（デバイス、コンテンツ）をサポートします。	✅	✅	❌
Netskopeの新しいイベントタイプ（クライアントステータス）をサポートします。	✅	✅	❌
Sends WebTx	✅	❌	✅
CEF形式に対応	✅（シングルテーブルオプションの場合）	✅	❌
JSON形式をサポートしています	✅（シングルテーブルモードとテーブルごとのモード）	✅	✅
統一されたテーブル	✅	✅	❌
データタイプ（アラート／イベント／Webトランザクション）ごとにテーブルを分ける	✅	❌	✅
Per-data-type field columns	✅	❌	❌
最新の認証 Microsoft Entraアプリケーション	✅	✅	❌

よくある質問

Q: Is the current Microsoft Azure Sentinel plugin being removed immediately?

A: いいえ。マイクロソフトが基盤となるデータコレクターAPIのサポートを継続する限り、現在お使いのプラグインは引き続き機能します。

Q: When will support for the current Microsoft Azure Sentinel plugin end?

A: Microsoftが非推奨のデータコレクターAPIを完全に廃止した後、現在ご利用のMicrosoft Azure Sentinelプラグイン構成のサポートは終了します。Microsoft は、これらの API は以降サポートされなくなると述べています。

Q: Which plugin should you use going forward?

A: Azure Sentinel/Microsoft Sentinel および Azure Monitor ログ取り込みワークフロー用の新しいMicrosoft Azure Log Analytics Workspaceプラグインを使用する必要があります。

Q: Does the new plugin support both Azure Sentinel and Azure Monitor workflows?

A: はい。Microsoft Azure Log Analytics ワークスペースプラグインは、既存の Azure Sentinel と現在の Azure Monitor 統合ワークフローの統合された取り込みエクスペリエンスを提供します。

Q: Do you need to migrate immediately?

A: Microsoftが非推奨APIを廃止する前に、ご自身のペースで移行を進めることができます。ただし、Netskopeは、データ取り込みの中断を避けるため、サービス終了日よりかなり前に移行計画を立て、検証しておくことを推奨します。

最終勧告／ガイダンス

Microsoft Azure Log Analytics Workspaceプラグインは、Cloud ExchangeからAzureベースのログを取り込むための、将来を見据えた宛先として扱うべきです。移行期間中は、既存の Microsoft Azure Sentinel プラグイン構成をそのまま使用できますが、サービスの中断を避けるため、Microsoft がデータコレクター API のサポートを終了する前に移行を完了してください。

参考文献

Microsoft Azure Log Analytics Workspaceプラグインの構成に関する詳細については、以下のドキュメントこちらをご参照ください。

Cloud Exchangeを新しいストレージドライブに移行する手順

この手順では、現在のストレージが不足している場合に、既存の Cloud Exchange インストールを新しく追加したドライブに移動する方法を説明します。

前提条件

Cloud Exchangeサーバーのフルイメージバックアップを取得してください。
新しいドライブが正しくマウントされていることを確認してください。
新しいドライブに十分なストレージ容量と必要な権限があることを確認してください。

Example:

現在のCEディレクトリ： /ta_cloud_exchange
新しいドライブ： /newdrive

移行手順

Cloud Exchangeのインストールディレクトリに移動し、CEコンテナを停止してください。
./stop
Cloud Exchangeのディレクトリ全体を新しいドライブに移動します。
mv /ta_cloud_exchange /newdrive/
新しいCEインストールディレクトリに移動してください。
cd /newdrive/ta_cloud_exchange
Cloud Exchangeを始める。
./start

すべてのサービスが開始されるまで約3–4 minutes待ち、Cloud ExchangeのUIを確認し、既存のすべての構成が利用可能であることを確認し、必要なサービス/プラグインが実行されていることを確認して、構成された統合を検証します。

Cloud Exchangeプラットフォームの管理と API ワークフロー

プロキシ設定

PIPプロキシ

pip のプロキシ設定に関するグローバルな方法については、次のリンクを参照してください: https://pip.pypa.io/en/latest/topics/configuration/#location

設定ファイルを見つけてください: /etc/pip.conf 。pip.confファイルが存在しない場合は作成します。

設定例：

[global]
proxy = http://<username>:<password>@<ip>:<port>

プロキシのユーザー名/パスワードに含まれる特殊文字は、URLエンコードする必要があります。

設定されたプロキシは使う pip config listで検証可能です。

Ubuntu

Ubuntu システムで APT パッケージマネージャーのプロキシ設定を構成するには、次の構成を/etc/apt/apt.confに追加します。apt.confファイルが存在しない場合は作成します。

設定例：

Acquire::http::Proxy "http://USERNAME:PASSWORD@SERVER:PORT";

Acquire::https::Proxy "https://USERNAME:PASSWORD@SERVER:PORT";

Docker（Ubuntu用）

https://docs.docker.com/engine/daemon/proxy/#httphttps-proxy

RHEL

RHEL システム上の YUM パッケージマネージャのプロキシ設定を構成するには、次の構成を/etc/yum.confに追加します。yum.confファイルが存在しない場合は作成します。

設定例：

proxy=http://SERVER:PORT
proxy_username=USERNAME
proxy_password=PASSWORD

RHELとPodman

RHELでPodmanを使用してプロキシを設定するには、次のコマンドを実行します。

export HTTP_PROXY="http://<your.proxy.tld:port>"
export HTTPS_PROXY="http://<your.proxy.tld:port>"
export NO_PROXY="localhost,127.0.0.1,..."

RBAC V3を使用してV2トークンを生成する

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

Prerequisities

クレデンシャルがNetskopeテナントにログインすることを承認されました。

Generate a new V2 token with RBAC V3

Netskopeテナントにログインして、 Settings .
にアクセスしてください。
Administrationをクリックしてオプションを展開してください。
Click Administrators & Roles.
Service Accountをクリックしてください。
Enter a Service Account Name, select Netskope Cloud Exchange for the Role, and then provide the time for Generate token now with expiry. When finished, click Create.
このモーダルポップアップが閉じられるとトークンは利用できなくなりますので、必ずコピーしておいてください。

7. Cloud Exchange UIでのナビゲーション(ホーム ->設定 ->テナント)
8. 設定を編集し、V2トークンを追加します

セキュアなUIアクセスを実現するためのカスタムSSL証明書のアップロード方法

この記事では、Cloud Exchange(CE)のデフォルトのSSL証明書をカスタムCA署名証明書に置き換えるためのステップバイステップガイドを提供します。このプロセスにより、Cloud Exchangeのウェブインターフェースにおける安全なHTTPS通信が保証されます。

前提条件

始める前に、以下のものを用意してください。

Backup: 既存の証明書ファイルを削除する前に、バックアップを取っておくことをお勧めします。
Certificate Files: 有効な証明書（形式： .crtと、それに対応する秘密鍵（形式： .key ）。
Terminal Access: sudo権限でCloud ExchangeホストマシンへのSSHアクセス。

Procedure

証明書のアップロードと検索

カスタム証明書とキーファイルをCloud Exchangeホストマシンに転送します ( SCP、SFTP、または同様の方法)。これらのファイルが保存されているディレクトリパスをメモしておいてください。

Cloud Exchangeサービスを停止する

# Navigate to Installation Directory
Move to the Cloud Exchange installation path. Typically located at: "ta_cloud_exchange/" or "/opt/cloudexchange/cloudexchange".

# Stop the containers
sudo ./stop

既存の証明書をクリアする

特定のSSLディレクトリに移動し、古い証明書ファイルを削除してください。

# Enter the SSL certificates directory
cd data/ssl_certs

# Remove old certificate and key
sudo rm -rf cte_cert.crt
sudo rm -rf cte_cert_key.key

新しい証明書をインストールする

新しい証明書ファイルをssl_certsフォルダにコピーし、システムの想定する命名規則に合わせて名前を変更してください。

# Copy the files

sudo cp <path/to/your/certificate.crt> .
sudo cp <path/to/your/certificate.key> .

# Rename the files: The system specifically looks for cte_cert.crt and cte_cert_key.key

sudo mv certificate.crt cte_cert.crt
sudo mv certificate.key cte_cert_key.key

Cloud Exchangeを再起動してください。

# Navigate back to the Cloud Exchange directory.

cd ../..

# Start the containers

sudo ./start

Validation

ブラウザを開き、 Cloud Exchangeユーザーインターフェースにアクセスしてください。
アドレスバーのlock iconをクリックしてください。
Certificate Informationが新しくアップロードしたカスタム証明書と一致することを確認してください。

Cloud Exchange UIポートの変更

この記事では、Cloud Exchangeのユーザーインターフェース(UI)ポートを安全に更新するためのステップバイステップの手順を提供します。このプロセスにはサービスを停止し、提供されたテンプレートを使う設定ファイルの再構成、そして Cloud Exchangeの再起動を含みます。

Cloud Exchangeサービスを停止せよ

設定を変更する前に、現在稼働中のCloud Exchangeサービスを停止する必要があります。ターミナルで以下のコマンドを実行してください。

sudo ./stop

古い設定ファイルを削除します

クリーンな構成更新を確実にするために、既存のcloudexchange.cofigファイルを削除してください。 :

rm -rf cloudexchange.cofig

テンプレートから新しい構成ファイルを作成する

提供されているサンプルテンプレートをコピーして、新しい設定ファイルを生成します。 :

cp cloudexchange.cofig.example cloudexchange.cofig

設定ファイルを編集する

新しく作成した設定ファイルをテキストエディタで開き、ポートを更新します。 :

vi cloudexchange.cofig

ファイル内で、 UI_PORT変数を探し、希望するポート番号に変更してください（デフォルトは443です）。

# Port number to use for the CE UI. Default 443
UI_PORT=<your_new_port_number>

Note: 変更を加えた後、ファイルを保存して閉じます（ viでEscを押し、 :wqと入力し、 Enterを押します）。

セットアップスクリプトを実行する

セットアップスクリプトを実行して新しい設定変更を適用してください:

sudo python3 ./setup

始める Cloud Exchange

セットアップが完了したら、再び Cloud Exchange サービスを始めて新しいポート設定を適用します:

sudo ./start

Verification

Verify Port Allocation: 選択した新しいポートが、ホストネットワーク上の他のサービスによってすでに使うしていないか確認してください。
Accessing the UI: Cloud Exchange UIにアクセスする際は、新しいポート番号をURLに必ず付け加えてください(例: https://<your-ip>:<new_port>)。

Netskope Cloud Exchange Super Admin Access のEntra属性設定

Netskope Cloud Exchangeは、ユーザーに割り当てられたカスタムEntra属性を通じてマッピングされるロールベースの権限をサポートしています。現在、一部のユーザーは以下の属性を設定しており、読む/writeアクセスが限定的に与えられています。

netskope-ce-write
netskope-ce-read

これらのユーザーのアクセス権限をSuper Adminに昇格させるには、追加の属性を追加する必要があります。

スーパー管理者アクセスに必要なEntra属性

Cloud Exchangeでユーザーに完全なスーパー管理者権限を与えるには、ユーザーのEntraプロフィールで以下の属性 all を設定してください:

#	Attribute Name:
1.	netskope-ce-write
2.	netskope-ce-read
3.	netskope-ce-admin
4.	netskope-settings-write
5.	netskope-ce-api

5つの属性すべてが存在する必要があります。いずれかを省略すると、権限が制限（スーパー管理者以外）されます。

Verification

ユーザーがすべてのCloud Exchangeモジュール(例:設定)に制限なくアクセスできるか確認してください。

Note

ユーザーがEntra IDを通じて netskope-ce-admin ロールを割り当てると、Cloud Exchange内で Administrator 権限が付与されます。

この役割では、ユーザーは以下を含む（ただしこれらに限定されない）完全な管理者権限を持ちます。

Cloud Exchangeモジュールの有効化または無効化。
Cloud Exchange内でユーザーアカウントの作成、変更、管理。
読むのみまたは書き込み専用権限を持つユーザーにはアクセスできない管理設定へのアクセスと管理。

Entra IDを通じて netskope-ce-admin ロールが割り当てられ、ユーザーが再度サインインすると、対応する管理権限が Cloud Exchange に自動的に適用されます。

Cloud Exchangeのログストリーミングとイベントストリーミングクライアントの比較

Netskopeは、トランザクションイベントを下流のSIEMおよび分析プラットフォームに配信するための複数の方法を提供します。本書で取り上げる2つのオプションは、AWS/Azure Log Streamingを使用したCloud Exchangeと、Event Streaming Client（ESC）です。

Cloud Exchange with AWS/Azure Log Streaming

Architecture

Netskopeテナント
↓
AWS S3/SQS または Azure Blob/Queue
↓
Cloud Exchange
↓
Log Shipper
↓
SIEM / XDR / データレイク

前提条件

Netskope Log Streamingが有効になりました。
Cloud Exchangeがデプロイされました。
テナントプラグインとLog Shipperが構成されました。
AWSまたはAzureストレージインフラストラクチャが構成されています。
宛先のSIEM/プラグインが構成されました。

構成概要

Netskopeログストリーミングを構成します。
AWSの場合は、S3およびSQSを構成します。Azureの場合は、Blob Storage、Event Grid、およびStorage Queueを構成します。
Cloud ExchangeでAWS/Azureログストリーミングプラグインを構成します。
Log Shipperのビジネスルールを構成します。
宛先プラグインとログ配信を構成します。
NetskopeからSIEMへのデータの流れを検証します。

主なメリット

複数のダウンストリーム統合をサポートします。
ビジネスルール処理の一元管理を提供します。

考慮事項

AWS/Azureストレージインフラストラクチャが必要です。
管理およびトラブルシューティングが必要なコンポーネントが増えます。
Cloud ExchangeおよびLog Shipperの処理レイヤーを追加します。

Event Streaming Client（ESC）

Architecture

Netskopeテナント
↓
gRPC/TLS
↓
Event Streaming Client
↓
Syslog
↓
SIEM

前提条件

Event Streaming Clientのエンタイトルメント。
サポートされているLinuxサーバー（RHELまたはUbuntu）。
Docker or Podman.
gRPC/TLSポート50051を含む、クライアントからNetskopeへのアウトバウンド接続。
クライアントからSIEMへのSyslog接続。

構成概要

必要なAPI認証を作成します。
Event Streaming Clientを作成します。
Linuxサーバーにクライアントをインストールします。
必要な出力形式（JSON、CEF、またはELFF）を作成します。
SIEMの宛先を構成します。
トランザクションイベントログストリーミングを構成します。
イベントの配信を検証します。

Key Benefits

直接ストリーミングアーキテクチャ。
AWS/Azureストレージまたはキューインフラストラクチャは不要です。
導入とトラブルシューティングをよりシンプルに。
JSON、CEF、およびELFF形式をサポートします。
フィールドのカスタマイズをサポートします。
大量のトランザクションイベントの配信に適しています。

Considerations

より広範なCloud Exchangeのワークフローではなく、イベントストリーミングに重点を置いています。
Cloud Exchangeのビジネスルールおよびプラグインベースの統合機能は提供されません。
追加の統合には、個別のソリューションが必要になる場合があります。

機能比較

Capability	Cloud Exchange ＋ Log Streaming	イベントストリーミングクライアント
Cloud Exchangeが必要です	はい	いいえ
AWS/Azureストレージが必要です	はい	いいえ
トランザクションイベントのサポート	はい	はい
複数の宛先との統合	はい	Limited
ビジネスルール	はい	いいえ
SIEMへの直接ストリーミング	いいえ	はい
インフラストラクチャの複雑さ	Higher	Lower
運用上の負荷	Higher	Lower
大量のトランザクションイベント	適合	優れた適合性

Summary

NetskopeトランザクションイベントをSIEMに直接配信することを主な目的とするお客様には、よりシンプルで直接的なストリーミングパスを提供できるため、一般的にEvent Streaming Clientのアーキテクチャが推奨されます。

すでに複数の統合やワークフローでCloud Exchangeを使用しているお客様にとって、AWS/Azureログストリーミングを組み合わせたCloud Exchangeは引き続き適切な選択肢であり、より優れた統合の柔軟性を提供します。

Netskope Azure Log AnalyticsプラグインとCodeless Connector Framework（CCF）の比較

Netskopeは、NetskopeのアラートとイベントをMicrosoft Sentinelに送信するための2つのアプローチを提供します：

Cloud Exchange Azure Log Analytics Plugin：Cloud Exchangeを中間ログ転送プラットフォームとして使用します。
Codeless Connector Framework (CCF)：Cloud Exchangeを必要とせずに、NetskopeとMicrosoft Sentinel間の直接統合を提供します。

どちらのソリューションもNetskopeのセキュリティデータをMicrosoft Sentinelに配信できますが、アーキテクチャ、スケーラビリティ、柔軟性、およびインフラストラクチャの要件が異なります。

主な違い

Capability	Cloud Exchange – Azure Log Analytics プラグイン	Codeless Connector Framework（CCF）
Architecture	Netskope → Cloud Exchange → Azure Log Analytics → Sentinel	Netskope → CCF → Sentinel
Cloud Exchangeが必要	はい	いいえ
Deployment	Cloud Exchangeインフラストラクチャが必要です	Microsoft Sentinelとのネイティブ統合
イベント容量	大容量の取り込みをサポートします。容量はCEのサイジングと構成によって異なります	1日/エンドポイントあたり1,440万イベントの制限
容量の計画	イベントタイプごとに1日あたり約7,500万件のイベントを、展開計画の参照として使用できます。	エンドポイントあたり1日1,440万イベントの制限
Filtering	Log Shipperのビジネスルールを使用した高度なフィルタリング	Cloud Exchangeと比較して制限があります
データトランスフォーメーション	サポート対象	Connector-defined
テーブル管理	Single Table or Per Data Type	Connector-defined
複数の宛先	サポート対象 – CEは、一元化された統合レイヤーとして機能します	主にSentinelに焦点を当てた
インフラストラクチャ管理	CEのデプロイとメンテナンスが必要です	最小限のインフラストラクチャ管理
最適な用途	柔軟性と制御を必要とする大容量環境	シンプルで直接的なSentinel統合

どれを選択すべきですか？

Cloud Exchange Log Analyticsプラグイン

組織が以下を必要とする場合に推奨されます：

より大容量または複雑なインジェスト要件
高度なフィルタリングとデータ制御
複数のSIEM/SOAR統合
柔軟なテーブルおよびデータ型の管理
既存のCloud Exchangeデプロイメント

コードレスコネクタフレームワーク

組織が以下を必要とする場合に推奨されます：

シンプルで直接的なNetskopeからSentinelへの統合
Cloud Exchangeインフラストラクチャなし
導入およびメンテナンスのオーバーヘッドを削減
14.4Mイベント/日/エンドポイントの制限内のイベントボリューム

Summary

CFはMicrosoft Sentinelとのよりシンプルで直接的な統合を提供し、Cloud Exchangeを不要にします。

Cloud Exchange Azure Log Analyticsプラグインは、インジェストパイプラインに対する柔軟性と制御を向上させ、より大容量または複雑な統合要件を持つ組織に適しています。

Capacity consideration: CCFには14.4 million events/day per endpointという文書化された制限があります。Cloud Exchangeの容量は、Cloud Exchangeのデプロイサイズと構成によって異なります。Netskopeが公開したテストでは、大規模なCloud Exchangeスタックにおけるアラートおよびイベントの処理能力が約119K–128K events/minuteであることが示されています。

プラグイン管理とモジュール設定

NetskopeからCloud Exchangeを使用して履歴データを取り込む

Log Shipperモジュールは、リアルタイムのログ転送に加えて、過去のデータが必要なシナリオ（SIEM障害、システム復旧、ギャップ分析など）に役立つhistorical events or alertsの取得もサポートしています。

When to Use Historical Log Pulling

ユーザーは、以下の理由により、Netskopeテナントから過去のイベントを取り込む必要がある場合があります。

SIEM/環境の障害によるデータ損失
障害発生後の復旧活動
過去のイベントキャプチャが必要なその他の使用ケース

Steps to Pull Historical Data for a Configured SIEM Mapping

Log Shipper Module > SIEM Mappingsへ移動
履歴ログを取得したいSIEMマッピングを特定します。
second action buttonをクリックしてください。ラベルは“Pull Historical Data”です（下の画像を参照）。
ポップアップウィンドウで：
– 目的のstartとend date-time Select （ UTC内）。
– “Pull”をクリックしてタスクを開始します。
送信が完了すると、Cloud Exchangeは選択されたSIEM構成に基づいて、選択された時間帯のログの取得を開始します。

Validate Pull Historical Data

以下の例に示すように、ログセクションを通して同じことを検証できます。
上記のログは、指定された日付までの履歴データ取得タスクが正常に完了したこと、およびテナントから取り込まれたイベント/アラートの数を示しています。

以下のデバッグログは、履歴同期の開始を示しており、その期間が強調表示されています。

Important Notes:

履歴ログの取得は、SIEMマッピングのリアルタイム取り込みには影響し。
この機能は、ウェブトランザクションログやクライアントステータスイベントなど、CSVベースのイテレータメカニズムではサポートされていません。

Netskope Log Shipperを使用してSIEMログに詳細な監査データを含める

Cloud Exchange内のNetskopeの Log Shipper (CLS) モジュールを使用すると、ログ (監査イベントなど) を SIEM システムに効率的に転送できます。デフォルトでは、SIEMに送信される監査ログには、「インラインポリシーが削除されました」などの管理アクションの概要のみが含まれ、具体的に何が変更されたかについての詳細は含まれていません。

これらの欠落した詳細は「サポートデータ」や「詳細」と呼ばれる他のフィールドに存在し、これらは Netskope テナント内の元の監査ログには存在しますが、SIEMログマッピングにはデフォルトで含まれていません。

Example

以下は、サポート情報が欠落しているデフォルトのSIEM出力の例です。

Solution: マッピングに「サポートデータ」と「詳細」を追加してください

構成変更に関する詳細情報を含めるには、ログシッパーの監査イベントマッピングに、必要なフィールドを手動で追加する必要があります。

Steps to Update the Mapping File

Cloud ExchangeでLog Shipperモジュールに進みます。
SIEMプラグインを一時的に無効にしてください。
現在SIEMプラグインによって使用されているマッピングファイル名を確認してください。
Settings > Log Shipper > Mappingへ移動してください。
マッピングファイルを見つけて、 CloneまたはEditを選択します（既にカスタム設定になっている場合）。
マッピングエディタで、 Events > Audit > Extensionに移動します。
以下の項目を追加してください:「支援データ」「詳細」
マッピングファイルへの変更を保存します。
SIEMプラグインの設定画面に戻る：
更新してください変更されたマッピングファイル。
SIEMプラグインを再度有効にします。

Resulting Output

マッピングを更新すると、SIEM ログには、詳細な構成データが含まれます。

<14>September 15 08:30:25 netskopece CEF:0|Netskope|TESTs|NULL|audit|NULL|High|auditLogEvent=Deleted Inline Policy Supporting_Data={"data_type": "policy","data_values": ["Non-admin updates policy"]} auditType=admin_audit_logs suser=[EMAIL_ADDRESS] timestamp=1747298327

Additional Reference: マッピングファイルの操作に関するより詳細なガイダンスについては、公式ドキュメント「マッピングファイルの作成/編集 – Netskope ドキュメント」を参照してください。

Netskope Cloud Exchangeでログソース識別子を設定する方法は？

Log Source Identifierは設定可能な属性ですログに一意の識別子をタグ付けすることで、セキュリティ情報およびイベント管理 (SIEM) システム内の複数のログソースを区別しやすくなります。これは、複数のログソースを Splunk、QRadar、 Rapid7などの集中型 SIEM プラットフォームに統合する場合に特に便利です。

このガイドでは、Syslogプラグインでログソース識別子を設定する方法について説明します。 Netskope Cloud Exchange 、SIEMがさまざまなログソースを効果的に区別できるようにします。

Configure Required Plugins

Log Shipper Plugin: このプラグインはNetskopeテナントからログ(アラートやイベントなど)を取得します。
Syslog Plugin: このプラグインはログをSIEMプラットフォーム(例:Splunk)に転送する役割を担います。

Syslogプラグインでログソース識別子を設定します。

Cloud Exchange UI内のSyslogプラグイン設定にアクセスし、Configuration Parametersの Log Source Identifier というフィールドを見つけてください。
ログソースに基づいてカスタム名または識別子（例： Log From My Netskope Tenant ）を入力し、 Saveをクリックして設定を適用します。

SIEMで検証する

設定が完了したら、正しいログソース識別子でログが受信されていることを確認してください。

例（Splunkの場合）：確認するには、次のSplunkクエリを実行してください：
index=<your_index> "Log From My Netskope Tenant"

"Log From My Netskope Tenant" 、実際に設定した識別子に置き換えてください。ログが表示されれば、設定は成功です。

Summary

Syslog プラグインのLog Source Identifierフィールドを使用すると、SIEM プラットフォームでのログソースの分離と可視性が向上します。これを正しく設定することで、セキュリティインフラストラクチャ内におけるNetskopeログの管理性と監視性を向上させることができます。

ベータ版プラグインを一般提供版（GA）プラグインに移行する方法

Cloud Exchangeは24時間ごとにプラグインの可用性チェックを行います。

プラグインが一般公開されると、プラグインリポジトリページに通知バナーが表示されます。このバナーは、設定済みのベータ版プラグインの移行が利用可能であることを示しています。

移行手順

移行を完了するには、以下の手順に従ってください。

Locate the Banner: プラグインリポジトリのページにアクセスしてください。GAバージョンが利用可能であることを示すnotification bannerを探して特定します。
Initiate Migration: 通知バナー内に表示されているMigrate pluginをクリックしてください。
Select the Plugin: 利用可能なプラグインのリスト(新しいGAバージョンを含む)が表示されます。移行したいプラグインの GA versionをSelectしてください。
Confirm and Save: Saveをクリックしてください。
Migration Process: システムは今、古いベータプラグインから新しいGAプラグインへの設定移行を開始します。

このプロセスが完了すると、あなたのシステムはより安定し公式にサポートされているGAプラグインとして使うとなります。

IoCの撤回がサポートされていない場合は、Netskopeから非アクティブなIoCを削除してください

この記事では、Netskopeで既にソースコードから削除されているIoC（侵害指標）を削除する方法について説明します。一部のプラグインは、STIXTAXII やウェブページインジデントの指標 Scraper などの IoC の撤回をサポートしていません。

Note: You need to follow this only if the plugin does not support IoCs retraction. Else you can directly configure IoCs retraction for remove IoCs

プラグインを再設定できます老化基準「1」。これを実現するには、以下の手順に従ってください。

既存のプラグインとそのプラグインに割り当てられているデータを削除します。
◇ 新しいプラグインを設定し、エージング基準「1」を設定します。
今後は、ソースコードから削除されたすべてのIoC（侵害指標）は、1日以内にCloud Exchangeでも期限切れとしてマークされます。
その後、Cloud Exchangeから期限切れのIoCを削除する設定を有効にできます。そのためには、以下の手順に従ってください。
Cloud Exchangeで Settings > Threat Exchangeに行き、 Delete Inactive IoC(s) Indicatorsを有効にして Saveをクリックします。
今後は、ソースコードから削除されたすべてのIoC（侵害指標）は、1日後にNetskopeからも自動的に削除されます。

Slack 用のCloud Exchangeプラットフォームログエラー通知の設定

このセクションでは、Cloud Exchangeのエラーに関するSlackの通知設定手順について説明します。これにより、顧客はCloud Exchange運用中に発生した重大な問題やエラーについて、迅速に通知を受けることができるようになります。以下の手順に従って、各種Cloud Exchangeモジュールの通知を設定し、エラー発生時に確実に通知を受け取れるようにしてください。

Overview

Cloud Exchangeにおける重大なエラーをお客様にお知らせするため、Slack通知プラグインを導入しました。これにより、Cloud Exchangeモジュールのいずれかでエラーが発生するたびに、リアルタイムのアラートをSlackチャンネルに直接受信できます。特定のモジュールに合わせたビジネスルールを設定することで、関連するエラーのみが通知をトリガーするようにすることができ、問題の監視と迅速な対処が容易になります。

Slack設定用通知機能

プラグインを新規インストールする場合は、チケットオーケストレーター用通知プラグインのドキュメントに記載されている手順に従って、Slack通知プラグインを設定してください。完了したら、このドキュメントを参照してビジネスルールを設定してください。既にNotifierを設定済みであれば、このドキュメントの手順に従って既存のビジネスルールを編集できます。各Cloud Exchangeモジュールのビジネスルールを設定する方法は以下のとおりです。