Que sont les connecteurs
Les connecteurs de Cisco Secure Workload sont des intégrations qui permettent à Cisco Secure Workload d’interagir avec diverses ressources et de recueillir des données à partir de diverses ressources à des fins différentes. Pour configurer et utiliser les connecteurs, dans le volet de navigation, choisissez
.![]() Note |
Les connecteurs nécessitent une appliance virtuelle. Pour en savoir plus, consultez la section Appliances virtuelles pour les connecteurs. |
Connecteurs pour l’acquisition de flux
Les connecteurs transmettent les observations de flux de différents commutateurs de réseau, routeurs et autres boîtiers intermédiaires (tels que les équilibreurs de charge et les pare-feu) à Cisco Secure Workload à des fins d'acquisition de flux.
Cisco Secure Workload prend en charge l’acquisition de flux par l’intermédiaire de NetFlow v9, IPfIX et des protocoles personnalisés. En plus des observations des flux, les connecteurs de boîtier intermédiaire relient les flux côté client et côté serveur pour comprendre quels flux client sont liés à quels flux serveur.
Connecteur |
Description |
Déployé sur une appliance virtuelle |
---|---|---|
NetFlow |
Recueillez les données télémétriques NetFlow V9 ou IP-fIX à partir d’appareils réseau comme les routeurs et les commutateurs. |
Acquisition de Cisco Secure Workload |
F5 BIG-IP |
Recueillez les données télémétriques de F5 BIG-IP, reliez les flux côté client et côté serveur, et enrichissez l’inventaire du client avec les attributs utilisateur. |
Acquisition de Cisco Secure Workload |
Citrix Netscaler |
Recueillez la télémétrie de Citrix ADC, reliez des flux côté client et côté serveur. |
Acquisition de Cisco Secure Workload |
Pare-feu du connecteur sécurisé Cisco |
Recueillez les données de télémétrie à partir de Cisco Secure Firewall ASA, de Cisco Secure Firewall Threat Defense, et reliez les flux côté client et côté serveur. |
Acquisition de Cisco Secure Workload |
Meraki |
Recueillez les données de télémétrie des pare-feux Meraki. |
Acquisition de Cisco Secure Workload |
ERSPAN |
Recueillir les données de télémétrie ERSPAN à partir de périphériques réseau qui prennent en charge ERSPAN |
Acquisition de Cisco Secure Workload |
Consultez aussi |
– |
Pour en savoir plus sur les appliances virtuelles nécessaires, consultez la section Virtual Appliances pour les connecteurs.
Connecteur NetFlow
Le connecteur NetFlow permet à Cisco Secure Workload d’intégrer les observations de flux des routeurs et des commutateurs du réseau.
Cette solution permet aux hôtes d’éviter d’exécuter des agents logiciels, car les commutateurs Cisco relayent les enregistrements NetFlow à un connecteur NetFlow hébergé dans un appareil d'acquisition Cisco Secure Workload pour traitement.
![](/c/dam/en/us/td/i/400001-500000/470001-480000/472001-473000/472462.jpg)
Qu’est-ce que NetFlow
Le protocole NetFlow permet aux routeurs et aux commutateurs d’agréger le trafic qui les traverse en flux et d’exporter ces flux vers un collecteur de flux.
Le collecteur de flux reçoit ces enregistrements de flux et les stocke pour les interroger et les analyser hors ligne. Les routeurs et commutateurs Cisco prennent en charge NetFlow.
En règle générale, la configuration comprend les étapes suivantes :
-
Activez la fonctionnalité NetFlow sur un ou plusieurs périphériques réseau et configurez les modèles de flux que les périphériques doivent exporter.
-
Configurez les informations de point terminal du collecteur NetFlow sur les périphériques réseau distants. Ce collecteur NetFlow est à l’écoute sur le point terminal configuré pour recevoir et traiter les enregistrements de flux NetFlow.
Acquisition de flux dans Cisco Secure Workload
Le connecteur NetFlow est essentiellement un collecteur NetFlow. Le connecteur reçoit les enregistrements de flux des périphériques réseau et les transfère à Cisco Secure Workload pour une analyse du flux. Vous pouvez activer un connecteur NetFlow sur un appareil d'acquisition Cisco Secure Workload et l’exécuter en tant que conteneur Docker.
Le connecteur NetFlow s’enregistre également auprès de Cisco Secure Workload en tant qu’agent NetFlow Cisco Secure Workload. Le connecteur NetFlow désencapsule les paquets de protocole NetFlow (c'est-à-dire les enregistrements de flux); traite ensuite les flux et les signale comme un agent Cisco Secure Workload normal. Contrairement à un agent de visibilité approfondie, il ne signale aucune information sur le processus ou l’interface.
![]() Remarque |
Le connecteur NetFlow prend en charge les protocoles NetFlow v9 et IPFIX. |
![]() Remarque |
Chaque connecteur NetFlow ne doit signaler les flux que pour un seul VRF. Le connecteur exporte les flux et les place dans le VRF en fonction de la configuration du VRF de l’agent dans la grappe Cisco Secure Workload. Pour configurer le VRF pour le connecteur, accédez à : Configuration. Dans cette page, sous la section Agent Remote VRF Configurations (Configurations VRF à distance de l'agent), cliquez sur Create Config (Créer une configuration) et fournissez les détails du connecteur. , puis cliquez sur l’ongletLe formulaire vous demande de fournir : le nom du VRF, le sous-réseau IP du connecteur et la plage de numéros de port qui peut potentiellement envoyer des enregistrements de flux à la grappe. |
Limitation de débit
Le connecteur NetFlow accepte jusqu’à 15 000 flux par seconde. Notez qu’un paquet NetFlow v9 ou IPFIX peut contenir un ou plusieurs enregistrements de flux et de modèle. Le connecteur NetFlow analyse les paquets et identifie les flux. Si le connecteur analyse plus de 15 000 flux par seconde, il abandonne les enregistrements de flux supplémentaires.
Notez également que le client Cisco Secure Workload ne prend en charge le connecteur NetFlow que si le débit se trouve dans cette limite acceptable.
Si le débit dépasse 15 000 flux par seconde, nous vous recommandons de commencer par régler le débit pour qu’il respecte les limites et de maintenir ce niveau pendant au moins trois jours (pour exclure les problèmes liés à un débit entrant plus élevé).
Si le problème persiste, le service d'assistance à la clientèle commence à examiner le problème et à identifier une solution de contournement et/ou une solution appropriée.
Éléments d’information pris en charge
Le connecteur NetFlow prend uniquement en charge les éléments d’information suivants dans les protocoles NetFlow v9 et IPFIX. Pour en savoir plus, consultez Entités IP Flow Information Export (IPFIX).
ID d’élément |
Nom |
Description |
Obligatoire |
---|---|---|---|
1 |
octetDeltaCount |
Nombre d’octets dans les paquets entrants pour ce flux. |
Oui |
2 |
packetDeltaCount |
Nombre de paquets entrants pour ce flux. |
Oui |
4 |
protocolIdentifier |
Valeur du numéro de protocole de l’en-tête du paquet IP. |
Oui |
6 |
tcpControlBits |
Bits de commande TCP observés pour les paquets de ce flux. L’agent gère les indicateurs FIN, SYN, RST, PSH, ACK et URG. |
Non |
7 |
sourceTransportPort |
Identifiant du port source dans l’en-tête de transport. |
Oui |
8 |
sourceIPv4Address |
Adresse source IPv4 dans l’en-tête du paquet IP. |
8 ou 27 |
11 |
destinationTransportPort |
Identifiant du port de destination dans l’en-tête de transport. |
Oui |
12 |
destinationIPv4Address |
Adresse de destination IPv4 dans l’en-tête du paquet IP. |
12 ou 28 |
27 |
sourceIPv6Address |
Adresse source IPv6 dans l’en-tête du paquet IP. |
8 ou 27 |
28 |
destinationIPv6Address |
Adresse de destination IPv6 dans l’en-tête du paquet IP. |
12 ou 28 |
150 |
flowStartSeconds |
Horodatage absolu du premier paquet du flux (en secondes). |
Non |
151 |
flowEndSeconds |
Horodatage absolu du dernier paquet du flux (en secondes). |
Non |
152 |
flowStartMilliseconds |
Horodatage absolu du premier paquet du flux (en millisecondes). |
Non |
153 |
flowEndMilliseconds |
Horodatage absolu du dernier paquet du flux (en millisecondes). |
Non |
154 |
flowStartMicroseconds |
Horodatage absolu du premier paquet du flux (en microsecondes). |
Non |
155 |
flowEndMicroseconds |
Horodatage absolu du dernier paquet du flux (en microsecondes). |
Non |
156 |
flowStartNanoseconds |
Horodatage absolu du premier paquet du flux (en nanosecondes). |
Non |
157 |
flowEndNanoseconds |
Horodatage absolu du dernier paquet du flux (en nanosecondes). |
Non |
Comment configurer NetFlow sur le commutateur
Les étapes suivantes concernent un commutateur Nexus 9000. Les configurations peuvent différer légèrement pour les autres plateformes Cisco. Dans tous les cas, consultez le guide de configuration officiel de Cisco pour la plateforme Cisco que vous configurez.
Procedure
Step 1 |
Entrer en mode de configuration globale.
|
Step 2 |
Activez la fonction NetFlow.
|
Step 3 |
Configurez un enregistrement de flux. L’exemple de configuration suivant montre comment générer des informations de cinq tuples d’un flux dans un enregistrement NetFlow.
|
Step 4 |
Configurez un exportateur de flux. L’exemple de configuration suivant précise la version du protocole NetFlow, l’intervalle d’échange du modèle NetFlow et les détails de point de terminaison du collecteur NetFlow. Préciser l’adresse IP et le port sur lesquels vous activez le connecteur NetFlow sur un appareil d'acquisition Cisco Secure Workload.
|
Step 5 |
Configurez un moniteur de flux. Créez un moniteur de flux et associez-le à un enregistrement de flux et à un exportateur de flux.
|
Step 6 |
appliquez le moniteur de flux à une interface.
Les étapes ci-dessus configurent NetFlow sur le Nexus 9000 pour exporter les paquets de protocole NetFlow v9 pour le trafic entrant passant par l’interface 1/1. Il envoie les enregistrements de flux au 172.26.230.173:4729 sur un protocole UDP. Chaque enregistrement de flux comprend des informations de cinq tuples du trafic et le nombre d’octets/paquets du flux. ![]() |
Comment configurer le connecteur
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Pour les connecteurs NetFlow, les adresses IPv4 et IPv6 (mode double pile) sont prises en charge. Cependant, notez que la prise en charge de la double pile est une fonctionnalité bêta.
Les configurations suivantes sont autorisées sur le connecteur.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
De plus, les ports d’écoute du protocole IPFIX sur le connecteur peuvent être mis à jour sur le conteneur Docker dans l’appareil d'acquisition Cisco Secure Workload à l’aide d’une commande autorisée. Cette commande peut être exécutée sur l’appareil en fournissant l’ID du connecteur, le type de port à mettre à jour et les renseignements sur le nouveau port. L’ID du connecteur se trouve sur la page du connecteur dans l’interface utilisateur Cisco Secure Workload. Pour plus d’informations, consultez l’article mise à jour-écoute-ports.
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs NetFlow sur un seul appareil d'acquisition Cisco Secure Workload |
3 |
Nombre maximal de connecteurs NetFlow sur un détenteur (portée racine) |
10 |
Nombre maximal de connecteurs NetFlow sur Cisco Secure Workload |
100 |
Connecteur F5
Le connecteur F5 permet à Cisco Secure Workload d’acquérir les observations de flux ADC F5 BIG-IP.
Il permet à Cisco Secure Workload de surveiller à distance les observations de flux sur les ADC F5 BIG-IP, d’assembler les flux côté client et côté serveur et d’annoter les utilisateurs sur les adresses IP clients (si les informations sur les utilisateurs sont disponibles).
Grâce à cette solution, les hôtes n’ont pas besoin d’exécuter des agents logiciels, car les ADC F5 BIG-IP configurent l’exportation des enregistrements IPFIXvers le connecteur F5 pour traitement.
![Connecteur F5](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467240.jpg)
What is F5 BIG-IP IPFIX
F5 BIG-IP IPFIX logging collects flow data for traffic going through the F5 BIG-IP and exports IPFIX records to flow collectors.
Typically, the setup involves the following steps:
-
Create IPFIX Log-Publisher on F5 BIG-IP appliance.
-
Configure the IPFIX Log-Destination on the F5 BIG-IP appliance. This log-destination will be listening on configured endpoint to receive and process flow records.
-
Create an F5 iRule that publishes IPFIX flow records to the log-publisher.
-
Add the F5 iRule to the virtual server of interest.
Note
F5 connector supports F5 BIG-IP software version 12.1.2 and above.
Acquisition de flux dans Cisco Secure Workload
Le connecteur F5 BIG-IP est principalement un collecteur IPFIX. Le connecteur reçoit les enregistrements de flux des CAN F5 BIG-IP, connecte les flux avec NAT et les transfère à Cisco Secure Workload pour une analyse des flux. En outre, si la configuration LDAP est fournie au connecteur F5, il détermine les valeurs des attributs LDAP configurés d’un utilisateur associé à la transaction (si F5 authentifie l’utilisateur avant de traiter la transaction). Les attributs sont associés à l’adresse IP du client où le flux s’est produit.
![]() Remarque |
Le connecteur F5 prend uniquement en charge le protocole IPFIX. |
![]() Remarque |
Chaque connecteur F5 ne signale les flux que pour un VRF. Le connecteur place les flux qu’il exporte dans le VRF en fonction de la configuration du VRF de l’agent dans la grappe Cisco Cisco Secure Workload. Pour configurer le VRF pour le connecteur, accédez à : Configuration. Dans cette page, sous la section Agent Remote VRF Configurations (Configurations VRF à distance de l'agent), cliquez sur l’onglet Create Config (Créer une configuration) et fournissez les détails du connecteur. Le formulaire vous demande de fournir : le nom du VRF, le sous-réseau IP du connecteur et la plage de numéros de port qui peut potentiellement envoyer des enregistrements de flux à la grappe. , puis cliquez sur l’onglet |
How to configure IPFIX on F5 BIG-IP
The following steps are for F5 BIG-IP load balancer. (Ref: Configuring F5 BIG-IP for IPFIX)
Purpose |
Description |
---|---|
1. Create a pool of IPFIX collectors. |
On F5 BIG-IP appliance, create the pool of IPFIX collectors. These are the IP addresses associated with F5 connectors on a Cisco Secure Workload Ingest appliance. F5 connectors run in Docker containers on the VM listen on port 4739 for IPFIX packets. |
2. Create a log-destination. |
The log destination configuration on F5 BIG-IP appliance specifies the actual pool of IPFIX collectors that should be used. |
3. Create a log-publisher. |
A log publisher specifies where F5 BIG-IP sends the IPFIX messages. The publisher is bound with a log-destination. |
4. Add a F5 and Cisco Secure Workload approved iRule. |
Secure Workload and F5 developed iRules that will export flow records to F5 connectors. These iRules will export complete information about a given transaction: including all the endpoints, byte and packet counts, flow start and end time (in milliseconds). F5 connectors will create 4 independent flows and match each flow with its related flow. |
5. Add the iRule to the virtual server. |
In the iRule settings of a virtual server, add the Secure Workload, approved iRule to the virtual server. |
The above steps configures IPFIX on F5 BIG-IP load balancer to export IPFIX protocol packets for traffic going through the appliance. Here is a sample config of F5.
![Running configuration of IPFIX on F5 BIG-IP load balancer](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467241.jpg)
In the example above, flow records will be published to ipfix-pub-1. ipfix-pub-1 is configured with log-destination ipfix-collector-1 which sends the IPFIX messages to IPFIX pool ipfix-pool-1. ipfix-pool-1 has 10.28.118.6 as one of the IPFIX collectors. The virtual server vip-1 is configured with IPFIX iRule ipfix-rule-1 which specifies the IPFIX template and how the template gets filled and sent.
-
F5 and Cisco Secure Workload approved iRule for TCP virtual server can be found in the following file See L4 iRule for TCP virtual server.
F5 and Cisco Secure Workload approved iRule for UDP virtual server can be found in the following file.
F5 and Cisco Secure Workload approved iRule for HTTPS virtual server with authentication enabled can be found in the following file.
![]() Note |
Before using the iRule downloaded from this guide, please update the log-publisher to point to the log- publisher configured in the F5 connector where the iRule will be added. |
![]() Note |
F5 has published a GitHub repository, f5-tetration to help users get started with flow-stitching. The iRules for publishing IPFIX records to F5 connector for various protocol types are available at: f5-tetration/irules. Please visit this site for latest iRule definitions. In addition, F5 also developed a script to: (1) install the correct iRule for the virtual servers, (2) add a pool of IPFIX collector endpoints (where F5 connectors listen for IPFIX records), (3) configure the log-collector and log-publisher, and (4) bind the correct iRule to the virtual servers. This tool minimizes manual configuration and user error while enabling flow-stitching use-case. The script is available at f5-tetration/scripts. |
Comment configurer le connecteur
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs.
Les configurations suivantes sont autorisées sur le connecteur.
-
LDAP : la configuration LDAP prend en charge la découverte des attributs LDAP et fournit un flux de travail pour choisir l’attribut qui correspond au nom d’utilisateur et une liste de six attributs maximum à récupérer pour chaque utilisateur. Pour en savoir plus, consultez la section Découverte.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
En outre, les ports d’écoute du protocole IPFIX sur le connecteur peuvent être mis à jour sur le conteneur Docker dans l’appareil d'acquisition Cisco Secure Workload à l’aide d’une commande qui peut être exécutée sur le conteneur. Cette commande peut être exécutée sur l’appareil en fournissant l’ID du connecteur, le type de port à mettre à jour et les renseignements sur le nouveau port. L’ID du connecteur se trouve sur la page du connecteur dans l’interface utilisateur Cisco Secure Workload. Pour plus d’informations, consultez l’article mise à jour-écoute-ports.
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs F5 sur un dispositif d'acquisition Cisco Secure Workload |
3 |
Nombre maximal de connecteurs F5 sur un détenteur (portée racine) |
10 |
Nombre maximal de connecteurs F5 sur Cisco Secure Workload |
100 |
Connecteur NetScaler
Le connecteur NetScaler permet à Cisco Secure Workload d’acquérir les observations de flux des ADC Citrix (Citrix NetScalers). Il permet à Cisco Secure Workload de surveiller à distance les observations de flux sur les ADC Citrix et d’assembler les flux côté client et côté serveur. Grâce à cette solution, les hôtes n’ont pas besoin d’exécuter des agents logiciels, car les ADC Citrix sont configurés pour exporter les enregistrements IPfFIX vers le connecteur NetScaler pour traitement.
![Connecteur NetScaler](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467242.jpg)
What is Citrix NetScaler AppFlow
Citrix NetScaler AppFlow collects flow data for traffic going through the NetScaler and exports IPFIX records to flow collectors. Citrix AppFlow protocol uses IPFIX to export the flows to flow collectors. Citrix AppFlow is supported in Citrix NetScaler load balancers.
Typically, the setup involves the following steps:
-
Enable AppFlow feature on one or more Citrix NetScaler instances.
-
Configure the AppFlow collector endpoint information on the remote network devices. This AppFlow collector will be listening on configured endpoint to receive and process flow records.
-
Configure AppFlow actions and policies to export flow records to AppFlow collectors.
![]() Note |
NetScaler connector supports Citrix ADC software version 11.1.51.26 and above. |
Acquisition de flux dans Cisco Secure Workload
Le connecteur NetScaler est essentiellement un collecteur Citrix AppFlow (IPFIX). Le connecteur reçoit les enregistrements de flux des ADC Citrix, regroupe les flux avec NAT et les transfère à Cisco Secure Workload pour une analyse des flux. Un connecteur NetScaler peut être activé sur un appareil d'acquisition Cisco Cisco Secure Workload et s’exécute en tant que conteneur Docker. Le connecteur NetScaler s’enregistre également auprès de Cisco Secure Workload en tant qu’agent NetScaler Cisco Secure Workload.
![]() Note |
Le connecteur NetScaler prend uniquement en charge le protocole IPFIX. |
![]() Note |
Chaque connecteur NetScaler ne doit signaler les flux que pour un seul VRF. Les flux exportés par le connecteur sont placés dans le VRF en fonction de la configuration du VRF de l’agent dans la grappe Cisco Secure Workload. Pour configurer le VRF pour le connecteur, accédez à : , puis cliquez sur l’onglet Configuration. Dans cette page, sous la section Agent Remote VRF Configurations Configurations VRF d'agents distants), cliquez sur Create Config (Créer une configuration) et fournissez les détails du connecteur. Le formulaire demande à l’utilisateur de fournir le nom du VRF, le sous-réseau IP du connecteur et la plage de numéros de port qui peut potentiellement envoyer des enregistrements de flux à la grappe. |
How to configure AppFlow on NetScaler
The following steps are for NetScaler load balancer. (Ref: Configuring AppFlow)
Procedure
Step 1 |
Enable AppFlow on NetScaler.
|
Step 2 |
Add AppFlow collector endpoints. The collector receives the AppFlow records from NetScaler. Please specify the IP and port of NetScaler connector enabled on a Cisco Secure Workload Ingest appliance as an AppFlow collector.
|
Step 3 |
Configure an AppFlow action. This lists the collectors that will get AppFlow records if the associated AppFlow policy matches.
|
Step 4 |
Configure an AppFlow policy. This is a rule that has to match for an AppFlow record to be generated.
|
Step 5 |
Bind AppFlow policy to Virtual Server. Traffic hitting the IP of the virtual server (VIP) will be evaluated for AppFlow policy matches. On a match, a flow record is generated and sent to all collectors listed in the associated AppFlow action.
|
Step 6 |
Optionally, bind AppFlow policy globally (for all virtual servers). An AppFlow policy could also be bound globally to all virtual servers. This policy applies to all traffic that flows through Citrix ADC.
|
Step 7 |
Optionally, template refresh interval.
The above steps configures AppFlow on Citrix NetScaler load balancer to export IPFIX protocol packets for traffic going through NetScaler. The flow records will be sent to either 172.26.230.173:4739 (for traffic going through vserver lb1) and to 172.26.230.184:4739 (for all traffic going through the NetScaler). Each flow record includes 5 tuple information of the traffic and the byte/packet count of the flow. The following screenshot shows a running configuration of AppFlow on a Citrix NetScaler load balancer. ![]() |
Comment configurer le connecteur
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Les configurations suivantes sont autorisées sur le connecteur.
-
Log (Journal) : Pour en savoir plus, consultez Log Configuration (Configuration des journaux).
De plus, les ports d’écoute du protocole IPFIX sur le connecteur peuvent être mis à jour sur le conteneur Docker dans l'appareil d'acquisition Cisco Secure Workload à l’aide d’une commande autorisée. Cette commande peut être exécutée sur l’appareil en fournissant l’ID du connecteur, le type de port à mettre à jour et les renseignements sur le nouveau port. L’ID du connecteur se trouve sur la page du connecteur dans l’interface utilisateur Cisco Secure Workload. . Pour plus d’informations, consultez l’article mise à jour-écoute-ports.
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs NetScaler sur un appareil d'acquisition Cisco Secure Workload |
3 |
Nombre maximal de connecteurs NetScaler sur un détenteur (portée racine) |
10 |
Nombre maximal de connecteurs NetScaler sur Cisco Secure Workload |
100 |
Cisco Secure Firewall Connector
Secure Firewall Connector (formerly known as ASA Connector) allows Cisco Secure Workload to ingest flow observations from Secure Firewall ASA (formerly known as Cisco ASA) and Secure Firewall Threat Defense (formerly known as Firepower Threat Defense or FTD). Using this solution, the hosts do not need to run software agents, because the Cisco switches will relay NetFlow Secure Event Logging (NSEL) records to Secure Firewall Connector hosted in a Cisco Secure Workload Ingest appliance for processing.
![Secure Firewall Connector](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467244.jpg)
Cisco Secure Firewall ASA NetFlow Secure Event Logging (NSEL) provides a stateful, IP flow monitoring that exports significant events in a flow to a NetFlow collector. When an event causes a state change on a flow, an NSEL event is triggered that sends the flow observation along with the event that caused the state change to the NetFlow collector. The flow collector receives these flow records and stores them in their flow storage for offline querying and analysis.
Typically, the setup involves the following steps:
-
Enable NSEL feature on Secure Firewall ASA and/or Secure Firewall Threat Defense.
-
Configure the Secure Firewall connector endpoint information on Secure Firewall ASA and/or Secure Firewall Threat Defense. Secure Firewall connector will be listening on configured endpoint to receive and process NSEL records.
Acquisition de flux dans Cisco Secure Workload
Le connecteur de Cisco Secure Firewall est essentiellement un collecteur NetFlow. Le connecteur reçoit les enregistrements NSEL de Cisco Secure Firewall ASA et de Cisco Secure Firewall Threat Defense et les transmet à Cisco Secure Workload pour analyse du flux. Le connecteur de Cisco Secure Firewall peut être activé sur un appareil d'acquisition Cisco Secure Workload et s’exécute en tant que conteneur Docker.
Le connecteur de Cisco Secure Firewall s’enregistre également auprès de Cisco Secure Workload en tant qu’agent Cisco Secure Workload. Le connecteur de Cisco Secure Firewall désencapsule les paquets de protocole NSEL (c.-à-d. les enregistrements de flux). traite ensuite les flux et les signale comme un agent Cisco Secure Workload normal. Contrairement à un agent de visibilité approfondie, il ne signale aucune information sur le processus ou l’interface.
![]() Note |
Le connecteur de Cisco Secure Firewall prend en charge le protocole NetFlow v9. |
![]() Note |
Chaque connecteur Cisco Secure Firewall ne doit signaler les flux que pour un seul VRF. Les flux exportés par le connecteur sont placés dans le VRF en fonction de la configuration VRF de l’agent dans la grappe Cisco Secure Workload. Pour configurer le VRF pour le connecteur, accédez à : , puis cliquez sur l’onglet Configuration. Dans cette page, sous la section Agent Remote VRF Configurations Configurations VRF d'agents distants), cliquez sur Create Config (Créer une configuration) et fournissez les détails du connecteur. Le formulaire demande à l’utilisateur de fournir le nom du VRF, le sous-réseau IP du connecteur et la plage de numéros de port qui peut potentiellement envoyer des enregistrements de flux à la grappe. |
Gestion des événements NSEL
Le tableau suivant montre comment les divers événements NSEL sont gérés par le connecteur Secure Firewall. Pour en savoir plus sur ces éléments, consultez le document Entités d'exportation d'informations sur les flux IP (IPFIX).
ID de l’élément de l’événement de flux : 233 Nom de l’élément : NF_F_FW_EVENT |
Événement de flux étendu ID de l’élément : 33002 Nom de l’élément : NF_F_FW_EXT_EVENT |
Action sur le connecteur de Cisco Secure Firewall |
---|---|---|
0 (par défaut, ignorez cette valeur) |
Ce n’est pas important |
Aucune opération |
1 (Flux créé) |
Ce n’est pas important |
Envoyer le flux à Cisco Secure Workload |
2 (Flux supprimé) |
> 2000 (indique le motif de fin) |
Envoyer le flux à Cisco Secure Workload |
3 (Flux refusé) |
1001 (refusé par la liste de contrôle d’accès d’entrée) |
Envoyer le flux avec le statut rejeté à Cisco Secure Workload |
1002 (refusé par la liste de contrôle d’accès de sortie) |
||
1003 (connexion refusée par l’interface ASA ou ICMP(v6) refusé au périphérique) |
||
1004 (le premier paquet sur TCP n’est pas SYN) |
||
4 (Alerte de flux) |
Ce n’est pas important |
Aucune opération |
5 (Flux mis à jour) |
Ce n’est pas important |
Envoyer le flux à Cisco Secure Workload |
Basé sur l’enregistrement NSEL, le connecteur de Cisco Secure Firewall envoie l’observation de flux à Cisco Secure Workload. Les enregistrements de flux de la NSEL sont bidirectionnels. Ainsi, le connecteur Cisco Secure Firewall envoie deux flux : le flux aller et le flux inverse vers Cisco Secure Workload.
Voici les détails sur l’observation de flux envoyées par le connecteur de Cisco Secure Firewall à Cisco Secure Workload.
Observation du flux aller
Champ |
ID d’élément NSEL |
Nom d’élément NSEL |
---|---|---|
Protocole |
4 |
NF_F_PROTOCOL |
Adresse de la source |
8 |
NF_F_SRC_ADDR_IPV4 |
27 |
NF_F_SRC_ADDR_IPV6 |
|
Source Port (port source) |
7 |
NF_F_SRC_PORT |
Adresse de destination |
12 |
NF_F_DST_ADDR_IPV4 |
28 |
NF_F_DST_ADDR_IPV6 |
|
Destination Port (port de destination) |
11 |
NF_F_DST_PORT |
Heure de début du flux |
152 |
NF_F_FLOW_CREATE_TIME_MSEC |
Nombre d’octets |
231 |
NF_F_FWD_FLOW_DELTA_BYTES |
Nombre de paquets |
298 |
NF_F_FWD_FLOW_DELTA_PACKETS |
Information de flux inverse
Champ |
ID d’élément NSEL |
Nom d’élément NSEL |
---|---|---|
Protocole |
4 |
NF_F_PROTOCOL |
Adresse de la source |
12 |
NF_F_DST_ADDR_IPV4 |
28 |
NF_F_DST_ADDR_IPV6 |
|
Source Port (port source) |
11 |
NF_F_DST_PORT |
Adresse de destination |
8 |
NF_F_SRC_ADDR_IPV4 |
27 |
NF_F_SRC_ADDR_IPV6 |
|
Destination Port (port de destination) |
7 |
NF_F_SRC_PORT |
Heure de début du flux |
152 |
NF_F_FLOW_CREATE_TIME_MSEC |
Nombre d’octets |
232 |
NF_F_REV_FLOW_DELTA_BYTES |
Nombre de paquets |
299 |
NF_F_REV_FLOW_DELTA_PACKETS |
NAT
Si le flux client vers ASA est avec NAT, les enregistrements de flux NSEL indiquent l’adresse IP/le port avec NAT du côté serveur. Le connecteur de Cisco Secure Firewall utilise ces informations pour relier les flux du serveur à l’ASA et de l’ASA au client.
Voici l’enregistrement de flux avec NAT vers l’avant.
Champ |
ID d’élément NSEL |
Nom d’élément NSEL |
---|---|---|
Protocole |
4 |
NF_F_PROTOCOL |
Adresse de la source |
225 |
NF_F_XLATE_SRC_ADDR_IPV4 |
281 |
NF_F_XLATE_SRC_ADDR_IPV6 |
|
Source Port (port source) |
227 |
NF_F_XLATE_SRC_PORT |
Adresse de destination |
226 |
NF_F_XLATE_DST_ADDR_IPV4 |
282 |
NF_F_XLATE_DST_ADDR_IPV6 |
|
Destination Port (port de destination) |
228 |
NF_F_XLATE_DST_PORT |
Heure de début du flux |
152 |
NF_F_FLOW_CREATE_TIME_MSEC |
Nombre d’octets |
231 |
NF_F_FWD_FLOW_DELTA_BYTES |
Nombre de paquets |
298 |
NF_F_FWD_FLOW_DELTA_PACKETS |
Le flux aller sera marqué comme étant lié à l'enregistrement de flux avec NAT dans la direction aller (et vice versa).
Voici l’enregistrement de flux avec NAT dans le sens inverse
Champ |
ID d’élément NSEL |
Nom d’élément NSEL |
---|---|---|
Protocole |
4 |
NF_F_PROTOCOL |
Adresse de la source |
226 |
NF_F_XLATE_DST_ADDR_IPV4 |
282 |
NF_F_XLATE_DST_ADDR_IPV6 |
|
Source Port (port source) |
228 |
NF_F_XLATE_DST_PORT |
Adresse de destination |
225 |
NF_F_XLATE_SRC_ADDR_IPV4 |
281 |
NF_F_XLATE_SRC_ADDR_IPV6 |
|
Destination Port (port de destination) |
227 |
NF_F_XLATE_SRC_PORT |
Heure de début du flux |
152 |
NF_F_FLOW_CREATE_TIME_MSEC |
Nombre d’octets |
232 |
NF_F_REV_FLOW_DELTA_BYTES |
Nombre de paquets |
299 |
NF_F_REV_FLOW_DELTA_PACKETS |
Le flux inverse sera marqué comme étant lié à l'enregistrement du flux avec NAT dans la direction inverse (et vice versa).
![]() Note |
Seuls les ID d’élément NSEL répertoriés dans cette section sont pris en charge par le connecteur Cisco Secure Firewall. |
Heuristique des indicateurs TCP
Les enregistrements NSEL ne contiennent pas d’information sur les indicateurs TCP. Le connecteur Cisco Secure Firewall utilise la méthode heuristique suivante pour définir les indicateurs TCP afin que les flux puissent être analysés de manière plus approfondie par la recherche automatique de politiques :
-
S’il y a au moins un paquet de transfert, ajoute
SYN
aux indicateurs TCP de flux aller. -
S’il y a au moins deux paquets aller et un paquet retour, ajoute
ACK
aux indicateurs TCP de flux aller etSYN-ACK
aux indicateurs TCP de flux inverse. -
Si la condition précédente est vérifiée et que l’événement de flux est Flux supprimé, ajoute
FIN
aux indicateurs TCP aller et arrière.
How to Configure NSEL on Secure Firewall ASA
The following steps are guidelines on how to configure NSEL and export NetFlow packets to a collector (i.e., Secure Firewall connector). Please also refer to the official Cisco configuration guide at Cisco Secure Firewall ASA NetFlow Implementation Guide for more details.
flow-export destination outside 172.29.142.27 4729
flow-export template timeout-rate 1
!
policy-map flow_export_policy
class class-default
flow-export event-type flow-create destination 172.29.142.27
flow-export event-type flow-teardown destination 172.29.142.27
flow-export event-type flow-denied destination 172.29.142.27
flow-export event-type flow-update destination 172.29.142.27
user-statistics accounting
service-policy flow_export_policy global
In this example, Secure Firewall ASA appliance is configured to sent NetFlow packets to 172.29.142.27 on port 4729. In addition, flow-export actions are enabled on flow-create, flow-teardown, flow-denied, and flow-update events. When these flow events occur on ASA, a NetFlow record is generated and sent to the destination specified in the configuration.
Assuming a Secure Firewall connector is enabled on Cisco Secure Workload and listening on 172.29.142.27:4729 in a Cisco Secure Workload Ingest appliance, the connector will receive NetFlow packets from Secure Firewall ASA appliance. The connector processes the NetFlow records as discussed in Handling NSEL Events and exports flow observations to Secure Workload. In addition, for NATed flows, the connector stitches the related flows (client-side and server-side) flows.
Comment configurer le connecteur
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Les configurations suivantes sont autorisées sur le connecteur.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
De plus, les ports d’écoute du protocole IPFIX sur le connecteur peuvent être mis à jour sur le conteneur Docker dans l'appareil d'acquisition Cisco Secure Workload à l’aide d’une commande autorisée. Cette commande peut être exécutée sur l’appareil en fournissant l’ID du connecteur, le type de port à mettre à jour et les renseignements sur le nouveau port. L’ID du connecteur se trouve sur la page du connecteur dans l’interface utilisateur Cisco Secure Workload. Pour plus d’informations, consultez l’article mise à jour-écoute-ports.
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs Cisco Secure Firewall sur un dispositif d'acquisition Cisco Secure Workload |
1 |
Nombre maximal de connecteurs Cisco Secure Firewall sur un détenteur (portée racine) |
10 |
Nombre maximal de connecteurs Cisco Secure Firewall sur Cisco Secure Workload |
100 |
Connecteur Meraki
Le connecteur Meraki permet à Cisco Secure Workload d’acquérir les observations de flux des pare-feu Meraki (inclus dans les appareils de sécurité et les points d’accès sans fil Meraki MX). Grâce à cette solution, les hôtes n’ont pas besoin d’exécuter des agents logiciels, car les commutateurs Cisco relayent les enregistrements NetFlow au connecteur Meraki hébergé dans un appareil d'acquisition Cisco Secure Workload pour le traitement.
![Connecteur Meraki](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467245.jpg)
Qu’est-ce que NetFlow
Le protocole NetFlow permet aux périphériques réseau comme le pare-feu Meraki d’agréger le trafic qui les traverse en flux et d’exporter ces flux vers un collecteur de flux. Le collecteur de flux reçoit ces enregistrements de flux et les stocke pour les interroger et les analyser hors ligne.
En règle générale, la configuration comprend les étapes suivantes :
-
Activer les rapports statistiques NetFlow sur le pare-feu Meraki.
-
Configurez les informations de point terminal du collecteur NetFlow sur le pare-feu Meraki.
Acquisition de flux dans Cisco Secure Workload
Le connecteur Meraki est essentiellement un collecteur NetFlow. Le connecteur reçoit les enregistrements de flux des pare-feu Meraki configurés pour exporter les statistiques de trafic NetFlow. Il traite les enregistrements NetFlow et envoie les observations de flux signalées par les pare-feu Meraki à Cisco Secure Workload pour une analyse de flux. Un connecteur Meraki peut être activé sur un appareil d'acquisition Cisco Secure Workload et s’exécute en tant que conteneur Docker.
Le connecteur Meraki s’enregistre également auprès de Cisco Secure Workload en tant qu’agent Meraki Cisco Secure Workload. Le connecteur Meraki désencapsule les paquets de protocole NetFlow (c.-à-d. les enregistrements de flux); traite ensuite les flux et les signale comme un agent Cisco Secure Workload normal. Contrairement à un agent de visibilité approfondie, il ne signale aucune information sur le processus ou l’interface.
![]() Note |
Le connecteur Meraki prend en charge le protocole NetFlow v9. |
![]() Note |
Chaque connecteur Meraki ne doit signaler les flux que pour un VRF. Les flux exportés par le connecteur sont placés dans le VRF en fonction de la configuration VRF de l’agent dans la grappe Cisco Secure Workload. Pour configurer le VRF pour le connecteur, accédez à : , puis cliquez sur l’onglet Configuration. Dans cette page, sous la section Agent Remote VRF Configurations Configurations VRF d'agents distants), cliquez sur Create Config (Créer une configuration) et fournissez les détails du connecteur. Le formulaire demande à l’utilisateur de fournir le nom du VRF, le sous-réseau IP du connecteur et la plage de numéros de port qui peut potentiellement envoyer des enregistrements de flux à la grappe. |
Gestion des enregistrements NetFlow
Selon l’enregistrement NetFlow, le connecteur Meraki envoie l’observation de flux à Cisco Secure Workload. Les enregistrements de flux Meraki NetFlow sont bidirectionnels. Ainsi, le connecteur Meraki envoie deux flux : le flux aller et le flux inverse à Cisco Secure Workload.
Voici les détails sur l’observation de flux envoyée par le connecteur Meraki à Cisco Secure Workload.
Observation du flux aller
Champ |
ID d’élément |
Nom de l’élément |
---|---|---|
Protocole |
4 |
protocolIdentifier |
Adresse de la source |
8 |
sourceIPv4Address |
Source Port (port source) |
7 |
sourceTransportPort |
Adresse de destination |
12 |
destinationIPv4Address |
Destination Port (port de destination) |
11 |
destinationTransportPort |
Nombre d’octets |
1 |
octetDeltaCount |
Nombre de paquets |
2 |
packetDeltaCount |
Heure de début du flux |
Défini en fonction du moment de la réception de l’enregistrement NetFlow pour ce flux sur le connecteur |
Information de flux inverse
Champ |
ID d’élément |
|
---|---|---|
Protocole |
4 |
protocolIdentifier |
Adresse de la source |
8 |
sourceIPv4Address |
Source Port (port source) |
7 |
sourceTransportPort |
Adresse de destination |
12 |
destinationIPv4Address |
Destination Port (port de destination) |
11 |
destinationTransportPort |
Nombre d’octets |
23 |
postOctetDeltaCount |
Nombre de paquets |
24 |
postPacketDeltaCount |
Heure de début du flux |
Défini en fonction du moment de la réception de l’enregistrement NetFlow pour ce flux sur le connecteur |
Comment configurer NetFlow sur un pare-feu Meraki
Les étapes suivantes montrent comment configurer les rapports NetFlow sur le pare-feu Meraki.
Procedure
Step 1 |
Connectez-vous à la console de l’interface utilisateur Meraki. |
Step 2 |
Naviguez jusqu’à les rapports sur le trafic NetFlow et assurez-vous que la valeur est définie sur Activé : envoyer les statistiques de trafic NetFlow. . Dans les paramètres de rapport, activez |
Step 3 |
Réglez NetFlow collector IP (adresse IP du collecteur NetFlow) et NetFlow collector port (port du collecteur NetFlow) sur l’adresse IP et le port sur lesquels le connecteur Meraki écoute dans le dispositif d'acquisition Cisco Secure Workload. Le port par défaut sur lequel le connecteur Meraki écoute les enregistrements NetFlow est 4729. |
Step 4 |
Enregistrer les modifications ![]() |
Comment configurer le connecteur
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Les configurations suivantes sont autorisées sur le connecteur.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
En outre, les ports d’écoute du protocole NetFlow v9 sur le connecteur peuvent être mis à jour sur le conteneur Docker dans l’appareil d'acquisition Cisco Secure Workload à l’aide d’une commande autorisée. Cette commande peut être exécutée sur l’appareil en fournissant l’ID du connecteur, le type de port à mettre à jour et les renseignements sur le nouveau port. L’ID du connecteur se trouve sur la page du connecteur dans l’interface utilisateur Cisco Secure Workload. Pour plus d’informations, consultez l’article mise à jour-écoute-ports.
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs Meraki sur un dispositif d'acquisition Cisco Secure Workload |
1 |
Nombre maximal de connecteurs Meraki sur un détenteur (portée racine) |
10 |
Nombre maximal de connecteurs Meraki sur Cisco Secure Workload |
100 |
Connecteur ERSPAN
Le connecteur ERSPAN permet à Cisco Secure Workload d’acquérir les observations de flux des routeurs et des commutateurs du réseau. Grâce à cette solution, les hôtes n’ont pas besoin d’exécuter d’agents logiciels, car les commutateurs Cisco relayent le trafic des hôtes vers le connecteur ERSPAN pour traitement.
Qu’est-ce qu’ERSPAN?
L’analyseur ERSPAN (Encapsulating Remote Switch Port Analyzer) est une fonctionnalité présente dans la plupart des commutateurs Cisco. Il reproduit les trames vues par un périphérique réseau, les encapsule dans un paquet IP et les envoie à un analyseur distant. Les utilisateurs peuvent sélectionner une liste d’interfaces ou de VLAN sur le commutateur à surveiller.
En général, l'installation consiste à configurer la ou les sessions de surveillance ERSPAN de source sur un ou plusieurs périphériques de réseau et à configurer la ou les sessions de surveillance ERSPAN de destination sur le ou les périphériques de réseau distants directement connectés à un analyseur de trafic.
Le connecteur ERSPAN Cisco Secure Workload fournit à la fois la session ERSPAN de destination et les fonctionnalités d’analyse du trafic; il n’est donc pas nécessaire de configurer des sessions de destination sur les commutateurs dotés de la solution Cisco Secure Workload.
Que sont les agents SPAN
Chaque connecteur ERSPAN enregistre un agent SPAN auprès de la grappe. Les agents SPAN Cisco Secure Workload sont des agents Cisco Secure Workload standard configurés pour traiter uniquement les paquets ERSPAN : à l’instar des sessions ERSPAN de destination de Cisco, ils désencapsulent les trames en miroir; ils traitent ensuite les flux et en rendent compte comme un agent Cisco Secure Workload normal. Contrairement aux agents de visibilité approfondie, ils ne signalent aucune information sur les processus ou l’interface.
Qu’est-ce que l’appareil d’acquisition pour ERSPAN
L’appareil d'acquisition Cisco Secure Workload pour ERSPAN est une machine virtuelle qui fait fonctionner en interne trois connecteurs ERSPAN Cisco Secure Workload. Il utilise le même OVA ou QCOW2 que l’appareil d'acquisition classique.
Chaque connecteur s’exécute dans un conteneur Docker dédié auquel une vNIC et deux cœurs vCPU sans quota de limite sont exclusivement affectés.
Le connecteur ERSPAN enregistre un agent SPAN avec la grappe avec le nom d’hôte du conteneur :<Nom d'hôte de la machine virtuelle> -<Adresse IP de l'interface>.
Les connecteurs et les agents sont conservés ou restaurés lors du blocage ou du redémarrage de la machine virtuelle, du daemon ou du conteneur Docker.
![]() Remarque |
L'état du connecteur ERSPAN est renvoyé à la page Connector (connecteur). Consultez la page Agent List (Liste des agents) et vérifiez l’état des agents SPAN correspondants. |
Pour en savoir plus sur les appliances virtuelles nécessaires, consultez la section Virtual Appliances pour les connecteurs. Pour les connecteurs ERSPAN, les adresses IPv4 et IPv6 (mode double pile) sont prises en charge. Cependant, notez que la prise en charge de la double pile est une fonctionnalité bêta.
Comment configurer la session ERSPAN source
Les étapes suivantes concernent un commutateur Nexus 9000. Les configurations peuvent différer légèrement pour les autres plateformes Cisco. Pour la configuration d’une plateforme Cisco, consultez le Guide de l’utilisateur du Cisco Secure Workload.
![Configurer la source ERSPAN sur Cisco Nexus 9000](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467247.jpg)
Les étapes ci-dessus ont créé une session ERSPAN source avec l’ID 10. Le commutateur mettra en miroir les trames entrant et sortant (à la fois) de l’interface eth1/23 et de celles sur les VLANS 315 et 512. Le paquet GRE externe transportant la trame miroir aura l’IP source 172.28.126.1 (doit être l’adresse d’une interface L3 sur ce commutateur) et l’IP de destination 172.28.126.194. Il s’agit de l’une des adresses IP configurées sur la machine virtuelle ERSPAN.
Formats ERSPAN pris en charge
Les agents SPAN Cisco Secure Workload peuvent traiter les paquets ERSPAN de type I, II et II décrits dans la RFC ERSPANproposée. Par conséquent, ils peuvent traiter les paquets ERSPAN générés par les périphériques Cisco. Parmi les formats non conformes à la RFC, ils peuvent traiter les paquets ERSPAN générés par VMware vSphere Distributed Switch (VDS).
Considérations relatives aux performances lors de la configuration de la source ERSPAN
Choisissez avec soin la liste de ports/VLAN de la source ERSPAN. Bien que l’agent SPAN dispose de deux vCPU dédiés, la session peut générer une quantité considérable de paquets, ce qui pourrait saturer la puissance de traitement de l’agent. Si un agent reçoit plus de paquets qu’il ne peut en traiter, cela sera indiqué dans le graphique Paquets manquants de l’agent sur la page Deep Visibility Agent (Agent de visibilité approfondie) de la grappe.
Un réglage plus fin des trames sur lesquelles la source ERSPAN sera mise en miroir peut être obtenu à l’aide de politiques ACL, généralement à l’aide du mot-clé de configuration filter.
Si le commutateur le prend en charge, la session source ERSPAN peut être configurée pour modifier l’unité de transport maximale (MTU) du paquet ERSPAN (généralement la valeur par défaut de 1500 octets), généralement au moyen d’un mot-clé mtu. La diminuer limitera l’utilisation de la bande passante ERSPAN dans votre infrastructure réseau, mais n’aura aucun effet sur la charge de l’agent SPAN, étant donné que la charge de travail de l’agent est par paquet. Lorsque vous réduisez cette valeur, prévoyez de la place pour 160 octets pour la trame miroir. Pour plus de détails sur le surdébit d'en-tête ERSPAN, consultez la demande d’informations sur ERSPAN RFCproposée.
Il existe trois versions d’ERSPAN. Plus la version est petite, plus le surdébit de l’en-tête ERSPAN est faible. Les versions II et III permettent d’appliquer des politiques de qualité de service (QoS) aux paquets ERSPAN et fournissent des renseignements sur le VLAN. La version III comporte encore plus de paramètres. La version II est généralement celle par défaut des commutateurs Cisco. Bien que les agents ERSPAN Cisco Secure Workload prennent en charge les trois versions, pour le moment ils n’utilisent aucune information supplémentaire que transportent les paquets ERSPAN versions II et III.
Questions de sécurité.
Le système d’exploitation invité de la machine virtuelle d'acquisition pour ERSPAN est CentOS 7.9, dont les paquets serveur/clients OpenSSL ont été supprimés.
![]() Remarque |
CentOS 7.9 est le système d’exploitation invité pour les appareils virtuels d’acquisition et de périphérie de Cisco Secure Workload 3.8.1.19 et les versions antérieures. À partir de la version 3.8.1.36 de Cisco Secure Workload, le système d’exploitation est AlmaLinux 9.2. |
Une fois que la machine virtuelle est démarrée et que les conteneurs d’agents SPAN sont déployés (l’opération prend quelques minutes lors du premier démarrage uniquement), aucune interface réseau, hormis la boucle avec retour, ne sera présente dans la machine virtuelle. Par conséquent, la seule façon d’accéder à l’appareil est via sa console.
L’interface réseau de la machine virtuelle est maintenant déplacée à l’intérieur des conteneurs Docker. Les conteneurs exécutent une image Docker basée sur centos : 7.9.2009 sans port TCP/UDP ouvert.
![]() Remarque |
À partir de la version 3.8.1.36 de Cisco Secure Workload, les conteneurs exécutent almalinux/9-base:9.2. |
En outre, les conteneurs sont exécutés avec les privilèges de base (option no –privileged) plus la capacité NET_ADMIN.
Dans le cas improbable où un conteneur serait contaminé, le système d'exploitation invité de la machine virtuelle ne devrait pas pouvoir être contaminé depuis l'intérieur du conteneur.
Toutes les autres considérations de sécurité valides pour les agents Cisco Secure Workload exécutés dans un hôte s’appliquent également aux agents SPAN Cisco Secure Workload exécutés dans les conteneurs Docker.
Dépannage
Une fois que les agents SPAN sont à l’état actif dans la page Monitoring/Agent Overview (Surveillance/Aperçu de l’agent) de la grappe, aucune action n’est nécessaire sur la machine virtuelle ERSPAN et l’utilisateur n’a pas besoin de s’y connecter. Si cela ne se produit pas ou si les flux ne sont pas signalés à la grappe, les renseignements suivants permettront d'identifier les problèmes de déploiement.
Dans des conditions normales, sur la machine virtuelle :
-
systemctl status tet_vm_setup
signale un service inactif avec l'état de sortie SUCCESS; -
systemctl status tet-nic-driver
signale un service actif; -
docker network ls
signale cinq réseaux :host, none
et troiserspan-<iface name>;
-
ip link
signale uniquement l’interface de boucle avec retour; -
docker ps
signale trois conteneurs en cours d’exécution; -
docker logs <cid>
pour chaque conteneur, contient le message :NFO success: tet-sensor entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
(Succès du NFO : le capteur tet est entré dans l'état RUNNING, le processus est resté en place pendant > 1 seconde (startsecs). -
docker exec <cid> ifconfig
ne signale qu’une seule interface, en plus de la boucle avec retour; -
docker exec <cid> route -n
signale la passerelle par défaut; -
docker exec <cid> iptables -t raw -S PREROUTING
signale la règle-A PREROUTING-p gre -j DROP;
Si l’un des éléments ci-dessus n’est pas vérifié, vérifiez les journaux du script de déploiement dans /local/tetration/logs/tet_vm_setup.log
pour connaître la raison de l’échec du déploiement des conteneurs d’agents SPAN.
Tout autre problème d’enregistrement ou de connectivité des agents peut être résolu de la même manière que pour les agents exécutés sur un hôte, à l’aide de la commande docker exec :
-
docker exec <cid> ps -ef
signale les deux instancestet-engine, tet-engine check_conf
et deux instances/usr/local/tet/tet-sensor -f /usr/local/tet/conf/.sensor_config
, une avec l'utilisateur racine et une avec l'utilisateur tet -sensor, ainsi que l’instance gestionnaire de processus/usr/bin/ python /usr/bin/supervisord -c /etc/supervisord.conf -n
. -
docker exec <cid> cat /usr/local/tet/log/tet-sensor.log
affiche les journaux de l’agent; -
docker exec <cid> cat /usr/local/tet/log/fetch_sensor_id.log
affiche les journaux des enregistrements de l’agent; -
docker exec <cid> cat /usr/local/tet/log/check_conf_update.log
affiche les journaux d’interrogation de la mise à jour de la configuration;Si nécessaire, le trafic vers/depuis le conteneur peut être surveillé à l’aide de la commande tcpdump après avoir été défini dans l’espace de nom réseau du conteneur :
-
Récupérez l'espace de noms réseau du conteneur (SandboxKey) à l'aide de docker inspect <cid> | grep SandboxKey;
-
Inscrit dans l'espace de noms du réseau du conteneur nsenter --net=/var/run/docker/netns/...;
-
Surveillez le trafic tcpdump -i eth0 -n.
-
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs ERSPAN sur un appareil d'acquisition (ingest appliance) Cisco Secure Workload |
3 |
Nombre maximal de connecteurs ERSPAN sur un détenteur (portée racine) |
24 (12 pour TaaS) |
Nombre maximal de connecteurs ERSPAN sur Cisco Secure Workload |
450 |
Connecteurs pour points terminaux
Les connecteurs pour points terminaux fournissent un contexte de point terminal pour Cisco Secure Workload.
Connecteur |
Description |
Déployé sur une appliance virtuelle |
---|---|---|
AnyConnect |
Recueillez des données de télémétrie à partir du module de visibilité réseau (Network Visibility Module ou NVM) Cisco AnyConnect et enrichissez les inventaires de points terminaux avec les attributs des utilisateurs. |
Acquisition de Cisco Secure Workload |
ISE |
Recueillez des renseignements sur les points terminaux et les inventaires gérés par les appareils Cisco ISE et enrichissez les inventaires des points terminaux avec des attributs utilisateur et des étiquettes de groupe sécurisées (SGL). |
Cisco Secure Workload Edge |
Pour en savoir plus sur les appliances virtuelles nécessaires, consultez la section Virtual Appliances pour les connecteurs.
AnyConnect Connector
AnyConnect connector monitors endpoints that run Cisco AnyConnect Secure Mobility Client with Network Visibility Module (NVM). Using this solution, the hosts do not need to run any software agents on endpoints, because NVM sends host, interface, and flow records in IPFIX format to a collector (e.g., AnyConnect connector).
AnyConnect connector does the following high-level functions.
-
Register each endpoint (supported user devices such as a desktop, a laptop, or a smartphone) on Cisco Cisco Secure Workload as an AnyConnect agent.
-
Update interface snapshots from these endpoints with Secure Workload.
-
Send flow information exported by these endpoints to Cisco Secure Workload collectors.
-
Periodically send process snapshots for processes that generate flows on the endpoints tracked by the AnyConnect connector.
-
Label endpoint interface IP addresses with Lightweight Directory Access Protocol (LDAP) attributes corresponding to the logged-in-user at each endpoint.
Figure 11. AnyConnect connector
Qu’est-ce qu’AnyConnect NVM?
AnyConnect NVM offre une visibilité et une surveillance du comportement des terminaux et des utilisateurs sur site et hors site. Il recueille des informations à partir des points terminaux qui incluent le contexte suivant.
-
Contexte d’appareil/point terminal : informations spécifiques à l’appareil ou au point terminal.
-
Contexte utilisateur : utilisateurs associés au flux.
-
Contexte d’application : processus associés au flux.
-
Contexte de l’emplacement : attributs propres à l’emplacement, si disponibles.
-
Contexte de destination : nom de domaine complet (FQDN) de la destination. AnyConnect NVM génère trois types d’enregistrements.
Enregistrement NVM
Description
Enregistrement de point terminal
Informations sur le périphérique ou le point terminal, y compris l’identifiant unique de périphérique (UDID), le nom d’hôte, le nom du système d’exploitation, la version du système d’exploitation et le fabricant.
Enregistrement d’interface
Informations sur chaque interface du point terminal, y compris l’UDID du point terminal, l’identifiant unique de l’interface (UID), l’indice d’interface, le type d’interface, le nom de l’interface et l’adresse MAC.
Enregistrement de flux
Renseignements sur les flux observés sur le point terminal, y compris l'UDID du point terminal, l'UID de l'interface, le 5-tuple (source/destination ip/port et protocole), le nombre d'octets entrants/sortants, les renseignements sur le processus, les renseignements sur l'utilisateur et le nom de domaine complet de la destination.
Chaque enregistrement est généré et exporté au format de protocole IPFIX. Lorsque le périphérique se trouve dans un réseau de confiance (sur site/VPN), AnyConnect NVM exporte les enregistrements vers un collecteur configuré. Le connecteur AnyConnect est un exemple de collecteur IPFIX qui peut recevoir et traiter le flux IPFIX de AnyConnect NVM.
![]() Note |
Le connecteur AnyConnect prend en charge AnyConnect NVM à partir des versions 4.2 et ultérieures de Cisco AnyConnect Secure Mobility Client. |
How to configure AnyConnect NVM
See How to Implement AnyConnect NVM document for step by step instructions on how to implement AnyConnect NVM using either Cisco Secure Firewall ASA or Cisco Identity Services engine (ISE). Once NVM module is deployed, an NVM profile should be specified and pushed to and installed on the endpoints running Cisco AnyConnect Secure Mobility Client. When specifying NVM profile, the IPFIX collector should be configured to point to AnyConnect connector on port 4739.
AnyConnect connector also registers with Cisco Secure Workload as a Cisco Secure Workload AnyConnect Proxy agent.
Traitement des enregistrements NVM
Le connecteur AnyConnect traite les enregistrements NVM AnyConnect comme indiqué ci-dessous.
Enregistrement de point terminal
Lors de la réception d’un enregistrement de point terminal, le connecteur AnyConnect enregistre ce point terminal en tant qu’agent AnyConnect sur la charge de travail sécurisée. Le connecteur AnyConnect utilise les renseignements spécifiques au point terminal présents dans l’enregistrement NVM avec le certificat du connecteur AnyConnect pour enregistrer le point terminal. Une fois qu’un point terminal est enregistré, le plan de données du point terminal est activé en créant une nouvelle connexion à l’un des collecteurs dans Cisco Secure Workload. En fonction de l’activité (enregistrements de flux) de ce point terminal, le connecteur AnyConnect connecte l’agent AnyConnect correspondant à ce point à la grappe périodiquement (20 à 30 minutes).
AnyConnect NVM commence à diffuser la version de l'agent à partir de la version 4.9. Par défaut, le point terminal AnyConnect est enregistré en tant que version 4.2.x sur Cisco Secure Workload. Cette version indique la version minimale NVM AnyConnect prise en charge. Pour les points terminaux AnyConnect dotés dans la version 4.9 ou ultérieure, l’agent AnyConnect correspondant sur Cisco Secure Workload affichera la version réelle installée.
![]() Note |
La version installée de l’agent AnyConnect n’est pas contrôlée par Cisco Secure Workload. La tentative de mise à niveau de l’agent terminal AnyConnect sur l’interface utilisateur Cisco Secure Workload n’a pas d’effet. |
Enregistrement d’interface
L’adresse IP de l’enregistrement d’interface pour une interface donnée ne fait pas partie de l’enregistrement d’interface NVM AnyConnect. L’adresse IP d’une interface est déterminée lorsque les enregistrements de flux commencent à être envoyés à partir du point terminal pour cette interface. Une fois que l’adresse IP est déterminée pour une interface, le connecteur AnyConnect envoie un instantané complet de toutes les interfaces de ce point terminal dont l’adresse IP est déterminée au serveur de configuration de Cisco Secure Workload. Le VRF est ainsi associé aux données de l'interface et les flux arrivant sur ces interfaces seront désormais marqués par ce VRF.Enregistrement de flux
Lors de la réception d’un enregistrement de flux, le connecteur AnyConnect le traduit au format que Cisco Secure Workload comprend et envoie FlowInfo sur le plan de données correspondant à ce point terminal. En outre, il stocke localement les informations de processus incluses dans l’enregistrement de flux. De plus, si une configuration LDAP est fournie au connecteur AnyConnect, celui-ci détermine les valeurs des attributs LDAP configurés de l’utilisateur connecté du point terminal. Les attributs sont associés à l’adresse IP du point terminal où le flux s’est produit. Périodiquement, les informations sur les processus et les étiquettes des utilisateurs sont transmises à Cisco Secure Workload.
![]() Note |
Chaque connecteur AnyConnect ne signalera que les points terminaux, les interfaces et les flux pour un VRF. Les points terminaux et les interfaces signalés par le connecteur AnyConnect sont associés au VRF en fonction de la configuration du VRF de l’agent dans Cisco Secure Workload. Les flux exportés par l’agent de connecteur AnyConnect au nom du point terminal AnyConnect appartiennent au même VRF. Pour configurer le VRF pour l'agent, accédez à : Configuration. Dans cette page, dans la section « Agent Remote VRF Configurations » (configurations de VRF à distance de l’agent), cliquez sur « Create Config » (Créer une configuration) et fournissez les détails du connecteur AnyConnect. Le formulaire demande à l’utilisateur de fournir le nom du VRF, le sous-réseau IP de l’hôte sur lequel l’agent est installé, et la plage de numéros de ports qui peuvent potentiellement envoyer des enregistrements de flux à la grappe. puis cliquez sur l’onglet |
UDID en double dans les points terminaux Windows
Si des machines de point terminal sont clonées à partir de la même image d'or, il est possible que les UDID de tous les points terminaux clonés soient identiques. Dans ce cas, le connecteur AnyConnect reçoit les enregistrements de point terminal de ces points terminaux avec le même UDID et les enregistre sur Cisco Secure Workload avec le même UDID. Lorsque des enregistrements d’interface ou de flux sont reçus par le connecteur de ces points terminaux, le connecteur ne peut pas déterminer l'agent AnyConnect correct sur Cisco Secure Workload auquel associer les données. Le connecteur associe toutes les données à un seul point terminal (et il n’est pas déterministe).
Pour résoudre ce problème, la version 4.8 d’AnyConnect NVM est livrée avec un outil appelé dartcli.exe pour déterminer et régénérer l’UDID sur le point terminal.
-
dartcli.exe -u récupère l’UDID du point terminal.
-
dartcli.exe -nu régénère l’UDID du point terminal. Pour exécuter cet outil, procédez comme suit :
C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -u
UDID : 8D0D1E8FA0AB09BE82599F10068593E41EF1BFFF
C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -nu
Are you sure you want to re-generate UDID [y/n]: y
Adding nonce success
UDID : 29F596758941E606BD0AFF49049216ED5BB9F7A5
C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -u
UDID : 29F596758941E606BD0AFF49049216ED5BB9F7A5
Tâches périodiques
Périodiquement, le connecteur AnyConnect envoie des instantanés de processus et des étiquettes d’utilisateur sur les inventaires de points terminaux AnyConnect.
-
Instantanés de processus : toutes les 5 minutes, le connecteur AnyConnect parcoure les processus qu’il gère localement pendant cet intervalle et envoie un instantané de processus pour tous les points terminaux qui ont reçu des flux pendant cet intervalle.
-
Étiquettes utilisateur : toutes les 2 minutes, le connecteur AnyConnect parcourt les étiquettes utilisateur LDAP qu’il gère localement et met à jour les étiquettes utilisateur sur ces adresses IP.
Pour les étiquettes d’utilisateur, le connecteur AnyConnect crée un instantané local des attributs LDAP de tous les utilisateurs de l’organisation. Lorsque le connecteur AnyConnect est activé, la configuration LDAP (informations sur le serveur/port, attributs à récupérer pour un utilisateur, attribut qui contient le nom d’utilisateur) peut être fournie. De plus, les renseignements d'authentification de l'utilisateur LDAP pour accéder au serveur LDAP peuvent être fournis. Les renseignements d’authentification des utilisateurs LDAP sont chiffrés et ne sont jamais révélés dans le connecteur AnyConnect. Si vous le souhaitez, un certificat LDAP peut être fourni pour un accès sécurisé au serveur LDAP.
![]() Note |
Le connecteur AnyConnect crée un nouvel instantané LDAP local toutes les 24 heures. Cet intervalle est configurable dans la configuration LDAP du connecteur. |
Comment configurer le connecteur
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Les configurations suivantes sont autorisées sur le connecteur.
-
LDAP : la configuration LDAP prend en charge la découverte des attributs LDAP et fournit un flux de travail pour choisir l’attribut qui correspond au nom d’utilisateur et une liste de six attributs maximum à récupérer pour chaque utilisateur. Pour en savoir plus, consultez la section Découverte .
-
Point terminal : pour en savoir plus, consultez Configuration de point terminal.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
De plus, les ports d’écoute du protocole IPFIX sur le connecteur peuvent être mis à jour sur le conteneur Docker dans l’appareil d'acquisition Cisco Secure Workload à l’aide d’une commande autorisée. Cette commande peut être exécutée sur l’appareil en fournissant l’ID du connecteur, le type de port à mettre à jour et les renseignements sur le nouveau port. L’ID du connecteur se trouve sur la page du connecteur dans l’interface utilisateur Cisco Secure Workload. Pour plus d’informations, consultez l’article mise à jour-écoute-ports.
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs AnyConnect sur un appareil d'acquisition Cisco Secure Workload |
1 |
Nombre maximal de connecteurs AnyConnect sur un détenteur (portée racine) |
50 |
Nombre maximal de connecteurs AnyConnect sur Cisco Secure Workload |
500 |
ISE Connector
ISE connector in Secure Workload connects with Cisco Identity Services Engine (ISE), using Cisco Platform Exchange Grid (pxGrid), to retrieve contextual information about endpoints reported by ISE. Using these solutions, we can obtain enriched metadata for endpoints.
The ISE connector in Secure Workload connects with Cisco Identity Services Engine (ISE) and ISE Passive Identity Connector (ISE-PIC) using the Cisco Platform Exchange Grid (pxGrid), to retrieve contextual information, such as metadata, for endpoints reported by ISE.
An ISE connector performs these functions:
-
Register each endpoint viewed by ISE on Cisco Secure Workload as an ISE endpoint agent.
-
Update metadata information regarding these endpoints to Cisco Secure Workload including MDM details, authentication, Security Group labels, and others.
-
Periodically take a snapshot and update cluster with active endpoints visible on ISE.
Figure 12. ISE connector
-
Registers each endpoint that are identified as an ISE endpoint on Secure Workload.
-
Updates metadata information on Secure Workload regarding the endpoints, such as MDM details, authentication, Security Group labels, ISE group name, and ISE group type.
-
Periodically takes a snapshot and updates the cluster with active endpoints visible on the ISE.
Figure 13. ISE connector
![]() Note |
Each ISE connector will register only endpoints and interfaces for one VRF. The endpoints and interfaces reported by ISE connector are associated with the VRF based on the Agent VRF configuration in Secure Workload. To configure the VRF for the agent, go to: Configuration tab. In this page, under the Agent Remote VRF Configurations section, click Create Config and provide the details about the ISE connector. The form requests the user to provide: the name of the VRF, IP subnet of the host on which the agent is installed, and range of port numbers that can potentially register ISE endpoints and interfaces on Secure Workload. and click the |
![]() Note |
The ISE endpoint agents are not listed on the Agents List page; instead ISE endpoints with the attributes can be viewed on the Inventory page. |
Comment configurer le connecteur
![]() Note |
ISE version 2.4+ et ISE PIC version 3.1+ sont nécessaires pour cette intégration. |
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Pour les connecteurs ISE, les adresses IPv4 et IPv6 (mode double pile) sont prises en charge. Cependant, notez que la prise en charge de la double pile est une fonctionnalité bêta.
Les configurations suivantes sont autorisées sur le connecteur.
-
Instance ISE : le connecteur ISE peut se connecter à plusieurs instances ISE en utilisant les configurations fournies. Chaque instance nécessite des renseignements d’authentification de certificat ISE ainsi qu’un nom d’hôte et un nom de nœud pour se connecter à ISE. Pour en savoir plus, consultez Configuration d’une instance ISE.
-
LDAP : la configuration LDAP prend en charge la découverte des attributs LDAP et fournit un flux de travail pour sélectionner l’attribut qui correspond au nom d’utilisateur et une liste de six attributs maximum à récupérer pour chaque utilisateur. Pour en savoir plus, consultez la section Découverte .
-
Point terminal : pour en savoir plus, consultez Configuration de point terminal.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
Configuration de l’instance ISE
![Configuration d’instance ISE](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467250.jpg)
![]() Note |
À partir de la version 3.7 de Cisco Secure Workload, le certificat SSL pour le nœud pxGrid de Cisco ISE nécessite d’autres noms de sujet (SAN) pour cette intégration. Assurez-vous que la configuration de certification des nœuds ISE est effectuée par votre administrateur ISE avant de procéder à l’intégration avec Cisco Secure Workload. |
Pour vérifier le certificat de votre nœud pxGrid et confirmer si le SAN est configuré, vous devez procéder comme suit pour vérifier le certificat d’ISE.
Procedure
Step 1 |
Rendez-vous à Certificates (Certificats) sous (Système). |
||||||||||||||||||||||
Step 2 |
Sous Certificate Management (Gestion du certificat) , sélectionnez System Certificates (Certificat système), sélectionnez votre certificat pxGrid « utilisé par » et choisissez View (afficher) pour examiner le certificat de nœud pxGrid. |
||||||||||||||||||||||
Step 3 |
Faites défiler le certificat et vérifiez que les Subject Alternative Names (autres noms de sujet) sont configurés pour ce certificat. |
||||||||||||||||||||||
Step 4 |
Ce certificat doit être signé par une autorité de certification (CA) valide, qui doit également être utilisée pour signer le certificat client pxGrid utilisé par le connecteur Cisco Secure Workload ISE. ![]() |
||||||||||||||||||||||
Step 5 |
Vous pouvez maintenant générer la demande de signature de certificat client pxGrid en utilisant le modèle suivant sur n’importe quel hôte installé avec OpenSSL.
Enregistrez le fichier sous le nom « example-connector.cfg » et utilisez la commande OpenSSL de votre hôte pour générer une requête de signature de certificat (CSR) et la clé privée du certificat à l’aide de la commande suivante.
|
||||||||||||||||||||||
Step 6 |
Signez la requête de signature de certificat (CSR) de votre autorité de certification en utilisant un serveur d’autorité de certification Windows. Si vous utilisez également un serveur d’autorité de certification Windows, exécutez la commande suivante pour signer la CSR du client pxGrid.
![]() |
||||||||||||||||||||||
Step 7 |
Copiez le certificat client signé et l’autorité de certification racine au format PEM sur votre hôte. Il s’agit du même hôte qui génère la demande de signature de certificat (CSR) du client et la clé privée. Utilisez OpenSSL pour vous assurer que le certificat client est au format PEM X.509. Exécutez la commande suivante à l’aide d’OpenSSL pour convertir le certificat client signé au format PEM X.509.
|
||||||||||||||||||||||
Step 8 |
Vous pouvez également confirmer le PEM signé par l’autorité de certification en utilisant la commande suivante.
|
||||||||||||||||||||||
Step 9 |
En utilisant les noms de fichiers de l'exemple ci-dessus, copiez le certificat client ISE - example-connector.pem, la clé du client - example-connector.key et l'autorité de certification – root-ca.example.com.pem dans les champs respectifs de la page de configuration ISE sur Cisco Secure Workload comme indiqué ci-dessous.
![]()
|
![]() Note |
|
Traitement des enregistrements ISE
Le connecteur ISE traite les enregistrements comme décrit ci-dessous.
Enregistrement de point terminal
Le connecteur ISE se connecte à l’instance ISE et s’abonne à toutes les mises à jour des points terminaux sur pxGrid. Lors de la réception d’un enregistrement de point terminal, le connecteur ISE enregistre ce point terminal en tant qu’agent ISE sur Cisco Secure Workload. Le connecteur ISE utilise les informations spécifiques au point terminal présentes dans l'enregistrement de ce dernier ainsi que le certificat du connecteur ISE pour enregistrer le point terminal. Une fois qu’un point terminal est enregistré. Le connecteur ISE utilise l’objet de point terminal pour l’enrichissement de l’inventaire en l’envoyant en tant qu’étiquettes d’utilisateur sur Cisco Secure Workload. Lorsque le connecteur ISE reçoit un point terminal déconnecté d’ISE, il supprime l’enrichissement d’inventaire de Cisco Secure Workload.
Enregistrement de groupe de sécurité
ISE connect s’abonne également aux mises à jour sur les modifications des étiquettes de groupes de sécurité via pxGrid. Lors de la réception de cet enregistrement, les connecteurs ISE conservent une base de données locale. ISE utilise cette base de données pour mapper le nom SGT avec la valeur lors de la réception d’un enregistrement de point terminal.
Tâches périodiques
Le connecteur ISE partage régulièrement des étiquettes d’utilisateur sur les inventaires de points terminaux ISE.
-
instantanés de points terminaux : toutes les 20 heures, le connecteur ISE récupère un instantané des points terminaux et des étiquettes de groupes de sécurité de l’instance ISE et met à jour la grappe si des modifications sont détectées. Cet appel ne tient pas compte des points terminaux déconnectés au cas où nous ne verrions pas de points terminaux sur Cisco Secure Workload en provenance d'ISE.
-
Étiquettes d’utilisateur : toutes les deux minutes, le connecteur ISE balaye les étiquettes d’utilisateur LDAP et de point terminal ISE gérées localement et met à jour les étiquettes d’utilisateur sur ces adresses IP.
Pour les étiquettes d’utilisateur, le connecteur ISE crée un instantané local des attributs LDAP de tous les utilisateurs de l’organisation. Lorsque le connecteur ISE est activé, la configuration LDAP (informations sur le serveur/port, attributs à récupérer pour un utilisateur, attribut qui contient le nom d’utilisateur) peut être fournie. De plus, les renseignements d'authentification de l'utilisateur LDAP pour accéder au serveur LDAP peuvent être fournis. Les informations d’authentification des utilisateurs LDAP sont chiffrées et ne sont jamais révélées dans le connecteur ISE. Si vous le souhaitez, un certificat LDAP peut être fourni pour un accès sécurisé au serveur LDAP.
![]() Note |
Le connecteur ISE crée un nouvel instantané LDAP local toutes les 24 heures. Cet intervalle est configurable dans la configuration LDAP du connecteur. |
![]() Note |
Lors de la mise à niveau d’un périphérique Cisco ISE, le connecteur ISE devra être reconfiguré avec les nouveaux certificats générés par ISE après la mise à niveau. |
Limites
Unité |
Limite |
---|---|
Nombre maximal d’instances ISE qui peuvent être configurées sur un connecteur ISE |
20 |
Nombre maximal de connecteurs ISE sur un appareil de périphérieCisco Secure Workload |
1 |
Nombre maximal de connecteurs ISE sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs ISE sur Cisco Secure Workload |
150 |
Connecteurs pour l’enrichissement de l'inventaire
Les connecteurs pour l’enrichissement de l'inventaire fournissent des métadonnées et du contexte supplémentaires sur les inventaires (adresses IP) surveillés par Cisco Secure Workload.
Connecteur |
Description |
Déployé sur une appliance virtuelle |
---|---|---|
ServiceNow |
Recueillez des renseignements sur le point terminal de l’instance ServiceNow et enrichissez l’inventaire avec les attributs ServiceNow |
Cisco Secure Workload Edge |
Consultez aussi : |
– |
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour le connecteur.
Connecteur ServiceNow
Le connecteur ServiceNow se connecte à l’instance ServiceNow pour obtenir toutes les étiquettes liées à la CMDB ServiceNow pour les points terminaux de l’inventaire ServiceNow. En utilisant cette solution, nous pouvons obtenir des métadonnées améliorées pour les points terminaux dans Cisco Secure Workload.
Le connecteur ServiceNow effectue les fonctions principales suivantes.
-
Mettre à jour les métadonnées ServiceNow dans l’inventaire de Cisco Secure Workload pour ces points terminaux.
-
Prendre régulièrement des instantanés et mettre à jour les étiquettes sur ces points terminaux.
Figure 18. Connecteur ServiceNow
Comment configurer le connecteur ServiceNow
Pour en savoir plus sur les appliances virtuelles requises, consultez Appliances virtuelles pour les connecteurs. Les configurations suivantes sont autorisées sur le connecteur.
-
ServiceNow Tables : la fonction ServiceNow Tables configure l’instance ServiceNow avec ses informations d’authentification et les informations sur les tables ServiceNow dans lesquelles récupérer les données.
-
API REST scriptée : les tableaux de l' API REST scriptée ServiceNow peuvent être configurés de la même manière que les tableaux ServiceNow.
-
Sync Interval : la configuration de l’intervalle de synchronisation permet de modifier la fréquence à laquelle Cisco Secure Workload doit interroger l’instance de ServiceNow pour obtenir des données mises à jour.
-
Log (Journal) : pour en savoir plus, consultez la configuration des journaux.
Configuration de l’instance ServiceNow
![Configuration de l’instance ServiceNow](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467255.jpg)
Vous aurez besoin des éléments suivants pour configurer avec succès une instance ServiceNow.
-
Nom d’utilisateur ServiceNow
-
Mot de passe ServiceNow
-
URL de l’instance ServiceNow
-
Inclure les API scriptées
Par la suite, Cisco Secure Workload effectue une découverte de tous les tableaux à partir de l’instance ServiceNow et des API REST scriptées (uniquement si la case Include Scripted APIs (Inclure les API scriptées) est cochée). Il présente à l’utilisateur la liste des tableaux parmi lesquels choisir. Une fois qu’un utilisateur a sélectionné un tableau, Cisco Secure Workload récupère toute la liste des attributs de ce tableau pour que l’utilisateur puisse les sélectionner. L’utilisateur doit choisir l’attribut ip_address dans le tableau comme clé. Ensuite, l'utilisateur peut choisir jusqu'à 10 attributs uniques dans le tableau. Consultez les figures suivantes pour chaque étape.
![]() Note |
Le connecteur ServiceNow peut uniquement prendre en charge l’intégration avec des tableaux comportant un champ d’adresse IP. |
![]() Note |
Pour intégrer les API REST scriptées de ServiceNow, vous devez cocher la case API scriptées, ce qui vous donnerait un flux de travail similaire à tout autre tableau. |
![]() Note |
Pour que les API REST scriptées s’intègrent au connecteur ServiceNow, elles ne peuvent pas avoir de paramètres de chemin. En outre, elles doivent prendre en charge sysparm_limit,sysparm_fields and sysparm_offset en tant que paramètres de requête. |
![]() Note |
Les rôles d'utilisateur ServiceNow doivent inclure cmdb_read pour les tableaux et web_service_admin pour les API REST scriptées afin de s'intégrer à Cisco Cisco Secure Workload. |
![Première étape de la configuration de l’instance ServiceNow](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467256.jpg)
![Cisco Secure Workload récupère les informations relatives aux tableaux de l'instance ServiceNow](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467257.jpg)
![Cisco Secure Workload présente la liste des tableaux](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467258.jpg)
![L’utilisateur sélectionne l’attribut ip_address et un autre attribut dans le tableau.](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467259.jpg)
![L’utilisateur finalise la configuration de ServiceNow.](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467260.jpg)
Traitement des enregistrements ServiceNow
En fonction de l’URL d’instance que vous avez fournie lors de la configuration, le connecteur ServiceNow se connecte à l’instance ServiceNow. L’instance ServiceNow utilise des appels HTTP utilisant https://{URL de l’instance}/api/new/doc/table/schema pour obtenir le schéma de table initial à partir de l’API de la table ServiceNow. En fonction des tables configurées, il interroge ces tables pour récupérer les étiquettes et les métadonnées de ServiceNow. Cisco Secure Workload annote les étiquettes ServiceNow des adresses IP de son inventaire. Le connecteur ServiceNow récupère régulièrement de nouvelles étiquettes et met à jour l’inventaire Cisco Secure Workload .
![]() Note |
Cisco Secure Workload récupère régulièrement les enregistrements des tables ServiceNow. Cela est configurable sous l’onglet SyncInterval dans le connecteur ServiceNow. L’intervalle de synchronisation par défaut est de 60 minutes. Pour les cas d’intégration de la table ServiceNow avec un grand nombre d’entrées, cet intervalle de synchronisation doit être défini à une valeur plus élevée. |
![]() Note |
Cisco Secure Workload supprimera toute entrée non visible pendant 10 intervalles de synchronisation continus. Si la connexion à l'instance ServiceNow est interrompue pendant une période aussi longue, cela peut entraîner le nettoyage de toutes les étiquettes de cette instance. |
Configuration de l’intervalle de synchronisation
-
Le connecteur ServiceNow de Cisco Secure Workload permet de configurer la fréquence de synchronisation entre Cisco Secure Workload et l’instance ServiceNow. Par défaut, l’intervalle de synchronisation est fixé à 60 minutes, mais il peut être modifié dans la configuration de l’intervalle de synchronisation sous la forme Fréquence d’extraction des données.
-
Pour détecter la suppression d’un enregistrement, le connecteur Cisco Secure Workload ServiceNow s’appuie sur les synchronisations des instances ServiceNow. Si une entrée n’est pas vue dans 48 intervalles de synchronisation consécutifs, nous supprimons l’entrée. Cela peut être configuré dans la configuration de l’intervalle de synchronisation sous la forme Delete entry interval (Supprimer l'intervalle d'entrée).
-
Si des paramètres supplémentaires doivent être transmis lors de l’appel des API REST pour les tableaux ServiceNow, vous pouvez les configurer dans le cadre des paramètres d’URL supplémentaires de l’API REST. Cette configuration est facultative. Par exemple, pour obtenir une recherche de référence à partir de ServiceNow, les paramètres d’URL suivants peuvent être utilisés sysparm_exclude_reference_link=true&sysparm_display_value=vrai
Figure 25. Configuration de l’intervalle de synchronisation
Commande Explore pour supprimer les étiquettes
Si l’utilisateur souhaite nettoyer les étiquettes pour une adresse IP particulière pour une instance donnée immédiatement, sans attendre l’intervalle de suppression, il peut le faire à l’aide de la commande explore. Voici les étapes à suivre pour exécuter la commande.
-
Recherche de l’ID VRF d'un détenteur
-
Accès à l’interface utilisateur de la commande Explore (Explorer)
-
Exécution des commandes
Recherche de l’ID VRF d'un détenteur
Les administrateurs du site et les utilisateurs du service d'assistance à la clientèle peuvent accéder à la page Tenant (Détenteur) sous le menu platform (plateforme) dans la barre de navigation à gauche de la fenêtre. Cette page affiche tous les détenteurs et VRF actuellement configurés. Pour en savoir plus, consultez la section Détenteurs pour plus de détails.
Dans la page Détenteurs, le champ ID
du tableau des détenteurs correspond à l’ID VRF du détenteur.
Accès à l’interface utilisateur de la commande Explore (Explorer)
Pour accéder à l’interface de commande Maintenance Explorer (Explorateur de maintenance), choisissez Cisco Secure Workload.
dans la barre de navigation de gauche de l’interface Web![]() Note |
Des privilèges de service d'assistance à la clientèle sont nécessaires pour accéder au menu d’exploration. Si l’onglet d’exploration ne s’affiche pas, le compte n’a peut-être pas les autorisations nécessaires. |
Cliquez sur l’onglet Explore (Explorer) dans le menu déroulant pour accéder à la page Maintenance Explorer (Explorateur de maintenance).
![Onglet Maintenance Explorer (Explorateur de maintenance)](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467262.jpg)
Exécution des commandes
-
Choisissez l’action
POST
-
Saisissez l’hôte de l’instantané en tant que
orchestrator.service.consul
-
Saisir le chemin d’accès à l’instantané
Pour supprimer les étiquettes d'une adresse IP particulière pour une
instance ServiceNow, procédez comme suit : servicenow_cleanup_annotations?args=<vrf-id> <ip_address> <instance_url> <table_name>
-
Cliquez sur Envoyer
Remarque
Si, après avoir été supprimé à l'aide de la commande explore, l'enregistrement apparaît dans l'instance de ServiceNow, il sera réalimenté.
Foire aux questions
-
Que faire si la table de CMDB ServiceNow ne comporte pas d’adresse IP.
Dans ce cas, il est recommandé de créer une vue sur ServiceNow qui contiendra les champs souhaités de la table actuelle ainsi que l’adresse IP (provenant potentiellement d’une opération JOIN avec une autre table). Une fois qu’une telle vue est créée, elle peut être utilisée à la place du nom de table.
-
Que se passe-t-il si l’instance ServiceNow nécessite une authentification multifactorielle
Actuellement, nous ne prenons pas en charge l’intégration de l’instance ServiceNow avec l’authentification multifactorielle.
Limites
Unité |
Limite |
---|---|
Nombre maximal d’instances ServiceNow qui peuvent être configurées sur un connecteur ServiceNow |
20 |
Nombre maximal d’attributs qui peuvent être extraits d’une instance de ServiceNow |
10 |
Nombre maximal de connecteurs ServiceNow sur un appareil de périphérie Cisco Secure Workload |
1 |
Nombre maximal de connecteurs ServiceNow sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs ServiceNow sur Cisco Secure Workload |
150 |
Connecteurs pour les notifications d’alertes
Les connecteurs pour les notifications d’alertes permettent à Cisco Secure Workload de publier des alertes Cisco Secure Workload sur diverses plateformes de messagerie et de journalisation. Ces connecteurs fonctionnent sur le service TAN sur l’appareil de périphérie Cisco Secure Workload.
Connecteur |
Description |
Déployé sur une appliance virtuelle |
---|---|---|
Syslog |
Envoyer des alertes Cisco Secure Workload au serveur Syslog. |
Cisco Secure Workload Edge |
|
Envoyer des alertes Cisco Secure Workload par courriel |
Cisco Secure Workload Edge |
Slack |
Envoyez des alertes Cisco Secure Workload sur Slack. |
Cisco Secure Workload Edge |
PagerDuty |
Envoi d’alertes Cisco Secure Workload sur Pager Duty. |
Cisco Secure Workload Edge |
Kinesis |
Envoyez des alertes Cisco Secure Workload sur Amazon Kinesis. |
Cisco Secure Workload Edge |
Pour en savoir plus sur les appliances virtuelles nécessaires, consultez la section Virtual Appliances pour les connecteurs.
Connecteur Syslog
Lorsqu'activé, le service TAN (Outil de notification d'alertes) sur l’appareil de périphérie Cisco Secure Workload de Cisco peut envoyer des alertes au serveur Syslog à l’aide de la configuration.
![Connecteur Syslog](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467263.jpg)
Le tableau suivant explique les détails de configuration pour la publication des alertes Cisco Secure Workload sur le serveur Syslog. Pour plus d’informations, consultez la Configuration du notificateur Syslog.
Nom du paramètre |
Type |
Description |
---|---|---|
Protocol |
Liste déroulante |
Protocole à utiliser pour la connexion au serveur |
•UDP | ||
• TCP | ||
Adresse du serveur |
chaîne |
Nom d’hôte ou adresse IP du serveur Syslog. |
Port |
number |
Port d’écoute du serveur Syslog. La valeur du port par défaut est 514. |
![Exemple de configuration pour le connecteur Syslog](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467264.jpg)
![Exemple d'alerte](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467265.jpg)
Mappage de gravité Syslog
Le tableau suivant présente le mappage de gravité par défaut pour les alertes Cisco Secure Workload dans Syslog.
Gravité des alertes pour Cisco Secure Workload |
Gravité de journal système |
---|---|
FAIBLE |
LOG_DEBUG |
MOYENNE |
LOG_WARNING |
ÉLEVÉE |
LOG_ERR |
CRITIQUE |
JOURNAL_CRIT |
ACTION IMMÉDIATE |
LOG_EMERG |
Ce paramètre peut être modifié à l’aide de la configuration du Mappage de la gravité du connecteur Syslog. Vous pouvez choisir la priorité Syslog correspondante pour chaque gravité d’alerte Cisco Secure Workload et modifier le mappage des gravités. Pour plus d’informations, consultez Configuration du mappage de gravité Syslog .
Nom du paramètre |
Liste déroulante des mappages |
---|---|
ACTION_IMMÉDIATE |
|
CRITIQUE |
|
ÉLEVÉ |
|
MOYENNE |
|
FAIBLE |
![Exemple de configuration pour le mappage de gravité Syslog](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467266.jpg)
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs Syslog sur un appareil de périphérie Cisco Secure Workload |
1 |
Nombre maximal de connecteurs Syslog sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs Syslog sur Cisco Secure Workload |
150 |
Connecteur de courriel
Lorsqu’activé, le service TAN sur l’appareil de périphérie Cisco Secure Workload peut envoyer des alertes pour une configuration donnée.
![Connecteur de courriel](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467267.jpg)
Le tableau suivant explique les détails de configuration pour la publication d’alertes Cisco Secure Workload dans des courriels. Pour en savoir plus, consultez la configuration du notificateur par courriel .
Nom du paramètre |
Type |
Description |
---|---|---|
Nom d’utilisateur SMTP |
chaîne |
Nom d’utilisateur du serveur SMTP Ce paramètre est facultatif. |
Mot de passe SMTP |
chaîne |
Mot de passe du serveur SMTP pour l’utilisateur (si fourni) Ce paramètre est facultatif. |
SMTP Server |
chaîne |
Nom d’hôte ou adresse IP du serveur SMTP |
Port SMTP |
number |
Port d’écoute du serveur SMTP. La valeur par défaut est 587. |
Connection sécurisée |
case |
Doit-on utiliser SSL pour la connexion au serveur SMTP? |
Adresse courriel d'expédition |
chaîne |
Adresse courriel à utiliser pour l’envoi des alertes |
Destinataires par défaut |
chaîne |
Liste d’adresses courriel de destinataires séparées par des virgules |
![Exemple de configuration pour un connecteur par courriel](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467268.jpg)
![Exemple d'alerte](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467269.jpg)
![]() Note |
|
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs de courriel sur un appareil de périphérie Cisco Secure Workload |
1 |
Nombre maximal de connecteurs de courriel sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs de courriel sur Cisco Secure Workload |
150 |
Connecteur Slack
Lorsqu’activé, le service TAN sur l’appareil de périphérie Cisco Secure Workload peut envoyer des alertes à Slack à l’aide de la configuration.
![Connecteur Slack](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467270.jpg)
Le tableau suivant explique les détails de la configuration pour la publication des alertes Cisco Secure Workload sur Slack. Pour en savoir plus, consultez la Configuration du notificateur Slack .
Nom du paramètre |
Type |
Description |
---|---|---|
URL de point d’ancrage Web Slack |
chaîne |
Point d’ancrage Web Slack sur lequel les alertes Cisco Secure Workload doivent être publiées |
![]() Note |
|
![Exemple de configuration pour le connecteur Slack](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467271.jpg)
![Exemple d'alerte](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467272.jpg)
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs Slack sur un appareil de périphérie Cisco Secure Workload |
1 |
Nombre maximal de connecteurs Slack sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs Slack sur Cisco Secure Workload |
150 |
Connecteur PagerDuty
Lorsqu'activé, le service TAN sur l’appareil de périphérie Cisco Secure Workload peut envoyer des alertes à PagerDuty à l’aide de la configuration.
![Connecteur PagerDuty](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467273.jpg)
Le tableau suivant explique les détails de configuration pour la publication des alertes Cisco Secure Workload sur PagerDuty. Pour en savoir plus, consultez la configuration de l'outil de notification PagerDuty.
Nom du paramètre |
Type |
Description |
---|---|---|
Clé de service PagerDuty |
chaîne |
Clé de service PagerDuty pour activer les alertes Cisco Secure Workload sur PagerDuty. |
![Exemple de configuration pour PagerDuty Connector](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467274.jpg)
![Exemple d'alerte](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467275.jpg)
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs PagerDuty sur un appareil de périphérie Cisco Secure Workload |
1 |
Nombre maximal de connecteurs PagerDuty sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs PagerDuty sur Cisco Secure Workload |
150 |
Connecteur Kinesis
Lorsqu'activé, le service TAN sur l’appareil de périphérie Cisco Secure Workload peut envoyer des alertes à l’aide de la configuration.
![Connecteur Kinesis](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467276.jpg)
Le tableau suivant explique les détails de configuration pour la publication des alertes Cisco Secure Workload sur Amazon Kinesis. Pour en savoir plus, consultez la configuration de l'outil de notification Kinesis.
Nom du paramètre |
Type |
Description |
---|---|---|
ID de la clé d'accès AWS |
chaîne |
ID de clé d’accès AWS pour communiquer avec AWS |
Clé d'accès secrète AWS |
chaîne |
Clé d’accès secrète AWS pour communiquer avec AWS |
Région AWS |
dropdown of AWS regions |
Nom de la région AWS où le flux Kinesis est configuré |
Kinesis Stream |
chaîne |
Nom du flux Kinesis |
Stream Partition |
chaîne |
Nom de la partition du flux |
![Exemple de configuration pour le connecteur Kinesis](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467277.jpg)
Limites
Unité |
Limite |
---|---|
Nombre maximal de connecteurs Kinesis sur un appareil de périphérie Cisco Secure Workload |
1 |
Nombre maximal de connecteurs Kinesis sur un détenteur (portée racine) |
1 |
Nombre maximal de connecteurs Kinesis sur Cisco Secure Workload |
150 |
connecteurs infonuagiques
Vous pouvez utiliser un connecteur infonuagique pour les fonctionnalités Cisco Secure Workload sur les charges de travail infonuagique.
Les connecteurs infonuagiques ne nécessitent pas d’appliance virtuelle.
Connecteur |
Fonctionnalités prises en charge |
Déployé sur une appliance virtuelle |
---|---|---|
AWS |
Pour les VPC Amazon Web Services :
À partir des grappes EKS (Elastic Kubernetes Service) :
|
S. O. |
Azure |
Pour les réseaux virtuels Azure :
À partir des grappes Azure Kubernetes Service (AKS) :
|
S. O. |
GCP |
Pour les VPC Google Cloud Platform :
À partir des grappes de Google Kubernetes Engine (GKE) :
|
s.o. |
Connecteur AWS
Le connecteur Amazon Web Services (AWS) se connecte à AWS pour remplir les fonctions générales suivantes :
-
Acquisition automatisée de l’inventaire (et de ses étiquettes) en direct à partir d’un nuage privé virtuel (VPC) AWS; AWS vous permet d’affecter des métadonnées à vos ressources sous forme de balises. Cisco Secure Workload interroger les balises de ces ressources qui peuvent ensuite être utilisées pour la visualisation des données d’inventaire et des flux de trafic, et pour la définition de politiques. Cette fonctionnalité maintient le mappage des balises de ressources à jour en synchronisant constamment ces données.
Les balises des charges de travail et des interfaces réseau d’un AWS VPC sont acquises. Si vous configurez à la fois des charges de travail et des interfaces réseau, Cisco Secure Workload fusionne et affiche les balises. Pour en savoir plus, consultez Étiquettes générées par les connecteurs infonuagiques.
-
Acquisition de journaux de flux VPC Si vous avez configuré les journaux de flux VPC dans AWS à des fins de surveillance, Cisco Secure Workload peut acquérir des informations des journaux de flux en lisant le compartiment S3 correspondant. Vous pouvez utiliser cette télémétrie pour la génération de politiques de visualisation et de segmentation.
-
Segmentation Lorsque l’option de segmentation est activée, Cisco Secure Workload programme les politiques de sécurité à l’aide des groupes de sécurité natifs d’AWS. Lorsque la mise en application est activée pour un VPC, les politiques pertinentes sont automatiquement programmées en tant que groupes de sécurité.
-
Acquisition automatisée des métadonnées des grappes EKS Lorsque Elastic Kubernetes Services (EKS) est exécuté sur AWS, vous pouvez choisir de rassembler toutes les métadonnées de nœuds, de services et de pods associées à toutes les grappes Kubernetes sélectionnées.
Vous pouvez choisir les fonctionnalités à activer pour chaque VPC.
![]() Note |
Nous ne prenons pas actuellement en charge les régions de la Chine. |
Exigences et prérequis AWS
Pour toutes les fonctionnalités : créez un utilisateur dédié dans AWS ou identifiez un utilisateur AWS existant pour ce connecteur. L'assistant de configuration du connecteur génère un modèle de formation de nuage CloudFormation (CFT) que vous pouvez utiliser pour attribuer les privilèges requis à cet utilisateur. Assurez-vous que vous avez les autorisations dans AWS pour charger ce CFT.
Pour accorder un accès multicompte AWS à l’utilisateur dédié, consultez (Facultatif) Configurer l'accès multicompte AWS dans AWS, y compris les privilèges d’accès requis.
Pour accorder l’accès au compte AWS à l’aide du rôle, consultez la section accès basé sur les rôles à la grappe Cisco Secure Workload.
Chaque VPC ne peut appartenir qu’à un seul connecteur AWS. Une grappe Cisco Secure Workload peut avoir plusieurs connecteurs AWS. Rassemblez les informations décrites dans les tableaux de la Configurer un nouveau connecteur AWS.
Ce connecteur ne nécessite pas d’appliance virtuelle.
Pour la collecte d’étiquettes et de l’inventaire : aucune condition préalable supplémentaire n’est requise.
Pour l’acquisition des journaux de flux : des définitions de journaux de flux au niveau VPC sont requises pour déclencher la collecte des journaux de flux.
Seuls les journaux de flux de niveau VPC peuvent être intégrés.
Les journaux de flux doivent être publiés dans Amazon Simple Storage Service (S3). Cisco Secure Workload ne peut pas collecter de données de flux à partir des journaux Amazon CloudWatch.
Secure Workload peut acquérir des journaux de flux d’un compartiment S3 associé à n’importe quel compte, si les informations d’authentification du compte d’utilisateur AWS fournies lors de la création du connecteur ont accès à la fois aux journaux de flux VPC et au compartiment S3.
Les attributs de journal de flux suivants (dans n’importe quel ordre) sont requis dans ce dernier : adresse source, adresse de destination, port source, port de destination, protocole, paquets, octets, heure de début, heure de fin, action, indicateurs TCP, ID d’interface, État du journal et direction du flux. Tout autre attribut est ignoré.
Les journaux de flux doivent saisir le trafic autorisé et refusé.
![]() Note |
Le connecteur Cisco Secure Workload AWS prend en charge la partition des journaux de flux VPC sur une base horaire et quotidienne. |
Pour la segmentation : l’activation de la segmentation nécessite l’activation de l’option Gather Labels (Rassembler les étiquettes).
Sauvegardez vos groupes de sécurité existants avant d’activer la segmentation du connecteur, car toutes les règles existantes sont remplacées lorsque vous activez la segmentation pour un VPC.
Pour en savoir plus, consultez Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire AWS.
Pour les services Kubernetes gérés (EKS) : si vous activez l’option Kubernetes, consultez les exigences et les conditions préalables dans la section des services Kubernetes gérés fonctionnant sur AWS (EKS), y compris les privilèges d’accès requis.
(Facultatif) Configurer l'accès multicompte AWS dans AWS
Si les renseignements d’authentification utilisateur fournis ont accès aux VPC appartenant à d’autres comptes AWS, ces derniers seront disponibles pour traitement dans le cadre du connecteur AWS.
-
L’utilisateur Cisco Secure Workload désigné doit disposer des autorisations d’accès AWS suivantes :
1. iam:GetPolicyVersion 2. iam:ListPolicyVersions 3. iam:ListAttachedUserPolicies 4. iam:GetUser 5. servicequotas:ListServiceQuotas
Exemple JSON de politique AWS :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "iam:GetPolicyVersion", "iam:ListPolicyVersions", "iam:ListAttachedUserPolicies", "iam:GetUser", "servicequotas:ListServiceQuotas" ], "Resource": "*" } ] }
-
Créez un rôle IAM AWS dans le compte AWS souhaité dont l’utilisateur Cisco Secure Workload désigné ne fait PAS partie.
-
Autorisez que le rôle AWS IAM soit assumé par l’utilisateur Cisco Secure Workload. Cela peut être fait en ajoutant l’ARN de l’utilisateur Cisco Secure Workload à la politique d’approbation du rôle IAM d’AWS.
Exemple JSON de politique d’approbation de rôle IAM AWS :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": <Secure Workload_user_arn> }, "Action": "sts:AssumeRole", "Condition": {} } ] }
-
Exécutez les étapes 2 et 3 pour tous les comptes AWS souhaités auxquels l’utilisateur Cisco Secure Workload n’appartient pas.
-
Créez une politique gérée par le client (PAS une politique en ligne) avec l’autorisation d’assumer tous les rôles AWS créés à partir de différents comptes.
Remarque
Dans le connecteur AWS, la politique en ligne du client n’est pas prise en charge.
Exemple de politique gérée JSON :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [<AWS_role_cross_account_1_arn>, <AWS_role_cross_account_2_arn>...] } ] }
-
Associez la politique gérée par le client créée à l’utilisateur Cisco Secure Workload.
-
L'assistant de configuration du connecteur fournit un modèle CloudFormation. Après avoir téléchargé la CFT telle quelle sur l’utilisateur Cisco Secure Workload désigné, vous modifierez le modèle et vous téléchargerez le modèle modifié sur le portail CloudFormation pour accorder les autorisations requises pour les rôles AWS IAM. Pour en savoir plus, consultez Configurer un nouveau connecteur AWS.
Authentification à l’aide de rôles
L’authentification basée sur l’utilisateur nécessite des clés d’authentification. Une clé d’authentification mal gérée peut constituer une menace pour la sécurité en raison de sa nature sensible.
L’utilisation de l’authentification basée sur les rôles vous permet de configurer le compte AWS à l’aide de rôles. La configuration du connecteur accepte l'identifiant du rôle (ARN) et assume ce rôle pour effectuer des actions spécifiques sur le compte du client.
L’authentification basée sur les rôles réduit le risque d’accès non autorisé.
Pour accéder à l’authentification basée sur les rôles, procédez comme suit :
Procédure
Étape 1 |
Cliquez sur l’onglet Role (Rôle) dans la page de configuration du connecteur. |
||
Étape 2 |
Enregistrez la grappe. Si la grappe n’est pas enregistrée, elle affiche le message « Cluster is not registered to use role credentials (La grappe n’est pas enregistrée pour utiliser les informations d’authentification du rôle) ». Téléchargez la charge utile fournie et communiquez avec un représentant du service d'assistance à la clientèle.. |
||
Étape 3 |
Dans le message de notification, cliquez sur le bouton de Download (Téléchargement) et téléchargez le fichier de charge utile. |
||
Étape 4 |
Vous pouvez utiliser le lien dans le message de notification pour contacter l’équipe TAC, créer le dossier et fournir le fichier que vous avez téléchargé. |
||
Étape 5 |
Lorsque la grappe est enregistrée, l’ ID externe et l’ARN de l’utilisateur sont remplis automatiquement.
|
||
Étape 6 |
Utilisez l’ ID externe et l’ARN utilisateur générés pour mettre à jour la relation d’approbation de rôle. Elle permet d’assumer le rôle. La même partie du fichier JSON : |
||
Étape 7 |
Lorsque l’étape précédente est terminée, vous pouvez copier l’ ARN de rôle du compte AWS et le coller dans la page de configuration du connecteur AWS. |
Aperçu de la configuration du connecteur AWS
Le graphique suivant donne un aperçu général du processus de configuration du connecteur. Pour obtenir des renseignements essentiels, consultez la rubrique suivante (Configurer un nouveau connecteur AWS)
![Aperçu de la configuration du connecteur AWS](/c/dam/en/us/td/i/400001-500000/460001-470000/468001-469000/468814.jpg)
(Notez que les numéros dans le graphique ne correspondent pas aux numéros d’étape de la procédure détaillée).
Configurer un nouveau connecteur AWS
Procédure
Étape 1 |
Dans le volet de navigation, choisissez . |
||||||||||||||||||||||||
Étape 2 |
Cliquez sur AWS Connector (Connecteur AWS). |
||||||||||||||||||||||||
Étape 3 |
Cliquez sur Generate Template (générer un modèle) et sélectionnez les fonctionnalités souhaitées. En fonction des capacités sélectionnées, un modèle CloudFormation (FormationNuage) (CFT) est généré. Utilisez le modèle CFT généré dans votre CloudFormation AWS pour créer la politique pour l’utilisateur ou le rôle. Pour activer la segmentation, vous devez également cocherGather Labels (Regrouper les étiquettes). |
||||||||||||||||||||||||
Étape 4 |
Téléchargez le modèle CloudFormation (CFT) généré. Le CFT généré peut être utilisé à la fois pour l’utilisateur et le rôle. Ce modèle dispose des privilèges IAM requis pour les fonctionnalités que vous avez sélectionnées à l’étape précédente. Si vous avez activé l’option Kubernetes, vous devez configurer séparément les autorisations pour EKS. Consultez Services gérés Kubernetes s’exécutant sur AWS (EKS). |
||||||||||||||||||||||||
Étape 5 |
Chargez le CFT sur le portail AWS CloudFormation pour attribuer des privilèges à l’utilisateur pour ce connecteur. Assurez-vous que l’utilisateur AWS dispose des privilèges requis avant de pouvoir continuer la configuration du connecteur AWS.
Vous pouvez appliquer le CFT à l’aide du portail ou de la CLI. Pour en savoir plus, consultez ;
Lorsque vous chargez le CFT, AWS exige les détails suivants :
|
||||||||||||||||||||||||
Étape 6 |
Si vous utilisez l’authentification basée sur les rôles d’AWS pour vous connecter au connecteur Cisco Secure Workload, consultez la section Rôles et privilèges d’accès EKS. |
||||||||||||||||||||||||
Étape 7 |
Si vous utilisez l’accès entre comptes AWS, suivez ces étapes supplémentaires :
|
||||||||||||||||||||||||
Étape 8 |
Cliquez sur Getting Started guide (Guide de démarrage, recommandé) ou sur le bouton Configure your new connector here (configurer votre nouveau connecteur ici) pour configurer le connecteur. |
||||||||||||||||||||||||
Étape 9 |
Comprenez et respectez les exigences et les conditions préalables aux rôles et privilèges d’accès AWS, EKS, et la politique de mise en application de la segmentation, puis cliquez sur Get Started (Démarrer). Ou, si vous effectuez la configuration à l’aide du bouton Configure your new connector, (Configurer votre nouveau connecteur) cliquez sur yes (oui). |
||||||||||||||||||||||||
Étape 10 |
Nommez le connecteur et saisissez la description. |
||||||||||||||||||||||||
Étape 11 |
Configurer les paramètres : Vous pouvez utiliser l’une ou l’autre de ces options pour vous connecter au compte AWS.
|
||||||||||||||||||||||||
Étape 12 |
Cliquez sur Next (suivant). |
||||||||||||||||||||||||
Étape 13 |
La page suivante affiche une arborescence des ressources que l'utilisateur peut développer pour visualiser différentes régions. À l'intérieur de la région, vous pouvez cocher ou décocher les cases des ressources pour obtenir la liste des VPC et des grappes EKS d'AWS. |
||||||||||||||||||||||||
Étape 14 |
Dans la liste des réseaux virtuels (VPC), choisissez les VPC pour lesquels vous souhaitez activer les fonctionnalités que vous avez sélectionnées. En général, vous devez activer l’acquisition de flux dès que possible, afin que Cisco Secure Workload puisse commencer à collecter suffisamment de données pour proposer des politiques précises. Notez que, comme EKS prend uniquement en charge la capacité de collecte d’étiquettes, aucune sélection de capacité explicite n’a été fournie. La sélection d’une grappe EKS activera implicitement la capacité prise en charge. Pour chaque grappe pour laquelle vous activez cette fonctionnalité, saisissez le Assume Role ARN (ARN du rôle assumé) (le numéro de ressource Amazon du rôle à assumer lors de la connexion à Cisco Secure Workload. Enable Segmentation (activer la segmentation) sur les VPC supprimera le ou les groupes de sécurité existants et fournira un accès par défaut à tous les VPC. En général, vous ne devez pas choisir Enable Segmentation (activer la segmentation) lors de la configuration initiale. Ultérieurement, lorsque vous serez prêt à appliquer la politique de segmentation pour des VPC spécifiques, vous pourrez modifier le connecteur et activer la segmentation pour ces VPC. Consultez le document de Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire AWS. |
||||||||||||||||||||||||
Étape 15 |
Pour la grappe EKS, vous pouvez autoriser l’accès au rôle AWS IAM en fournissant l’ID d’accès Assume Role ARN pour vous connecter au connecteur AWS. |
||||||||||||||||||||||||
Étape 16 |
Une fois vos sélections terminées, cliquez sur Create (créer) et attendez quelques minutes que la vérification de validation soit terminée. |
Prochaine étape
Si vous avez activé la collecte d'étiquettes, l'acquisition de données de flux ou la segmentation :
-
Si vous activez l’acquisition de flux, cela prendre jusqu’à 25 minutes avant que les flux ne commencent à s’afficher dans la page
(Enquêter sur le trafic). -
(Facultatif) Pour approfondir les données de flux et d’autres avantages, notamment une visibilité sur les vulnérabilités de l’hôte (CVE), installez l’agent approprié pour votre système d’exploitation sur vos charges de travail basées sur VPC. Pour connaître les exigences et en savoir plus, consultez le chapitre sur l’installation de l’agent.
-
Après avoir configuré avec succès le connecteur AWS pour qu’il recueille les étiquettes et les flux d'acquisition, suivez le processus standard pour créer des politiques de segmentation. Par exemple : autorisez Cisco Secure Workload à recueillir suffisamment de données de flux pour générer des politiques fiables; définir ou modifier les portées (en général une pour chaque VPC); créer un espace de travail pour chaque portée; découvrir automatiquement les politiques en fonction de vos données de flux ou créer manuellement des politiques; analyser et affiner vos politiques; vérifier que vos politiques respectent les directives et les bonnes pratiques ci-dessous; puis, lorsque vous êtes prêt, approuvez et appliquez ces politiques dans l’espace de travail. Lorsque vous êtes prêt à appliquer la politique de segmentation pour un VPC particulier, revenez à la configuration du connecteur pour activer la segmentation pour le VPC. Pour de plus amples renseignements, consultez la section Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire AWS.
Si vous avez activé l'option des services gérés par Kubernetes (EKS) :
-
Installez les agents Kubernetes sur vos charges de travail basées sur des conteneurs. Pour en savoir plus, consultez la section Agents Kubernetes/OpenShift : Visibilité et application approfondies dans le chapitre sur le déploiement des agents.
Journal des événements
Les journaux des événements peuvent être utilisés pour connaître les événements importants qui se produisent par connecteur à partir de différentes capacités. Nous pouvons les filtrer à l’aide de divers attributs tels que le composant, l’espace de nom, les messages et l’horodatage.
Modifier un connecteur AWS
Vous pouvez modifier un connecteur AWS, par exemple pour activer l'application de la segmentation pour des VPC spécifiques ou pour apporter d'autres modifications.
Les modifications ne sont pas enregistrées tant que vous n’avez pas achevé l'exécution de l’assistant.
Procedure
Step 1 |
Dans la barre de navigation à gauche de la fenêtre, choisissez . |
Step 2 |
Cliquez sur AWS. |
Step 3 |
Si vous possédez plusieurs connecteurs AWS, choisissez le connecteur à modifier en haut de la fenêtre. |
Step 4 |
Cliquez sur Edit Connector (modifier un connecteur). |
Step 5 |
Cliquez à nouveau dans l’assistant et apportez des modifications. Pour une description détaillée des paramètres, consultez Configurer un nouveau connecteur AWS. |
Step 6 |
Si vous activez différentes fonctionnalités (collecte d’étiquettes, acquisition de flux, application de la segmentation ou collecte de données EKS), vous devez télécharger le modèle Cloud Formation (CFT) révisé et le téléverser sur AWS avant de poursuivre l'assistant. |
Step 7 |
Pour activer l’application de la politique de segmentation, assurez-vous d’abord que vous avez satisfait aux conditions préalables recommandées décrites dans Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire AWS. Sur la page qui répertorie les VPC, choisissez Enable Segmentation (activer la segmentation) pour les VPC sur lesquels vous souhaitez activer l’application. |
Step 8 |
Si vous avez déjà créé des portées pour l’un des VPC sélectionnés, soit à l’aide de l’assistant, soit manuellement, cliquez sur Skip this step (Ignorer cette étape) pour fermer l’assistant. Vous pouvez modifier l’arborescence de la portée manuellement à l’aide de la page . |
Step 9 |
Si vous n'avez pas encore créé de portée pour les VPC sélectionnés et que vous souhaitez conserver la hiérarchie proposée, choisissez la portée parentale au-dessus de l'arborescence des portées, puis cliquez sur Save (Enregistrer). |
Suppression des connecteurs et des données
Si vous supprimez un connecteur, les données déjà acquises par ce connecteur ne sont pas supprimées.
Les étiquettes et l’inventaire sont automatiquement supprimés de l’inventaire actif après 24 heures.
Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire AWS
![]() Warning |
Avant d'activer l'application de la segmentation sur un VPC, créez une sauvegarde des groupes de sécurité sur ce VPC. L’activation de la segmentation pour un VPC supprime les groupes de sécurité existants de ce VPC. La désactivation de la segmentation ne restaure pas les anciens groupes de sécurité. |
Lors de la création de politiques :
-
Comme pour toutes les politiques découvertes, vérifiez que vous disposez de suffisamment de données de flux pour produire des politiques précises.
-
Étant donné qu’AWS n’autorise que les règles ALLLOW (Autoriser) dans les groupes de sécurité, vos politiques de segmentation ne doivent inclure que des politiques Allow, sauf la politique collectrice Catch-All, qui doit avoir l’action Deny (Refuser).
Nous vous recommandons d’activer l’application dans l’espace de travail avant d’activer la segmentation pour le VPC associé. Si vous activez la segmentation pour un VPC qui n’est pas inclus dans un espace de travail dont l’application est activée, tout le trafic sera autorisé sur ce VPC.
Lorsque vous êtes prêt à appliquer une politique pour un VPC, modifiez le connecteur AWS (voir Modifier un connecteur AWS) et activez la segmentation pour ce VPC.
Afficher les étiquettes d’inventaire, les détails et l’état d’application AWS
Pour afficher des informations résumées sur un connecteur AWS, accédez à la page du connecteur (Manage > Connectors), (Gérer > Connecteurs) puis sélectionnez le connecteur en haut de la page. Pour plus de détails, cliquez sur la ligne d’un VPC.
Pour afficher des informations sur l’inventaire de VPC AWS, cliquez sur une adresse IP dans la page AWS Connectors (Connecteurs AWS) afin d’afficher la page Inventory Profile (Profil d'inventaire) pour cette charge de travail. Pour en savoir plus sur les profils d'inventaire, consultez Profil d'Inventaire.
Pour en savoir plus sur les étiquettes, consultez :
Des politiques concrètes pour l’inventaire VPC sont générées en fonction de leur valeur d’étiquette orchestrator_system/interface_id. Vous pouvez le voir sur la page Inventory Profile (Profil d'inventaire).
Pour afficher l’état d’application, choisissez Cisco Secure Workload. Pour en savoir plus, consultez État d’application pour les connecteurs du nuage.
dans la barre de navigation à gauche de la fenêtreRésoudre les problèmes de connecteur AWS
Problème : La page Enforcement Status (État de la mise en application) indique qu’une politique concrète a été SKIPPED (IGNORÉE).
Solution : Cette situation se produit lorsque le nombre de groupes de sécurité dépasse les limites d'AWS, telles que configurées dans le connecteur AWS.
Lorsqu’une politique concrète s’affiche comme SKIPPED (IGNORÉE), les nouveaux groupes de sécurité ne sont pas mis en œuvre et les groupes de sécurité existants sur AWS restent en vigueur.
Pour résoudre ce problème, voyez si vous pouvez consolider les politiques, par exemple en utilisant un sous-réseau plus grand dans une politique plutôt que plusieurs avec des sous-réseaux plus petits.
Si vous choisissez d'augmenter les limites du nombre de règles, vous devez communiquer avec Amazon avant de modifier les limites dans la configuration du connecteur AWS.
Contexte :
Des politiques concrètes sont générées pour chaque VPC lorsque la segmentation est activée. Ces politiques concrètes sont utilisées pour créer des groupes de sécurité dans AWS. Cependant, AWS et Cisco Secure Workload comptabilisent les politiques différemment. Lors de la conversion des politiques Cisco Secure Workload en groupes de sécurité AWS, AWS compte chaque sous-réseau unique comme une règle.
Exemple de comptabilisation :
Examinez l’exemple de politique Cisco Secure Workload suivant :
SORTANT : ensemble d’adresses du client -> ensemble d’adresses du fournisseur – Autoriser les ports TCP 80, 8080
AWS compte cette politique comme (le nombre de sous-réseaux uniques dans l’ensemble d’adresses du fournisseur) multiplié par (le nombre de ports uniques).
Ainsi, si l’ensemble d’adresses du fournisseur se compose de 20 sous-réseaux uniques, cette politique Cisco Secure Workload unique compte dans AWS comme 20 (sous-réseaux uniques) * 2 (ports uniques) = 40 règles dans les groupes de sécurité.
Gardez à l’esprit que, comme les VPC sont dynamiques, le nombre de règles l’est également : les nombres sont donc approximatifs.
Problème : AWS autorise tout le trafic de manière inattendue
Solution : Vérifiez que la politique Catch-All (globale collectrice) dans Cisco Secure Workload est définie sur Deny (Refuser).
Services gérés Kubernetes s’exécutant sur AWS (EKS)
Si vous avez déployé Amazon Elastic Kubernetes Service (EKS) sur votre nuage AWS, vous pouvez utiliser un connecteur AWS pour extraire l’inventaire et les étiquettes (balises EKS) de votre grappe Kubernetes.
Lorsqu’un connecteur AWS est configuré pour extraire des métadonnées de services Kubernetes gérés, Cisco Secure Workload se connecte au serveur d’API de la grappe et suit l’état des nœuds, des pods et des services de cette grappe. Pour les étiquettes Kubernetes collectées et générées à l’aide de ce connecteur, consultez Étiquettes liées aux grappes Kubernetes.
Exigences et prérequis EKS
-
Vérifiez que votre version de Kubernetes est prise en charge. Consultez https://www.cisco.com/go/secure-workload/requirements/integrations.
-
Configurer l’accès requis dans EKS, comme décrit ci-dessous.
Rôles et privilèges d’accès EKS
$ kubectl edit configmap -n kube-system aws-auth
apiVersion: v1
data:
mapAccounts: |
[]
mapRoles: |
- "groups":
- "system:bootstrappers"
- "system:nodes"
"rolearn": "arn:aws:iam::938996165657:role/eks-cluster-2021011418144523470000000a"
"username": "system:node:{{EC2PrivateDNSName}}"
- "rolearn": arn:aws:iam::938996165657:role/BasicPrivilegesRole
"username": secure.workload.read.only-user
"groups":
- secure.workload.read.only
mapUsers: |
[]
kind: ConfigMap
metadata:
creationTimestamp: "2021-01-14T18:14:47Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:mapAccounts: {}
f:mapRoles: {}
f:mapUsers: {}
manager: HashiCorp
operation: Update
time: "2021-01-14T18:14:47Z"
name: aws-auth
namespace: kube-system
resourceVersion: "829"
selfLink: /api/v1/namespaces/kube-system/configmaps/aws-auth
uid: 6c5a3ac7-58c7-4c57-a9c9-cad701110569
Considérations RBAC spécifiques à EKS
Créer un lien de rôle de grappe entre le rôle de grappe et le compte d'utilisateur/de service.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: csw-clusterrolebinging
subjects:
- kind: User
name: csw.read.only
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: csw.read.only
apiGroup: rbac.authorization.k8s.io
kubectl create -f clusterrolebinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/csw-clusterrolebinging created
Pour en savoir plus sur les rôles et l’accès EKS, consultez la section Rôles EKS et privilèges d’accès.
Configurer les paramètres EKS dans l'assistant du connecteur AWS
Vous activez la fonctionnalité des Services gérés Kubernetes lorsque vous configurez le connecteur AWS. Consultez la section Configurer un nouveau connecteur AWS.
Vous aurez besoin de l'ARN Assume Role (ARN Assumer le rôle) pour chaque grappe EKS. Pour en savoir plus, consultez https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html.
Si vous utilisez l’utilisateur AWS pour accéder à la grappe EKS, permettez à l’utilisateur d’accéder à la fonction Assumer le rôle.
Si vous utilisez un rôle IAM entre comptes, permettez au rôle IAM d’accéder à Assumer le rôle.
Prise en charge de l’équilibreur de charge EKS
Nous ajoutons la prise en charge des services de l’équilibreur de charge dans EKS. Les agents Cisco CSW appliquent les règles aux hôtes consommateurs et aux hôtes/pods fournisseurs.
Un équilibreur de charge EKS offre deux options :
-
Conserver l’adresse IP du client.
-
Sur le pod du fournisseur, nous générons
-
Type de cible.
Avant de commencer les scénarios, pour l’intent de politique suivante :
Le service de consommateur à fournisseur, de protocole de service et de port avec des règles d’action Allow (autorisation) pour divers cas est généré comme suit :
Scénario |
Conserver l'adresse IP du client |
Type de cible |
---|---|---|
1 |
Activé |
IP |
2 |
Activé |
Instance |
3 |
Désactivé |
IP |
4 |
Désactivé |
Instance |
Cas 1 :
Sur le nœud du consommateur, nous générons une règle de sortie avec le protocole de service du consommateur au service de l’équilibreur de charge (lb ingress ip) et une autorisation de port.
Il n’y a pas de règle d’hôte sur le nœud fournisseur, mais nous générons une règle d’entrée sur le pod fournisseur avec la source comme pod consommateur, la destination comme pod de fournisseur (tout), le protocole comme protocole cible, le port comme port cible, et (Allow, autoriser) comme action.
Cas 2 :
Sur le nœud du consommateur, nous générons une règle de sortie avec le protocole de service du consommateur au service de l’équilibreur de charge (lb ingress ip) et une autorisation de port.
Le nœud fournisseur génère une règle de préroutage dont la source est le consommateur et la destination tous les nœuds fournisseurs, le protocole le protocole du service, le port le port du nœud du service et l'action l'autorisation.
Sur le pod fournisseur, nous générons une règle d'entrée dont la source est le nœud fournisseur, la destination le pod fournisseur (quelconque), le protocole le protocole cible, le port le port cible et l'action l'autorisation.
Cas 3 :
Sur le nœud du consommateur, nous générons une règle de sortie avec le protocole de service du consommateur au service de l’équilibreur de charge (lb ingress ip) et une autorisation de port.
Il n’y a aucune règle d’hôte sur le nœud du fournisseur. Sur le pod fournisseur, nous générons une règle d'entrée avec la source comme ip d'entrée lb, la destination comme pod fournisseur (quelconque), le protocole comme protocole cible, le port comme port cible et l'action comme autorisation.
Cas 4 :
Sur le nœud du consommateur, nous générons une règle de sortie avec le protocole de service du consommateur au service de l’équilibreur de charge (lb ingress ip) et une autorisation de port.
Le nœud fournisseur génère une règle de préroutage qui définit les adresses IP d’entrée comme source et tous les nœuds fournisseurs comme destination. La règle spécifie le protocole du service comme protocole et le port de nœud du service comme port, avec l’action définie sur allow (autoriser).
Sur le pod fournisseur, nous générons une règle d'entrée dont la source est le nœud fournisseur, la destination le pod fournisseur (quelconque), le protocole le protocole cible, le port le port cible et l'action l'autorisation.
Connecteur Azure
Le connecteur Azure se connecte à votre compte Microsoft Azure pour effectuer les fonctions générales suivantes :
-
Acquisition automatisée de l’inventaire (et de ses balises) en direct à partir de vos réseaux virtuels Azure (VNets) Azure vous permet d’affecter des métadonnées à vos ressources sous forme de balises. Cisco Secure Workload peut intégrer les balises associées aux machines virtuelles et aux interfaces réseau, qui peuvent ensuite être utilisées comme étiquettes dans Cisco Secure Workload pour la visualisation des données d’inventaire et des flux de trafic et les définitions de politiques. Ces métadonnées sont synchronisées en permanence.
Les balises des charges de travail et des interfaces réseau de l’abonnement associé au connecteur sont intégrées. Si les charges de travail et les interfaces réseau sont configurées, les balises sont fusionnées et affichées dans Cisco Secure Workload. Pour en savoir plus, consultez Étiquettes générées par les connecteurs infonuagiques.
-
Acquisition des journaux de flux Le connecteur peut intégrer les journaux de flux que vous configurez dans Azure pour vos groupes de sécurité réseau (NSG). Vous pouvez ensuite utiliser ces données de télémétrie dans Cisco Secure Workload pour la génération de politiques de visualisation et de segmentation.
-
Segmentation Lorsque l’application de la politique de segmentation est activée pour un réseau virtuel, les politiques Cisco Secure Workload sont appliquées à l’aide des groupes de sécurité réseau natifs d’Azure.
-
Acquisition automatisée des métadonnées des grappes AKS Lorsque les services Azure Kubernetes (AKS) sont exécutés sur Azure, vous pouvez choisir de rassembler toutes les métadonnées de nœuds, de services et d’espaces liées à toutes les grappes Kubernetes sélectionnées.
Vous pouvez choisir laquelle des capacités ci-dessus vous souhaitez activer pour chaque réseau virtuel.
Le connecteur Azure prend en charge plusieurs abonnements.
![]() Remarque |
Les régions de la Chine ne sont actuellement pas prises en charge. |
Exigences et prérequis Azure
Pour toutes les fonctionnalités : un seul connecteur peut gérer plusieurs abonnements. Vous aurez besoin d’un ID d’abonnement pour configurer le connecteur. Cet ID d’abonnement peut être l’un des nombreux ID d’abonnement qui sont intégrés à un connecteur.
Dans Azure, créer et enregistrer une application à l’aide d’Azure Active Directory (AD). Vous aurez besoin des renseignements suivants provenant de cette application :
-
ID (client) d’application
-
ID de l’annuaire (détenteur)
-
Renseignements d’authentification client (vous pouvez utiliser un certificat ou une clé secrète client)
-
Identifiant d’abonnement
L’assistant de configuration du connecteur génère un modèle de gestionnaire de ressources Azure (ARM) que vous pouvez utiliser pour créer un rôle personnalisé avec les autorisations nécessaires pour les fonctionnalités du connecteur que vous choisissez d’activer. Ces autorisations s’appliqueront à toutes les ressources de l’abonnement que vous spécifiez pour le connecteur. Assurez-vous que vous disposez des autorisations dans Azure pour charger ce modèle.
Si la connectivité l’exige, assurez-vous qu’un serveur mandataire HTTP est disponible pour cette intégration.
Chaque réseau virtuel (VNet) ne peut appartenir qu’à un seul connecteur Azure. Un compte Azure peut avoir plusieurs connecteurs Azure.
Ce connecteur ne nécessite pas d’appliance virtuelle.
Pour la collecte d’étiquettes et de l’inventaire : aucune condition préalable supplémentaire n’est requise.
Pour l’acquisition des journaux de flux : chaque réseau virtuel (VNet) doit avoir au moins un sous-réseau configuré.
Chaque sous-réseau de chaque réseau virtuel doit être associé à un groupe de sécurité réseau (NSG). Vous pouvez associer un seul NSG à plusieurs sous-réseaux. Vous pouvez définir n’importe quel groupe de ressources lors de la configuration du groupe de sécurité réseau.
Seul le trafic qui atteint une règle NSG sera inclus dans les journaux de flux. Par conséquent, chaque groupe de sécurité réseau devrait avoir au moins une règle pour le trafic entrant et une règle pour le trafic sortant qui s’applique à n’importe quelle source et à toute destination. L’équivalent d’une règle collectrice globale dans Cisco Secure Workload. (Par défaut, les groupes de sécurité réseau incluent ces règles).
Les journaux de flux doivent être activés pour chaque groupe de sécurité réseau.
-
Un compte de stockage dans Azure est requis. Des autorisations d’accès doivent être incluses pour l’abonnement que vous utilisez pour ce connecteur.
-
Les journaux de flux doivent utiliser la version 2.
-
La durée de conservation peut être de deux jours (le connecteur extrait de nouvelles données de flux toutes les minutes, et deux jours devraient laisser suffisamment de temps pour résoudre les échecs de connexion).
Pour la segmentation : l’activation de la segmentation nécessite l’activation de l’option Gather Labels (Rassembler les étiquettes).
Lorsque vous activez la segmentation pour un réseau virtuel (VNet), toutes les règles existantes sont supprimées des groupes de sécurité réseau associés aux sous-réseaux et aux interfaces réseau qui font partie de ces sous-réseaux. Sauvegardez vos règles existantes de groupe de sécurité réseau du sous-réseau et de l’interface réseau avant d’activer la segmentation dans le connecteur.
Voir également Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire Azure, ci-dessous.
Pour les services Kubernetes gérés (AKS) : si vous activez l’option Kubernetes AKS, consultez les exigences et les conditions préalables dans la section des services Kubernetes gérés fonctionnant sur Azure (AKS) ci-dessous, .
Présentation de la configuration du connecteur Azure
Le graphique suivant donne un aperçu général du processus de configuration du connecteur. Pour en savoir plus sur les renseignements importants, consultez la rubrique suivante (Configurer un connecteur Azure).
![Présentation de la configuration du connecteur Azure](/c/dam/en/us/td/i/400001-500000/460001-470000/468001-469000/468825.jpg)
(Notez que les numéros dans le graphique ne correspondent pas aux numéros d’étape de la procédure détaillée).
Configurer un connecteur Azure
Procédure
Étape 1 |
Dans la barre de navigation à gauche de la fenêtre, choisissez (gestion des connecteurs). |
||||||||||||||||
Étape 2 |
Cliquez sur le connecteur Azure. |
||||||||||||||||
Étape 3 |
Cliquez sur Enable (activer) pour le premier connecteur (dans une portée racine) ou Enable Another (activer un autre connecteur) pour les connecteurs supplémentaires de la même portée racine. |
||||||||||||||||
Étape 4 |
Comprenez et respectez les exigences et les prérequis dans le document Exigences et conditions préalables, puis cliquez sur Get Started (Démarrer). |
||||||||||||||||
Étape 5 |
Nommez le connecteur et choisissez les fonctionnalités souhaitées : Les sélections que vous effectuez sur cette page sont utilisées uniquement pour déterminer les privilèges inclus dans le modèle de gestionnaire de ressources Azure (ARM) qui sera généré à l’étape suivante et pour afficher les paramètres que vous devrez configurer. Pour activer la segmentation, vous devez également activer Gather Labels (Regrouper les étiquettes). L’activation de la segmentation sur cette page ne permet pas en elle-même l’application des politiques et n’affecte pas les groupes de sécurité réseau existants. L’application des politiques et la suppression des groupes de sécurité existants se produisent uniquement si vous activez la segmentation pour les réseaux virtuels ultérieurement dans l’assistant. Vous pouvez revenir à cet assistant plus tard pour activer l’application de la politique de segmentation pour les réseaux virtuels individuels. |
||||||||||||||||
Étape 6 |
Cliquez sur Next (suivant) et lisez les informations sur la page de configuration. |
||||||||||||||||
Étape 7 |
Votre abonnement doit disposer des privilèges requis pour que vous puissiez passer à la page suivante de l'assistant. Pour utiliser le modèle Azure Resource Manager (ARM) fourni pour attribuer les autorisations requises pour le connecteur :
Ce modèle dispose des autorisations IAM requises pour les fonctionnalités que vous avez sélectionnées à l’étape précédente. Si vous avez activé l’option des services gérés par Kubernetes, vous devez configurer séparément les autorisations pour AKS. Consultez Services gérés Kubernetes fonctionnant sur Azure (AKS). |
||||||||||||||||
Étape 8 |
Configurer les paramètres :
|
||||||||||||||||
Étape 9 |
Cliquez sur Next (suivant). Le système peut nécessiter quelques minutes pour obtenir la liste des réseaux virtuels et des grappes AKS d’Azure. |
||||||||||||||||
Étape 10 |
Dans la liste des réseaux virtuels et des grappes AKS pour chaque réseau virtuel, choisissez les réseaux virtuels et les grappes AKS pour lesquels vous voulez activer les fonctionnalités sélectionnées. En général, vous devez activer l’acquisition de flux dès que possible, afin que Cisco Secure Workload puisse commencer à collecter suffisamment de données pour proposer des politiques précises. Notez que, puisqu’AKS prend uniquement en charge la capacité de collecte d’étiquettes, aucune sélection de capacité explicite n’a été fournie. La sélection d’une grappe AKS activera implicitement la capacité prise en charge. Téléversez le certificat client et la clé pour chaque grappe pour laquelle vous activez cette fonctionnalité. En général, vous ne devez pas choisir Enable Segmentation (activer la segmentation) lors de la configuration initiale. Plus tard, lorsque vous serez prêt à appliquer la politique de segmentation pour des réseaux virtuels spécifiques, vous pourrez modifier le connecteur et activer la segmentation pour ces réseaux. Consultez Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire Azure. |
||||||||||||||||
Étape 11 |
Une fois vos sélections terminées, cliquez sur Create (créer) et attendez quelques minutes que la vérification de validation soit terminée. La page View Groups (Afficher les groupes) affiche tous les réseaux virtuels que vous avez activés pour les fonctionnalités de la page précédente, regroupés par région. Chaque région et chaque réseau virtuel dans chaque région constitue une nouvelle portée. |
||||||||||||||||
Étape 12 |
(Facultatif) Choisissez la portée parente sous laquelle ajouter le nouvel ensemble de portées. Si vous n’avez encore défini aucune portée, votre seule possibilité est la portée par défaut. |
||||||||||||||||
Étape 13 |
(Facultatif) Pour accepter tous les paramètres configurés dans l'assistant, y compris l'arborescence de portée hiérarchique, cliquez sur Save(enregistrer) . Pour accepter tous les paramètres à l’exception de l’arborescence de la portée hiérarchique, cliquez sur Skip (Ignorer) cette étape. Vous pourrez créer ou modifier manuellement l’arborescence de la porte ultérieurement, sous ). |
Prochaine étape
Si vous avez activé la collecte d’étiquettes, l’acquisition de données de flux ou la segmentation :
-
Si vous avez activé l’acquisition de flux, 25 minutes peuvent être nécessaires avant que les flux ne commencent à s’afficher sur la page
. -
(Facultatif) Pour approfondir des données de flux et d’autres avantages, notamment une visibilité sur les vulnérabilités de l’hôte (CVE), installez l’agent approprié pour votre système d’exploitation sur vos charges de travail de réseau virtuel. Pour connaître les exigences et en savoir plus, consultez le chapitre sur l’installation de l’agent.
-
Après avoir configuré avec succès le connecteur Azure pour recueillir des étiquettes et des flux d'acquisition, suivez le processus standard pour créer des politiques de segmentation. Par exemple : autorisez Cisco Secure Workload à recueillir suffisamment de données de flux pour générer des politiques fiables; définir ou modifier la portée (en général une pour chaque réseau virtuel); créer un espace de travail pour chaque portée; découvrir automatiquement les politiques en fonction de vos données de flux ou créer manuellement des politiques; analyser et affiner vos politiques; vérifier qu'elles respectent les directives et les bonnes pratiques ci-dessous; puis, lorsque vous êtes prêt, approuvez et appliquez ces politiques dans l’espace de travail. Lorsque vous êtes prêt à appliquer la politique de segmentation pour un réseau virtuel donné, revenez à la configuration du connecteur pour activer la segmentation pour ce réseau virtuel. Pour de plus amples renseignements, consultez la section Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire Azure.
Si vous avez activé l’option des services gérés par Kubernetes (AKS) :
-
Installez les agents Kubernetes sur vos charges de travail basées sur des conteneurs. Pour en savoir plus, consultez Installer les agents Kubernetes ou OpenShift pour une visibilité et une application approfondies dans le chapitre sur le déploiement des agents.
Journal des événements
Les journaux des événements peuvent être utilisés pour connaître les événements importants qui se produisent par connecteur à partir de différentes capacités. Nous pouvons les filtrer à l’aide de divers attributs tels que le composant, l’espace de nom, les messages et l’horodatage.
Modifier un connecteur Azure
Vous pouvez modifier un connecteur Azure, par exemple pour activer l’application de la segmentation pour des réseaux virtuels spécifiques ou pour apporter d’autres modifications.
Les modifications ne sont pas enregistrées tant que vous n’avez pas achevé l'exécution de l’assistant.
Procédure
Étape 1 |
Dans la barre de navigation à gauche de la fenêtre, choisissez (gestion des connecteurs). |
Étape 2 |
Cliquez sur Azure. |
Étape 3 |
Si vous avez plusieurs connecteurs Azure, choisissez le connecteur à modifier en haut de la fenêtre. |
Étape 4 |
Cliquez sur Edit Connector (modifier un connecteur). |
Étape 5 |
Cliquez à nouveau dans l’assistant et apportez des modifications. Pour une description détaillée des paramètres, reportez-vous à Configurer un connecteur Azure. |
Étape 6 |
Si vous activez différentes fonctionnalités (collecte d’étiquettes, acquisition de flux, application de la segmentation ou collecte de données AKS), vous devez télécharger le modèle ARM révisé, modifier le texte du nouveau modèle pour préciser l’ID d’abonnement, et charger le nouveau modèle dans le rôle personnalisé que vous voulez. créé dans Azure avant de poursuivre l’assistant. |
Étape 7 |
Pour activer l’application de la politique de segmentation, assurez-vous d’abord que vous avez rempli les conditions préalables recommandées décrites dans Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire Azure. Ensuite, sur la page de l’assistant qui répertorie les réseaux virtuels, choisissez Enable Segmentation (activer la segmentation) pour les réseaux virtuels sur lesquels vous souhaitez activer l’application. |
Étape 8 |
Si vous avez déjà créé des portées pour l’un des réseaux virtuels sélectionnés, soit à l’aide de l’assistant, soit manuellement, cliquez sur Skip this étape (Ignorer cette étape) pour fermer l’assistant. Vous pouvez modifier l’arborescence de la portée manuellement à l’aide de la page . |
Étape 9 |
Si vous n’avez pas encore créé de portées pour les réseaux virtuels sélectionnés et que vous souhaitez conserver la hiérarchie proposée, choisissez la portée parente dans la partie supérieure de l’arborescence, puis cliquez sur Save (Enregistrer). |
Suppression des connecteurs et des données
Si vous supprimez un connecteur, les données déjà acquises par ce connecteur ne sont pas supprimées.
Les étiquettes et l’inventaire sont automatiquement supprimés de l’inventaire actif après 24 heures.
Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire Azure
![]() Avertissement |
Avant d’activer l’application de la segmentation sur un réseau virtuel, créez une sauvegarde des groupes de sécurité réseau sur ce réseau virtuel. L’activation de la segmentation pour un réseau virtuel supprime les règles existantes du groupe de sécurité réseau associé à ce dernier. La désactivation de la segmentation ne restaure pas les anciens groupes de sécurité réseau. |
Lors de la création de politiques : comme pour toutes les politiques découvertes, vérifiez que vous disposez de suffisamment de données de flux pour produire des politiques précises.
Nous vous recommandons d’activer l’application dans l’espace de travail avant d’activer la segmentation pour le réseau virtuel associé. Si vous activez la segmentation pour un réseau virtuel qui n’est pas inclus dans un espace de travail dont l’application est activée, tout le trafic sera autorisé sur ce réseau virtuel.
Lorsque vous êtes prêt à appliquer la politique pour un réseau virtuel, modifiez le connecteur Azure (voir Modifier un connecteur Azure) et activez la segmentation pour ce réseau virtuel.
Notez que si un sous-réseau n’est associé à aucun groupe de sécurité de réseau, Cisco Secure Workload n’applique pas la politique de segmentation sur ce sous-réseau. Lorsque vous appliquez la politique de segmentation sur un réseau virtuel, le groupe de sécurité réseau au niveau du sous-réseau est modifié pour autoriser tout le trafic, et les politiques Cisco Secure Workload remplacent le groupe de sécurité réseau au niveau de l’interface. Un groupe de sécurité réseau pour l’interface est automatiquement créé s’il n’est pas déjà présent.
Afficher les étiquettes d’inventaire, les détails et l’état d’application d’Azure
Pour afficher des renseignements résumés sur un connecteur Azure, accédez à la page du connecteur (Manage > Connectors) (Gérer > Connecteurs), puis sélectionnez le connecteur en haut de la page. Pour plus de détails, cliquez sur une ligne VNet.
Pour afficher des informations sur l’inventaire VNet Azure, cliquez sur une adresse IP dans la page Azure Connectors (connecteurs Azure) afin d’afficher la page Inventory Profile (Profil d'inventaire) pour cette charge de travail. Pour en savoir plus sur les profils d'inventaire, consultez Profil d'Inventaire.
Pour en savoir plus sur les étiquettes, consultez :
Des politiques concrètes pour l’inventaire de réseau virtuel sont générées en fonction de leur valeur d’étiquette orchestrator_system/interface_id. Vous pouvez le voir sur la page Inventory Profile (Profil d'inventaire).
Pour afficher l’état d’application, choisissez Cisco Secure Workload. Pour en savoir plus, consultez État d’application pour les connecteurs du nuage.
dans la barre de navigation à gauche de la fenêtreRésoudre les problèmes de connecteur Azure
Problème : Azure autorise tout le trafic de manière inattendue
Solution : Vérifiez que la politique Catch-All (globale collectrice) dans Cisco Secure Workload est définie sur Deny (Refuser).
Services gérés Kubernetes fonctionnant sur Azure (AKS)
Si vous avez déployé Azure Kubernetes Services (AKS) sur votre nuage Azure, vous pouvez utiliser un connecteur Azure pour extraire dynamiquement l’inventaire et les étiquettes (balises AKS) de votre grappe Kubernetes.
Lorsqu’un connecteur Azure est configuré pour extraire des métadonnées de services Kubernetes gérés, Cisco Secure Workload suit l’état des nœuds, des pods et des services de cette grappe.
Pour les étiquettes Kubernetes collectées et générées à l’aide de ce connecteur, consultez Étiquettes liées aux grappes Kubernetes.
Requirements and Prerequisites for AKS
-
Verify that your Kubernetes version is supported. See the Compatibility Matrix for the operating systems, external systems, and connectors for Secure Workload agents.
-
Enable and configure the Managed Kubernetes Services (AKS) capability when you configure the Azure connector. See Configure an Azure Connector for details.
Prise en charge de l’équilibreur de charge AKS
AKS prend en charge la conservation de l’adresse IP du client.
Pour l’intent de politique suivant :
Le service de consommateur à fournisseur, le protocole de service et le port avec des règles d’action Allow (autorisation) dans différents scénarios se génèrent comme suit :
Scénario |
Conserver l'adresse IP du client |
---|---|
1 |
Activé |
2 |
Désactivé |
Scénario 1 : la fonction Conserver l’adresse IP du client est activée.
Sur le nœud du consommateur, nous générons une règle de sortie avec le service du consommateur vers l'équilibreur de charge (lb ingress ip), le protocole du service et le port sont autorisés.
Une règle de préroutage générée pour le nœud fournisseur, qui définit le consommateur comme source et tous les nœuds fournisseurs comme destination. La règle inclut le protocole de service comme protocole et le port de nœud du service comme port, avec l’action définie sur allow (autoriser).
Sur le pod du fournisseur, nous générons une règle d’entrée avec source comme nœuds de fournisseur, une destination comme pod de fournisseur (n'importe lequel), le protocole comme protocole cible, le port comme port cible et l’action comme allow (autoriser).
Scénario 2 : la fonction de conservation de l’adresse IP du client est désactivée.
Sur le nœud du consommateur, nous générons une règle de sortie avec le service du consommateur vers l'équilibreur de charge (lb ingress ip), le protocole du service et le port sont autorisés.
Le nœud fournisseur génère une règle de préroutage qui définit les adresses IP d’entrée comme source et tous les nœuds fournisseurs comme destination. La règle spécifie le protocole du service comme protocole et le port de nœud du service comme port, avec l’action définie sur allow (autoriser).
Sur le pod du fournisseur, nous générons une règle d’entrée avec la source comme nœuds de fournisseur, la destination comme pod de fournisseur (n’importe quel), le protocole comme protocole cible, le port comme port cible et l’action comme allow (autoriser).
Connecteur GCP
Le connecteur Google Cloud Platform se connecte à GCP pour effectuer les fonctions générales suivantes :
-
Acquisition automatisée de l’inventaire (et de ses balises) en direct à partir du nuage privé virtuel (VPC) GCP
GCP vous permet d'affecter des métadonnées à vos ressources sous forme de balises. Cisco Secure Workload interrogera les balises de ces ressources, qui peuvent ensuite être utilisées pour la visualisation des données d’inventaire et des flux de trafic, et pour la définition de politiques. Cette fonctionnalité maintient le mappage des balises de ressources à jour en synchronisant constamment ces données.
Les balises des charges de travail et des interfaces réseau d’un VPC GCP sont intégrées. Si les charges de travail et les interfaces réseau sont configurées, les balises sont fusionnées et affichées dans Cisco Secure Workload. Pour en savoir plus, consultez Étiquettes générées par les connecteurs infonuagiques.
-
Acquisition des journaux de flux du VPC si vous avez configuré les journaux de flux VPC dans GCP à des fins de surveillance, Cisco Secure Workload peut procéder à l'acquisition des informations des journaux de flux en lisant le compartiment de stockage Google correspondant. Ces données de télémétrie peuvent être utilisées pour la génération de politiques de visualisation et de segmentation.
-
Segmentation : l'activation de cette option permettra à Cisco Secure Workload de programmer les politiques de sécurité à l’aide du pare-feu VPC natif de GCP. Lorsque l’application est activée pour un VPC, les politiques pertinentes sont automatiquement programmées sur le pare-feu de celui-ci.
-
Acquisition automatisée des métadonnées des grappes GKE (capacités K8s) lorsque Google Kubernetes Engine (GKE) s’exécute sur GCP, vous pouvez choisir de rassembler toutes les métadonnées de nœuds, de services et de pods associées à toutes les grappes Kubernetes sélectionnées.
Vous pouvez choisir laquelle des capacités ci-dessus vous souhaitez activer pour chaque VPC.
Exigences et conditions préalables des connecteurs GCP
Pour toutes les fonctionnalités : créez un compte de service dédié dans GCP ou identifiez un compte de service GCP existant pour ce connecteur. L'assistant de configuration du connecteur génère une liste de politiques IAM que vous pouvez utiliser pour attribuer les privilèges requis à ce compte de service. Assurez-vous que vous avez les autorisations dans GCP pour charger cette liste de politiques IAM.
![]() Remarque |
La méthode recommandée pour appliquer l’autorisation de la liste de politiques IAM au compte de service consiste à utiliser la CLI. |
Chaque VPC ne peut appartenir qu’à un seul connecteur GCP. Une grappe Cisco Secure Workload peut avoir plusieurs connecteurs GCP. Recueillez les informations décrites dans les tableaux Configurer un connecteur GCP, ci-dessous.
Ce connecteur ne nécessite pas d’appliance virtuelle.
-
Pour la collecte d’étiquettes et de l’inventaire : aucune condition préalable supplémentaire n’est requise.
-
Pour l’acquisition des journaux de flux : des définitions de journaux de flux au niveau VPC sont requises pour déclencher la collecte des journaux de flux.
Pour utiliser l’acquisition des journaux de flux, l’utilisateur doit activer les journaux de flux sur les VPC souhaités et configurer un récepteur de routeur de journaux.
Filtre d’inclusion pour le récepteur du routeur de journal :
-
resource.type="gce-subnetwork"
-
log_name="projects/<project_id>/logs/compute.googleapis.com%2Fvpc_flows"
Choisissez la destination du récepteur en tant que compartiment de stockage infonuagique, puis choisissez l’ensemble de stockage souhaité.
Lors de la configuration du connecteur GCP avec les journaux de flux d’entrée, il est obligatoire de saisir le nom du compartiment de stockage.
Seuls les journaux de flux du VPC peuvent être intégrés.
Les journaux de flux doivent être publiés dans le compartiment de stockage Google; Cisco Secure Workload ne peut pas collecter les données de flux de Google Cloud Operations Suite.
Cisco Secure Workload peut acquérir des logs de flux à partir d'un compartiment de stockage Google associé à n'importe quel compte, si le compte utilisateur GCP fourni lors de la création du connecteur a accès à la fois aux journaux de flux VPC et au compartiment de stockage Google.
Les attributs de journal de flux suivants (dans n’importe quel ordre) sont requis dans ce dernier : adresse source, adresse de destination, port source, port de destination, protocole, paquets, octets, heure de début, heure de fin, action, indicateurs TCP, ID d’interface, État du journal et direction du flux. Tout autre attribut est ignoré.
Les journaux de flux doivent saisir le trafic autorisé et refusé.
-
-
Pour la segmentation : l’activation de la segmentation nécessite l’activation de l’option Gather Labels (Rassembler les étiquettes).
Sauvegardez vos groupes de sécurité existants avant d’activer la segmentation dans le connecteur, car toutes les règles existantes seront remplacées lorsque vous activerez l’application de la politique de segmentation pour un VPC.
Voir également Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire GCP, ci-dessous.
-
Pour les services Kubernetes gérés (GKE) : si vous activez l’option Kubernetes, consultez les exigences et les conditions préalables dans la section Services gérés Kubernetes s’exécutant sur GCP (GKE) ci-dessous, y compris les privilèges d’accès requis.
Configurer l’accès à plusieurs projets dans GCP
Pour configurer l’accès entre plusieurs projets dans GCP, vous pouvez suivre ces étapes :
Procédure
Étape 1 |
Connectez-vous à votre console GCP. |
||
Étape 2 |
Cliquez sur le menu déroulant du projet dans la barre de navigation supérieure et sélectionnez New Project (Nouveau projet). Vous pouvez soit créer un nouveau projet, soit utiliser un projet existant avec le compte de service. |
||
Étape 3 |
Saisissez un nom pour votre nouveau projet. Choisissez l’organisation à laquelle appartient le nouveau projet ou sélectionnez No organization (Aucune organisation) si vous n’en avez pas. |
||
Étape 4 |
Cliquez sur le bouton Create (Créer) pour créer le nouveau projet.
|
||
Étape 5 |
Pour lier plusieurs projets à un seul compte de service, accédez à la page IAM & Admin et choisissez Service Account (Compte de service). |
||
Étape 6 |
Cliquez sur le bouton Create Service Account (Créer un compte de service). Suivez les instructions pour créer le compte de service et lui accorder les autorisations nécessaires.
|
||
Étape 7 |
Sous l’onglet Keys (clés), cliquez sur Add Key (Ajouter une clé) pour générer une clé privée dans un fichier JSON. |
||
Étape 8 |
Rendez-vous sur la page IAM & Admin de la console GCP et sélectionnez IAM.
|
||
Étape 9 |
Cliquez sur le bouton Grant access (accorder l’accès) pour ajouter un nouveau projet. |
||
Étape 10 |
Dans le champ New principals (oNuveaux principaux), saisissez l’adresse courriel du compte de service que vous souhaitez associer au projet. |
||
Étape 11 |
Cliquez sur le bouton Save (Enregistrer) pour associer le compte de service à votre projet.
|
||
Étape 12 |
Assurez-vous que le compte de service dispose d'autorisations pour le niveau de ressources ancêtre le moins élevé commun (ancêtre commun à tous les projets sélectionnés), tel qu'un dossier ou une organisation. |
Aperçu de la configuration du connecteur GCP
Le graphique suivant donne un aperçu général du processus de configuration du connecteur. Pour en apprendre davantage, consultez la rubrique suivante (Configurer un connecteur GCP).
![](/c/dam/en/us/td/i/400001-500000/470001-480000/472001-473000/472467.jpg)
(Notez que les numéros dans le graphique ne correspondent pas aux numéros d’étape de la procédure détaillée).
Configurer un connecteur GCP
Procédure
Étape 1 |
Dans la barre de navigation à gauche de la fenêtre, choisissez (gestion des connecteurs). |
||||||||
Étape 2 |
Cliquez sur le GCP connector (connecteur GCP). |
||||||||
Étape 3 |
Cliquez sur Enable (activer) pour le premier connecteur (dans une portée racine) ou Enable Another (activer un autre connecteur) pour les connecteurs supplémentaires de la même portée racine. |
||||||||
Étape 4 |
Comprenez et respectez les exigences et les conditions préalables indiquées dans Exigences et conditions préalables des connecteurs GCP et Services gérés Kubernetes s’exécutant sur GCP (GKE), puis cliquez sur Get Started (Démarrer). |
||||||||
Étape 5 |
Attribuez un nom au connecteur et choisissez les fonctionnalités souhaitées, puis cliquez sur Next (Suivant). Les sélections effectuées sur cette page servent uniquement à déterminer les privilèges inclus dans la liste de règles IAM qui sera générée à l'étape suivante, et à afficher les paramètres que vous devrez configurer. Si la fonctionnalité Injest Flow Logs (injecter les journaux de flux) est cochée, vous devez saisir le nom du compartiment de stockage des journaux de flux à l’étape suivante. Pour activer la segmentation, vous devez cocher Gather Labels (recueillir les étiquettes). ![]() |
||||||||
Étape 6 |
Téléchargez la liste des politiques de rôle personnalisé IAM générée. Cette liste de politiques de rôles personnalisés IAM dispose des privilèges IAM requis pour les fonctionnalités que vous avez sélectionnées à l’étape précédente. Si vous avez activé l’option Kubernetes, vous devez configurer séparément les autorisations pour GKE. Pour en savoir plus, consultez Services gérés Kubernetes s’exécutant sur GCP (GKE). |
||||||||
Étape 7 |
Chargez le fichier
|
||||||||
Étape 8 |
Saisissez le nom de la compartiment de stockage des journaux de flux si la fonctionnalité des journaux de flux d’entrée est cochée. |
||||||||
Étape 9 |
Configurez les paramètres suivants :
|
||||||||
Étape 10 |
Cliquez sur Next (suivant). Quelques minutes peuvent être nécessaires pour que le système obtienne la liste des réseaux virtuels et des grappes GKE de votre (vos) projet(s) GCP. |
||||||||
Étape 11 |
Dans la liste des VPC (réseaux virtuels) et des grappes GKE, choisissez les ressources et leurs capacités respectives. En général, vous devez activer l’acquisition de flux dès que possible, afin que Cisco Secure Workload puisse commencer à collecter suffisamment de données pour proposer des politiques précises. En général, vous ne devez pas choisir Enable Segmentation (activer la segmentation) lors de la configuration initiale. Ultérieurement, lorsque vous serez prêt à appliquer la politique de segmentation pour des VPC spécifiques, vous pourrez modifier le connecteur et activer la segmentation pour ces VPC. Consultez la section Bonnes pratiques lors de l’application de la politique de segmentation pour un inventaire GCP. |
||||||||
Étape 12 |
Cliquez sur Create (créer) et attendez quelques minutes que la vérification de validation se termine. La page View Groups (Afficher les groupes) affiche tous les VPC que vous avez activés pour toutes les fonctionnalités sur la page précédente, regroupés par logic_group_id (CSW), qui est également un ID de projet (GCP). Chaque logic_group_id et chaque VPC de chaque logic_group_id est une nouvelle portée. |
||||||||
Étape 13 |
Choisissez la portée parente sous laquelle ajouter le nouvel ensemble de portées. Si vous n’avez encore défini aucune portée, votre seule possibilité est la portée par défaut. |
||||||||
Étape 14 |
Pour accepter tous les paramètres configurés dans l’assistant, y compris l’arborescence de portée hiérarchique, cliquez sur Save(enregistrer). Pour accepter tous les paramètres à l’exception de l’arborescence de la portée hiérarchique, cliquez sur Skip (Ignorer) cette étape. Vous pourrez créer ou modifier manuellement l’arborescence de la porte ultérieurement, sous ). |
Prochaine étape
Si vous avez activé la collecte d'étiquettes, l'acquisition de données de flux ou la segmentation :
-
Si vous avez activé l’acquisition de flux, 25 minutes peuvent être nécessaires avant que les flux ne commencent à s’afficher sur la page
. -
(Facultatif) Pour approfondir les données de flux et d’autres avantages, notamment une visibilité sur les vulnérabilités de l’hôte (CVE), installez l’agent approprié pour votre système d’exploitation sur vos charges de travail basées sur VPC. Pour connaître les exigences et en savoir plus, consultez le chapitre sur l’installation de l’agent.
-
Après avoir configuré avec succès le connecteur GCP pour recueillir des étiquettes et des flux d'acquisition, suivez le processus standard pour élaborer des politiques de segmentation. Par exemple : autorisez Cisco Secure Workload à recueillir suffisamment de données de flux pour générer des politiques fiables; définir ou modifier les portées (en général une pour chaque VPC); créer un espace de travail pour chaque portée; découvrir automatiquement les politiques en fonction de vos données de flux ou créer manuellement des politiques; analyser et affiner vos politiques; vérifier que vos politiques respectent les directives et les bonnes pratiques ci-dessous; puis, lorsque vous êtes prêt, approuvez et appliquez ces politiques dans l’espace de travail. Lorsque vous êtes prêt à appliquer la politique de segmentation pour un VPC particulier, revenez à la configuration du connecteur pour activer la segmentation pour le VPC. Pour de plus amples renseignements, consultez la section Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire GCP.
Si vous avez activé l'option des services gérés par Kubernetes (GKE) :
-
Installez les agents Kubernetes sur vos charges de travail basées sur des conteneurs. Pour en savoir plus, consultez la section Agents Kubernetes/OpenShift : Visibilité et application approfondies dans le chapitre sur le déploiement des agents.
Journal des événements
Les journaux des événements peuvent être utilisés pour connaître les événements importants qui se produisent par connecteur à partir de différentes capacités. Nous pouvons les filtrer à l’aide de divers attributs tels que le composant, l’espace de nom, les messages et l’horodatage.
Modifier un connecteur GCP
Si vous souhaitez activer la collecte de données à partir de grappes GKE ou de VPC différents ou supplémentaires, vous devrez peut-être charger un fichier json de compte de service avec les fonctionnalités requises et des autorisations différentes avant de pouvoir sélectionner différents VPC ou GKE.
Les modifications ne sont pas enregistrées tant que vous n’avez pas achevé l'exécution de l’assistant.
Procédure
Étape 1 |
Dans la barre de navigation à gauche de la fenêtre, choisissez . |
Étape 2 |
Cliquez sur GCP connector (connecteur GCP). |
Étape 3 |
Si vous avez plusieurs connecteurs GCP, choisissez le connecteur à modifier en haut de la fenêtre. |
Étape 4 |
Cliquez sur Edit Connector (modifier un connecteur). |
Étape 5 |
Cliquez à nouveau dans l’assistant et apportez des modifications. Pour une description détaillée des paramètres, reportez-vous à Configurer un connecteur GCP. |
Étape 6 |
Si vous activez différentes fonctionnalités (collecte d’étiquettes, acquisition de flux, application de la segmentation ou collecte de données GKE), vous devez télécharger le modèle IAM révisé et le charger dans GKE avant de poursuivre l'assistant. |
Étape 7 |
Pour activer l’application de la politique de segmentation, assurez-vous d’abord que vous avez rempli les conditions préalables recommandées décrites dans Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire GCP. Dans la page qui répertorie les VPC, sélectionnez Enable Segmentation (activer la segmentation) pour les VPC sur lesquels vous souhaitez activer l’application. |
Étape 8 |
Si vous avez déjà créé des portées pour l’un des VPC sélectionnés, soit à l’aide de l’assistant, soit manuellement, cliquez sur Skip this step (Ignorer cette étape) pour fermer l’assistant. Vous pouvez modifier l’arborescence de la portée manuellement à l’aide de la page . |
Étape 9 |
Si vous n'avez pas encore créé de portée pour les VPC sélectionnés et que vous souhaitez conserver la hiérarchie proposée, choisissez la portée parentale au-dessus de l'arborescence des portées, puis cliquez sur Save (Enregistrer). |
Suppression des connecteurs et des données GCP
Si vous supprimez un connecteur, les données déjà acquises par ce connecteur ne sont pas supprimées.
Les étiquettes et l’inventaire sont automatiquement supprimés de l’inventaire actif après 24 heures.
Bonnes pratiques lors de l’application de la politique de segmentation pour l’inventaire GCP
![]() Avertissement |
Avant d'activer l'application de la segmentation sur un VPC, créez une sauvegarde des groupes de sécurité sur ce VPC. L’activation de la segmentation pour un VPC supprime les groupes de sécurité existants de ce VPC. La désactivation de la segmentation ne restaure pas les anciens groupes de sécurité. |
Lors de la création de politiques :
-
Comme pour toutes les politiques découvertes, vérifiez que vous disposez de suffisamment de données de flux pour produire des politiques précises.
-
Parce que GCP autorise les deux règles ALLOW/DENY (AUTORISER/REFUSER) dans la politique de pare-feu. Depuis, GCP a une limitation très stricte sur le nombre de règles. Donc, il est préférable d’avoir uniquement la liste ALLOW.
Nous vous recommandons d’activer l’application dans l’espace de travail avant d’activer la segmentation pour le VPC associé. Si vous activez la segmentation pour un VPC qui n’est pas inclus dans un espace de travail dont l’application est activée, tout le trafic sera autorisé sur ce VPC.
Lorsque vous êtes prêt à appliquer des politiques pour un VPC, modifiez le connecteur GCP (voir Modifier un connecteur GCP) et activez la segmentation pour ce VPC.
Étiquettes d’inventaire de GKE, détails et état d’application
Pour afficher des informations sommaires sur un connecteur GCP, accédez à Connector > et choisissez GCP Connector (Connecteur GCP) dans la page Connectors (Connecteurs).
Pour afficher des informations sur l’inventaire, cliquez sur l’adresse IP d’une charge de travail particulière dans la page Scopes and Inventory (Portée et inventaire). Vous pouvez également accéder au profil d’inventaire à partir de l’onglet d’interface du profil VPC. Pour en savoir plus sur le profil d’inventaire, consultez Profil d’inventaire.
De même, pour afficher toutes les politiques concrètes sous le profil VPC, sous l’onglet Politiques concrètes du profil d’inventaire, accédez au profil VPC parent pour voir toutes les politiques concrètes sous le VPC.
Le profil VPC est accessible à partir de la page de configuration ou d'état d’application GCP (globale ou au sein d’un espace de travail). Vous pouvez afficher l’état de l’application et les politiques concrètes au niveau du VPC sur le profil VPC. Vous pouvez également afficher les politiques de pare-feu VPC combinées de toutes les interfaces dans l’onglet VPC Firewall Rules (politiques de pare-feu VPC).
Pour en savoir plus sur les étiquettes, consultez :
Résoudre les problèmes de connecteur GCP
Problème : La page Enforcement Status (État de la mise en application) indique qu’une politique concrète a été SKIPPED (IGNORÉE).
Solution : Ce problème se produit lorsque le nombre de règles dans la politique de pare-feu dépasse les limites GCP, telles que configurées dans le connecteur GCP.
Lorsqu’une politique concrète s’affiche comme SKIPPED (IGNORÉE), les nouveaux groupes de sécurité ne sont pas mis en œuvre et les groupes de sécurité existants sur GCP restent en vigueur.
Pour résoudre ce problème, voyez si vous pouvez consolider les politiques, par exemple en utilisant un sous-réseau plus grand dans une politique plutôt que plusieurs avec des sous-réseaux plus petits.
Contexte :
Des politiques concrètes sont générées pour chaque VPC lorsque la segmentation est activée. Ces politiques concrètes sont utilisées pour créer des politiques de pare-feu dans GCP. Cependant, GCP et Cisco Secure Workload comptabilisent les politiques différemment. Lors de la conversion de politiques Cisco Secure Workload en règles de pare-feu GCP dans les politiques de pare-feu, le mécanisme de comptage GCP est complexe. Pour plus de renseignements, voir GCP.
Problème : GCP autorise tout le trafic de manière inattendue
Solution : Vérifiez que la politique Catch-All (globale collectrice) dans Cisco Secure Workload est définie sur Deny (Refuser).
Services gérés Kubernetes s’exécutant sur GCP (GKE)
Vous pouvez utiliser un connecteur infonuagique pour recueillir des métadonnées à partir des grappes Google Kubernetes Engine (GKE) s'exécutant sur Google Cloud Platform (GCP).
Le connecteur rassemble toutes les métadonnées de nœuds, de services et d’espaces liées à toutes les grappes Kubernetes sélectionnées.
Exigences et prérequis
Exigences de Cisco Secure Workload : ce connecteur ne nécessite pas d'appliance virtuelle.
Exigences de la plateforme :
-
Assurez-vous que vous disposez des autorisations dans GCP pour configurer l’accès requis pour ce connecteur.
-
Chaque grappe GKE ne peut appartenir qu’à un seul connecteur GCP.
-
Recueillez les informations décrites dans les tableaux de la section Configurer un connecteur GCP, ci-dessous.
Exigences GKE :
-
Vous devez configurer les privilèges d'accès requis dans GKE.
-
Pour prendre en charge les fonctionnalités des K8 gérés, les rôles requis par le compte de service sont les suivants :
-
Le Compute Network Viewer (Visualiseur de réseau informatique) est un rôle IAM qui donne un accès en lecture seule à toutes les ressources réseau dans GCP.https://cloud.google.com/compute/docs/access/iam#compute.networkViewer
-
Le Kubernetes Engine Viewer (Visualiseur de moteur Kubernetes) est un rôle de grappe GKE qui fournit un accès en lecture seule aux ressources des grappes GKE, telles que les nœuds, les pods et les objets d’API GKE. https://cloud.google.com/iam/docs/understanding-roles#kubernetes-engine-roles
-
Connecteurs d’identité
Le connecteur d’identités sert de pont entre Cisco Secure Workload et divers entrepôts d’identités, tels qu’OpenLDAP, Active Directory et Azure AD. Le connecteur vous permet de synchroniser les renseignements stockés dans les entrepôts d’identités sans intervention manuelle. Actuellement, vous pouvez configurer un connecteur d’identité pour acquérir les données des utilisateurs à partir de LDAP.
Configurer un connecteur OpenLDAP
![]() Note |
La version prise en charge pour l’acquisition de données OpenLDAP est OpenLDAP 2.6. |
Configuration
Créez un connecteur d’identité pour LDAP dans Cisco Secure Workload afin d’établir la communication avec OpenLDAP.
Procédure
Étape 1 |
Dans le volet de navigation, choisissez . |
||||||||||||||||||||
Étape 2 |
Sélectionnez Identity Connector (Connecteur d'identité) et cliquez sur Configure your new connector here (Configurez votre nouveau connecteur ici). |
||||||||||||||||||||
Étape 3 |
Sur la page New Connection (Nouvelle connexion), saisissez les détails comme suit :
|
||||||||||||||||||||
Étape 4 |
Cliquez sur Create (créer). ![]() Un nouveau connecteur d’identité est créé et la communication entre Cisco Secure Workload et OpenLDAP est configurée. |
Inventaire
Lorsque la connexion entre Cisco Secure Workload et OpenLDAP est établie, vous pouvez afficher une liste des utilisateurs et des groupes d’utilisateurs sous l’onglet Inventory (inventaire). Tous les groupes d’utilisateurs auxquels un utilisateur appartient sont affichés sous l’onglet Users (utilisateurs). Seuls les groupes d’utilisateurs uniques sont affichés dans l’onglet User Groups (groupes d’utilisateurs).
Procédure
Étape 1 |
Saisissez les attributs à filtrer. Passez le curseur sur l’icône d’information pour afficher les propriétés à filtrer. |
||
Étape 2 |
Cliquez sur l’icône de menu pour télécharger les données au format JSON ou CSV. ![]()
|
Journal des événements
L’onglet Event Log (journal des événements) affiche des informations, des avertissements et des erreurs qui se produisent lors de l’établissement de la connexion avec OpenLDAP.
Procédure
Étape 1 |
Saisissez les attributs à filtrer. Passez le curseur sur l’icône d’information pour afficher les propriétés à filtrer. |
||
Étape 2 |
Cliquez sur l’icône de menu pour télécharger les données au format JSON ou CSV. ![]()
|
Paramètres avancés
Procédure
Étape 1 |
Sous Synchronize Schedule (Synchroniser la planification), vous pouvez choisir une fréquence à laquelle Cisco Secure Workload synchronise les données d’utilisateur à partir du serveur LDAP. |
Étape 2 |
Dans le champ User Attributes (attributs de l’utilisateur), saisissez jusqu’à six attributs utilisateur à afficher. ![]() |