Cisco SUDI verstehen: Hardware-basierte Geräteidentität in der Netzwerk-Zugriffskontrolle

Cisco SUDI verstehen: Hardware-basierte Geräteidentität in der Netzwerk-Zugriffskontrolle Ein technisches Briefing von Purple - Vollständiges Podcast-Skript (ca. 10 Minuten) --- SEGMENT 1: EINFÜHRUNG UND KONTEXT (ca. 1 Minute) Hallo und herzlich willkommen zu einem technischen Briefing von Purple. Ich werde in den nächsten zehn Minuten mit Ihnen über Cisco SUDI – Secure Unique Device Identifier – sprechen: was es eigentlich ist, wie es sich in Ihre Netzwerk-Zugriffskontroll-Architektur einfügt und was Sie tun müssen, wenn Sie eine Cisco-Infrastruktur in großem Maßstab betreiben. Dies richtet sich an Netzwerkarchitekten, IT-Manager und CTOs an Veranstaltungsorten – Hotels, Einzelhandelsflächen, Stadien, Konferenzzentren –, überall dort, wo Sie Enterprise-WiFi betreiben und sicher sein müssen, dass die Hardware in Ihrem Netzwerk genau das ist, was sie zu sein vorgibt. Beginnen wir mit dem Problem, das SUDI löst. In jedem großen Standort-Netzwerk haben Sie Dutzende oder Hunderte von Access Points, Switches und Controllern. Die Frage, von der Ihre Sicherheitslage abhängt, lautet: Woher wissen Sie, dass jedes dieser Geräte ein echtes, unmodifiziertes Cisco-Produkt ist – und keine Fälschung, kein kompromittiertes Gerät oder ein Gerät, das während des Transports manipuliert wurde? Das ist die Lücke, die SUDI schließt. --- SEGMENT 2: TECHNISCHER DEEP-DIVE (ca. 5 Minuten) SUDI steht für Secure Unique Device Identifier. Es handelt sich um ein X.509-Version-3-Zertifikat – dasselbe Zertifikatsformat, das auch bei HTTPS und TLS verwendet wird –, aber anstatt für eine Person oder einen Server ausgestellt zu werden, wird es während der Herstellung für ein bestimmtes Hardware-Teil ausgestellt. Es enthält die Produktkennung und die Seriennummer des Geräts und ist in Ciscos eigener Public-Key-Infrastruktur verankert. Hier ist der Unterschied zwischen SUDI und einem Software-Zertifikat, das Sie selbst installieren würden. Das SUDI-Zertifikat befindet sich zusammen mit dem zugehörigen Schlüsselpaar in einem manipulationssicheren Chip namens Trust Anchor module oder TAm. Der private Schlüssel wird in diesem Chip generiert und verlässt ihn nie. Sie können ihn nicht exportieren. Sie können ihn nicht klonen. Wenn jemand den Chip physisch manipuliert, wird der Schlüssel zerstört. Das ist der Hardware-Root-of-Trust. SUDI is Ciscos Implementierung des Standards IEEE 802.1AR – dem Branchenstandard für sichere Geräteidentifikatoren (Secure Device Identifiers oder DevIDs). Unter 802.1AR wird der vom Hersteller installierte Berechtigungsnachweis als Initial Device Identifier oder IDevID bezeichnet. Cisco SUDI ist genau das – eine IDevID, die Cisco im Werk installiert. Sie können sie durch einen Locally Significant Device Identifier oder LDevID ergänzen, den Ihre eigene PKI für lokale Autorisierungsrichtlinien ausstellt. Wie lässt sich das nun in die Netzwerk-Zugriffskontrolle integrieren? Der häufigste Integrationspunkt ist IEEE 802.1X – der Standard für die portbasierte Netzwerk-Zugriffskontrolle. Wenn ein Cisco Access Point oder Switch online geht, kann er sein SUDI-Zertifikat einem RADIUS-Server – typischerweise Cisco ISE (Identity Services Engine) – über EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security) präsentieren. Der RADIUS-Server validiert das Zertifikat anhand der öffentlichen Zertifizierungsstelle von Cisco, bestätigt die Echtheit des Geräts und wendet dann die entsprechende Netzwerkrichtlinie an. Dies ist erheblich sicherer als der MAC Address Bypass, den die meisten Netzwerke als Fallback für Infrastrukturgeräte nutzen. MAC-Adressen können in weniger als einer Minute gefälscht werden. Ein hardwaregebundenes Zertifikat in einem manipulationssicheren Chip kann nicht gefälscht werden, ohne das Gerät physisch zu zerstören. In einem Standort-Kontext ist dies aus drei Gründen wichtig. Erstens eliminiert es das Risiko, dass unbefugte Access Points Ihrem Netzwerk beitreten. Ein gefälschtes oder nicht autorisiertes Gerät kann schlichtweg kein gültiges SUDI vorweisen. Zweitens ermöglicht es ein automatisiertes Zero Touch Provisioning – ein neues Gerät wird an Ihren Standort geliefert, eingeschaltet, präsentiert sein SUDI, und Ihr Managementsystem gleicht es mit Ihrem Bestand ab, bevor es die Konfiguration überträgt. Kein manuelles Eingreifen erforderlich. Drittens erhalten Sie einen kryptografisch überprüfbaren Audit-Trail. Jedes Gerät, das sich an Ihrem Netzwerk authentifiziert hat, tat dies mit einem Zertifikat, das beweist, dass es sich um ein bestimmtes, namentlich genanntes Cisco-Produkt handelt. Lassen Sie mich noch etwas genauer auf das Trust Anchor module eingehen, da es das Fundament für alles andere bildet. Das TAm ist ein proprietärer Cisco-Chip, der drei Dinge bietet: einen nicht-flüchtigen, sicheren Speicher für das SUDI und die Schlüssel, kryptografische Dienste einschließlich Zufallszahlengenerierung sowie Hardware-Fingerprinting. Letzteres ist besonders bemerkenswert – Cisco erfasst bei der Herstellung einen kryptografischen Fingerabdruck der kritischen Hardwarekomponenten eines Geräts und speichert diesen im TAm. Beim Booten des Geräts wird der festgestellte Hardware-Fingerabdruck mit dem gespeicherten abgeglichen. Stimmen sie nicht überein, startet das Gerät nicht. Dadurch werden Hardware-Manipulationen während des Transports erkannt – ein echtes Problem bei großen Standort-Bereitstellungen, bei denen die Hardware vor der Installation durch mehrere Hände gehen kann. Ein betriebliches Thema, das Sie beachten müssen: Vor Mai 2019 ausgestellte SUDI-Zertifikate laufen entweder zehn Jahre nach dem Herstellungsdatum oder am 14. Mai 2029 ab, je nachdem, was zuerst eintritt. Cisco hat dieses Problem mit einer neuen Generation von Zertifikaten namens SUDI-2099 gelöst, die bis Dezember 2099 gültig sind. Wenn Sie Catalyst 9000-Hardware betreiben, die vor 2019 hergestellt wurde, müssen Sie Ihre SUDI-Ablaufdaten jetzt überprüfen. Der Befehl lautet „show crypto pki certificate“ auf IOS-XE. Suchen Sie nach dem Trustpoint CISCO_IDEVID_SUDI und prüfen Sie das Enddatum. Wenn Sie Catalyst 9200 nutzen, aktualisieren Sie auf IOS-XE 17.12.2 oder neuer, um sicherzustellen, dass Sie das korrekte 2099-Zertifikat verwenden. --- SEGMENT 3: IMPLEMENTIERUNGSEMPFEHLUNGEN UND FALLSTRICKE (ca. 2 Minuten) Lassen Sie mich Ihnen die praktische Umsetzung beschreiben. Wenn Sie eine SUDI-basierte Authentifizierung in einer Standort-Umgebung bereitstellen, hat sich folgende Reihenfolge bewährt. Beginnen Sie mit Ihrer RADIUS-Infrastruktur. Cisco ISE ist die naheliegende Wahl, wenn Sie sich bereits im Cisco-Ökosystem befinden, aber jeder RADIUS-Server, der EAP-TLS unterstützt und eine Validierung gegen eine externe CA durchführen kann, ist geeignet. Sie müssen die Cisco Root CA und die ACT2 SUDI CA-Zertifikate in den Vertrauensspeicher Ihres RADIUS-Servers importieren. Diese sind im PKI-Portal von Cisco öffentlich zugänglich. Konfigurieren Sie als Nächstes Ihre 802.1X-Richtlinie so, dass eine zertifikatsbasierte Authentifizierung für Infrastrukturgeräte erforderlich ist. Trennen Sie diese von Ihrer Richtlinie für die Endbenutzer-Authentifizierung – die Authentifizierungsabläufe für Mitarbeiter und Gäste sind unterschiedlich und sollten in ISE auf verschiedenen Richtliniensätzen liegen. Aktivieren Sie für neue Bereitstellungen das Zero Touch Provisioning. Ihr Netzwerkmanagementsystem – Cisco DNA Center oder Catalyst Center – kann SUDI verwenden, um die Geräteidentität zu überprüfen, bevor die Konfiguration übertragen wird. Dies eliminiert den manuellen Bereitstellungsprozess und verkürzt die Einrichtungszeit von Stunden auf wenige Minuten pro Gerät. Nun zu den Fallstricken. Der häufigste Fehler, den ich sehe, ist die Mischung aus SUDI-Authentifizierung und MAC Address Bypass auf demselben Port. Wenn Sie bei einem SUDI-Fehlschlag auf MAB zurückgreifen, untergraben Sie das gesamte Sicherheitsmodell. Definieren Sie eine klare Richtlinie: SUDI-fähige Geräte müssen sich ausnahmslos über SUDI authentifizieren. Nicht-SUDI-Geräte gehören bis zur manuellen Überprüfung in ein Quarantäne-VLAN. Der zweite Fallstrick ist der Ablauf von Zertifikaten. Richten Sie jetzt eine Überwachung der SUDI-Ablaufdaten für Ihre gesamte Infrastruktur ein. Warten Sie nicht auf einen Dienstausfall, um festzustellen, dass sich Ihre Access Points nicht mehr authentifizieren können. Die Plattform von Purple lässt sich in Cisco Meraki und andere Hardware-Hersteller integrieren, um den Gerätestatus – einschließlich des Authentifizierungsstatus – in einem einzigen Dashboard anzuzeigen, was diese Art der proaktiven Überwachung im großen Stil praktikabel macht. Der dritte Fallstrick ist die Ausweitung des Fokus (Scope Creep). SUDI authentifiziert das Hardware-Gerät. Es authentifiziert nicht den Benutzer, der sich über dieses Gerät verbindet. Sie benötigen weiterhin eine separate Identitätsebene für Gäste, Mitarbeiter und Bewohner. Genau dort setzt eine Plattform wie Purple an – wir kümmern uns um die menschliche Identitätsebene, die Einwilligungserfassung, die VLAN-Zuweisung für den Gast-Datenverkehr und die Analysen, während SUDI die darunter liegende Infrastrukturebene absichert. --- SEGMENT 4: SCHNELLE FRAGEN UND ANTWORTEN (ca. 1 Minute) Lassen Sie uns drei Fragen durchgehen, die mir regelmäßig gestellt werden. Ersetzt SUDI meine bestehende PKI? Nein. SUDI ist eine vom Hersteller installierte IDevID. Es beweist, dass das Gerät echte Cisco-Hardware ist. Ihre Unternehmens-PKI stellt LDevIDs und Benutzerzertifikate für alles andere aus. Beide Systeme arbeiten parallel. Kann ich SUDI auf Nicht-Cisco-Hardware verwenden? Nein. SUDI ist Cisco-spezifisch. HPE Aruba hat ein Äquivalent namens IAP-Bereitstellungszertifikate. Ruckus und Juniper Mist haben ihre eigenen Mechanismen zur Geräteidentifikation. Der zugrunde liegende Standard – IEEE 802.1AR – ist herstellerneutral, aber jeder Hersteller implementiert ihn anders. Was passiert, wenn ein SUDI-Zertifikat abläuft? Dienste, die sich bei der Authentifizierung auf SUDI verlassen – wie HTTPS, SSH mit Zertifikatsauthentifizierung oder Zero Touch Provisioning –, schlagen fehl. Das Gerät selbst läuft zwar weiter, kann seine Identität jedoch nicht mehr kryptografisch nachweisen. Deshalb ist die SUDI-2099-Migration so wichtig. --- SEGMENT 5: ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE (ca. 1 Minute) Zusammenfassend lässt sich sagen: Cisco SUDI bietet Ihnen eine hardwareverankerte Geräteidentität, die nicht gefälscht, geklont oder exportiert werden kann. Sie ist das Fundament einer vertrauenswürdigen Infrastrukturebene. In Kombination mit IEEE 802.1X und einer gut konfigurierten RADIUS-Richtlinie eliminiert sie das Risiko unbefugter Geräte und ermöglicht eine automatisierte Bereitstellung im großen Stil. Ihre drei sofortigen Maßnahmen: Erstens, prüfen Sie Ihre Cisco-Infrastruktur mit „show crypto pki certificate“ auf SUDI-Ablaufdaten. Zweitens, importieren Sie die Cisco Root CA in Ihren RADIUS-Vertrauensspeicher und konfigurieren Sie EAP-TLS-Richtlinien für Infrastrukturgeräte. Drittens, trennen Sie Ihre Richtlinie zur Infrastruktur-Authentifizierung von Ihrer Richtlinie zur Endbenutzer-Authentifizierung – sie dienen unterschiedlichen Zwecken und sollten unabhängig voneinander verwaltet werden. Wenn Sie mehr darüber erfahren möchten, wie sich Purple in Cisco Meraki und andere Hardware-Hersteller integrieren lässt, um eine identitätsbasierte Netzwerksegmentierung für Gäste, Mitarbeiter und Bewohner bereitzustellen, besuchen Sie purple.ai oder lesen Sie die entsprechenden Leitfäden, die unter dieser Episode verlinkt sind. Vielen Dank fürs Zuhören. Wir sehen uns beim nächsten Briefing. --- ENDE DES SKRIPTS