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

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

• /en/ Cloud Exchange -kb-articles#prerequisite-for-ha-deployment-on-linux/
• /en/ Cloud Exchange -kb-articles#prerequisite-for-ha-deployment-on-linux

前提条件

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ストレージをマウントする

1. NFSファイル共有の概要ページへ移動してください。
   
2. マウントパスに記載されているようにマウントディレクトリを作成します（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の設定です。
     
3. このコマンドを実行してください。

   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

1. 各ノードで、Podman Compose HA構成ファイルを編集してCSVインデックス作成を有効にします。

   $ vi podman-compose-ha.yml

2. コアセクションを見つけて、ネットワークイベントストリーミングを有効にするために、次の環境変数を追加してください。

   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タグを更新します

1. NFSストレージに移動します。
2. .envファイルを編集します:

   $ vi config/.env

3. 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開始する

1. プライマリ ノードで開始スクリプトを実行します。

   $ sudo ./start

2. 次のステップに進む前に、移行完了メッセージが表示されるまでお待ちください。

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

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

$ sudo ./start

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

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

ユーザーは、マシンの再起動時に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導入タイプを特定する方法は複数あります。

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

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

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

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

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

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

前提条件

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

   重要

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

   注記

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

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

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

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

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

1. 先に進む前に、すべての前提条件が満たされていることを確認してください。これらの要件を事前に確認しておくことは、プロセス中に発生する可能性のある問題を回避するために不可欠です。
2. 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

3. If you have made any local changes to the docker-compose.yml file, reset those using (you might need sudo).

   sudo git reset --hard

4. Cloud Exchange v5.0.1 をご確認ください。

   sudo git checkout v5.0.1

5. 最新の変更を取り込む。

   sudo git pull origin v5.0.1

6. セットアップスクリプトを実行してください。

   sudo python3 ./setup

7. Cloud Exchangeを起動します。

   sudo ./start

8. チェックアウトCloud Exchangeメイン
   

   sudo git checkout main

9. Cloud Exchangeのブラウザインスタンスをすべて閉じ、シークレットモードで再度ログインするか、ログインする前にブラウザのキャッシュをクリアしてください。

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

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

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

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

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

前提条件

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

   重要

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

   注記

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

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

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

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

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

1. 先に進む前に、すべての前提条件が満たされていることを確認してください。これらの要件を事前に確認しておくことは、プロセス中に発生する可能性のある問題を回避するために不可欠です。
2. 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

3. If you have made any local changes to the docker-compose.yml file, reset those using (you might need sudo).

   sudo git reset --hard

4. Cloud Exchange 5.1.1 を確認してください。

   sudo git checkout 5.1.1

5. 最新の変更を取り込む。

   sudo git pull origin 5.1.1

6. セットアップスクリプトを実行してください。

   sudo python3 ./setup

7. Cloud Exchangeを起動します。

   sudo ./start

8. チェックアウトCloud Exchangeメイン
   

   sudo git checkout main

9. Cloud Exchangeのブラウザインスタンスをすべて閉じ、シークレットモードで再度ログインするか、ログインする前にブラウザのキャッシュをクリアしてください。

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

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

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

1. 先に進む前に、すべての前提条件が満たされていることを確認してください。これらの要件を事前に確認しておくことは、プロセス中に発生する可能性のある問題を回避するために不可欠です。
2. cloudexchangeディレクトリに移動し、スタンドアロンデプロイメントを停止してください。

   cd /opt/cloudexchange/cloudexchange 
   sudo ./stop

3. 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

4. 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

5. 情報源を更新してください。

   sudo apt update

6. Cloud Exchangeをアップグレードし、処理が完了するまでお待ちください。

   sudo apt install cloud-exchange=5.1.1-2

   注記

   ステップ7を実行する前に、対象バージョンに必要なすべての前提条件が満たされていることを確認してください。

7. 以下のコマンドでセットアップスクリプトを実行してください。

   sudo python3 ./setup

8. 以下のコマンドを使用して開始スクリプトを実行します。

   sudo ./start

9. Cloud Exchangeのブラウザインスタンスをすべて閉じ、シークレットモードで再度ログインするか、ログインする前にブラウザのキャッシュをクリアしてください。

   Cloud Exchange UI は現在、システムの IP アドレスを使用してアクセスできます: http(s):// <ip> 。

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

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

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

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

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 ビジネスルールによって、共有されるデータが決まります。脅威データ内の特定のフィールドに基づいて、これらのルールをカスタマイズできます。ビジネスルールの例を以下に示します。

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

推奨交換部品

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

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

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

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

注記

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

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

Summary:

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

For the configuration/migration of Microsoft Azure Log Analytics Workspace plugin, please refer to the following documentation Microsoft Azure Log Analytics Plugin for Log Shipper

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

何が変わるのか？

マイクロソフトは、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廃止前にご自身のペースで移行を進めることができます。

推奨される行動

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

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

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

比較概要

よくある質問

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プラグインの設定に関する詳細については、こちらのドキュメントを参照してください。

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,..."

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

Prerequisities

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

Generate a new V2 token with RBAC V3

1. Netskopeテナントにログインして、 Settings .
   にアクセスしてください。
2. Administrationをクリックしてオプションを展開してください。
   
3. Click Administrators & Roles.
   
4. Service Accountをクリックしてください。
5. 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.
6. このモーダルポップアップが閉じられるとトークンは利用できなくなりますので、必ずコピーしておいてください。

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

この記事では、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の再起動を含みます。

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>)。

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

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

Validate Pull Historical Data

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

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

Important Notes:

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

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

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

Example

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

<14>September 15 08:19:45 netskopece CEF:0|Netskope|TESTs|NULL|audit|NULL|High|auditLogEvent=Deleted Inline Policy auditType=admin_audit_logs suser=[EMAIL_ADDRESS] timestamp=1747298327

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

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

Steps to Update the Mapping File

1. Cloud ExchangeでLog Shipperモジュールに進みます。
2. SIEMプラグインを一時的に無効にしてください。
3. 現在SIEMプラグインによって使用されているマッピングファイル名を確認してください。
4. Settings > Log Shipper > Mappingへ移動してください。
5. マッピングファイルを見つけて、 CloneまたはEditを選択します（既にカスタム設定になっている場合）。
6. マッピングエディタで、 Events > Audit > Extensionに移動します。 
7. 以下の項目を追加してください:「支援データ」「詳細」
8. マッピングファイルへの変更を保存します。
9. SIEMプラグインの設定画面に戻る：
10. 更新してください 変更されたマッピングファイル。
11. 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 ドキュメント」を参照してください。

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プラグインでログソース識別子を設定します。

1. Cloud Exchange UI内のSyslogプラグイン設定にアクセスし、Configuration Parametersの Log Source Identifier というフィールドを見つけてください。
2. ログソースに基づいてカスタム名または識別子（例： 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ログの管理性と監視性を向上させることができます。

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

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

移行手順

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

1. Locate the Banner: プラグインリポジトリのページにアクセスしてください。GAバージョンが利用可能であることを示すnotification bannerを探して特定します。

   

2. Initiate Migration: 通知バナー内に表示されているMigrate pluginをクリックしてください。

   

3. Select the Plugin: 利用可能なプラグインのリスト(新しいGAバージョンを含む)が表示されます。 移行したいプラグインの GA versionをSelectしてください。
4. Confirm and Save: Saveをクリックしてください。

   

5. Migration Process: システムは今、古いベータプラグインから新しいGAプラグインへの設定移行を開始します。

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

この記事では、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. 既存のプラグインとそのプラグインに割り当てられているデータを削除します。
   
2. ◇ 新しいプラグインを設定し、エージング基準「1」を設定します。

   

3. 今後は、ソースコードから削除されたすべてのIoC（侵害指標）は、1日以内にCloud Exchangeでも期限切れとしてマークされます。
4. その後、Cloud Exchangeから期限切れのIoCを削除する設定を有効にできます。そのためには、以下の手順に従ってください。
5. Cloud Exchangeで Settings > Threat Exchangeに行き、 Delete Inactive IoC(s) Indicatorsを有効にして Saveをクリックします。

   

6. 今後は、ソースコードから削除されたすべてのIoC（侵害指標）は、1日後にNetskopeからも自動的に削除されます。

   

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

Overview

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

Slack設定用通知機能

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

Cloud Exchangeプラットフォームのエラー

このセクションでは、特定のモジュールに関係しない一般的なCloud Exchangeプラットフォームのエラーについて説明します。 これらのエラーには、システム全体の問題が含まれる可能性があります。

Steps to Configure the Business Rule

1. Cloud Exchange では、Cloud Exchange モジュール (Ticket Orchestrator など) に移動して Business Rulesをクリックし、ビジネス ルールを作成または既存のビジネス ルールを編集します。
2. 表示されているようにルールを編集してください。
   
3. Saveをクリックしてください。

ログシッパーモジュールのエラー

このセクションでは、 Cloud Exchange環境におけるログシッパーモジュールに特有のエラーについて説明します。 このモジュールに関連して発生したエラーはすべて、Slackに通知されます。

Steps to Configure the Business Rule

1. Cloud Exchangeで、 Log Shipper > Business Rulesに移動して、ビジネスルールを作成または既存のビジネスルールを編集します。
2. 表示されているようにルールを編集してください。
   
3. Saveをクリックしてください。

チケットオーケストレーターモジュールのエラー

このセクションではCloud Exchange環境におけるチケットオーケストレーターモジュールに特有のエラーについて説明します。 このモジュールに関連して発生したエラーはすべて、Slackに通知されます。

Steps to Configure the Business Rule

1. Cloud Exchangeで、「チケットオーケストレーター」>「ビジネスルール」に移動し、ビジネスルールを作成または既存のビジネスルールを編集します。
2. 表示されているようにルールを編集してください。
3. 完了したらルールを保存してください。

脅威交換モジュールのエラー

このセクションでは、 Cloud Exchangeプラットフォーム全体での脅威インテリジェンスの共有を管理する Threat Exchange モジュールに焦点を当てます。 このモジュールでエラーが発生すると、セキュリティ関連の問題について通知が送信されます。

Steps to Configure the Business Rule

1. Cloud Exchangeで、 Threat Exchange > Business Rulesに移動して、ビジネスルールを作成または既存のビジネスルールを編集します。
2. 表示されているようにルールを編集してください。
   
3. Saveをクリックしてください。

リスク交換モジュールのエラー

このセクションではCloud Exchange環境におけるリスクエクスチェンジモジュールに特有のエラーについて説明します。 このモジュールに関連して発生したエラーはすべて、Slackに通知されます。

Steps to Configure the Business Rule

1. Cloud Exchangeで、 Risk Exchange > Business Rulesに移動して、ビジネスルールを作成または既存のビジネスルールを編集します。
2. 表示されているようにルールを編集してください。
   
3. Saveをクリックしてください。

キュー構成

キューの設定は、適切なフィールドをマッピングできる重要なステップです。

Map Fieldsこのセクションでは、アラートと通知の間で値をマッピングできます。アラート属性には、 カスタムメッセージフィールドの「$」記号からアクセスできます。

例えば、以下のスクリーンショットでは、$errorCode、$alertType、および$messageの値をマッピングしています。その結果、Slackで通知を受け取った際には、ここに記載された情報が表示されます。

キュー構成でフィールドをマッピングします。

例えば、 Event TypesとAlert Typesフィールドを空のままにしてプラグインを保存しようとすると、エラーが発生します。このエラーが発生すると、Slackに通知が送信されます。

CLSモジュールで発生したエラーを確認しました。

Slackに通知が送信されました。

Cloud Exchangeエラーコード

以下は、さまざまなCloud Exchangeエラーコードの詳細な解説を提供するセクションへのリンクです。 これらのセクションではCloud Exchange内のさまざまなモジュールに関連する特定のエラーコードについて説明し、各エラーの種類とその原因について詳細な解説を提供します。

• Cloud Exchangeプラットフォームのエラー コード
• ログシッパーモジュールのエラーコード
• チケットオーケストレーターモジュールのエラーコード
• 脅威交換モジュールのエラーコード
• リスク交換モジュールのエラーコード

既存のクライアントステータスを削除するには、以下の手順に従ってください。

1. Settings > Toolsへ移動してください。
2. REST API V2をクリックしてください。
3. API Documentationをクリックしてください。

   

4. APIドキュメントを開いたら、 Authorizeをクリックする必要があります。

   

5. 認証には REST API V2 トークンを使用します。
6. Now search for the Create a new Iterator endpoint and click Try it now.
7. Provide any name for Iterator and for eventtype, select create a client status event iterator.

   

8. Executeをクリックしてください。
9. クライアントの状態が既に作成されている場合は、イテレータの名前が取得されます。

   

10. この名前をコピーしてdelete an existing iteratorに移動し、 Try it nowをクリックしてください。
11. コピーしたイテレータの名前を貼り付けて、 Executeをクリックしてください。
12. サーバーからの応答を確認し、イテレータが正常に削除されたことを確認してください。

以下の表は、SIEM/SOARで受信したクライアントステータスイベントフィールドとNetskopeポータル内の対応するイベントを関連付けるのに役立つマッピングの詳細を示しています。

Summary: 既存のCTO HaloITSMプラグインを最新バージョン（v2.0.0）にアップグレードする場合、新しいバージョンには以前のバージョンには存在しなかった構成パラメータが含まれているため、プラグインのワークフローが破損する可能性があります。その結果、ユーザーはアップグレード中にプラグインを保存できなくなる可能性があります。以下の回避策を実行してアップグレードを完了し、既存のプラグイン ワークフローを復元してください。

Issue

以前のCTO HaloITSMプラグインバージョンからアップグレードした後、更新されたバージョンでは設定パラメータが変更されているため、ユーザーはプラグインを保存できない場合があります。アップグレード処理中にプロンプトが表示されたらSkipを選択してアップグレードを完了させ、その後プラグインの設定を編集してください。

回避策

1. プラグインのアップグレード中に、プロンプトが表示されたらSkipを選択してください。

   

2. Pluginsページに移動して、アップグレードされたCTO HaloITSMプラグインを編集してください。

   

3. 必要な認証情報を入力し、 Nextをクリックしてください。

   

4. 必要なチケットの種類Select 、 Saveをクリックしてください。
   Important: チケットの種類を変更するには、ユーザーはConfiguration Parametersタブからプラグインを保存する必要があります。ユーザーがチケットの種類を更新し、 Mapping Configuration 、 Authentication 、またはBasic Informationタブからプラグインを保存した場合、変更は反映されません。

   

5. Enable the plugin.

マッピング構成ガイダンス

マッピング設定は、CTO HaloITSMプラグインバージョン2.0.0で導入されました。このタブを使用して、 Netskope Cloud ExchangeフィールドをHaloITSMのフィールドにマッピングします。

デフォルトのマッピング設定を維持したい場合は、 Configuration Parametersタブからプラグインを保存してください。

この記事では、Netskopeのアラートやイベントを複数のサードパーティ宛先(Syslog、QRadarなど)とシームレスに共有するためのCloud Exchangeを設定するために必要なエンドツーエンドワークフローを概説します。

システム要件を確認する

設定を始める前に、Cloud Exchangeの導入がマルチデスティネーションを円滑に処理するためのシステム要件を満たしているか確認してください。

具体的なハードウェアおよびリソースの指標については、システム要件に関するドキュメントを参照してください。

Configure the Netskope Tenant

NetskopeテナントをCloud Exchangeに接続して、プライマリのデータ接続を確立しましょう。

テナントクレデンシャルとAPIアクセスの設定については 、テナントプラグインガイド を参照してください。

Netskopeログ発送者プラグインの設定

Log Shipperプラグインを設定して、テナントからデータを始めるようにしてください。

詳細な設定手順については、ログシッパープラグインのガイドを参照してください。

宛先プラグインの設定

ログを送信したい各サードパーティプラットフォームごとにプラグインを設定してください例えば、SyslogとQRadarの両方にアラートとイベントを取り込みたい場合は、Cloud Exchange内でそれぞれのプラグインを設定しなければなりません。

サポートされている各ベンダーの具体的な実装ガイドについては、 「サードパーティ製宛先プラグイン」の記事を参照してください。

ビジネスルールの設定

組織のコンプライアンスや運用要件に応じてデータをフィルタリングするビジネスルールを設定しましょう。

• 特定の基準に合わせてカスタマイズしたビジネスルールを設計できます。
• あるいは、使うデフォルトのビジネスルールを使えば、フィルターなしで利用可能なアラートやイベント All 共有できます。

ロジック作成の手順については、 「ビジネスルール」の記事を参照してください。

ログ配信の設定

最後のステップは、ログ配信を設定することで、ログソース、宛先プラグイン、およびビジネスルールを連携させることです。

ログ取り込みワークフローを起動するには「 ログ配信」の記事 を参照してください。

Summary

Cloud Exchange(CE)EDMモジュールは、CSVやDBなどに保存された生のデータ取得、ハッシュ生成、そしてExact data MatchデータをNetskopeテナントにアップロードするためのエンドツーエンドソリューションを提供します。専用プラグインを通じて複数のソースタイプから顧客データを取得することが可能です。これにはLinuxファイルシェアサーバー(SFTP経由)、MySQLやOracleデータベース、SMBベースのファイル共有などが含まれます。

CEは、インターバルベースのプラグインライフサイクルタスクを通じて、データプル、ハッシュ生成、アップロードを単一のパイプラインで自動化します。 ソースに新しく追加されたレコードは、設定されたプラグインの間隔に従って、テナントに自動的に反映されます。プラグインのライフサイクルタスクをオンデマンドで実行するための手動同期オプションも用意されており、即時更新が必要な場合に利用できます。CE EDMモジュールは、引き取ったデータに対するサニタイズ、正規化、引用の削除、ストップワードの削除などのカスタマイズもサポートしています。

Performance Results

以下のレコードは、EDMモジュールの機能と性能を検証するために使うしました。

Detailed Performance Results

以下の表は、EDM処理時間を示しています。この処理時間は、EDMプラグインの設定オプション（サニタイズ、正規化、辞書作成、ストップワード除去など）によっても異なり、複数の列にわたって変化します。

Performance Results with Plugin Configuration

Guidance

上記の数値はCloud Exchange(CE)EDMモジュールのパフォーマンスベンチマークです。CEは、EDMモジュールを介して最大100万件のレコードのハッシュ生成とアップロードをサポートしています。もしデータセットが100万行を超える場合は、DLPxハッシュ生成スクリプト+Pythonアップロードスクリプトベースのソリューションを使います。詳細は ローカルハッシュ生成 を参照してください。

Term Definitions

• Remove Quotes: CSVファイル内のフィールド値が二重引用符で囲まれている場合（例えば、値にカンマが含まれている場合）に有効にします。引用符で囲まれたフィールドは単一の列として解析されます。引用符の位置が不適切だと、行がスキップされる可能性があります。
• Sanitization (Columns): ハッシュ生成前に、選択された列を検証およびクリーニングします。セルは、文字が1文字しかない場合、数字が含まれている場合、ストップワードに一致する場合（「ストップワードの削除」が有効になっている場合のみ）、または英数字以外の文字が含まれている場合（これらの文字は削除されます）に無効とマークされます。（デフォルト：なし）
• Remove Stopwords: 有効にすると、ストップワードリストの単語に一致するセルは、サニタイズ処理中に無効としてマークされます。
• Normalization (Columns): ハッシュ生成前に選択された列の値を標準化し、ソースデータの細かなフォーマットの違いで有効なマッチを見逃さないようにします。文字列列はタイトルケースに変換されます(例:JOHN DOEがJohn Doeに変わる);数字列はダッシュ、ドット、スペースが削除されています(例:123-45.678は12345678になります)。（デフォルト：なし）
• Dictionary Creation (Columns): 選択された列の一意値の辞書を作成し、 Netskope テナントのDLPルールで使うすることができます。 （デフォルト：なし）
• Proceed Without Sanitization: チェックされなければ、すべてのデータはハッシュ生成に含まれます。確認すると、ハッシュ生成のために使うとなるのはサニタイズを通過したデータ(「良いファイル」コンテンツ)だけです。

この記事では、既存のワークフローをCloud Exchange内で URL Lists から Destination Profiles へ移行するための指針を提供します。既存の使うケースを維持しつつ移行プロセスを概説し、バージョン6.1.0の既知の制限に関する重要な考慮事項 Cloud Exchange 強調しています。

この例では、既存のSIEM統合使う Anomali ThreatStream XDRが、IoCsを Netskope URLリストに共有するよう設定されています。 この記事では、このワークフローを使う Destination Profiles に移行する方法を紹介しています。

既存の構成例

この例では、現在の環境は以下の構成になっています。

Cloud Exchangeで設定されたプラグイン

既存のビジネスルール

現在、以下のようなビジネスルールが存在します。

• Anomali ThreatStream XDRからIoC（侵害指標）を受信します。
• Netskopeへの共有に必要なIoCタイプをフィルタリングします。

既存の共有設定

現在の共有設定では、以下の動作が実行されます。

• 受信した IoC を、Crest PS URL Listという名前の既存の URL リストにプッシュします。

現在のワークフローは以下の通りです:

Anomali ThreatStream XDR → Business Rule → Sharing Configuration → Netskope URL List

URLリストを宛先プロファイルに移行する手順

既存のURLリストワークフローをDestination Profileに移行するには、以下の手順に従ってください。

既存のビジネスルールのコピーを作成する

既存のプラグインとワークフローがすでに設定されているため:

1. 脅威交換で、 Business Rulesに移動します。
2. URLリスト共有に関する既存のビジネスルール「使う」を見つけてください。
3. ルールのCopyアイコンをクリックしてください。
4. 重複したルールに新しい名前を付けます。
5. 新しく作成したビジネスルールを保存します。

既存のビジネスルールのコピーを作成することで、移行時に現在の本社ワークフローに影響を及ぼすことを避けられます。

宛先プロファイル用の新しい共有構成を作成する

使う 新たに作られたビジネスルール:

1. Sharingへ移動してください。
2. 新しい共有設定を作成します。
3. Select 新たに作られたビジネスルールです。
4. Target下で、 Add to Destination Profileを選択してください。
5. 以下の選択肢から1つをSelect 。
   • 既存の目的地プロファイルを選択してください
   • 新しい Destination プロファイルを作成するSelect Create New Profile
6. 共有設定を保存します。

更新されたワークフローは今後、以下のようになります。

Anomali ThreatStream XDR → New Business Rule → New Sharing Configuration → Netskope Destination Profile List

References

NetskopeのLog Shipper(CLS)モジュールを使うマッピングファイル内に Cloud Exchange 含め、どのイベントフィールドをSIEMプラットフォームに転送するかを決定します。 デフォルトのマッピングファイルは最も一般的な使うフィールドを含むように設計されていますが、 Netskope テナントに保存された元のイベントデータで利用可能なすべてのフィールドを含むとは限りません。

その結果、ユーザーはNetskopeイベントや監査UIには特定のフィールドが見えるものの、SIEMが受信するログには存在しないことに気づくことがあります。ほとんどのケースでは、このフィールドがデフォルトのLog Shipperマッピングファイルに含まれていないために起こります。

例

ユーザーはSIEMログで特定のイベントフィールド(例えばポリシー属性、ユーザー属性、メタデータフィールド)を検索しています。このフィールドはNetskopeテナント内の対応するイベントでは表示されますが、SIEM出力には現れません。

これは、当該フィールドがソースイベントに存在するものの、現在Log Shipperによってエクスポート用にマッピングされていないことを示しています。

解決策：マッピングファイルに必須フィールドを追加する

SIEMに送信されるログにイベントフィールドを追加するには、カスタムマッピングファイルを作成または変更し、必要なフィールドを追加します。マッピングを更新した後、SIEMプラグインを設定してカスタマイズしたマッピングファイルを使うします

マッピングファイルを更新する手順

1. Cloud ExchangeでLog Shipperに行ってください。
2. 一時的にSIEM Pluginを無効にします。
3. 現在SIEMプラグインに割り当てられているマッピングファイルを特定します。
4. Settings > Log Shipper > Mappingへ移動してください。
5. マッピングファイルを見つけて、 Clone (推奨)またはすでに使うカスタムマッピングをしている場合は Edit を選択します。
6. 転送するログに対応するカテゴリ（例：アラート、イベントなど）に移動してください。

   

7. 特定のログタイプに移動し、 拡張機能 メニューを展開します。

   

8. 拡張機能メニューの一番下に行き、Addをクリックしてください。 SelectNetskopeフィールドドロップダウンから追加したい必要欄メニュ。SIEMでの識別に必要なフィールド名を指定してください。Save .
   をクリックしてください。

   

9. SIEM Plugin設定に戻ります。
10. Select 新たに作成されたまたは更新されたマッピングファイルです。
11. Re-enable the SIEM Plugin.

Result

更新されたマッピングが適用されると、新たに転送されたログには追加のフィールドが含まれ、SIEMプラットフォーム内でそれらを検索、解析、相関させることが可能になります。

注記

• マッピング変更後に生成された新しいイベントのみが新たに追加されたフィールドを含みます。以前に転送されたログは、遡って更新されません。
• Netskopeテナント内の元のイベントデータに、追加したいフィールドが存在していることを確認してください。ソースイベントに該当フィールドが存在しない場合、ログシッパーのマッピングを通じてエクスポートすることはできません。
• 必要なフィールドがマッピングのドロップダウンにない場合は、表示ラベルの代わりに使うそのバックエンドフィールド名を検索してください。

参考例

1. イベント詳細に表示されているフィールドと、利用可能なマッピングフィールドを比較してください。

   

2. フィールドが見つからない場合は、SkopeITでフィールド名にカーソルを合わせると、バックエンドのフィールド名が表示されます。

   

3. マッピングフィールドの検索ボックスでバックエンドフィールド名を検索し、適切なフィールドを選択してください。