BUILD-002 · Zero-Trust-PoC
Zugriff gewähren.Und wiederentziehen.
Vom Maschinenzertifikat bis zur Anwendung: Cisco ISE, 802.1X und Secure Firewall in einer durchgängig geprüften Zugriffskette.
Geprüft am 25. September 2026 · Configlane
Derselbe Client. Dieselbe Anwendung.
01 · Autorisiert
HTTP 200
EAP-TLS · VLAN 11 · SGT 20
02 · Berechtigung entzogen
Zugriff gesperrt
Policy-Änderung + CoA
03 · Wieder freigegeben
HTTP 200
Regel aktiv · erneut autorisiert
Die Fragestellung
Was darf ein erfolgreich angemeldetes Gerät?
Ein Gerät weist sich mit seinem Maschinenzertifikat aus, bekommt eine definierte Rolle und erreicht die dafür freigegebene Anwendung. Ändert sich die Autorisierung, muss dieser Zugriff wieder verschwinden. Genau diese Kette haben wir aufgebaut und mit echtem Anwendungstraffic überprüft.
Der per EAP-TLS autorisierte Client erhält eine erfolgreiche HTTPS-Antwort. Ein registriertes IoT-Gerät bekommt Netzzugang in einem anderen Segment, wird aber vor derselben Anwendung blockiert. Nach einer gezielten Policy-Änderung und Change of Authorization verliert auch der zuvor berechtigte Client den Zugriff. Sobald die Freigabe wieder gilt, funktioniert seine HTTPS-Anfrage erneut.
01 / Architektur
Jede Entscheidung hat ihren Ort.
ISE entscheidet über den Netzzugang. Der Catalyst setzt die Entscheidung am Anschluss um. Die Firewall begrenzt den gerouteten Verkehr zur Anwendung.
AD / Enterprise-CA
Identität und Zertifikate
Cisco ISE
RADIUS / CoA
Cisco FMC
Policy-Verwaltung
ISE → Catalyst: Zulassung und Rolle. FMC → FTD: Firewall-Policy.
Datenpfad zur Anwendung
- 01 / Identität
Endpunkte
EAP-TLS / MAB
- 02 / Netzzugang
Catalyst
VLAN 11 / 12 · SGT 20 / 30
- 03 / Segmentierung
Secure Firewall
IP-basierte Regeln
- 04 / Zugriff
Anwendung
HTTPS
EAP-TLS · VLAN 11 / SGT 20
Autorisierter Client → HTTPS erlaubt
MAB · VLAN 12 / SGT 30
Registriertes IoT → HTTPS gesperrt
- 01
Identität prüfen
EAP-TLS, vertrauenswürdige Zertifikate und eine zuordenbare Computeridentität.
- 02
Berechtigung bestimmen
ISE wertet Anmeldetyp und Gruppe aus und weist VLAN und Security Group Tag zu.
- 03
Zugriff durchsetzen
Der Access-Port kontrolliert die Zulassung. FTD erlaubt oder sperrt den Anwendungszugriff.
02 / EAP-TLS
Zertifikat trifft Verzeichnisidentität.
- Exakte Prüfung des EAP-Servernamens
- AD-Gruppe: Domain Computers
- VLAN 11 / SGT 20
- Default: DenyAccess
Der Linux-Client verwendet ein Maschinenzertifikat aus der Enterprise-CA. Sein Supplicant prüft die vertrauenswürdige CA und den exakten Namen des ISE-EAP-Servers. Der private Clientschlüssel bleibt auf dem Endpunkt und ist mit Dateimodus 0600 geschützt.
ISE entnimmt dem Zertifikat die Identität. Für die Autorisierung wird sie dem vorbereiteten AD-Computerkonto und dessen Gruppe Domain Computers zugeordnet. Der Linux-Client selbst ist für diesen konkreten Test nicht der Domäne beigetreten. Zertifikatsprüfung und gruppenbasierte Autorisierung sind getrennte Schritte [1].
Die passende Regel liefert VLAN 11 und SGT 20. Der Rollenname Employee bezeichnet hier das berechtigte Gerätesegment; geprüft wurde eine Computeridentität. Für 802.1X ist ausschließlich EAP-TLS zugelassen. Der nachgewiesene Handshake verwendete TLS 1.2.
Vor der Autorisierung war der Datenport gesperrt und die HTTPS-Anfrage erfolglos. Nach EAP-TLS meldete der Catalyst Authorized, einschließlich VLAN 11 und SGT 20. Die erneute Anfrage über das Dateninterface des Clients lieferte HTTP 200.
03 / MAB
Begrenzte Rechte für IoT.
Netzzugang erlaubt. Anwendungszugriff gesperrt.
Für den zweiten Endpunkt verwenden wir MAC Authentication Bypass. ISE akzeptiert eine ausdrücklich registrierte MAC-Adresse in einer festgelegten Endpunktgruppe und weist VLAN 12 sowie SGT 30 zu. Unbekannte Geräte erhalten keine allgemeine Freigabe.
Eine MAC-Adresse lässt sich nachbilden. MAB ist deshalb kein kryptografischer Identitätsnachweis [2]. Der Endpunkt erhält nur die für seine Rolle vorgesehenen Rechte.
Der IoT-Endpunkt war am Catalyst erfolgreich autorisiert. Seine HTTPS-Anfrage zur geschützten Anwendung lief dennoch in einen Timeout. Gleichzeitig stieg der Trefferzähler der zugehörigen FTD-Sperrregel von 7 auf 14. Dieselbe Anwendung war vom EAP-TLS-Client erreichbar.
04 / Change of Authorization
Berechtigung ändern. Wirkung nachweisen.
Wir haben die Autorisierungsregel gezielt deaktiviert, über ISE die Sitzung neu bewerten lassen und anschließend die ursprüngliche Freigabe wiederhergestellt. Die Firewall-Regeln blieben dabei unverändert.
Ausgewählter Prüfschritt 1 / 3
Zugriff erlaubt
EAP-TLS identifiziert den Client. Die AD-Gruppenbedingung trifft zu, die Autorisierungsregel ist aktiv.
- Neue HTTPS-Anfrage
- HTTP 200
- Catalyst-Sitzung
- Authorized
- ISE-Entscheidung
- VLAN 11 / SGT 20
Interaktive Darstellung der gemessenen Testfolge · keine Live-Verbindung
Der CoA-Aufruf löste eine Reauthentisierung der ausgewählten Sitzung aus [3]. Geprüft wurden neue HTTPS-Anfragen nach dem Berechtigungsentzug. Eine Abschaltzeit und das Verhalten bereits laufender Langzeitverbindungen wurden nicht gemessen.
05 / Abnahme
Die Zugriffsmatrix.
Sitzungszustand und Anwendungsergebnis wurden gemeinsam bewertet. Die Messpunkte liegen auf dem tatsächlichen Weg vom Client zum Dienst.
| Zustand | Netzzugang / Rolle | HTTPS-Ergebnis | Beleg |
|---|---|---|---|
| Vor EAP-TLS | Nicht autorisiert | Gesperrt | Anfrage erfolglos |
| Nach EAP-TLS + AD | VLAN 11 / SGT 20 | HTTP 200 | Authorized + App-Antwort |
| Registriertes IoT / MAB | VLAN 12 / SGT 30 | Gesperrt | Timeout + FTD-Deny 7 → 14 |
| Policy-Entzug + CoA | Nicht autorisiert | Gesperrt | ISE 15039 + Timeout |
| Freigabe wiederhergestellt | VLAN 11 / SGT 20 | HTTP 200 | Erneute Autorisierung |
| Nach Wiederanlauf | EAP-TLS / MAB erhalten | Rollenabhängig | HTTP 200 / FTD-Deny 0 → 7 |
Der Supplicant besitzt einen getrennten Managementzugang. Die Anwendungstests liefen über sein NAC-Dateninterface. Routen, Weiterleitung, Next Hops und Rückwege wurden geprüft. Access-ACLs sperren direktes Employee↔IoT-Routing am Switch; im internen FTD-Pfad findet kein NAT statt.
SGT / TrustSec
Zuweisung am Access. Klare Grenze der Abnahme.
Nachgewiesen: SGT-Zuweisung
ISE liefert SGT 20 beziehungsweise SGT 30. Der Catalyst zeigt beide Werte an den jeweiligen Sitzungen. Damit ist die Zuordnung von authentisierter Identität und Sicherheitsgruppe am Access belegt.
Durchgesetzt: IP-basierte Firewall-Regeln
FTD entscheidet in diesem PoC anhand der Clientnetze. Eine FMC-Anbindung über pxGrid, SGT-basierte Firewall-Regeln und SGACL-Durchsetzung wurden nicht abgenommen.
Für einen vollständigen TrustSec-Nachweis folgen die Prüfung der Weitergabe der Gruppenzuordnung und ihrer Verwendung am jeweiligen Durchsetzungspunkt.
06 / Wiederanlauf
Gesichert. Wiederhergestellt. Erneut geprüft.
- EAP-TLS: HTTP 200
- IoT: FTD-Deny 0 → 7
- VLAN / SGT erhalten
Nach der Abnahme haben wir den vollständigen Zustand gesichert und daraus den Aufbau erneut gestartet. EAP-TLS, MAB, VLAN-/SGT-Zuordnung sowie erlaubte und gesperrte HTTPS-Zugriffe wurden wieder geprüft. Die benötigten Zertifikate und privaten Schlüssel waren vorhanden.
Der EAP-TLS-Client erreichte die Anwendung erneut. Der IoT-Zugriff blieb gesperrt und erzeugte neue Treffer der FTD-Regel. Dafür waren keine nachträglichen Konfigurationsänderungen erforderlich.
Der geprüfte Stack
Softwarestände des PoC.
| Baustein | Aufgabe | Stand |
|---|---|---|
| Cisco ISE | EAP-TLS, AD, VLAN/SGT, CoA | 3.5.0.527 Patch 4 |
| Cisco FMC | Access-Control-Policy verwalten | 10.0.1 Build 1 |
| Cisco FTD | Anwendungszugriffe durchsetzen | 10.0.0 Build 140 |
| Virtueller Catalyst 9000 | Authenticator / Access | IOS XE 17.18.2 |
| Windows Server | AD, DNS, Enterprise-CA | Server 2022 |
| Linux / wpa_supplicant | Verkabeltes 802.1X | Ubuntu 24.04.4 |
Die Liste beschreibt die geprüften Versionen. Plattformauswahl und Softwarefreigabe für einen produktiven Einsatz erfolgen projektspezifisch.
07 / Umfang & nächste Schritte
Eine belastbare Grundlage für den nächsten Schritt.
Der PoC verbindet Identität, Rollenentscheidung, erlaubten Datenpfad, gesperrten Datenpfad und den Entzug einer Berechtigung. Jeder dieser Schritte lässt sich einzeln beobachten und gemeinsam testen.
Der dokumentierte 802.1X-Nachweis gilt für den verkabelten Linux-Supplicant. Windows-802.1X, Produktionsdurchsatz und Skalierung gehören nicht zu diesem Ergebnis. Eine automatische, risikobasierte Quarantäne wurde nicht eingerichtet.
- Zertifikatslebenszyklus einschließlich CRL / OCSP
- Ausfallverhalten und Hochverfügbarkeit
- Rollout auf den vorgesehenen Endgeräten
- Posture und SGT-basierte Durchsetzung
Quellen und Einordnung
Die Ergebnisse stammen aus der eigenen Abnahme vom 25. September 2026. Die Cisco-Quellen erläutern die zugrunde liegenden Mechanismen.
- [1]Configure EAP-TLS Authentication with ISE
Cisco · Veröffentlicht / aktualisiert: 2023-07-13 · Geprüft am 25.09.2026
- [2]Trust Analytics and Anti-Spoofing Protection
Cisco Blogs · Veröffentlicht / aktualisiert: 2021-07-20 · Geprüft am 25.09.2026
- [3]Using Change of Authorization REST APIs
Cisco DevNet · Geprüft am 25.09.2026