Déployer des agents de sécurité de charge de travail
Suggérer des modifications
PDF
Les agents de sécurité des charges de travail surveillent l'activité des utilisateurs et détectent les menaces potentielles pour la sécurité de votre infrastructure de stockage. Ce guide couvre l'installation d'un agent, l'ouverture des ports réseau requis, la gestion des actions de pause/reprise et d'épinglage/désépinglage, ainsi que la vérification de l'agent après le déploiement. Avant de commencer, assurez-vous que l'hôte de l'agent répond aux exigences indiquées dans Workload Security Agent Requirements.
Avant de commencer
-
Vérifiez que l’hôte de l’agent répond aux exigences système, de package et de réseau décrites dans les exigences de l’agent Workload Security (4 cœurs de processeur, 16 Go de RAM, /opt/netapp avec au moins 35 Go d’espace libre, distribution Linux prise en charge, unzip / zip / sshpass, IP statique, NTP).
-
Les privilèges sudo sont requis pour l'installation, l'exécution de scripts et la désinstallation.
-
Lors de l'installation, un utilisateur local cssys et un groupe local cssys sont créés sur la machine. Si la stratégie ne permet pas de créer un utilisateur local et exige plutôt Active Directory, créez un utilisateur avec le nom d'utilisateur cssys dans Active Directory avant l'installation.
-
Un Agent prend en charge un maximum de 50 collecteurs de données (tous types confondus — par exemple Active Directory, LDAP et ONTAP SVM collectors), avec un plafond d'environ 20 000 événements par seconde. Planifiez la capacité avec l'Event Rate Checker avant de déployer de nombreux collecteurs sur un Agent.
-
Si l'agent utilise un proxy pour accéder au SaaS, assurez-vous d'avoir à disposition l'hôte, le port et les identifiants du proxy. Vous configurez le proxy lors de l'installation, à l'étape 4.
Étapes pour installer un agent
-
Connectez-vous en tant qu’administrateur ou propriétaire de compte à votre environnement Workload Security.
-
Sélectionnez Collectors > Agents > +Agent. Le système affiche la page Ajouter un agent.
-
Dans le panneau Configuration requise du serveur d'agent, cliquez sur Linux Versions Supported (i) et Minimum Server Requirements (i) pour confirmer que le système d'exploitation hôte est pris en charge et correctement dimensionné.
-
Si votre réseau utilise un serveur proxy, développez la section « Optionnel : Paramètres du serveur proxy » > Afficher les instructions et cliquez sur Copier les paramètres du serveur proxy. Sur l’hôte de l’agent, exécutez la commande copiée dans un terminal, en remplaçant USER, PASSWORD, PROXY_SERVER et PORT par vos propres valeurs :
export https_proxy='USER:PASSWORD@PROXY_SERVER:PORT'
Exécutez cette commande dans le même terminal que celui utilisé pour l’extrait de code du programme d’installation, afin que ce dernier hérite du paramètre de proxy.
-
Cliquez sur « Copier l’extrait de programme d’installation ». Cet extrait contient une clé unique, valable 2 heures et pour un seul Agent. Exécutez-le immédiatement et ne le réutilisez pas pour un second Agent. Pour l’examiner au préalable, cliquez sur « Afficher l’extrait de programme d’installation ».
-
Sur le serveur de l'agent, ouvrez un terminal, collez la commande d'installation et exécutez-la. Privilégiez un répertoire de travail vide dont vous êtes propriétaire (par exemple mkdir cloudsecure && cd cloudsecure) afin que chmod lors de l'installation n'échoue pas sur des fichiers appartenant à d'autres utilisateurs.
-
Une fois l'installation terminée avec succès, le programme d'installation affiche un message de réussite et le service Agent démarre. Retournez dans le navigateur et cliquez sur Complete Setup pour terminer l'ajout de l'Agent. "New agent detected" s'affichera en cas d'installation réussie.
Après avoir terminé
-
Confirmez que l’agent apparaît comme connecté dans Workload Security > Collectors > Agents.
-
Ouvrez les ports de rappel FPolicy/EMS sur l'hôte de l'Agent (voir la configuration réseau ci-dessous).
-
Configurez un collecteur d'annuaire utilisateur (Active Directory ou LDAP) pour chaque domaine dont les utilisateurs accèdent aux SVM surveillées, idéalement avant ou en même temps que le premier collecteur SVM ONTAP. Sans cela, Activity Forensics peut afficher les SID au lieu des noms d'utilisateur. La fonction Test Connection n'est pas disponible pour les collecteurs d'annuaire utilisateur.
-
Configurez un ou plusieurs collecteurs de données ONTAP SVM. Privilégiez l+adresse IP de gestion du cluster et le nom de la SVM avec les informations d'identification du cluster, puis exécutez Test Connection avant d'enregistrer afin que les vérifications réseau et RBAC soient validées.
-
Restez dans les limites de la capacité de l'Agent : au maximum 50 collecteurs par Agent ; utilisez le vérificateur de taux d’événements pour dimensionner en fonction du taux d’événements de pointe.
Modifiez le proxy après l'installation
Si le proxy change après l'installation de l'Agent, mettez à jour la configuration de l'Agent et redémarrez le service.
-
Accédez au répertoire de configuration : cd /opt/netapp/cloudsecure/conf
-
Modifiez le fichier agent.properties et définissez AGENT_PROXY_HOST, AGENT_PROXY_PORT, et si nécessaire AGENT_PROXY_USER et AGENT_PROXY_PASSWORD.
-
Redémarrez l’agent : sudo systemctl restart cloudsecure-agent.service
Si l'agent est derrière une inspection SSL (par exemple Zscaler), désactivez l'inspection SSL pour *.cloudinsights.netapp.com et l'hôte agentlogin régional. Workload Security ne fonctionne pas correctement lorsque des certificats intermédiaires re-signent les points de terminaison SaaS.
Configuration réseau
Ouvrez les ports TCP qu'ONTAP utilise pour envoyer les événements FPolicy (et EMS) à l'Agent. Il n'est pas nécessaire d'ouvrir toute la plage 35000–55000. Dimensionnez la réservation pour les collecteurs sur cet Agent : chaque SVM utilise jusqu'à 4 ports (2 par protocole activé — NFS et CIFS/SMB). Pour un Agent pleinement chargé (50 collecteurs), réservez environ 200 ports dans la plage 35000–55000. Augmentez la réservation si nécessaire.
Ouvrez la plage vers l’hôte Agent, y compris tout pare-feu local. Assurez-vous également que les LIF de données SVM peuvent atteindre l’Agent pour les événements FPolicy et (si vous utilisez des fonctionnalités basées sur EMS telles que ARP) que l’adresse IP de gestion du cluster peut atteindre l’Agent sur les mêmes ports réservés. Consultez les exigences de l’Agent Workload Security pour les tableaux complets d’égresse réseau et cloud.
Exemple — firewalld (permanent) :
sudo firewall-cmd --permanent --zone=public --add-port=35000-55000/tcp
sudo firewall-cmd --reload
Vérifiez la règle :
Sur les systèmes utilisant firewalld (par exemple RHEL / CentOS 8+):
sudo firewall-cmd --zone=public --list-ports | grep 35000
Exemple de sortie : 35000-55000/tcp
Sur les systèmes utilisant iptables (par exemple les anciennes versions de RHEL / CentOS 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
Test Connection (on the ONTAP SVM collector page) ne vérifie qu'un sous-ensemble de ports dans cette plage. Gardez l'ensemble complet des ports réservés ouverts sur l'Agent._
Vérification post-installation
Après une installation réussie, vérifiez les points suivants sur l'hôte de l'agent et dans l'interface utilisateur :
-
État de l'interface utilisateur : Collectors > Agents affiche l'Agent comme Connected (not NOT_CONNECTED).
-
Service : sudo systemctl status cloudsecure-agent.service signale actif (running).
-
Utilisateur : l’identifiant cssys et le groupe cssys réussissent (l’utilisateur/groupe cssys local existe ou le compte cssys AD est disponible).
-
Chemin du disque : /opt/netapp se trouve sur un disque local auquel cssys peut accéder (et non sur un montage NFS que l’utilisateur local ne peut pas utiliser).
-
Ports : Le sous-ensemble réservé 35000–55000 est ouvert en entrée vers l’Agent (firewall-cmd ou vérification iptables ci-dessus).
-
Chemin SaaS : Le trafic TCP sortant 443 vers *.cloudinsights.netapp.com et les points de terminaison agentlogin de votre région réussit (pas de réécriture d’inspection SSL).
Si l’agent ne démarre pas avant que les journaux d’application n’existent, consultez journalctl -u cloudsecure-agent.service — les erreurs de démarrage précoces sont consignées dans le journal du service, et non dans agent.log.
Mises à jour de l'agent de contrôle : épingler et désépingler
Par défaut, Workload Security met à jour automatiquement les Agents. L'épinglage d'un Agent suspend ces mises à jour automatiques, de sorte que l'Agent et les collecteurs qu'il héberge restent à leur version actuelle.
Remarque : Les fonctions Épingler et Désépingler s’appliquent à un Agent et sont disponibles uniquement via l’API. Les fonctions Pause et Reprendre sont des commandes du collecteur — elles ne s’appliquent pas à un Agent — et vous pouvez les exécuter depuis l’interface utilisateur ou l’API. Voir Configuration du collecteur de données ONTAP SVM._ _
| Contrôle | Comment vous l’exécutez | Ce qu'il fait |
|---|---|---|
Épingle |
API cloudsecure_config.agents uniquement. Non disponible dans l'interface utilisateur. |
Les mises à jour automatiques sont suspendues. L'agent et les collecteurs qu'il héberge restent à leur version actuelle. |
Détacher |
API cloudsecure_config.agents uniquement. Non disponible dans l'interface utilisateur. |
Les mises à jour automatiques reprennent. L’Agent récupère la dernière version disponible et se met à jour ainsi que ses collecteurs. |
Un agent épinglé reprend les mises à jour automatiques lorsque l'un des événements suivants se produit :
-
Vous détachez l'agent.
-
30 jours se sont écoulés. La période de 30 jours commence le jour de la mise à jour la plus récente de l'Agent, et non le jour où vous épinglez l'Agent.
Dans les deux cas, l'Agent se met à jour lors de la prochaine actualisation de Workload Security après que la condition est remplie. Prévoyez jusqu'à cinq minutes pour qu'une demande d'épinglage ou de désépinglage prenne effet.
Pour épingler ou désépingler un Agent, utilisez les API cloudsecure_config.agents. Vous pouvez consulter les versions actuelles des Agents dans Workload Security > Collectors > Agents.
Versions des agents affichées dans l'onglet Agents.
Épingler et désépingler un Agent à la fois
L'épinglage et le désépinglage sont également pris en charge au niveau du locataire. Si vous désépinglez au niveau du locataire, chaque Agent du locataire est mis à niveau automatiquement et immédiatement.
Utilisez plutôt l'épinglage et le désépinglage au niveau de l'Agent. Le contrôle au niveau de l'Agent est plus granulaire : seul l'Agent que vous désépinglez reçoit la mise à niveau, de sorte que l'effet d'une nouvelle version est limité à cet Agent et aux collecteurs qu'il héberge.
| Portée | Épingle | Détacher |
|---|---|---|
Tous les agents du locataire |
POST /v1/cloudsecure/agents/configuration |
SUPPRIMER /v1/cloudsecure/agents/configuration |
Un seul agent (recommandé) |
POST /v1/cloudsecure/agents/ {agentId}/configuration |
SUPPRIMER /v1/cloudsecure/agents/ {agentId}/configuration |
Approche suggérée
-
Épinglez les Agents que vous souhaitez conserver dans leur version actuelle.
-
Désépinglez un agent et laissez-le se mettre à jour.
-
Vérifiez que l’agent repasse à l’état Connecté et que ses collecteurs repassent à l’état En cours d’exécution.
-
Désactivez les Agents restants par lots, afin qu’un problème inattendu n’affecte qu’une partie de votre environnement.
Meilleures pratiques pour les agents
Ces pratiques s'appliquent à l'Agent. Pour les pratiques relatives au collecteur, notamment quand suspendre un collecteur, consultez la section Configuring the ONTAP SVM Data Collector.
-
Utilisez les fonctions « épingler » et « désépingler » pour contrôler le moment où un Agent est mis à jour. Vous n'avez pas besoin de suspendre les collecteurs pour contrôler la mise à jour.
-
Épinglez et désépinglez au niveau de l'Agent plutôt qu'au niveau du tenant, afin qu'une mise à niveau n'affecte qu'un Agent et ses collecteurs à la fois.
-
Ne prévoyez pas de rester épinglé indéfiniment. Un agent épinglé se met à jour automatiquement 30 jours après sa dernière mise à jour.
-
Respectez la capacité des agents : 50 collecteurs maximum par agent (tous types confondus), pour un plafond de 20 000 événements par seconde. Environ 10 collecteurs conviennent à 4 cœurs de processeur et 16 Go de RAM ; environ 20 collecteurs conviennent à 4 cœurs de processeur et 32 Go de RAM.
-
Dimensionnez l'Agent en fonction du taux d'événements maximal à l'aide de l'Event Rate Checker avant d'ajouter des collecteurs, et migrez un collecteur vers un autre Agent plutôt que de surcharger un seul Agent.
-
Répartissez les collecteurs entre les Agents afin que la maintenance sur un Agent n'interrompe pas la surveillance de chaque SVM.
-
Attribuez à l'hôte Agent une adresse IP statique et gardez son horloge synchronisée avec ONTAP à l'aide du protocole NTP.
-
Gardez ouverts les ports de rappel FPolicy réservés vers l’Agent, y compris dans le pare-feu hôte (voir Network configuration).
Dépannage
Pour les échecs d'installation et de connectivité de l'agent (système d'exploitation non pris en charge, absence de unzip/zip, problèmes d'autorisation cssys, NOT_CONNECTED, modifications du proxy, échecs du symptom-collector), consultez la section Dépannage du collecteur de données ONTAP SVM — Installation et état de l'agent, ainsi que Workload Security Agent Requirements.
Pour collecter un ensemble de diagnostics pour le support (exécutez en tant que root) :
sudo /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh -o /tmp
Joignez le fichier cloudsecure-agent-symptoms.zip (ou le fichier zip créé dans /tmp) à la demande, ainsi que votre numéro de série Data Infrastructure Insights. Assurez-vous que le package zip est installé sur l’hôte Agent avant d’exécuter le collecteur de symptômes.