Cette section explique comment configurer un environnement de haute disponibilité (HA) pour Cloud Exchange sur des nœuds Linux en utilisant Azure Blob Storage comme NFS (Network File System) pour le stockage partagé.

La configuration requise pour Cloud Exchange est disponible à l'adresse suivante

• /en/cloud-exchange-kb-articles#prerequisite-for-ha-deployment-on-linux/
• /en/cloud-exchange-kb-articles#prerequisite-for-ha-deployment-on-linux

Conditions préalables

Configuration requise pour les nœuds HA

• 16 CPU CORES (série F16s à forte intensité de calcul)
• 32 GO DE RAM
• 120 Go Espace disque disponible où CE sera installé ; par exemple : /home/root/
• 20 Go d'espace libre sur /var/lib pour le stockage des conteneurs.

Configuration de NFS avec Azure Blob Storage

Consultez la page : https://learn.microsoft.com/en-us/azure/storage/files/storage-files-quick-create-use-linux#create-an-nfs-azure-file-share

Configuration du réseau

Les machines Linux seront traitées comme des nœuds HA, et tous les nœuds ainsi que les comptes de stockage doivent se trouver dans le même réseau/sous-réseau virtuel et la même région/zone Azure.Après avoir configuré les partages de fichiers NFS, reportez-vous aux étapes ci-dessous pour monter le partage NFS.

Configurer Cloud Exchange High Availability (HA)Valider les prérequis

• Vérifiez les ports requis : Assurez-vous que les ports suivants sont ouverts et disponibles sur chaque nœud :
  

  4369	Port de communication RabbitMQ
  5672	AMQP Communication PORT
  15672	Console d'administration RABBITMQ
  25672	Port interne RabbitMQ
  35672	Utilisé pour les communications CLI
  27017	MongoDB Port
  443	Bilan de santé des services

• Configuration du réseau : Le réseau virtuel doit être unique pour tous les nœuds.
• Validez la RAM, l'espace disque et le CPU.

  sudo df -h
  sudo free -h
  sudo nproc

• Paquet Git, paquet curl et paquet zip :

  sudo yum install -y git curl zip

• Install nfs-utils.

  sudo yum install -y nfs-utils

• Python3 avec pip.

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

• Podman et podman-compose (Réf : 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

• Vérifiez la version de Podman et de podman-compose :

  podman-compose —-version
  podman –-version

• Paquets python requis :

  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

Configurer NFS dans Azure Blob Storage

Consultez la page : https://learn.microsoft.com/en-us/azure/storage/files/storage-files-quick-create-use-linux#create-an-nfs-azure-file-share

Monter le stockage NFS dans chaque nœud

1. Accédez à la page NFS File Share Overview (Présentation du partage de fichiers NFS).
   
2. Créez un répertoire de montage comme indiqué dans le chemin de montage (également disponible dans le guide de présentation du partage de fichiers NFS) à l'aide de cette commande :

   sudo mkdir -p <mount_path>

   
   Modifiez le fichier /etc/fstab et la configuration montée comme indiqué ci-dessous :
   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 sera le répertoire NFS source présent dans le partage de fichiers NFS Azure Blob Storage, qui sera obtenu à partir de commandes d’exemple présentées à domicile > compte de stockage respectif > partages de fichiers > partage de fichiers NFS nouvellement créé > Aperçu général.
   • /mount/cestorageha/shared-storage-nfs Il s'agira du chemin de montage et du répertoire créé.
   • L'autre partie restante est la configuration NFS.
     
3. Exécutez cette commande :

   sudo mount -a

Téléchargez le paquet d'installation

Sur chaque nœud, téléchargez le paquet d'installation de Cloud Exchange à l'aide de cette commande :

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

Exécutez le script d'installation sur le nœud primaire

Allez dans le répertoire Cloud Exchange. Sur le nœud principal, exécutez le script d'installation à l'aide de cette commande :

sudo ./setup

Exécutez le script d'installation dans les nœuds secondaires

Sur chaque nœud secondaire, accédez au répertoire Cloud Exchange. Exécutez le script d'installation à l'aide de la commande suivante, en remplaçant <mounting_dir> par le chemin d'accès à votre répertoire de montage NFS :

sudo ./setup --location <mounting_dir>

Enable the CSV index

1. Sur chaque nœud, modifiez le fichier de configuration de Podman Compose HA pour activer l'indexation CSV :

   $ vi podman-compose-ha.yml

2. Localisez la section core et ajoutez la variable d'environnement suivante pour activer le streaming d'événements réseau :

   ITERATOR_EVENT_NETWORK=stream_network_events_rollsroyce

Mettez à jour les balises RabbitMQ et MongoDB

• RabbitMQ :

  index.docker.io/

  Pour chaque nœud, ouvrez le fichier podman-compose-ha.yml.

  $ vi podman-compose-ha.yml

  Mettez à jour les balises d'image des services RabbitMQ et MongoDB comme suit :

• MongoDB:

  index.docker.io/

Mise à jour des balises Core et UI

1. Accédez au stockage NFS.
2. Modifiez le fichier .env:

   $ vi config/.env

3. Mettez à jour les variables CORE_TAG et UI_TAG comme suit.

   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

Sur chaque nœud, créez une sauvegarde du fichier podman-compose-ha.yml:

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

Démarrer Cloud Exchange sur le nœud primaire

1. Exécutez le script de démarrage sur le nœud principal :

   $ sudo ./start

2. Attendez le message " Migration terminée" avant de passer à l'étape suivante.

Démarrer Cloud Exchange sur les nœuds secondaires

Après avoir reçu le message Migration completed dans le nœud principal, exécutez le script de démarrage dans les autres nœuds.

$ sudo ./start

Téléchargez et configurez le plugin Azure Sentinel

1. Allez sur Settings > Plugin Repository dans CE et cliquez sur le bouton upload plugin (⬆).
2. Select le fichier Zip qui est partagé dans le dossier d'assistance et cliquez sur le bouton de téléchargement.
   
3. Une fois le plugin téléchargé avec succès, allez dans Settings > plugins pour configurer le plugin téléchargé avec la version 3.0.2.
   

Les utilisateurs peuvent suivre les étapes suivantes pour démarrer automatiquement les conteneurs podman de Cloud Exchange au redémarrage de la machine.

Créer un fichier de service systemd

Créez un fichier de service New systemd pour Cloud Exchange à l'aide d'un éditeur de texte comme nano ou vim.

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

2. Add the Service Configuration

Collez la configuration suivante dans le fichier. 

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

Enregistrez le fichier et quittez l'éditeur.
Si vous utilisez nano, appuyez sur Ctrl+X, puis sur Y et Enter.
Si vous utilisez VIM, appuyez sur ESC, puis sur :wq ! et Enter.

3. Save and Reload systemd

Rechargez le démon systemd pour qu'il prenne connaissance du fichier de service New.

$ sudo systemctl daemon-reload

4. Enable the Service

Activez le service pour qu'il démarre automatiquement à chaque démarrage.

$ sudo systemctl enable netskope-cloud-exchange.service

Vous devriez voir une confirmation qu'un lien symbolique a été créé.

Maintenant, lorsque la machine redémarre, elle exécutera le script de démarrage de Cloud Exchange.

There are multiple ways to identify the current Cloud Exchange deployment type:

1. Using the Cloud Exchange UI
   • On the Cloud Exchange home page, go to System Status > System Specifications and check the Deployment Type and Flavor fields. Explore the Dashboards – Netskope Knowledge Portal

2. Using the .env file
   • Navigate to the CE working directory and run the following command:
     grep '^CE_AS_VM=' .env
    
   • If the output is CE_AS_VM=False, the deployment type is Containerized Deployment.
    
   • If the output is CE_AS_VM=True, the deployment type is Cloud Exchange as a VM Deployment (CEasVM).

3. Checking the SSH username
   • If you are using the cteadmin user, the deployment type is Cloud Exchange as a VM Deployment (CEasVM).
    
   • If you are using any username other than cteadmin, the deployment type is Containerized Deployment.
 
4. Checking the CE working directory
   • If the CE working directory is /opt/cloudexchange/cloudexchange, the deployment type is Cloud Exchange as a VM Deployment (CEasVM).
    
   • If the working directory is different from /opt/cloudexchange/cloudexchange, the deployment type is Containerized Deployment.

Utilisez la méthode de mise à niveau si la machine hôte/le système d'exploitation est inchangé, et si vous disposez d'une connectivité GitHub et docker hub pour obtenir le dernier paquet de mise à niveau.

Si la machine hôte est modifiée, vous devez utiliser la méthode de migration. Actuellement, si vous souhaitez utiliser CE en tant que VM, seule la migration est prise en charge puisque vous allez déployer les machines hôtes New via OVA/AMI/VHDX. Si vous passez du mode autonome au mode HA, vous devez également utiliser la méthode de migration car vous devrez configurer plusieurs machines hôtes conformément aux exigences du mode HA.

Veillez à effectuer une sauvegarde avant de procéder à la mise à niveau.

Conditions préalables

1. Avant d'initier une mise à niveau ou une migration, assurez-vous que votre instance répond aux exigences du système pour Cloud Exchange.
2. Assurez-vous d'avoir le mot de passe de maintenance à portée de main, car il sera nécessaire pour effectuer certaines étapes de ce processus.

   Important

   Si le mot de passe de maintenance est perdu, les données ne peuvent pas être conservées.

   Notes

   La migration de HA vers standalone n'est actuellement pas prise en charge. La migration des données de RabbiMQ n'est pas prise en charge en raison du changement de type de file d'attente de Classic à Quorum.

Mise à jour vers la version 5.0.1

Mise à jour vers 5.0.1 Standalone

A partir de 3.x ou 4.x ou 5.0.x Autonome

Vous devez mettre à jour tous vos locataires Netskope avec un jeton V2 qui a accès à tous les points de terminaison dataexport avant de procéder à la mise à niveau.

1. Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
2. Allez dans le répertoire ta_cloud_exchange existant avec le fichier docker-compose.yml. Arrêtez les conteneurs 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. Checkout Cloud Exchange v5.0.1.

   sudo git checkout v5.0.1

5. Téléchargez les dernières modifications.

   sudo git pull origin v5.0.1

6. Exécutez le script d'installation.

   sudo python3 ./setup

7. Lancez Cloud Exchange.

   sudo ./start

8. Checkout Cloud Exchange Main
   

   sudo git checkout main

9. Fermez toutes les instances de votre navigateur Cloud Exchange et connectez-vous à nouveau en mode Incognito, ou effacez le cache du navigateur avant de vous connecter.

L’interface Cloud Exchange est désormais accessible avec l’IP du système : http(s) ://<ip>.

Une fois que votre Cloud Exchange est opérationnel sur la version 5.0.1, vous pouvez procéder à la mise à niveau vers la version 5.1.1 en suivant les étapes recommandées.

Utilisez la méthode de mise à niveau si la machine hôte/le système d'exploitation est inchangé, et si vous disposez d'une connectivité GitHub et docker hub pour obtenir le dernier paquet de mise à niveau.

Si la machine hôte est modifiée, vous devez utiliser la méthode de migration. Actuellement, si vous souhaitez utiliser CE en tant que VM, seule la migration est prise en charge puisque vous allez déployer les machines hôtes New via OVA/AMI/VHDX. Si vous passez du mode autonome au mode HA, vous devez également utiliser la méthode de migration car vous devrez configurer plusieurs machines hôtes conformément aux exigences du mode HA.

Veillez à effectuer une sauvegarde avant de procéder à la mise à niveau.

Conditions préalables

1. Avant d'initier une mise à niveau ou une migration, assurez-vous que votre instance répond aux exigences du système pour Cloud Exchange.
2. Assurez-vous d'avoir le mot de passe de maintenance à portée de main, car il sera nécessaire pour effectuer certaines étapes de ce processus.

   Important

   Si le mot de passe de maintenance est perdu, les données ne peuvent pas être conservées.

   Notes

   La migration de HA vers standalone n'est actuellement pas prise en charge. La migration des données de RabbiMQ n'est pas prise en charge en raison du changement de type de file d'attente de Classic à Quorum.

Upgrade to 5.1.1 Containerized

Upgrade to 5.1.1 Containerized Standalone

From 5.0.1 or 5.1.0 Standalone

Vous devez mettre à jour tous vos locataires Netskope avec un jeton V2 qui a accès à tous les points de terminaison dataexport avant de procéder à la mise à niveau.

1. Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
2. Allez dans le répertoire ta_cloud_exchange existant avec le fichier docker-compose.yml. Arrêtez les conteneurs 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. Checkout Cloud Exchange 5.1.1.

   sudo git checkout 5.1.1

5. Téléchargez les dernières modifications.

   sudo git pull origin 5.1.1

6. Exécutez le script d'installation.

   sudo python3 ./setup

7. Lancez Cloud Exchange.

   sudo ./start

8. Checkout Cloud Exchange Main
   

   sudo git checkout main

9. Fermez toutes les instances de votre navigateur Cloud Exchange et connectez-vous à nouveau en mode Incognito, ou effacez le cache du navigateur avant de vous connecter.

L’interface Cloud Exchange est désormais accessible avec l’IP du système : http(s) ://<ip>.

Une fois que votre Cloud Exchange sera opérationnel avec la version 5.1.1, Vous pouvez procéder à la mise à jour ou à la migration vers la dernière version en suivant les étapes recommandées de mise à niveau et de migration .

Veillez à effectuer une sauvegarde avant de procéder à la mise à niveau.

1. Avant de poursuivre, assurez-vous que toutes les conditions préalables ont été remplies. Il est essentiel de vérifier ces exigences à l'avance afin d'éviter tout problème potentiel au cours du processus.
2. Allez dans le répertoire CloudExchange et arrêtez le déploiement autonome.

   cd /opt/cloudexchange/cloudexchange 
   sudo ./stop

3. Chargez la clé publique de Cloud Exchange en tant que clé GPG de confiance. Notez que lors de la mise à niveau d'un déploiement autonome vers un déploiement à haute disponibilité (HA), le nœud autonome existant servira de nœud principal dans la configuration 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. Ajoutez une URL s3 comme source du paquet deb.

   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. Mettez à jour les sources.

   sudo apt update

6. Mettez à jour le site Cloud Exchange et attendez la fin du processus.

   sudo apt install cloud-exchange=5.1.1-2

   Notes

   Avant de lancer l’étape 7, assurez-vous que tous les prérequis sont remplis pour la version ciblée.

7. Exécutez le script de configuration en utilisant la commande ci-dessous.

   sudo python3 ./setup

8. Exécutez le script de démarrage à l'aide de la commande ci-dessous.

   sudo ./start

9. Fermez toutes les instances de votre navigateur Cloud Exchange et connectez-vous à nouveau en mode Incognito, ou effacez le cache du navigateur avant de vous connecter.

   L'interface utilisateur de Cloud Exchange est maintenant accessible avec l'IP du système : http(s)://<ip>.

Une fois votre Cloud Exchange opérationnel sur la version 5.1.1, Vous pouvez procéder à la mise à niveau ou à la migration vers la dernière version en suivant les étapes de mise à niveau et de migration recommandées.

To upgrade Cloud Exchange on a VM from Ubuntu 20.04 to Ubuntu 22.04, perform the steps after meeting the listed prerequisites. The steps will require reboot of Cloud Exchange as VM machine hence plan the upgrade accordingly. The steps are divided into two parts: before reboot and doing the reboot.

Conditions préalables

• Vous devez disposer des privilèges sudo pour exécuter les commandes du script.
• Connectivité Internet pour les URL suivants :
  • Dépôts officiels d'Ubuntu :
    • http://archive.ubuntu.com/ubuntu
    • http://security.ubuntu.com/ubuntu
  • Sources complémentaires :
    • https://download.docker.com/linux/ubuntu
    • https://cloud-exchange-store.s3.us-east-1.amazonaws.com
  • Serveurs de mise à jour de la version Ubuntu :
    • http://changelogs.ubuntu.com
    • http://archive.ubuntu.com
  • Python Package Index (PyPI) :
    • https://pypi.org
    • https://files.pythonhosted.org
  • Les informations d'identification de la racine sont nécessaires pour mettre à niveau le système d'exploitation sous-jacent de 20 à 22. Vous trouverez ci-dessous les informations d'identification de la racine pour l'OVA.
    • Nom d'utilisateur : root
    • Mot de passe : M5#w6V+.T^8gv ?%,

Avant le redémarrage

Configuration du mode non interactif

Le script commence par définir la variable d'environnement afin de s'assurer qu'aucune invite interactive n'interfère avec l'exécution.

cd /opt/cloudexchange/cloudexchange 
sudo ./stop

export DEBIAN_FRONTEND=noninteractive

Désactivation de sources APT supplémentaires

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

Mise à jour et mise à niveau du système

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

Préparation de la mise à jour de la version

sudo apt install -y update-manager-core

Redémarrage du système

sudo reboot

Mise à niveau de la distribution

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

Correction des configurations de paquets incomplètes

sudo apt update 
sudo dpkg --configure -a

Installation des paquets 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"

Réactivation des sources APT et mise à jour finale

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

Redémarrer le système

sudo reboot

If you are using Containerized standalone and migrate to another Containerized standalone deployment.

1. Arrêtez le conteneur.
   • sudo ./stop
2. Créez un fichier zip pour le dossier Cloud Exchange.
   • sudo zip -r ce_backup.zip ta_cloud_exchange
3. Transférez le dossier ce_backup.zip sur la machine New
4. Décompressez le dossier.
   • unzip ce_backup.zip
5. Exécutez le script d'installation.
   • sudo ./setup
6. Démarrez le conteneur.
   • sudo ./start

Netskope ne prendra désormais en charge que les intégrations de détection et de réponse des terminaux avec Netskope Threat Exchange. L’intégration EDR en locataire ne sera plus disponible après le 1er décembre 2025.
Avec l’introduction et l’amélioration continue de Cloud Exchange, il est désormais la plateforme la plus avancée pour l’intégration de l’EDR et du renseignement sur les menaces.
Netskope Cloud Threat Exchange (CTE) fait partie de Cloud Exchange, qui permet de partager facilement et en toute sécurité des données de menaces telles que des URL malveillantes et des hachages de fichiers entre leurs outils de sécurité existants.

Le module Threat Exchange prend en charge les intégrations avec plusieurs fournisseurs de sécurité tiers.

Avec le CTE, nous pouvons envoyer et recevoir automatiquement des données sur les menaces en temps quasi réel, ce qui améliore la protection des points d'extrémité, des pare-feu, des passerelles web et des outils de sécurité en nuage.

Get started with EDR Integrations in Cloud Exchange

1. Pour déployer Cloud Exchange, il vous faudra un système dédié (VM). Cloud Exchange prend en place le déploiement sur plusieurs plateformes. Pour le guide de déploiement, cliquez ici
2. Après le déploiement, vous pouvez accéder à la console web Cloud Exchange où vous pouvez activer le module Cloud Threat Exchange (CTE). Consultez les modules Enable pour plus d’informations.
3. Configurez votre locataire Netskope
4. Commencez à utiliser le module Threat Exchange.

Business Rules in Threat Exchange : Les règles de gestion déterminent quelles données sont partagées. Vous pouvez personnaliser ces règles en fonction de champs spécifiques dans les données relatives aux menaces. Voici un exemple de règle de gestion.

The Illumio plugin for the Threat Exchange Module in Netskope Cloud Exchange will be deprecated around mid-year 2026. Review this document to learn how to retain Illumio support through Risk Exchange.

Recommended Replacement

Users currently leveraging this plugin for their Threat Exchange use cases should migrate to the Illumio plugin for Risk Exchange to maintain functionality.

Workflow Example: Fetching Workloads to Update Private Apps

If you previously used the Threat Exchange Illumio plugin to fetch workloads (IP Addresses, Hostnames) and update them in Private Apps via the Netskope Threat Exchange plugin, follow this new workflow using the Risk Exchange module:

1. Configure the Netskope Risk Exchange plugin. This replaces the Netskope Threat Exchange plugin. The plugin guide is here.
2. Configure the Illumio plugin for Risk Exchange. This replaces the Threat Exchange Illumio plugin. The plugin guide is here.
3. Establish the required configurations for the Add hosts to Private App action from the Risk Exchange plugin to resume your workflow. Details are explained in the aforementioned plugin guides.

Note

The Illumio plugin for Risk Exchange doesn’t support IoC Retraction.

Pour toute question concernant cette migration ou cette workflow, contactez Netskope Support pour plus d’informations.

Microsoft a annoncé la dépréciation des API de collecte de données Azure Monitor pour les journaux personnalisés. Si vous utilisez le plugin Netskope Cloud Exchange Microsoft Azure Sentinel existant, votre configuration dépend de ces API de collecte de données obsolètes et ne restera fonctionnelle que tant que Microsoft continuera à prendre en charge les API sous-jacentes. Vous devriez prévoir de migrer vers le New plugin Microsoft Azure Log Analytics Workspace , qui utilise les dernières API d'ingestion de journaux de Microsoft.

Pour la configuration/migration du plugin Microsoft Azure Log Analytics Workspace, veuillez consulter la documentation suivante : Plugin Microsoft Azure Log Analytics pour Log Shipper.

Consultez l’annonce de dépréciation de Microsoft à partir de là.

Qu'est-ce qui change ?

Microsoft is moving from the legacy Data Collector API model to the newer Log Ingestion API model for custom log ingestion into Azure Monitor Logs and Microsoft Sentinel-backed Log Analytics workspaces.
To align with Microsoft’s supported architecture, Netskope is introducing a new Cloud Exchange Log Shipper destination plugin named Microsoft Azure Log Analytics Workspace. This plugin is built on Microsoft’s latest Log Ingestion APIs and provides you with a unified ingestion experience for both:

• Existing Microsoft Azure Sentinel use cases
• Current Microsoft Azure Monitor integration workflows

Impact sur les clients

• If you use the existing Microsoft Azure Sentinel plugin, it will continue to function as long as Microsoft supports the underlying Data Collector APIs.
• After Microsoft fully retires the deprecated APIs, support for your current Microsoft Azure Sentinel plugin configuration will end.
• You should migrate to the new Microsoft Azure Log Analytics Workspace plugin before Microsoft’s API retirement date.
• You control your migration timeline and can transition at your own pace before API retirement.

Recommended Action

1. Review your current Cloud Exchange Log Shipper configurations that use the Microsoft Azure Sentinel plugin.
2. Plan your migration to the new Microsoft Azure Log Analytics Workspace plugin.
3. Validate your target Log Analytics workspace, Data Collection Endpoint, Data Collection Rule, table configuration, and Microsoft Entra application permissions required for Log Ingestion API-based ingestion.
4. Test ingestion with the new plugin in your non-production or controlled configuration.
5. Move your production log forwarding to the new plugin before .

The following tables help you compare the available Azure destination options and understand which plugin best fits your ingestion requirements. Use these comparisons to identify whether you need a unified table, separate tables by data type, current Microsoft ingestion APIs, or support for specific log formats such as JSON, CEF, Alerts, Events, and WebTx.

Table Configuration Options Comparison

Comparison Summary

Frequently asked questions

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

A: No. Your current plugin will continue to function while Microsoft continues to support the underlying Data Collector APIs.

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

A: Support for your current Microsoft Azure Sentinel plugin configuration will end after Microsoft fully retires the deprecated Data Collector APIs. Microsoft has stated that these APIs will no longer be supported after .

Q: Which plugin should you use going forward?

A: Vous devriez utiliser le New plugin Microsoft Azure Log Analytics Workspace pour le flux de travail d'ingestion des journaux Azure Sentinel/Microsoft Sentinel et Azure Monitor.

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

A: Yes. The Microsoft Azure Log Analytics Workspace plugin provides you with a unified ingestion experience for your existing Azure Sentinel use cases and current Azure Monitor integration workflows.

Q: Do you need to migrate immediately?

A: You can migrate at your own pace before Microsoft retires the deprecated APIs. However, Netskope recommends that you plan and validate your migration well before the retirement date to avoid ingestion disruption.

Final Recommendation/Guidance

You should treat the Microsoft Azure Log Analytics Workspace plugin as the forward-looking destination for Azure-based log ingestion from Cloud Exchange. Your existing Microsoft Azure Sentinel plugin configurations can remain in place during the transition period, but you should complete migration before Microsoft retires the Data Collector APIs to avoid service interruption.

Références

Pour plus de détails concernant la configuration du plugin Microsoft Azure Log Analytics Workspace, veuillez consulter la documentation ici.

Cette procédure explique comment déplacer l'installation existante de Cloud Exchange vers un lecteur nouvellement ajouté lorsque le stockage actuel est insuffisant.

Conditions préalables

• Effectuez une sauvegarde complète de l’image du serveur Cloud Exchange.
• Confirmez que le New lecteur est correctement monté.
• Assurez-vous que le New lecteur dispose d’un espace de stockage suffisant et des autorisations requises.

Example:

• Annuaire CE actuel : /ta_cloud_exchange
• New drive : /newdrive

Étapes de la migration

1. Accéder au répertoire d’installation de Cloud Exchange et arrêter les conteneurs CE.
   ./stop
2. Déplacez le répertoire complet de Cloud Exchange vers le New lecteur.
   mv /ta_cloud_exchange /newdrive/
3. Allez dans le New répertoire d'installation CE.
   cd /newdrive/ta_cloud_exchange
4. Démarrer Cloud Exchange.
   ./start

Patientez environ 3–4 minutes le temps que tous les services démarrent, puis vérifiez l’interface utilisateur de Cloud Exchange, confirmez que toutes les configurations existantes sont disponibles, assurez-vous que les services/plugins requis sont en cours d’exécution et validez les intégrations configurées.

PIP Proxy

Consultez la méthode globale de configuration d'un proxy pour pip : https://pip.pypa.io/en/latest/topics/configuration/#location

Trouvez le fichier de configuration : à l'adresse /etc/pip.conf. Créez un fichier pip.conf, s'il n'y en a pas.

Exemple de configuration :

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

Tout caractère spécial dans le nom d'utilisateur/mot de passe du proxy doit être encodé dans l'URL.

Un proxy configuré peut être vérifié à l'aide de pip config list.

Ubuntu

Pour configurer les paramètres de proxy pour le gestionnaire de paquets APT sur les systèmes Ubuntu, ajoutez la configuration suivante à /etc/apt/apt.conf. Créez un fichier apt.conf s'il n'existe pas.

Exemples de configurations :

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

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

Docker (pour Ubuntu)

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

RHEL

Pour configurer les paramètres de proxy pour les gestionnaires de paquets YUM sur les systèmes RHEL, ajoutez la configuration suivante à /etc/yum.conf. Créez un fichier yum.conf s'il n'existe pas.

Exemples de configurations :

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

RHEL avec Podman

Pour configurer un proxy dans RHEL avec Podman, exécutez la commande suivante :

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

Étant donné que l'approvisionnement en jetons de workflow for REST API V2 est obsolète, l'approvisionnement futur en jetons doit être effectué à l'aide du processus de création et de gestion de comptes de service New, qui est intégré à RBAC V3.

Prerequisities

Informations d'identification autorisées pour se connecter à Netskope Tenant.

Generate a new V2 token with RBAC V3

1. Connectez-vous à votre tenant Netskope et accédez à Settings.
   
2. Cliquez sur Administration pour élargir les options.
   
3. Click Administrators & Roles.
   
4. Cliquez sur 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. Veillez à copier le jeton, car il ne sera plus disponible après la fermeture de la fenêtre modale.

7. Naviguer dans l’interface Cloud Exchange (Accueil -> Paramètres -> Locataires)
8. Modifier la configuration et ajouter votre jeton V2

Cet article propose un guide étape par étape pour remplacer les certificats SSL par défaut dans Cloud Exchange (CE) par des certificats personnalisés signés par la CA. Ce processus garantit une communication HTTPS sécurisée pour l’interface web de Cloud Exchange.

Conditions préalables

Avant de commencer, assurez-vous que vous disposez des éléments suivants :

• Backup: Il est recommandé de sauvegarder vos fichiers de certificats existants avant de les supprimer.
• Certificate Files: Un certificat valide au format .crt et sa clé privée correspondante au format .key .
• Terminal Access: Accès SSH à la machine hôte Cloud Exchange avec les privilèges sudo .

Procedure

Télécharger et localiser les certificats

Transférez votre certificat personnalisé et les fichiers de clés vers la machine hôte de Cloud Exchange (en utilisant SCP, SFTP, ou une méthode similaire). Notez le chemin d'accès au répertoire où ces fichiers sont stockés.

Stop Cloud Exchange Services

# 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

Effacer les certificats existants

• Naviguez jusqu'au répertoire SSL spécifique et supprimez les anciens fichiers de certificats.

# 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

Installer les certificats New

• Copiez vos fichiers de certificats New dans le dossier ssl_certs et renommez-les pour qu'ils correspondent à la convention d'appellation prévue par le système.

# 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

Redémarrer Cloud Exchange

# Navigate back to the Cloud Exchange directory.

cd ../..

# Start the containers

sudo ./start

Validation

• Ouvrez votre navigateur et accédez à l'interface utilisateur de Cloud Exchange.
• Cliquez sur le site lock icon dans la barre d'adresse.
• Vérifiez que le site Certificate Information correspond à votre certificat personnalisé nouvellement téléchargé.

Cet article fournit des instructions étape par étape pour mettre à jour en toute sécurité le port de l’interface utilisateur (UI) pour Cloud Exchange. Ce processus consiste à arrêter le service, à reconfigurer le fichier de configuration à l’aide du modèle fourni, puis à redémarrer Cloud Exchange.

Arrêter le service Cloud Exchange

Avant d’effectuer toute modification de configuration, vous devez arrêter le service Cloud Exchange en cours d’exécution. Exécutez la commande suivante dans votre terminal :

sudo ./stop

Supprimer l’ancien fichier de configuration

Pour garantir une mise à jour de configuration propre, supprimez le fichier cloudexchange.cofig existant :

rm -rf cloudexchange.cofig

Créer un fichier de configuration New à partir du modèle

Générez un nouveau fichier de configuration en copiant le modèle d’exemple fourni :

cp cloudexchange.cofig.example cloudexchange.cofig

Modifier le fichier de configuration

Ouvrez le nouveau fichier de configuration créé dans un éditeur de texte pour mettre à jour le port:

vi cloudexchange.cofig

Dans le fichier, localisez la variable UI_PORT et modifiez-la au numéro de port souhaité (par défaut est 443) :

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

Note: Sauvegardez et fermez le fichier après avoir effectué la modification (dans vi, appuyez sur Esc, tapez :wq, puis appuyez sur Enter).

Exécutez le script d'installation

Appliquez les New modifications de configuration en exécutant le script de configuration :

sudo python3 ./setup

Démarrer Cloud Exchange

Une fois la configuration terminée, relancez le service Cloud Exchange pour appliquer les paramètres de port New :

sudo ./start

Verification

• Verify Port Allocation: Assurez-vous que le port New que vous sélectionnez n’est pas déjà utilisé par un autre service sur le réseau hôte.
• Accessing the UI: N’oubliez pas d’ajouter le numéro de port New à votre URL lorsque vous accédez à l’interface Cloud Exchange (par exemple, https://<your-ip>:<new_port>).

En plus de la transmission des journaux en temps réel, le module Log Shipper prend également en charge l'extraction de historical events or alerts, ce qui est utile pour les scénarios nécessitant des données antérieures, tels que les pannes SIEM, la récupération du système ou l'analyse des écarts.

When to Use Historical Log Pulling

Les utilisateurs peuvent avoir besoin d'ingérer des événements historiques de leur locataire Netskope pour les raisons suivantes :

• Les pannes de SIEM/environnement entraînent des pertes de données
• Efforts de redressement à la suite d'échecs
• Autres cas d'utilisation nécessitant la saisie d'événements rétroactifs

Steps to Pull Historical Data for a Configured SIEM Mapping

1. Va à Log Shipper Module > SIEM Mappings
2. Identifiez le mappage SIEM pour lequel vous souhaitez extraire les journaux historiques.
3. Cliquez sur le second action button, étiqueté “Pull Historical Data” (voir l'image ci-dessous)
   
4. Dans la fenêtre contextuelle :
   – Select le start et end date-time désirés (en UTC)
   – Cliquez “Pull” pour lancer la tâche
   
5. Une fois soumis, Cloud Exchange commencera à récupérer les journaux à partir de la fenêtre de temps sélectionnée en fonction de la configuration SIEM choisie.

Validate Pull Historical Data

• Nous pouvons valider la même chose dans la section de journalisation, comme le montre l'exemple ci-dessous.
• Les journaux ci-dessus indiquent que la tâche d'extraction de l'historique s'est déroulée avec succès jusqu'à la date spécifiée, ainsi que le nombre d'événements/alertes ingérés depuis le locataire.

• Le journal de débogage ci-dessous indique l'initiation de la synchronisation historique, en mettant en évidence la période de temps.
  

Important Notes:

• L'extraction des journaux historiques n'affecte pas l'ingestion en temps réel pour le mappage SIEM.
• Cette fonctionnalité n'est pas prise en charge pour les mécanismes d'itération basés sur le format CSV, y compris les journaux de transactions Web et les événements de statut du client.

Le module Log Shipper (CLS) de Netskope au sein de la plateforme Cloud Exchange permet une transmission efficace des journaux (par exemple, les événements d'audit) vers les systèmes SIEM. Par défaut, les journaux d'audit envoyés aux SIEM ne contiennent que des résumés de haut niveau des actions administratives telles que "Politique en ligne supprimée", mais manquent de détails spécifiques sur ce qui a été modifié exactement.

Ces détails manquants se trouvent dans d’autres champs appelés « Données de soutien » et « Détails », qui sont présents dans les journaux d’audit originaux du tenant Netskope mais non inclus par défaut dans le mappage des journaux SIEM.

Example

Voici un exemple d'une sortie SIEM par défaut qui ne contient pas les détails nécessaires :

<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: Ajoutez « Données de soutien » et « Détails » à la cartographie

Pour inclure des informations détaillées sur les modifications de configuration, vous devez ajouter manuellement le champ requis à la cartographie de vos événements d’audit dans le Log Shipper.

Steps to Update the Mapping File

1. Dans Cloud Exchange, allez dans le module Log Shipper.
2. Désactivez temporairement le plugin SIEM.
3. Confirmez le nom du fichier de mappage actuellement utilisé par le plugin SIEM.
4. Allez sur Settings > Log Shipper > Mapping.
5. Localisez le fichier de mappage et choisissez Clone ou Edit (s’il est déjà personnalisé).
6. Dans l’éditeur de cartographie, allez sur : Events > Audit > Extension. 
7. Ajoutez les champs suivants : « Données de soutien », « Détails »
8. Enregistrez les modifications dans le fichier de mappage.
9. Retournez à la configuration du plugin SIEM :
10. Mettez-le à jour pour utiliser le fichier de cartographie modifié.
11. Réactivez le plugin SIEM.

Resulting Output

Après la mise à jour du mappage, le journal SIEM comprendra désormais des données de configuration détaillées :

<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: Pour plus de détails sur l'utilisation des fichiers de cartographie, reportez-vous à la documentation officielle : Créer/modifier un fichier de mappage - Netskope Docs

Le site Log Source Identifier est un attribut configurable utilisé pour marquer les journaux avec un identifiant unique, ce qui permet de différencier plus facilement plusieurs sources de journaux dans votre système de gestion des informations et des événements de sécurité (SIEM). Ceci est particulièrement utile lors de l'intégration de plusieurs sources de logs dans une plateforme SIEM centralisée comme Splunk, QRadar ou Rapid7.

Dans ce guide, nous allons voir comment configurer l'identifiant de la source du journal dans le plugin Syslog en utilisant Netskope Cloud Exchange, afin que votre SIEM puisse distinguer efficacement les différentes sources de journaux.

Configure Required Plugins

Log Shipper Plugin: Ce plugin extrait des journaux (comme les alertes et événements) du locataire Netskope.
Syslog Plugin: Ce plugin est responsable de la transmission des journaux vers votre plateforme SIEM (par exemple, Splunk).

Définir l’identifiant source de journal dans le plugin Syslog

1. Allez dans la configuration du plugin Syslog dans l’interface Cloud Exchange et localisez le champ nommé Log Source Identifier dans Paramètres de configuration.
2. Saisissez un nom ou identifiant personnalisé basé sur la source du journal (comme Log From My Netskope Tenant) et cliquez sur Save pour appliquer la configuration.

Valider dans SIEM

Une fois la configuration terminée, validez que les journaux sont reçus avec l’identifiant de source de journal correct.

Exemple (pour Splunk) : Vous pouvez lancer la requête Splunk suivante pour confirmer :
index=<your_index> "Log From My Netskope Tenant"

Remplacez "Log From My Netskope Tenant" par l’identifiant réel que vous avez configuré. Si des journaux apparaissent, la configuration est réussie.

Summary

L'utilisation du champ Log Source Identifier dans le plugin Syslog permet une meilleure séparation des sources de logs et une meilleure visibilité dans votre plateforme SIEM. En configurant cela correctement, vous améliorez la gestion et l'observabilité de vos journaux Netskope au sein de votre infrastructure de sécurité.

Le Cloud Exchange effectue une vérification de disponibilité des plugins toutes les 24 heures.

Une fois le plugin GA, vous recevrez une bannière de notification affichée sur la page du dépôt de plugins. Cette bannière indique qu’une migration est disponible pour un plugin Beta configuré.

Étapes de la migration

Suivez les étapes suivantes pour terminer la migration :

1. Locate the Banner: Allez sur la page de votre dépôt de plugins. Cherchez et identifiez les notification banner indiquant la disponibilité de la version GA.

   

2. Initiate Migration: Cliquez sur Migrate plugin présenté dans la bannière de notification.

   

3. Select the Plugin: Une liste des plugins disponibles (incluant la version New GA) sera affichée. Select la GA version du plugin vers lequel vous souhaitez migrer.
4. Confirm and Save: Cliquez sur Save.

   

5. Migration Process: Le système va alors commencer le processus de migration de votre configuration de l’ancien plugin Beta vers le plugin New GA.

Une fois ce processus terminé, votre système utilisera le plugin GA, plus stable et officiellement supporté.

Cet article explique comment supprimer les IoC de Netskope qui ont déjà été supprimés de la source. Certains plugins ne supportent pas les retraits d'IoCs comme STIXTAXII et Web Page IOC Scraper.

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

Vous pouvez reconfigurer le plugin en utilisant le critère de vieillissement "1". Pour ce faire, suivez les étapes suivantes.

1. Supprimez le plugin existant, y compris les données qui lui sont affectées.
   
2. Configurez maintenant un plugin New et configurez le critère de vieillissement "1".

   

3. Désormais, tous les IoC qui ont été supprimés de la source seront également marqués comme expirés dans Cloud Exchange en un jour.
4. Ensuite, vous pouvez activer les paramètres pour supprimer les IoC expirés de Cloud Exchange. Pour cela, vous pouvez suivre les étapes suivantes.
5. Dans Cloud Exchange, allez à Settings > Threat Exchange, activez Delete Inactive IoC(s) Indicators, et cliquez sur Save.

   

6. Désormais, tous les IoCs supprimés de la source seront automatiquement supprimés de Netskope au bout d'un jour.

   

Cette section est conçue pour vous guider dans le processus de configuration des notifications dans Slack pour les erreurs de Cloud Exchange. Cela permettra aux clients d'être rapidement informés de tout problème ou erreur critique rencontré au cours des opérations de Cloud Exchange. Suivez les étapes ci-dessous pour configurer les notifications pour les différents modules de Cloud Exchange, afin d'être averti dès qu'une erreur se produit.

Overview

Pour tenir les clients informés des erreurs critiques dans Cloud Exchange, nous avons mis en place un plugin de notification Slack. Cela vous permet de recevoir des alertes en temps réel directement sur votre canal Slack dès qu'une erreur se produit dans l'un des modules de Cloud Exchange. En définissant des règles de gestion adaptées à des modules spécifiques, vous pouvez vous assurer que seules les erreurs pertinentes déclenchent des notifications, ce qui facilite le suivi et la résolution rapide des problèmes.

Configuration du notificateur pour Slack

Si vous venez d'installer le plugin, configurez le Slack Notifier Plugin en suivant les étapes décrites dans le document Notifier Plugin for Ticket Orchestrator. Une fois cela fait, reportez-vous à ce document pour configurer les règles de gestion. Si vous avez déjà configuré Notifier, vous pouvez suivre directement ce document pour modifier les règles de gestion existantes. Vous trouverez ci-dessous comment configurer la règle de gestion pour chaque module Cloud Exchange :

Erreurs de la plateforme Cloud Exchange

Cette section couvre les erreurs générales de Cloud Exchange Platform qui ne sont pas liées à un module spécifique. Ces erreurs peuvent concerner l'ensemble du système.

Steps to Configure the Business Rule

1. Dans Cloud Exchange, allez dans un module Cloud Exchange (comme Ticket Orchestrator) et cliquez sur Business Rules, puis créez ou modifiez une règle métier existante.
2. Modifiez la règle comme indiqué.
   
3. Cliquez sur Save.

Enregistrer les erreurs du module de l'expéditeur

Cette section couvre les erreurs spécifiques au module Log Shipper dans l'environnement Cloud Exchange. Toute erreur générée en rapport avec ce module déclenchera une notification sur Slack.

Steps to Configure the Business Rule

1. Dans Cloud Exchange, allez sur Log Shipper > Business Rules et créez ou modifiez une règle métier existante.
2. Modifiez la règle comme indiqué.
   
3. Cliquez sur Save.

Erreurs du module Ticket Orchestrator

Cette section couvre les erreurs spécifiques au module Ticket Orchestrator dans l'environnement Cloud Exchange. Toute erreur générée en rapport avec ce module déclenchera une notification sur Slack.

Steps to Configure the Business Rule

1. Dans Cloud Exchange, allez sur Ticket Orchestrator > Business Rules et créez ou modifiez une règle métier existante.
2. Modifiez la règle comme indiqué.
3. Une fois cela fait, enregistrez la règle.

Erreurs du module Threat Exchange

Cette section se concentre sur le module Threat Exchange, qui gère le partage des renseignements sur les menaces à travers la plateforme Cloud Exchange. Les erreurs dans ce module déclencheront des notifications pour vous tenir informé des problèmes liés à la sécurité.

Steps to Configure the Business Rule

1. Dans Cloud Exchange, allez sur Threat Exchange > Business Rules et créez ou modifiez une règle métier existante.
2. Modifiez la règle comme indiqué.
   
3. Cliquez sur Save.

Erreurs du module d'échange de risques

Cette section couvre les erreurs spécifiques au module Risk Exchange dans l'environnement Cloud Exchange. Toute erreur générée en rapport avec ce module déclenchera une notification sur Slack.

Steps to Configure the Business Rule

1. Dans Cloud Exchange, allez sur Risk Exchange > Business Rules et créez ou modifiez une règle métier existante.
2. Modifiez la règle comme indiqué.
   
3. Cliquez sur Save.

Configuration de la file d'attente

La configuration de la file d'attente est une étape cruciale au cours de laquelle vous pouvez mettre en correspondance les champs appropriés.

Map Fields: Dans cette section, vous pouvez associer des valeurs aux alertes et aux notifications. Les attributs d'alerte sont accessibles à l'aide du symbole "$" dans le champ du message personnalisé.

Par exemple, dans les captures d'écran ci-dessous, nous avons mappé les valeurs $errorCode, $alertType et $message. Par conséquent, lorsque vous recevrez la notification dans Slack, celle-ci affichera les informations spécifiées ici.

Mapper les champs dans la configuration de la file d'attente.

Par exemple, si nous essayons de sauvegarder le plugin en laissant les champs Event Types et Alert Types vides, nous obtiendrons une erreur. Cette erreur déclenchera une notification sur Slack.

Vérifiez que l'erreur a été générée pour le module CLS.

Notification générée sur Slack.

Codes d'erreur de Cloud Exchange

Vous trouverez ici des liens vers des sections qui fournissent des descriptions détaillées des différents codes d'erreur de Cloud Exchange. Ces sections couvrent des codes d'erreur spécifiques liés à différents modules de la plateforme Cloud Exchange, offrant des explications approfondies sur chaque type d'erreur et ses causes.

• Codes d'erreur de la plateforme Cloud Exchange
• Codes d'erreur du module Log Shipper
• Codes d'erreur du module Ticket Orchestrator
• Codes d'erreur du module Threat Exchange
• Codes d'erreur du module d'échange de risques

Suivez les étapes suivantes pour supprimer un Statut de Client existant.

1. Allez sur Settings > Tools.
2. Cliquez sur REST API V2.
3. Cliquez sur API Documentation.

   

4. Après avoir ouvert la documentation API, vous devez cliquer Authorize.

   

5. Utilisez votre jeton V2 de l'API REST pour l'authentification.
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. Cliquez sur Execute.
9. Si le statut du client est déjà créé, vous obtiendrez le nom de l'itérateur.

   

10. Copiez ce nom et allez à delete an existing iterator et cliquez sur Try it now.
11. Collez le nom de l’itérateur que vous avez copié et cliquez Execute.
12. Vérifiez la réponse du serveur pour confirmer que l'itérateur a été supprimé avec succès.

This table below provides mapping details to help correlate Client Status event fields received by your SIEM/SOAR with the corresponding events in the Netskope Portal.

Summary: When upgrading an existing CTO HaloITSM plugin to the updated version (v2.0.0), the plugin workflow may break because the newer version includes configuration parameters that were not present in earlier versions. As a result, users may be unable to save the plugin during the upgrade. Use the workaround below to complete the upgrade and restore the existing plugin workflow.

Issue

After upgrading from an older CTO HaloITSM plugin version, users may be unable to save the plugin because the configuration parameters have changed in the updated version. During the upgrade flow, select Skip when prompted so the upgrade can complete, and then edit the plugin configuration afterward.

Workaround steps

1. During the plugin upgrade, select Skip when prompted.

   

2. Go to the Plugins page and edit the upgraded CTO HaloITSM plugin.

   

3. Saisissez les informations d'authentification requises, puis cliquez sur Next.

   

4. Select the required ticket type, and then click Save.
   Important: Pour modifier le type de ticket, les utilisateurs doivent enregistrer le plugin depuis l'onglet Configuration Parameters . Si les utilisateurs mettent à jour le type de ticket et enregistrent le plugin à partir de l'onglet Mapping Configuration, Authentication ou Basic Information , la modification ne sera pas prise en compte.

   

5. Enable the plugin.

Mapping configuration guidance

Mapping Configuration is introduced in CTO HaloITSM plugin version 2.0.0. Use this tab to map Netskope Cloud Exchange fields with HaloITSM fields.

If you want to keep the default Mapping Configuration, save the plugin from the Configuration Parameters tab.

Cet article décrit les workflow de bout en bout nécessaires pour configurer Cloud Exchange afin de partager sans interruption Netskope Alertes et Événements avec plusieurs destinations tierces (telles que Syslog, QRadar, etc.).

Vérifier les exigences système

Avant de commencer la configuration, assurez-vous que votre déploiement Cloud Exchange répond aux exigences système nécessaires pour gérer l’ingestion multi-destinations sans problème.

Consultez la documentation des exigences système pour des métriques matérielles et de ressources spécifiques.

Configure the Netskope Tenant

Établissez la connexion principale de données en reliant votre locataire Netskope à Cloud Exchange.

Consultez le guide Tenant Plugin pour configurer vos identifiants locataires et l’accès à l’API.

Configurez le plugin Netskope Log Shipper

Configurez le plugin Log Shipper pour commencer à récupérer les données de votre locataire.

Consultez le guide du plugin Log Shipper pour des étapes d’installation détaillées.

Configurez les plugins de destination

Configurez les plugins pour chaque plateforme tierce où vous souhaitez envoyer vos journaux. Par exemple, si vous souhaitez intégrer les alertes et événements dans Syslog et QRadar, vous devez configurer les deux plugins individuels dans Cloud Exchange.

Consultez l’article sur les plugins de destination tiers pour des guides d’implémentation spécifiques à chaque fournisseur pris en charge.

Configurer les règles métier

Mettez en place des règles métier pour filtrer les données selon la conformité ou les exigences opérationnelles de votre organisation.

• Vous pouvez concevoir des règles métier personnalisées selon des critères spécifiques.
• Sinon, vous pouvez utiliser la règle métier par défaut intégrée All pour partager toutes les alertes et événements disponibles sans filtre.

Consultez l’article sur les règles métier pour la création de logique étape par étape.

Configurer la livraison des journaux

La dernière étape consiste à relier la source de vos logs, vos plugins de destination et vos règles métier en configurant la livraison des logs.

Consultez l’article sur la livraison de journaux pour activer votre workflowd’ingestion de journaux .

Summary

Le module EDM Cloud Exchange (CE) fournit une solution de bout en bout pour récupérer les données brutes stockées en CSV, DB, etc., la génération de hachages, et le téléchargement des données exactes Match données sur votre locataire Netskope . Il permet de récupérer des données clients de plusieurs types de sources via des plugins dédiés — y compris les serveurs de partage de fichiers Linux (via SFTP), les bases de données MySQL et Oracle, ainsi que les partages de fichiers basés sur les PME.

CE automatise l’intégralité de la workflow via des tâches de cycle de vie de plugins basées sur des intervalles, qui gèrent le tirage de données, la génération de hachages et le téléchargement dans un seul pipeline. Tout nouvel enregistrement ajouté dans la source est automatiquement reflété dans le locataire selon l’intervalle de plugin configuré. Une option de synchronisation manuelle est également disponible pour déclencher la tâche du cycle de vie du plugin à la demande lorsqu’une mise à jour immédiate est nécessaire. Le module CE EDM prend aussi en charge la personnalisation de la Sanitisation, de la Normalisation, de la Suppression des citations, de la suppression des stopwards sur les données extraites.

Performance Results

Les enregistrements suivants ont été utilisés pour valider la fonctionnalité et la performance des modules EDM.

Detailed Performance Results

Le tableau ci-dessous montre le temps de traitement EDM, qui dépend également des options de configuration du plugin EDM telles que la salubrisation, la normalisation, la création de dictionnaire et la suppression des mots stopword sur plusieurs colonnes.

Performance Results with Plugin Configuration

Guidance

Les chiffres ci-dessus sont des benchmarks de performance pour le module Cloud Exchange (CE) EDM. CE prend en charge la génération de hachage et le téléversement de jusqu’à 1 million d’enregistrements via le module EDM. Si votre jeu de données dépasse 1 million de lignes, utilisez plutôt la solution basée sur le script de génération de hachage DLPx + script d’upload Python ; voir génération de hachage locale pour plus de détails.

Term Definitions

• Remove Quotes: Activer si le CSV enferme les valeurs du champ entre guillemets doubles (par exemple, lorsque les valeurs contiennent des virgules). Les champs cités sont analysés en une seule colonne ; Un mauvais placement des citations peut entraîner des sautages de lignes.
• Sanitization (Columns): Valide et nettoie les colonnes sélectionnées avant la génération du hachage. Une cellule est marquée comme invalide si elle ne comporte qu’un seul caractère, contient des chiffres, correspond à un mot stop (uniquement lorsque Supprimer les mots stopword est activé), ou contient des caractères non alphanumériques (qui sont supprimés). (Par défaut : aucun)
• Remove Stopwords: Lorsqu’elles sont activées, les cellules correspondant à un mot de la liste de mots stopword sont marquées comme invalides lors de la désinfection.
• Normalization (Columns): Standardise la valeur dans les colonnes sélectionnées avant la génération du hachage, afin que de légères différences de formatage dans les données sources ne fassent pas passer une correspondance valide à côté. Les colonnes de cordes sont converties en majuscule de titre (par exemple, JOHN DOE devient John Doe) ; Les colonnes numérotées ont des tirets, des points et des espaces supprimés (par exemple, 123-45,678 devient 12345678). (Par défaut : aucun)
• Dictionary Creation (Columns): Crée un dictionnaire de valeurs uniques pour la(s) colonne(s) sélectionnée(s), qui peut être utilisée dans une règle DLP (Prévention des pertes de données) dans le locataire Netskope . (Par défaut : aucun)
• Proceed Without Sanitization: Si ce n’est pas coché, toutes les données sont incluses dans la génération de hachages. Si elle est vérifiée, seules les données ayant passé la salubrisation (le contenu « Good File ») sont utilisées pour la génération de hachages.

Cet article fournit des conseils pour migrer un workflow existant de URL Lists à Destination Profiles au sein de Cloud Exchange. Il décrit le processus de migration tout en préservant le cas d’usage existant et met en lumière des considérations importantes liées aux limitations connues dans Cloud Exchange version 6.1.0.

Dans ce scénario d’exemple, une intégration SIEM existante utilisant Anomali ThreatStream XDR est configurée pour partager des IoC dans une liste d’URL Netskope. L’article montre comment migrer ce workflow pour utiliser plutôt les profils de destination.

Exemple de configuration existante

Dans cet exemple, l’environnement actuel se compose de la configuration suivante :

Plugins configurés dans Cloud Exchange

Règle d’affaires existante

Une règle d’affaires existe actuellement qui suit :

• Reçoit les IoC d’Anomali ThreatStream XDR.
• Filtre les types d’IoC nécessaires au partage vers Netskope.

Configuration de partage existante

La configuration de partage actuelle effectue l’action suivante :

• Pousse les IoC reçus dans une liste d’URL existante nommée : Crest PS URL List.

Le workflow fonctionne actuellement sous le nom de :

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

Étapes de migration de la liste d’URL vers le profil de destination

Suivez ces étapes pour migrer la liste d’URL existante workflow vers un profil de destination.

Créer une copie de la règle métier existante

Puisqu’un plugin existant et un workflow sont déjà configurés :

1. Dans Threat Exchange, allez à Business Rules.
2. Localiser la règle métier existante actuellement utilisée pour le partage de liste d’URL.
3. Cliquez sur l’icône Copy pour la règle.
4. Fournissez un nom New à la règle dupliquée.
5. Épargnez la nouvelle règle d’activité.

Créer une copie de la règle métier existante évite d’impacter le workflow de production actuel lors de la migration.

Créez une configuration de partage New pour le profil de destination

En utilisant la nouvelle règle métier :

1. Allez sur Sharing.
2. Créez une configuration de partage New .
3. Select la nouvelle règle d’affaires.
4. Sous Target, sélectionnez : Add to Destination Profile
5. Select one of the following options:
   • Choisissez un profil de destination existant
   • Select Create New Profile créer un profil de destination New
6. Sauvegardez la configuration de partage.

La workflow mise à jour deviendra désormais :

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

References

Le module Log Shipper (CLS) de Netskope dans Cloud Exchange utilise des fichiers de cartographie pour déterminer quels champs d’événements sont transmis à une plateforme SIEM. Les fichiers de mappage par défaut sont conçus pour inclure les champs les plus couramment utilisés, mais ils ne contiennent pas nécessairement tous les champs disponibles dans les données d’événement originales stockées dans le locataire Netskope.

En conséquence, les utilisateurs peuvent remarquer qu’un champ spécifique est visible dans les événements Netskope ou l’interface d’audit mais n’est pas présent dans les journaux reçus par leur SIEM. Dans la plupart des cas, cela se produit parce que le champ n’est pas inclus dans le fichier de mappage par défaut du Log Shipper.

Exemple

Un utilisateur recherche un champ d’événement particulier (par exemple, un attribut de politique, un attribut utilisateur ou un champ de métadonnées) dans ses journaux SIEM. Le champ est visible dans l’événement correspondant à l’intérieur du locataire Netskope mais n’apparaît pas dans la sortie SIEM.

Cela indique que le champ existe dans l’événement source mais n’est pas actuellement mappé pour l’exportation par le Log Shipper.

Solution : Ajouter le champ requis au fichier de mappage

Pour inclure des champs d’événements supplémentaires dans les journaux envoyés à votre SIEM, créez ou modifiez un fichier de mappage personnalisé et ajoutez le(s) champ(s) requis. Après avoir mis à jour la cartographie, configurez le plugin SIEM pour utiliser le fichier de mappage personnalisé

Étapes de la mise à jour du fichier de cartographie

1. Dans Cloud Exchange, allez dans Log Shipper.
2. Désactivez temporairement le SIEM Plugin.
3. Identifiez le fichier de mappage actuellement assigné au plugin SIEM.
4. Allez sur Settings > Log Shipper > Mapping.
5. Localisez le fichier de mappage et sélectionnez Clone (recommandé) ou Edit si vous utilisez déjà une correspondance personnalisée.
6. Naviguez vers la catégorie correspondant aux journaux que vous transférez (par exemple, Alertes, Événements, etc.).

   

7. Naviguez jusqu’au type spécifique de journal et développez le menu Extension .

   

8. Allez en bas du menu Extension et cliquez sur Add. Select le champ requis dans le menu déroulant Netskope champs que vous souhaitez ajouter. Fournir le nom du champ au besoin pour l’identification dans le SIEM. Cliquez Save.
   

   

9. Revenez à la configuration SIEM Plugin .
10. Select le fichier de mappage nouvellement créé ou mis à jour.
11. Re-enable the SIEM Plugin.

Result

Après l’application de la correspondance mise à jour, les journaux nouvellement transférés incluront le(s) champ(s) supplémentaire(s), permettant de les rechercher, analyser et corrélér au sein de la plateforme SIEM.

Note

• Seuls New événements générés après le changement de mappage contiendront les champs nouvellement ajoutés. Les journaux précédemment transférés ne sont pas mis à jour rétroactivement.
• Assurez-vous que le champ que vous souhaitez ajouter est présent dans les données d’événement originales dans le locataire Netskope. Si le champ n’est pas disponible dans l’événement source, il ne peut pas être exporté via la cartographie Log Shipper.
• Si le champ requis n’est pas disponible dans le menu déroulant de la cartographie, recherchez en utilisant le nom du champ backend au lieu de l’étiquette affichée.

Exemple de référence

1. Comparez le champ affiché dans les détails de l’événement avec les champs de cartographie disponibles.

   

2. Si le champ n’est pas trouvé, passez la souris sur le nom du champ dans SkopeIT pour consulter son nom de champ en arrière-plan.

   

3. Recherchez le nom du champ backend dans la boîte de recherche de champs de correspondance et sélectionnez le champ approprié.

   

Si un plugin apparaît grisé et ne peut pas être sélectionné lors d’une mise à jour de plugin dans Cloud Exchange, cela signifie généralement que le plugin n’est pas pris en charge par la version de Cloud Exchange actuellement installée.

Capture d’écran : boîte de dialogue « Choisir les plugins à mettre à jour » – les plugins grisés affichent leur message de compatibilité de version en texte gris (les numéros de version réels affichés varieront selon la version).

What the Grayed-Out Text Means

Comme indiqué dans la capture d’écran ci-dessus, chaque plugin incompatible est répertorié avec un message en texte gris, indiquant la version de Cloud Exchange actuellement installée et la version minimale requise pour ce plugin. Certains plugins peuvent également afficher une version minimale requise du plugin fournisseur en plus de la version du cœur. Ce texte grisé n’est pas une erreur : c’est Cloud Exchange qui vous indique exactement quelle(s) version(s) est/sont requise(s) avant que ce plugin puisse être sélectionné et configuré.

How to Resolve This

1. Notez la « Version requise » affichée en gris à côté du plugin (il s’agit de la version minimale du cœur de Cloud Exchange nécessaire).
2. Si une version minimale du plugin fournisseur est également indiquée, confirmez cette exigence séparément — les deux conditions doivent être remplies.
3. Vérifiez la version de Cloud Exchange actuellement installée dans votre environnement (indiquée comme « Current core version » dans la boîte de dialogue).
4. Si votre version installée est antérieure à la version requise, mettez à jour Cloud Exchange vers une version prise en charge.
5. Après la mise à niveau, actualisez l’écran de mise à jour des plugins ; le plugin ne sera plus grisé et pourra être sélectionné et configuré.

Checking for a Required Version That Isn’t Released Yet

Dans certains cas, la version requise par un plugin peut ne pas encore être disponible. Netskope publie régulièrement de New versions de Cloud Exchange ; il est donc utile de vérifier périodiquement. Vous pouvez consulter toutes les versions publiées de Cloud Exchange, leurs dates de sortie et leur statut de support sur la page Cycle de vie du produit Cloud Exchange :

Cycle de vie du produit Cloud Exchange & Politique de support

Une fois que la version requise par votre plugin apparaît comme étant généralement disponible (GA) sur cette page, vous pouvez mettre à jour Cloud Exchange et le plugin deviendra configurable.

Good to Know: Support Policy

Netskope prend activement en charge les deux versions les plus récentes de Cloud Exchange (la version actuelle et la précédente). Si votre environnement exécute une version antérieure à celle-ci, nous vous recommandons de planifier une mise à jour plutôt que d’attendre une seule version, car les versions plus anciennes ne bénéficient plus du support actif.

Consultez toujours le dernier guide de configuration des plugins pour connaître les versions prises en charge et les prérequis exacts avant d’effectuer une mise à jour.