La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Installation de l'agent de sécurité de la charge de travail

10/14/2025 Contributeurs

Workload Security (anciennement Cloud Secure) collecte les données d’activité des utilisateurs à l’aide d’un ou plusieurs agents. Les agents se connectent aux appareils de votre locataire et collectent des données qui sont envoyées à la couche SaaS Workload Security pour analyse. Voir"Exigences relatives aux agents" pour configurer une machine virtuelle agent.

Avant de commencer

Le privilège sudo est requis pour l'installation, l'exécution de scripts et la désinstallation.
Lors de l'installation de l'agent, un utilisateur local cssys et un groupe local cssys sont créés sur la machine. Si les paramètres d'autorisation ne permettent pas la création d'un utilisateur local et nécessitent plutôt Active Directory, un utilisateur avec le nom d'utilisateur cssys doit être créé sur le serveur Active Directory.
Vous pouvez en savoir plus sur la sécurité de Data Infrastructure Insights"ici" .

Les changements globaux peuvent avoir un impact potentiel sur vos systèmes ONTAP . Il est fortement recommandé d'effectuer des modifications affectant un grand nombre de collecteurs de données pendant les heures creuses.

Étapes pour installer l'agent

Connectez-vous en tant qu’administrateur ou propriétaire de compte à votre environnement Workload Security.
Sélectionnez Collecteurs > Agents > +Agent

Le système affiche la page Ajouter un agent :
Vérifiez que le serveur d’agent répond à la configuration système minimale requise.
Pour vérifier que le serveur d’agent exécute une version prise en charge de Linux, cliquez sur Versions prises en charge (i).
Si votre réseau utilise un serveur proxy, veuillez définir les détails du serveur proxy en suivant les instructions de la section Proxy.
Cliquez sur l’icône Copier dans le presse-papiers pour copier la commande d’installation.
Exécutez la commande d’installation dans une fenêtre de terminal.
Le système affiche le message suivant lorsque l'installation se termine avec succès :

Après avoir terminé

Vous devez configurer un"Collecteur d'annuaires utilisateurs" .
Vous devez configurer un ou plusieurs collecteurs de données.

Configuration du réseau

Exécutez les commandes suivantes sur le système local pour ouvrir les ports qui seront utilisés par Workload Security. S'il existe un problème de sécurité concernant la plage de ports, vous pouvez utiliser une plage de ports plus petite, par exemple 35000:35100. Chaque SVM utilise deux ports.

Étapes

sudo firewall-cmd --permanent --zone=public --add-port=35000-55000/tcp
sudo firewall-cmd --reload

Suivez les étapes suivantes en fonction de votre plateforme :

CentOS 7.x / RHEL 7.x:

sudo iptables-save | grep 35000

Exemple de sortie :

 -A IN_public_allow -p tcp -m tcp --dport 35000:55000 -m conntrack -ctstate NEW,UNTRACKED -j ACCEPT
*CentOS 8.x / RHEL 8.x*:

sudo firewall-cmd --zone=public --list-ports | grep 35000(pour CentOS 8)

Exemple de sortie :

35000-55000/tcp

« Épingler » un agent sur la version actuelle

Par défaut, Data Infrastructure Insights Workload Security met à jour automatiquement les agents. Certains clients peuvent souhaiter suspendre la mise à jour automatique, ce qui laisse un agent à sa version actuelle jusqu'à ce que l'un des événements suivants se produise :

Le client reprend les mises à jour automatiques de l'agent.
30 jours sont passés. Notez que les 30 jours commencent le jour de la mise à jour la plus récente de l'agent, et non le jour où l'agent est mis en pause.

Dans chacun de ces cas, l’agent sera mis à jour lors de la prochaine actualisation de Workload Security.

Pour suspendre ou reprendre les mises à jour automatiques des agents, utilisez les API cloudsecure_config.agents :

API d'agent cloudsecure pour épingler et désépingler des agents

Notez que l'action de pause ou de reprise peut prendre jusqu'à cinq minutes pour prendre effet.

Vous pouvez afficher vos versions d'agent actuelles sur la page Sécurité de la charge de travail > Collecteurs, dans l'onglet Agents.

Versions de l'agent WS affichées dans le tableau des agents

Dépannage des erreurs de l'agent

Les problèmes connus et leurs résolutions sont décrits dans le tableau suivant.

Problème: Résolution:

Problème:	Résolution:
L'installation de l'agent ne parvient pas à créer le dossier /opt/netapp/cloudsecure/agent/logs/agent.log et le fichier install.log ne fournit aucune information pertinente.	Cette erreur se produit lors de l'amorçage de l'agent. L'erreur n'est pas enregistrée dans les fichiers journaux car elle se produit avant l'initialisation de l'enregistreur. L'erreur est redirigée vers la sortie standard et est visible dans le journal de service à l'aide de l' `journalctl -u cloudsecure-agent.service` commande. Cette commande peut être utilisée pour résoudre le problème plus en détail. est
L'installation de l'agent échoue avec le message « Cette distribution Linux n'est pas prise en charge. Sortie de l'installation'.	Cette erreur apparaît lorsque vous tentez d’installer l’agent sur un système non pris en charge. Voir "Exigences relatives aux agents" .
L'installation de l'agent a échoué avec l'erreur : « -bash : unzip : commande introuvable »	Installez, décompressez, puis exécutez à nouveau la commande d'installation. Si Yum est installé sur la machine, essayez « yum install unzip » pour installer le logiciel de décompression. Après cela, recopiez la commande depuis l’interface utilisateur d’installation de l’agent et collez-la dans l’interface de ligne de commande pour exécuter à nouveau l’installation.
L'agent a été installé et était en cours d'exécution. Cependant, l'agent s'est arrêté soudainement.	Connectez-vous en SSH à la machine de l'agent. Vérifiez l'état du service de l'agent via `sudo systemctl status cloudsecure-agent.service` . 1. Vérifiez si les journaux affichent un message « Échec du démarrage du service démon Workload Security ». 2. Vérifiez si l'utilisateur cssys existe ou non dans la machine Agent. Exécutez les commandes suivantes une par une avec l'autorisation root et vérifiez si l'utilisateur et le groupe cssys existent. `sudo id cssys` `sudo groups cssys` 3. S'il n'en existe aucun, une politique de surveillance centralisée peut avoir supprimé l'utilisateur cssys. 4. Créez l’utilisateur et le groupe cssys manuellement en exécutant les commandes suivantes. `sudo useradd cssys` `sudo groupadd cssys` 5. Redémarrez ensuite le service de l'agent en exécutant la commande suivante : `sudo systemctl restart cloudsecure-agent.service` 6. Si le problème persiste, veuillez vérifier les autres options de dépannage.
Impossible d'ajouter plus de 50 collecteurs de données à un agent.	Seuls 50 collecteurs de données peuvent être ajoutés à un agent. Il peut s'agir d'une combinaison de tous les types de collecteurs, par exemple, Active Directory, SVM et d'autres collecteurs.
L'interface utilisateur indique que l'agent est dans l'état NOT_CONNECTED.	Étapes pour redémarrer l'agent. 1. Connectez-vous en SSH à la machine de l'agent. 2. Redémarrez ensuite le service de l'agent en exécutant la commande suivante : `sudo systemctl restart cloudsecure-agent.service` 3. Vérifiez l'état du service de l'agent via `sudo systemctl status cloudsecure-agent.service` . 4. L'agent doit passer à l'état CONNECTÉ.
L'agent VM est derrière le proxy Zscaler et l'installation de l'agent échoue. En raison de l'inspection SSL du proxy Zscaler, les certificats de sécurité de la charge de travail sont présentés comme s'ils étaient signés par Zscaler CA, de sorte que l'agent ne fait pas confiance à la communication.	Désactivez l'inspection SSL dans le proxy Zscaler pour l'URL *.cloudinsights.netapp.com. Si Zscaler effectue une inspection SSL et remplace les certificats, Workload Security ne fonctionnera pas.
Lors de l'installation de l'agent, l'installation se bloque après la décompression.	La commande « chmod 755 -Rf » échoue. La commande échoue lorsque la commande d'installation de l'agent est exécutée par un utilisateur sudo non root qui possède des fichiers dans le répertoire de travail, appartenant à un autre utilisateur, et les autorisations de ces fichiers ne peuvent pas être modifiées. En raison de l'échec de la commande chmod, le reste de l'installation ne s'exécute pas. 1. Créez un nouveau répertoire nommé « cloudsecure ». 2. Allez dans ce répertoire. 3. Copiez et collez la commande d'installation complète « token=…… … ./cloudsecure-agent-install.sh » et appuyez sur Entrée. 4. L'installation devrait pouvoir se poursuivre.
Si l'agent ne parvient toujours pas à se connecter à Saas, veuillez ouvrir un dossier auprès du support NetApp . Fournissez le numéro de série Data Infrastructure Insights pour ouvrir un dossier et joignez les journaux au dossier comme indiqué.	Pour joindre des journaux au dossier : 1. Exécutez le script suivant avec l'autorisation root et partagez le fichier de sortie (cloudsecure-agent-symptoms.zip). a. /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh 2. Exécutez les commandes suivantes une par une avec l'autorisation root et partagez la sortie. a. id cssys b. groups cssys c. cat /etc/os-release
Le script cloudsecure-agent-symptom-collector.sh échoue avec l'erreur suivante. [root@machine tmp]# /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh Collecte du journal de service Collecte des journaux d'application Collecte des configurations d'agent Prise d'un instantané de l'état du service Prise d'un instantané de la structure du répertoire de l'agent …………………. …………………. /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh : ligne 52 : zip : commande introuvable ERREUR : Échec de la création de /tmp/cloudsecure-agent-symptoms.zip	L'outil Zip n'est pas installé. Installez l’outil zip en exécutant la commande « yum install zip ». Exécutez ensuite à nouveau cloudsecure-agent-symptom-collector.sh.
L'installation de l'agent échoue avec useradd : impossible de créer le répertoire /home/cssys	Cette erreur peut se produire si le répertoire de connexion de l'utilisateur ne peut pas être créé sous /home, en raison d'un manque d'autorisations. La solution de contournement serait de créer un utilisateur cssys et d'ajouter son répertoire de connexion manuellement à l'aide de la commande suivante : sudo useradd user_name -m -d HOME_DIR -m : Créez le répertoire personnel de l'utilisateur s'il n'existe pas. -d : Le nouvel utilisateur est créé en utilisant HOME_DIR comme valeur pour le répertoire de connexion de l'utilisateur. Par exemple, sudo useradd cssys -m -d /cssys, ajoute un utilisateur cssys et crée son répertoire de connexion sous root.
L'agent ne s'exécute pas après l'installation. Systemctl status cloudsecure-agent.service affiche ce qui suit : [root@demo ~]# systemctl status cloudsecure-agent.service agent.service – Workload Security Agent Daemon Service Loaded: loaded (/usr/lib/systemd/system/cloudsecure-agent.service; enabled; vendor preset: disabled) Active: activation (redémarrage automatique) (Result: exit-code) since Tue 2021-08-03 21:12:26 PDT; Il y a 2 s Processus : 25889 ExecStart=/bin/bash /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent (code=exited status=126) PID principal : 25889 (code=exited, status=126), 03 août 21:12:26 démo systemd[1] : cloudsecure-agent.service : processus principal terminé, code=exited, status=126/n/a 03 août 21:12:26 démo systemd[1] : l'unité cloudsecure-agent.service est entrée en état d'échec. 03 août 21:12:26 démo systemd[1] : cloudsecure-agent.service a échoué.	Cela peut échouer car l'utilisateur cssys n'a peut-être pas l'autorisation d'installer. Si /opt/netapp est un montage NFS et si l'utilisateur cssys n'a pas accès à ce dossier, l'installation échouera. cssys est un utilisateur local créé par le programme d'installation de Workload Security qui n'est peut-être pas autorisé à accéder au partage monté. Vous pouvez le vérifier en essayant d'accéder à /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent en utilisant l'utilisateur cssys. Si le message « Autorisation refusée » est renvoyé, l’autorisation d’installation n’est pas présente. Au lieu d'un dossier monté, installez-le dans un répertoire local sur la machine.
L'agent a été initialement connecté via un serveur proxy et le proxy a été défini lors de l'installation de l'agent. Le serveur proxy a maintenant changé. Comment la configuration du proxy de l'agent peut-elle être modifiée ?	Vous pouvez modifier le fichier agent.properties pour ajouter les détails du proxy. Suivez ces étapes : 1. Accédez au dossier contenant le fichier de propriétés : cd /opt/netapp/cloudsecure/conf 2. À l’aide de votre éditeur de texte préféré, ouvrez le fichier agent.properties pour le modifier. 3. Ajoutez ou modifiez les lignes suivantes : AGENT_PROXY_HOST=scspa1950329001.vm.netapp.com AGENT_PROXY_PORT=80 AGENT_PROXY_USER=pxuser AGENT_PROXY_PASSWORD=pass1234 4. Enregistrez le fichier. 5. Redémarrez l'agent : sudo systemctl restart cloudsecure-agent.service

L'installation de l'agent ne parvient pas à créer le dossier /opt/netapp/cloudsecure/agent/logs/agent.log et le fichier install.log ne fournit aucune information pertinente.

Cette erreur se produit lors de l'amorçage de l'agent. L'erreur n'est pas enregistrée dans les fichiers journaux car elle se produit avant l'initialisation de l'enregistreur. L'erreur est redirigée vers la sortie standard et est visible dans le journal de service à l'aide de l' journalctl -u cloudsecure-agent.service commande. Cette commande peut être utilisée pour résoudre le problème plus en détail. est

L'installation de l'agent échoue avec le message « Cette distribution Linux n'est pas prise en charge. Sortie de l'installation'.

Cette erreur apparaît lorsque vous tentez d’installer l’agent sur un système non pris en charge. Voir "Exigences relatives aux agents" .

L'installation de l'agent a échoué avec l'erreur : « -bash : unzip : commande introuvable »

Installez, décompressez, puis exécutez à nouveau la commande d'installation. Si Yum est installé sur la machine, essayez « yum install unzip » pour installer le logiciel de décompression. Après cela, recopiez la commande depuis l’interface utilisateur d’installation de l’agent et collez-la dans l’interface de ligne de commande pour exécuter à nouveau l’installation.

L'agent a été installé et était en cours d'exécution. Cependant, l'agent s'est arrêté soudainement.

Connectez-vous en SSH à la machine de l'agent. Vérifiez l'état du service de l'agent via sudo systemctl status cloudsecure-agent.service . 1. Vérifiez si les journaux affichent un message « Échec du démarrage du service démon Workload Security ». 2. Vérifiez si l'utilisateur cssys existe ou non dans la machine Agent. Exécutez les commandes suivantes une par une avec l'autorisation root et vérifiez si l'utilisateur et le groupe cssys existent.
sudo id cssys
sudo groups cssys 3. S'il n'en existe aucun, une politique de surveillance centralisée peut avoir supprimé l'utilisateur cssys. 4. Créez l’utilisateur et le groupe cssys manuellement en exécutant les commandes suivantes.
sudo useradd cssys
sudo groupadd cssys 5. Redémarrez ensuite le service de l'agent en exécutant la commande suivante :
sudo systemctl restart cloudsecure-agent.service 6. Si le problème persiste, veuillez vérifier les autres options de dépannage.

Impossible d'ajouter plus de 50 collecteurs de données à un agent.

Seuls 50 collecteurs de données peuvent être ajoutés à un agent. Il peut s'agir d'une combinaison de tous les types de collecteurs, par exemple, Active Directory, SVM et d'autres collecteurs.

L'interface utilisateur indique que l'agent est dans l'état NOT_CONNECTED.

Étapes pour redémarrer l'agent. 1. Connectez-vous en SSH à la machine de l'agent. 2. Redémarrez ensuite le service de l'agent en exécutant la commande suivante :
sudo systemctl restart cloudsecure-agent.service 3. Vérifiez l'état du service de l'agent via sudo systemctl status cloudsecure-agent.service . 4. L'agent doit passer à l'état CONNECTÉ.

L'agent VM est derrière le proxy Zscaler et l'installation de l'agent échoue. En raison de l'inspection SSL du proxy Zscaler, les certificats de sécurité de la charge de travail sont présentés comme s'ils étaient signés par Zscaler CA, de sorte que l'agent ne fait pas confiance à la communication.

Désactivez l'inspection SSL dans le proxy Zscaler pour l'URL *.cloudinsights.netapp.com. Si Zscaler effectue une inspection SSL et remplace les certificats, Workload Security ne fonctionnera pas.

Lors de l'installation de l'agent, l'installation se bloque après la décompression.

La commande « chmod 755 -Rf » échoue. La commande échoue lorsque la commande d'installation de l'agent est exécutée par un utilisateur sudo non root qui possède des fichiers dans le répertoire de travail, appartenant à un autre utilisateur, et les autorisations de ces fichiers ne peuvent pas être modifiées. En raison de l'échec de la commande chmod, le reste de l'installation ne s'exécute pas. 1. Créez un nouveau répertoire nommé « cloudsecure ». 2. Allez dans ce répertoire. 3. Copiez et collez la commande d'installation complète « token=…… … ./cloudsecure-agent-install.sh » et appuyez sur Entrée. 4. L'installation devrait pouvoir se poursuivre.

Si l'agent ne parvient toujours pas à se connecter à Saas, veuillez ouvrir un dossier auprès du support NetApp . Fournissez le numéro de série Data Infrastructure Insights pour ouvrir un dossier et joignez les journaux au dossier comme indiqué.

Pour joindre des journaux au dossier : 1. Exécutez le script suivant avec l'autorisation root et partagez le fichier de sortie (cloudsecure-agent-symptoms.zip). a. /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh 2. Exécutez les commandes suivantes une par une avec l'autorisation root et partagez la sortie. a. id cssys b. groups cssys c. cat /etc/os-release

Le script cloudsecure-agent-symptom-collector.sh échoue avec l'erreur suivante. [root@machine tmp]# /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh Collecte du journal de service Collecte des journaux d'application Collecte des configurations d'agent Prise d'un instantané de l'état du service Prise d'un instantané de la structure du répertoire de l'agent …………………. …………………. /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh : ligne 52 : zip : commande introuvable ERREUR : Échec de la création de /tmp/cloudsecure-agent-symptoms.zip

L'outil Zip n'est pas installé. Installez l’outil zip en exécutant la commande « yum install zip ». Exécutez ensuite à nouveau cloudsecure-agent-symptom-collector.sh.

L'installation de l'agent échoue avec useradd : impossible de créer le répertoire /home/cssys

Cette erreur peut se produire si le répertoire de connexion de l'utilisateur ne peut pas être créé sous /home, en raison d'un manque d'autorisations. La solution de contournement serait de créer un utilisateur cssys et d'ajouter son répertoire de connexion manuellement à l'aide de la commande suivante : sudo useradd user_name -m -d HOME_DIR -m : Créez le répertoire personnel de l'utilisateur s'il n'existe pas. -d : Le nouvel utilisateur est créé en utilisant HOME_DIR comme valeur pour le répertoire de connexion de l'utilisateur. Par exemple, sudo useradd cssys -m -d /cssys, ajoute un utilisateur cssys et crée son répertoire de connexion sous root.

L'agent ne s'exécute pas après l'installation. Systemctl status cloudsecure-agent.service affiche ce qui suit : [root@demo ~]# systemctl status cloudsecure-agent.service agent.service – Workload Security Agent Daemon Service Loaded: loaded (/usr/lib/systemd/system/cloudsecure-agent.service; enabled; vendor preset: disabled) Active: activation (redémarrage automatique) (Result: exit-code) since Tue 2021-08-03 21:12:26 PDT; Il y a 2 s Processus : 25889 ExecStart=/bin/bash /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent (code=exited status=126) PID principal : 25889 (code=exited, status=126), 03 août 21:12:26 démo systemd[1] : cloudsecure-agent.service : processus principal terminé, code=exited, status=126/n/a 03 août 21:12:26 démo systemd[1] : l'unité cloudsecure-agent.service est entrée en état d'échec. 03 août 21:12:26 démo systemd[1] : cloudsecure-agent.service a échoué.

Cela peut échouer car l'utilisateur cssys n'a peut-être pas l'autorisation d'installer. Si /opt/netapp est un montage NFS et si l'utilisateur cssys n'a pas accès à ce dossier, l'installation échouera. cssys est un utilisateur local créé par le programme d'installation de Workload Security qui n'est peut-être pas autorisé à accéder au partage monté. Vous pouvez le vérifier en essayant d'accéder à /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent en utilisant l'utilisateur cssys. Si le message « Autorisation refusée » est renvoyé, l’autorisation d’installation n’est pas présente. Au lieu d'un dossier monté, installez-le dans un répertoire local sur la machine.

L'agent a été initialement connecté via un serveur proxy et le proxy a été défini lors de l'installation de l'agent. Le serveur proxy a maintenant changé. Comment la configuration du proxy de l'agent peut-elle être modifiée ?

Vous pouvez modifier le fichier agent.properties pour ajouter les détails du proxy. Suivez ces étapes : 1. Accédez au dossier contenant le fichier de propriétés : cd /opt/netapp/cloudsecure/conf 2. À l’aide de votre éditeur de texte préféré, ouvrez le fichier agent.properties pour le modifier. 3. Ajoutez ou modifiez les lignes suivantes : AGENT_PROXY_HOST=scspa1950329001.vm.netapp.com AGENT_PROXY_PORT=80 AGENT_PROXY_USER=pxuser AGENT_PROXY_PASSWORD=pass1234 4. Enregistrez le fichier. 5. Redémarrez l'agent : sudo systemctl restart cloudsecure-agent.service