Cisco SUDI verstehen: Hardware-verankerte Identität bei der sicheren Netzwerk-Zugangskontrolle

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und konversationellen Ton - wie ein leitender Netzwerksicherheitsberater, der einen Kunden bei einem Arbeitsessen informiert. Gemäßigtes Tempo, klare Artikulation, gelegentlicher trockener Humor. Kein Vortrag. Kein Verkaufsgespräch. Ein technisches Peer-to-Peer-Briefing: Willkommen zur technischen Briefing-Reihe von Purple. Ich bin Ihr Gastgeber, und heute befassen wir uns mit etwas, das bei Netzwerkbereitstellungen in Unternehmen häufig vorkommt - Cisco SUDI. Das steht für Secure Unique Device Identifier. Wenn Sie nach einer klaren Antwort darauf gesucht haben, was es eigentlich tut, wie es in die 802.1X-Authentifizierung passt und ob es für Ihr Standort- oder Campus-Netzwerk eine Rolle spielt, [kurze Pause] sind Sie hier genau richtig. Beginnen wir mit dem Kernproblem. Die meisten Unternehmensnetzwerke verlassen sich immer noch auf MAC-Adressen zur Identifizierung von Geräten. MAC Authentication Bypass - oder MAB - ist allgegenwärtig. Das Problem ist, dass MAC-Adressen trivial gefälscht werden können. Ein böswilliger Akteur mit einem Laptop und fünfzehn Minuten Zeit kann die MAC-Adresse eines vertrauenswürdigen Access Points klonen und direkt in Ihr Netzwerk eindringen. Das ist kein theoretisches Risiko. Es ist ein dokumentierter Angriffsvektor, und einer, den PCI DSS 4.0 ausdrücklich als unzureichend für Karteninhaber-Datenumgebungen bezeichnet. Die Frage lautet also: Wie beweisen Sie, dass ein Gerät das ist, was es zu sein vorgibt? Nicht nur "es hat die richtige MAC-Adresse" - sondern echt, kryptografisch bewiesen. Hier kommt SUDI ins Spiel. [kurze Pause] Ciscos Secure Unique Device Identifier ist ein X.509-Version-3-Zertifikat, das während der Herstellung in das Trust Anchor-Modul des Geräts - den TAm-Chip - eingebrannt wird. Das Zertifikat enthält die Produktkennung und die Seriennummer und ist mit der öffentlichen Root-Zertifizierungsstelle von Cisco verknüpft. Der private Schlüssel wird im TAm-Chip generiert und niemals exportiert. Niemals. Sie können ihn nicht klonen. Sie können ihn nicht fälschen. Die Identität ist physisch an das Silizium gebunden. Dies macht SUDI zu einer Implementierung von IEEE 802.1AR - dem Standard für Secure Device Identifiers. In der 802.1AR-Terminologie ist die SUDI eine IDevID - ein Initial Device Identifier. Es ist die werkseitig installierte Identität, die beweist, dass das Gerät ein echtes Cisco-Produkt ist, das in einer bekannten Einrichtung mit einer bekannten Seriennummer hergestellt wurde. Warum ist das nun in der Praxis wichtig? Lassen Sie uns den Authentifizierungsfluss durchgehen. Wenn ein Cisco-Gerät - beispielsweise ein Catalyst-Switch oder ein Meraki Access Point - eine Verbindung zu Ihrem Netzwerk herstellt, kann es als 802.1X-Supplicant fungieren. Es präsentiert sein SUDI-Zertifikat dem Authentifikator des Netzwerks, in der Regel einem Switch-Port oder einem Wireless-Controller. Der Authentifikator leitet diese Anmeldeinformationen an einen RADIUS-Server weiter - Cisco ISE ist hier die am häufigsten verwendete Option, aber jeder RFC 2865-konforme RADIUS-Server funktioniert. Der RADIUS-Server validiert die Zertifikatskette zurück zur Root-CA von Cisco. Wenn die Kette gültig ist, ist das Gerät echt. Der Zugriff wird gewährt und das entsprechende VLAN zugewiesen. Der gesamte Austausch nutzt EAP-TLS - Extensible Authentication Protocol mit Transport Layer Security - also die Variante der gegenseitigen Authentifizierung. Sowohl das Gerät als auch das Netzwerk authentifizieren sich gegenseitig. Keine Passwörter. Keine gemeinsam genutzten Geheimnisse. Keine MAC-Adressen. Nur ein kryptografischer Nachweis. [short pause] Lassen Sie uns über Zero Touch Provisioning sprechen, denn hier wird SUDI für große Bereitstellungen erst richtig nützlich. Stellen Sie sich vor, Sie installieren 200 Access Points in einer Hotelkette oder stellen eine Netzwerkinfrastruktur an 40 Einzelhandelsstandorten bereit. Traditionell bedeutet das, dass an jedem Standort ein Techniker jedes Gerät manuell konfigurieren muss. Mit SUDI-basiertem ZTP startet das Gerät, präsentiert seine SUDI-Identität einem Provisionierungsserver, der Server validiert das Zertifikat, gleicht die Seriennummer mit Ihrem Bestand ab und pusht die korrekte Konfiguration - verschlüsselt, sodass nur dieses spezifische Gerät sie entschlüsseln kann. Die Aufgabe des Technikers beschränkt sich auf die physische Installation. Das Netzwerk erledigt den Rest. Für Hotel- und Einzelhandelsbetreiber bedeutet das eine erhebliche betriebliche Ersparnis. Premier Inn zum Beispiel betreibt Hunderte von Hotels. Die Möglichkeit, vorkonfigurierte Hardware an einen Standort zu versenden und sie sich selbst gegen eine bekannte Identität konfigurieren zu lassen, macht den Unterschied zwischen einem zweitägigen Inbetriebnahmebesuch und einem zweistündigen aus. [short pause] Kommen wir nun zum Lebenszyklus von Zertifikaten, denn hier geraten Teams manchmal in Stolperfallen. Die ursprünglichen SUDI-Zertifikate wurden mit einer Gültigkeitsdauer von zehn Jahren ab Herstellungsdatum ausgestellt, begrenzt auf den 14. Mai 2029. Cisco hat Field Notices herausgegeben - FN 72094 und FN 72105 - die die betroffenen Produkte abdecken. Geräte, die nach Mai 2019 hergestellt wurden, haben ein kürzeres Zeitfenster als zehn Jahre. Wenn das SUDI abläuft, funktionieren Funktionen, die für TLS darauf angewiesen sind - wie HTTPS-Verwaltungsschnittstellen, SSH-Zertifikatsauthentifizierung, ZTP - möglicherweise nicht mehr. Das Gerät selbst läuft weiter; es wird nicht unbrauchbar. Aber diese spezifischen authentifizierten Dienste fallen aus. Die Reaktion von Cisco bestand darin, SUDI-2099-Zertifikate auf neuerer Hardware einzuführen, die bis Dezember 2099 gültig sind. Wenn Sie heute Cisco-Infrastruktur beschaffen, erhalten Sie SUDI-2099. Wenn Sie ältere Geräte im Einsatz haben, überprüfen Sie Ihre Ablaufdaten mit "show crypto pki certificates" unter IOS oder IOS-XE. Planen Sie Ihren Erneuerungszyklus entsprechend. [short pause] Nun zu den Implementierungsempfehlungen. Drei Dinge, die ich jedem IT-Manager mit auf den Weg geben würde, der eine SUDI-basierte Authentifizierung einführt. Erstens: Bauen Sie Ihre RADIUS-Richtlinie auf Zertifikatsattributen auf, nicht nur auf der Zertifikatskette. Validieren Sie den Subject CN mit Ihrem Gerätebestand. Ein gültiges Cisco-Zertifikat beweist zwar, dass es sich um echte Cisco-Hardware handelt - es beweist jedoch nicht, dass es sich um das spezifische Gerät handelt, das Sie für diesen Standort bestellt haben. Vergleichen Sie die Seriennummer in Ihrer RADIUS-Autorisierungsrichtlinie.Zweitens: Führen Sie SUDI während der Migration parallel zu Ihrer bestehenden MAB-Richtlinie aus und nicht anstelle von ihr. Nutzen Sie das Profiling von Cisco ISE, um zu identifizieren, welche Geräte 802.1AR unterstützen, und verschieben Sie diese schrittweise zur zertifikatsbasierten Authentifizierung. Ältere IoT-Geräte - Kameras, HLK-Regler, Kartenleser - unterstützen 802.1X oft überhaupt nicht. Für diese bleibt MAB die Ausweichlösung. Das Ziel ist es, MAB zuerst für Infrastrukturgeräte zu eliminieren, da dort das Risiko am höchsten ist. Drittens: Dokumentieren Sie die Ablaufdaten Ihrer Zertifikate in Ihrer CMDB. Das klingt offensichtlich, ist aber der Punkt, an dem Teams oft scheitern. Ein Switch, der keine HTTPS-Managementverbindungen mehr akzeptiert, weil sein SUDI abgelaufen ist, ist kein angenehmer Vorfall, den man um zwei Uhr morgens diagnostizieren möchte. [kurze Pause] Schnellfragen. Ich gebe Ihnen die kurzen Antworten. Ersetzt SUDI 802.1X? Nein. SUDI ist der Identitätsnachweis. 802.1X ist das Authentifizierungs-Framework. SUDI ist das, was Sie während eines 802.1X-Austauschs vorlegen. Kann ich SUDI mit RADIUS-Servern anderer Hersteller als Cisco verwenden? Ja. Jeder RADIUS-Server, der EAP-TLS unterstützt und eine X.509-Zertifikatskette validieren kann, ist mit SUDI kompatibel. Sie müssen das Root-CA-Zertifikat von Cisco in den vertrauenswürdigen Speicher Ihres RADIUS-Servers importieren. Unterstützt Cisco Meraki SUDI? Ja, für die Infrastruktur-Authentifizierung. Meraki Access Points verwenden ihre eigene Variante von herstellerseitig installierten Zertifikaten für die Authentifizierung beim Cloud-Controller. Das Meraki Dashboard wurde aktualisiert, um den Ablauf von SUDI vor der Frist im Jahr 2026 zu verwalten. Was ist mit Purple WiFi? Purple fungiert als Cloud-Overlay über Ihrer bestehenden Infrastruktur - Cisco Meraki, HPE Aruba, Ruckus und anderen. Die Identity-Based Networks-Ebene von Purple befindet sich oberhalb der Hardware-Authentifizierungsebene. SUDI sichert die Infrastrukturgeräte selbst. Purple sichert die Identitätsebene für Besucher und Mitarbeiter darüber. Beide ergänzen sich und stehen nicht in Konkurrenz zueinander. [kurze Pause] Zusammenfassend: Cisco SUDI bietet Ihnen eine hardware-verankerte, kryptografisch überprüfbare Geräteidentität. Es eliminiert MAC-Spoofing als Angriffsvektor für Infrastrukturgeräte. Es ermöglicht Zero Touch Provisioning in großem Maßstab. Es entspricht den Kontrollanforderungen von IEEE 802.1AR, PCI-DSS 4.0 und ISO 27001. Und es lässt sich nahtlos in jede 802.1X- und EAP-TLS-fähige RADIUS-Infrastruktur integrieren. Die praktischen nächsten Schritte: Überprüfen Sie Ihren Cisco-Gerätebestand auf Ablaufdaten von SUDI-Zertifikaten, identifizieren Sie, welche Geräte mit MAB laufen und auf eine zertifikatsbasierte Authentifizierung umgestellt werden könnten, und überprüfen Sie Ihre RADIUS-Richtlinie, um eine Seriennummernvalidierung parallel zur Überprüfung der Vertrauenskette hinzuzufügen. Wenn Sie Purple an Ihren Standorten einsetzen, kann unser Team Ihnen zeigen, wie sich Identity-Based Networks auf Ihre bestehende Cisco-Infrastruktur übertragen lässt. Der Link befindet sich in den Shownotes. Vielen Dank fürs Zuhören. Bis zum nächsten Mal.