Comment puis-je minimiser la latence dans l'évaluation des politiques ISE ?

Les déploiements à grande échelle devraient utiliser des Device Groups et des attributs basés sur la Localisation dans les politiques de sélection de service pour garder les Policy Sets individuels ciblés et sous 100 règles chacun. Utilisez la logique d'évaluation de haut en bas pour placer le trafic le plus fréquent (dot1x) au-dessus du trafic moins fréquent (Guest/CWA).

Le MAB (MAC Authentication Bypass) est-il toujours viable dans un environnement Zero Trust ?

Le MAB doit toujours être combiné avec le profilage DHCP et HTTP. Ne faites jamais confiance au seul OUI MAC. Dans les environnements hautement sécurisés, les périphériques MAB inconnus doivent être mis en quarantaine à l'aide d'un SGT et scannés avec NMAP avant de se voir accorder un accès limité.

Pourquoi devrais-je utiliser les SGTs au lieu des VLANs pour la segmentation ?

Les SGTs (Security Group Tags) de TrustSec permettent une segmentation basée sur l'identité qui est indépendante de la topologie VLAN/IP sous-jacente. Cela réduit la complexité des ensembles de règles de pare-feu et prévient le 'VLAN sprawl' dans les grands réseaux de campus.

Comment puis-je dépanner les erreurs 'EAP Session Timed Out' ?

Vérifiez 'Operations > RADIUS > Live Logs' et recherchez l'erreur 5411. Cela indique généralement une lacune de communication entre le demandeur et ISE, souvent causée par un délai d'attente sur le commutateur réseau ou la configuration EAP du endpoint.

Quel est le matériel recommandé pour un déploiement global d'ISE 3.4 ?

Pour les déploiements à grande échelle, utilisez une paire d'appliances de la série 3700 ou des machines virtuelles équivalentes par région. Assurez-vous qu'il y a moins de 300 ms de latence aller-retour entre les PSN et le PAN principal pour la synchronisation de la base de données. Utilisez un équilibreur de charge avec persistance de session pour le trafic EAP.

Conception d'entreprise : Maîtriser les Policy Sets de Cisco ISE 3.4 pour 2026

Cisco Identity Services Engine (ISE) 3.4 n'est plus un simple serveur RADIUS ; c'est le moteur de politique pour le réseau programmable. Si vous déployez toujours ISE avec une liste plate de Policy Sets lourds en logique ou si vous vous appuyez sur une logique "hit-first" obsolète sans segmentation contextuelle, vous construisez un château de cartes qui s'effondrera sous le poids de la prolifération de l'IoT et des exigences Zero Trust en 2026. La transition d'ISE 2.x à 3.x a introduit des nuances architecturales que de nombreux ingénieurs ignorent, entraînant une dégradation des performances et une "policy bloat" qui rend le dépannage cauchemardesque.

L'architecture des Policy Sets modernes

Pour concevoir ISE à l'échelle, nous devons nous éloigner de l'approche "silo héritée". Dans une entreprise globale, les Policy Sets devraient être structurés par type de site ou unité commerciale, plutôt que par types de périphériques globaux. ISE 3.4 traite les politiques de haut en bas, mais la vitesse d'évaluation dépend fortement du nombre de conditions au sein de chaque ensemble. Nous utilisons la hiérarchie des Policy Sets pour minimiser le chemin d'évaluation.

Un "Golden Standard" pour une structure de Policy Set prête pour 2026 ressemble à ceci :

Global Infrastructure: (TACACS+ pour les administrateurs réseau)
Wireless - Corporate: (802.1X, EAP-TLS, Managed Devices)
Wireless - Guest: (WebAuth, CWA)
Wired - Dot1X: (Strict 802.1X pour les postes de travail)
Wired - MAB/IoT: (Profilage intensif pour les périphériques sans interface utilisateur)
VPN/ZTNA: (AnyConnect/Secure Client avec SAML 2.0 / Azure AD integration)

En séparant Wired et Wireless au niveau du Policy Set (niveau supérieur), vous réduisez le nombre de règles d'autorisation que le moteur doit vérifier pour chaque demande de MAC authentication bypass (MAB). Si votre scanner IoT atteint le même Policy Set que l'iPad de votre PDG, votre conception est défectueuse.

Conditions avancées : Au-delà des attributs RADIUS de base

Dans ISE 3.4, nous exploitons les Smart Conditions. Cessez de coder en dur des adresses IP ou des ID de Switch spécifiques dans votre politique. Utilisez plutôt les Device Groups et les hiérarchies de localisation. Si vous avez 500 bureaux, utilisez l'attribut DEVICE:Device-Location. Cela vous permet d'évoluer vers plus de 100 000 endpoints sans ajouter une seule ligne à votre logique de politique lorsqu'une nouvelle succursale ouvre.

Condition: Wired_Auto_Condition
Logic: Radius:Service-Type EQUALS Framed-User 
AND Cisco-VPN-3000:CVPN3000-User-Group CONTAINS 'Finance'
AND DEVICE:Device-Location STARTSWITH 'Americas#West'

L'introduction de PassiveID et l'intégration profonde avec Microsoft Azure AD (Entra ID) signifient que vos conditions devraient maintenant fréquemment utiliser AzureAD:ExternalGroups. Cependant, un piège courant est la latence introduite par de multiples appels d'API REST vers le cloud. En 3.4, assurez-vous d'utiliser le ISE Messaging Service pour gérer les récupérations d'attributs à haute fréquence de vos connecteurs AD afin d'éviter les délais d'authentification (Error 5411).

Profils d'autorisation et intégration TrustSec (SGT)

La segmentation traditionnelle basée sur les VLAN est dépassée. Elle est trop fragile. Dans un environnement moderne Cisco DNA Center ou VXLAN/EVPN manuel, vos Authorization Profiles doivent pousser les Security Group Tags (SGTs). Le SGT est l'"étiquette d'identité" qui reste avec le paquet, quel que soit l'endroit où l'utilisateur se déplace sur le campus.

Lorsque vous configurez vos Authorization Profiles dans ISE 3.4, vous devez toujours renvoyer :

VLAN ID/Name: En tant que solution de repli pour les switches non compatibles SGT.
SGT (Security Group Tag): Pour l'application matérielle sur la série Catalyst 9k.
Voice Domain Permission: Nécessaire pour les déploiements multi-authentification sur un seul port.

Par exemple, un profil "Developer_Access" devrait renvoyer SGT 15. La politique sur votre ASA/FTD ou Catalyst Core gère ensuite la logique réelle de permission/refus de 15 -> 20 (DB_Servers). Cela élimine la "VLAN Sprawl" qui a affligé les réseaux de campus au cours de la dernière décennie.

MAB vs. Dot1X : Le conflit Zero Trust

L'industrie pousse pour "Dot1X everywhere", mais la réalité de 2026 est une explosion d'IoT non gérés. Le MAC Authentication Bypass (MAB) est intrinsèquement non sécurisé — les adresses MAC sont facilement usurpées. Pour atténuer cela dans ISE 3.4, nous utilisons le Profiling + Probing. Ne permettez pas à un périphérique MAB d'accéder au réseau uniquement sur la base de son adresse MAC figurant dans une liste.

Utilisez la hiérarchie de sondes suivante pour un profilage de haute fidélité :

DHCP Probe: Capture les chaînes Option 55 et Option 60 (les plus précises pour la détection de l'OS).
HTTP Probe: Capture la chaîne User-Agent du navigateur.
SNMP Query: Utilisé pour les switches industriels hérités.
NMAP Scan: Déclenché comme un CoA (Change of Authorization) lorsqu'un périphérique est "Unknown".

En affinant ces sondes, vous pouvez écrire une politique qui dit : "Identifiez ceci comme une imprimante HP uniquement si le MAC est enregistré OUI pour HP ET l'Option 60 DHCP correspond à 'HP-JetDirect'." Si l'OS passe à 'Kali Linux', ISE envoie un CoA Disconnect immédiat.

Posture Assessment en 3.4 : La conformité est non négociable

ISE 3.4 gère la Posture via le AnyConnect/Cisco Secure Client. Dans un monde hybride post-COVID, l'état de la machine est tout aussi important que les identifiants de l'utilisateur. Votre logique de Policy Set pour les actifs d'entreprise devrait toujours impliquer trois états :

Unknown: VLAN temporaire / SGT limité. Redirection vers le portail de provisionnement client pour télécharger l'agent.
Non-Compliant: Redirection vers la remédiation (WSUS/gestion des patchs). SGT à haut risque appliqué.
Compliant: SGT d'accès complet appliqué.

Consultez notre analyse approfondie sur l'optimisation des modules de posture Secure Client pour plus d'informations à ce sujet. Nous recommandons d'utiliser le Periodic Re-assessment (PRA) toutes les 4 à 8 heures pour les cibles de grande valeur (contrôleurs financiers, rôles d'administrateur) afin de s'assurer qu'ils n'ont pas désactivé leur EDR/AV après la connexion initiale.

Dépannage ISE 3.4 : La réalité de l'ingénierie

Quand un utilisateur ne peut pas se connecter, ne regardez pas d'abord la CLI du Switch. Allez directement à Operations > RADIUS > Live Logs. Dans ISE 3.4, la section "Steps" du rapport détaillé est votre feuille de route. Recherchez 'Step 11001: Received RADIUS Access-Request' et suivez-le jusqu'à 'Step 15008: Evaluating Service Selection Policy'.

Les échecs courants que nous rencontrons sur le terrain :

11507 Ext-ID Store failure: Vos nœuds ISE ne peuvent pas atteindre les Domain Controllers. Vérifiez la latence ; si >200ms, l'authentification échouera.
5411 EAP Session Timed Out: Généralement causé par le endpoint en attente d'une saisie de crédentiels par l'utilisateur, ou le switch qui expire trop tôt. Augmentez le dot1x timeout tx-period sur vos ports Catalyst.
12511 Unexpected Certificate in EAP-TLS: Le client présente un certificat non signé par une CA dans votre magasin de certificats approuvés ou la vérification CRL a échoué.

Utilisez l'outil TCP Dump intégré au nœud Cisco ISE (Operations > Troubleshoot > Diagnostic Tools) pour capturer le trafic directement sur l'interface Gi0 du Policy Service Node (PSN). C'est souvent plus rapide que de configurer un RSPAN sur le switch.

Mise à l'échelle du déploiement : Groupes PSN et équilibrage de charge

N'utilisez pas simplement un équilibreur de charge round-robin. Pour les déploiements ISE à grande échelle (plus de 50 000 endpoints), utilisez les Persistent Sessions sur votre F5 ou Citrix ADC. Si un endpoint démarre une séquence EAP avec PSN-01, il doit la terminer avec PSN-01. Si l'équilibreur de charge bascule le milieu d'une transaction vers PSN-02, la session échouera car l'état EAP est local au nœud.

Concevez vos nœuds PSN par paires par région géographique. Un seul appliance 3695 (grande) peut gérer environ 50 000 sessions simultanées, mais nous recommandons de plafonner cela à 30 000 pour laisser de la marge pour les pics MAB à profilage intensif lors des pannes de courant (lorsque 5 000 imprimantes essaient de se reconnecter en même temps).

En résumé, Cisco ISE 3.4 est le cerveau de votre réseau. Traitez vos Policy Sets avec la rigueur du code. Chaque condition doit avoir un but, et chaque règle doit vous rapprocher d'un environnement macro-segmenté et basé sur les SGT. Pour une aide pratique sur votre conception ISE ou un audit de sécurité complet, visitez-nous sur techleague.io.