Cisco
Enterprise Design: Beherrschen von Cisco ISE 3.4 Policy Sets für 2026
Die Cisco Identity Services Engine (ISE) 3.4 ist nicht mehr nur ein RADIUS-Server; sie ist die Policy Engine für das programmierbare Netzwerk. Wenn Sie ISE immer noch mit einer flachen Liste von logiklastigen Policy Sets bereitstellen oder sich auf veraltete „hit-first”-Logik ohne kontextuelle Segmentierung verlassen, bauen Sie ein Kartenhaus, das unter dem Gewicht der IoT-Proliferation und Zero Trust-Anforderungen im Jahr 2026 zusammenbrechen wird. Der Übergang von ISE 2.x zu 3.x führte architektonische Nuancen ein, die viele Ingenieure ignorieren, was zu Leistungseinbußen und „Policy Bloat” führt, die das Troubleshooting zu einem Albtraum machen.
Die Architektur moderner Policy Sets
Um ISE in großem Maßstab zu entwerfen, müssen wir uns vom „Legacy-Silo”-Ansatz lösen. In einem globalen Unternehmen sollten Policy Sets nach Standorttyp oder Geschäftsbereich strukturiert werden, anstatt nach globalen Gerätetypen. ISE 3.4 verarbeitet Richtlinien von oben nach unten, aber die Evaluierungsgeschwindigkeit hängt stark von der Anzahl der Bedingungen innerhalb jedes Sets ab. Wir verwenden die Policy Set-Hierarchie, um den Evaluierungspfad zu minimieren.
Ein „Goldstandard” für eine 2026-Bereite Policy Set-Struktur sieht wie folgt aus:
- Globale Infrastruktur: (TACACS+ für Netzwerkadministratoren)
- Wireless – Corporate: (802.1X, EAP-TLS, Managed Devices)
- Wireless – Guest: (WebAuth, CWA)
- Wired – Dot1X: (Strict 802.1X für Workstations)
- Wired – MAB/IoT: (Profiling-intensiv für Headless Devices)
- VPN/ZTNA: (AnyConnect/Secure Client mit SAML 2.0 / Azure AD-Integration)
Durch die Trennung von Wired und Wireless auf Policy Set-Ebene (Top Level) reduzieren Sie die Anzahl der Autorisierungsregeln, die die Engine für jede einzelne MAC Authentication Bypass (MAB)-Anfrage überprüfen muss. Wenn Ihr IoT-Scanner auf dasselbe Policy Set zugreift wie das iPad Ihres CEOs, ist Ihr Design fehlerhaft.
Erweiterte Bedingungen: Jenseits grundlegender RADIUS-Attribute
In ISE 3.4 nutzen wir Smart Conditions. Hören Sie auf, IP-Adressen oder spezifische Switch IDs in Ihre Policy zu hardcodieren. Verwenden Sie stattdessen Device Groups und Standorthierarchien. Wenn Sie 500 Niederlassungen haben, verwenden Sie das Attribut DEVICE:Device-Location. Dies ermöglicht es Ihnen, auf über 100.000 Endpunkte zu skalieren, ohne eine einzige Zeile zu Ihrer Policy-Logik hinzuzufügen, wenn eine neue Niederlassung eröffnet wird.
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'
Die Einführung von PassiveID und die tiefe Integration mit Microsoft Azure AD (Entra ID) bedeutet, dass Ihre Bedingungen jetzt häufig AzureAD:ExternalGroups verwenden sollten. Ein häufiges Problem ist jedoch die Latenz, die durch mehrere REST API-Aufrufe an die Cloud entsteht. Stellen Sie in 3.4 sicher, dass Sie den ISE Messaging Service verwenden, um hochfrequente Attributabrufe von Ihren AD-Konnektoren zu verarbeiten, um Authentifizierungs-Timeouts (Fehler 5411) zu verhindern.
Autorisierungsprofile und TrustSec (SGT) Integration
Traditionelle VLAN-basierte Segmentierung ist tot. Sie ist zu unbeständig. In einer modernen Cisco DNA Center- oder manuellen VXLAN/EVPN-Umgebung müssen Ihre Autorisierungsprofile Security Group Tags (SGTs) pushen. Der SGT ist das „Identitätslabel“, das dem Paket erhalten bleibt, unabhängig davon, wohin sich der Benutzer im Campus bewegt.
Beim Konfigurieren Ihrer Autorisierungsprofile in ISE 3.4 sollten Sie immer zurückgegeben werden:
- VLAN ID/Name: Als Fallback für nicht-SGT-fähige Switche.
- SGT (Security Group Tag): Für hardwarebasierte Durchsetzung auf der Catalyst 9k-Serie.
- Voice Domain Permission: Notwendig für Multi-Auth-Bereitstellungen an einem einzelnen Port.
Zum Beispiel sollte ein „Developer_Access“-Profil SGT 15 zurückgeben. Die Policy auf Ihrer ASA/FTD oder Ihrem Catalyst Core übernimmt dann die eigentliche 15 -> 20 (DB_Servers) Permit/Deny-Logik. Dies beseitigt das „VLAN Sprawl“, das die Campus-Netzwerke in den letzten zehn Jahren geplagt hat.
MAB vs. Dot1X: Der Zero Trust Konflikt
Die Branche drängt auf „Dot1X überall“, aber die Realität von 2026 ist eine Explosion von unmanaged IoT. MAC Authentication Bypass (MAB) ist von Natur aus unsicher – MAC-Adressen können leicht gespooft werden. Um dies in ISE 3.4 zu mindern, verwenden wir Profiling + Probing. Erlauben Sie einem MAB-Gerät nicht den Zugriff auf das Netzwerk, basierend allein auf seiner MAC-Adresse in einer Liste.
Verwenden Sie die folgende Probing-Hierarchie für hochpräzises Profiling:
- DHCP Probe: Erfasst die Option 55 und Option 60 Strings (am genauesten für die OS-Erkennung).
- HTTP Probe: Erfasst den User-Agent String vom Browser.
- SNMP Query: Wird für Legacy-Industrie-Switches verwendet.
- NMAP Scan: Wird als CoA (Change of Authorization) ausgelöst, wenn ein Gerät „Unknown“ ist.
Durch die Verfeinerung dieser Probes können Sie eine Policy schreiben, die besagt: „Identifiziere dies als HP-Drucker nur, wenn die MAC OUI-registriert bei HP ist UND die DHCP Option 60 mit 'HP-JetDirect' übereinstimmt.“ Wenn sich das OS zu 'Kali Linux' ändert, sendet ISE einen sofortigen CoA-Disconnect.
Posture Assessment in 3.4: Compliance ist unverhandelbar
ISE 3.4 verwaltet die Posture über den AnyConnect/Cisco Secure Client. In einer hybriden Welt nach COVID ist der Zustand der Maschine genauso wichtig wie die Benutzeranmeldeinformationen. Ihre Policy Set Logik für Firmen-Assets sollte immer drei Zustände umfassen:
- Unknown: Temporäres VLAN / Begrenztes SGT. Umleitung zum Client Provisioning Portal, um den Agent herunterzuladen.
- Non-Compliant: Umleitung zur Remediation (WSUS/Patch-Management). Angewandtes High-Risk SGT.
- Compliant: Angewandtes Full-Access SGT.
Informieren Sie sich in unserem Deep Dive über die Optimierung der Secure Client Posture-Module für weitere Details. Wir empfehlen die Verwendung von Periodic Re-assessment (PRA) alle 4 bis 8 Stunden für hochrangige Ziele (Finanzcontroller, Admin-Rollen), um sicherzustellen, dass sie ihre EDR/AV nach der Erstanmeldung nicht deaktiviert haben.
Troubleshooting ISE 3.4: Die technische Realität
Wenn ein Benutzer sich nicht verbinden kann, schauen Sie nicht zuerst in die Switch CLI. Gehen Sie direkt zu Operations > RADIUS > Live Logs. In ISE 3.4 ist der Abschnitt „Steps“ des Detailberichts Ihr Leitfaden. Suchen Sie nach „Step 11001: Received RADIUS Access-Request“ und folgen Sie ihm bis zu „Step 15008: Evaluating Service Selection Policy“.
Häufige Fehler, die wir im Feld sehen:
- 11507 Ext-ID Store failure: Ihre ISE-Nodes können die Domain Controller nicht erreichen. Überprüfen Sie die Latenz; wenn >200ms, schlägt die Authentifizierung fehl.
- 5411 EAP Session Timed Out: Normalerweise verursacht, weil der Endpunkt auf die Eingabe von Anmeldeinformationen durch den Benutzer wartet oder der Switch zu früh ein Timeout hat. Erhöhen Sie den
dot1x timeout tx-periodauf Ihren Catalyst-Ports. - 12511 Unexpected Certificate in EAP-TLS: Der Client präsentiert ein Zertifikat, das nicht von einer CA in Ihrem Trusted Certificates Store signiert ist oder die CRL-Überprüfung fehlgeschlagen ist.
Verwenden Sie das TCP Dump-Tool, das in den Cisco ISE-Node integriert ist (Operations > Troubleshoot > Diagnostic Tools), um den Traffic direkt auf der Gi0-Schnittstelle des Policy Service Node (PSN) zu erfassen. Dies ist oft schneller, als einen RSPAN auf dem Switch einzurichten.
Skalierung der Bereitstellung: PSN-Gruppen und Lastverteilung
Verwenden Sie nicht einfach einen Round-Robin Load Balancer. Für hochskalierte ISE-Bereitstellungen (50.000+ Endpunkte) verwenden Sie Persistent Sessions auf Ihrem F5 oder Citrix ADC. Wenn ein Endpunkt eine EAP-Sequenz mit PSN-01 beginnt, muss er sie mit PSN-01 beenden. Wenn der Load Balancer die Mitte einer Transaktion zu PSN-02 umschaltet, schlägt die Sitzung fehl, da der EAP-Status lokal zu dem Node ist.
Entwerfen Sie Ihre PSN-Nodes paarweise pro geografischer Region. Eine einzelne 3695 (large) Appliance kann ungefähr 50.000 gleichzeitige Sitzungen verarbeiten, aber wir empfehlen, dies auf 30.000 zu begrenzen, um Puffer für Profiling-intensive MAB-Spitzen während Stromausfällen zu lassen (wenn 5.000 Drucker gleichzeitig versuchen, sich wieder zu verbinden).
Zusammenfassend ist Cisco ISE 3.4 das Gehirn Ihres Netzwerks. Behandeln Sie Ihre Policy Sets mit der Strenge von Code. Jede Bedingung sollte einen Zweck haben, und jede Regel sollte Sie einem makro-segmentierten, SGT-gesteuerten Umgebung näherbringen. Für praktische Hilfe bei Ihrem ISE-Design oder einem vollständigen Sicherheitsaudit besuchen Sie uns unter techleague.io.
Häufige Fragen
Was sind die Hauptunterschiede zwischen ISE 3.2 und 3.4 für das Policy-Design?+
Cisco ISE 3.4 bietet eine verbesserte Zuverlässigkeit des Messaging Service, erweiterte SAML 2.0-Unterstützung für Cloud Identity Provider und präzisere Optionen für die Posture Assessment im Vergleich zu 3.2. Es erhöht auch die Sicherheit, indem es standardmäßig ältere, unsichere Protokolle veraltet.
Wie minimiere ich die Latenz bei der ISE Policy-Evaluierung?+
Hochskalierte Bereitstellungen sollten Device Groups und standortbasierte Attribute in den Service Selection Policies verwenden, um einzelne Policy Sets fokussiert und unter 100 Regeln zu halten. Nutzen Sie die Top-to-Bottom-Evaluierungslogik, um den häufigsten Traffic (Dot1X) über weniger häufigen Traffic (Guest/CWA) zu platzieren.
Ist MAB (MAC Authentication Bypass) in einer Zero Trust-Umgebung noch praktikabel?+
MAB sollte immer mit DHCP- und HTTP-Profiling kombiniert werden. Verlassen Sie sich niemals allein auf eine MAC OUI. In Hochsicherheitsumgebungen sollten unbekannte MAB-Geräte mittels eines SGT unter Quarantäne gestellt und mit NMAP gescannt werden, bevor ihnen begrenzter Zugriff gewährt wird.
Warum sollte ich SGTs anstelle von VLANs für die Segmentierung verwenden?+
TrustSec SGTs (Security Group Tags) ermöglichen eine identitätsbasierte Segmentierung, die unabhängig von der zugrunde liegenden VLAN/IP-Topologie ist. Dies reduziert die Komplexität der Firewall-Regelsätze und verhindert das 'VLAN Sprawl' in großen Campus-Netzwerken.
Wie behebe ich „EAP Session Timed Out“-Fehler?+
Überprüfen Sie „Operations > RADIUS > Live Logs“ und suchen Sie nach Fehler 5411. Dies deutet normalerweise auf eine Kommunikationslücke zwischen dem Supplicant und ISE hin, oft verursacht durch ein Timeout auf dem Netzwerk-Switch oder die EAP-Konfiguration des Endpunkts.
Was ist die empfohlene Hardware für eine globale ISE 3.4-Bereitstellung?+
Für große Bereitstellungen verwenden Sie pro Region ein Paar von 3700er-Appliances oder entsprechende VMs. Stellen Sie sicher, dass die Round-Trip-Latenz zwischen PSNs und dem primären PAN für die Datenbanksynchronisierung weniger als 300 ms beträgt. Verwenden Sie einen Load Balancer mit Session-Persistenz für den EAP-Verkehr.