So konfigurieren Sie SCEP für sichere BYOD- und 802.1X-Netzwerkauthentifizierung

Hallo und willkommen zu diesem technischen Briefing von Purple. Ich bin Ihr Gastgeber, und heute gehen wir ins Detail bei SCEP – dem Simple Certificate Enrollment Protocol – und wie man es für die sichere BYOD- und 802.1X-Netzwerkauthentifizierung korrekt konfiguriert. Wenn Sie IT-Manager, Netzwerkarchitekt oder CTO sind und die Verantwortung für die WiFi-Infrastruktur einer Hotelgruppe, eines Einzelhandelsunternehmens, eines Stadions oder einer Organisation des öffentlichen Sektors tragen, ist dies für Sie von direkter Relevanz. Wir machen heute keine Theorie. Wir sprechen über Architektur und Entscheidungen. Legen wir los. [SECTION: Introduction and Context - approximately 1 minute] Hier ist das Problem, vor dem Sie wahrscheinlich stehen: Sie haben Mitarbeitergeräte, Laptops von Auftragnehmern und private Telefone, die alle Netzwerkzugriff benötigen. Wahrscheinlich haben Sie eine Mischung aus verwalteten und unverwalteten Geräten. Und irgendwo in Ihrer Infrastruktur gibt es immer noch einen gemeinsam genutzten WPA2-Pre-Shared-Key, den zwölf Personen kennen – von denen drei das Unternehmen letztes Jahr verlassen haben. Das ist kein Sicherheitskonzept. Das ist ein Sicherheitsrisiko. Die Antwort lautet 802.1X – der IEEE-Standard für portbasierte Netzwerkzugriffskontrolle. Er stellt sicher, dass kein Gerät Datenverkehr überträgt, bevor es explizit authentifiziert wurde. Aber 802.1X ist nur das Framework. Die eigentliche Frage ist, welche Authentifizierungsmethode darin verwendet wird. Und für BYOD in großem Maßstab lautet die Antwort EAP-TLS mit Zertifikaten, die über SCEP bereitgestellt werden. Genau das schauen wir uns heute genauer an. [SECTION: Technical Deep-Dive - approximately 5 minutes] Beginnen wir damit, was SCEP eigentlich tut. SCEP – Simple Certificate Enrollment Protocol – wurde ursprünglich 1999 von VeriSign als Internet-Draft bei der IETF eingereicht und später als RFC 8894 formalisiert. Seine Aufgabe ist denkbar einfach: Die automatisierte Ausstellung digitaler X.509-Zertifikate an Geräte in großem Maßstab, ohne dass ein Mensch jedes einzelne Zertifikat manuell erstellen und installieren muss. Hier ist der Ablauf in vier Schritten. Schritt eins: Das Gerät stellt eine Verbindung zu einem SCEP-Endpunkt her – einer URL, die entweder lokal über eine Windows-Server-Rolle namens NDES (Network Device Enrollment Service) oder über einen Cloud-PKI-Anbieter gehostet wird. Diese URL ist das Gateway zu Ihrer Certificate Authority. Schritt zweit: Das Gerät präsentiert eine SCEP-Challenge – ein Shared Secret, das beweist, dass es berechtigt ist, ein Zertifikat anzufordern. In einer per MDM verwalteten Umgebung wie Microsoft Intune wird diese Challenge dynamisch und individuell für jedes Gerät bereitgestellt, was weitaus sicherer ist als ein statisches Passwort, das für alle Geräte gilt. Schritt drei: Das Gerät generiert lokal sein eigenes privates und öffentliches Schlüsselpaar. Es erstellt eine Zertifikatsignierungsanforderung – einen CSR – unter Verwendung des öffentlichen Schlüssels und sendet diesen an den SCEP-Server. Hier ist der entscheidende Sicherheitspunkt: Der private Schlüssel verlässt das Gerät nie. Er wird lokal generiert, im sicheren Speicher des Geräts abgelegt – das ist das TPM unter Windows oder das Secure Enclave unter iOS – und wird niemals übertragen. Aus diesem Grund ist SCEP die richtige Wahl für die Netzwerkauthentifizierung und nicht PKCS, bei dem die CA den Schlüssel zentral generiert und an das Gerät übertragen muss. Schritt vier: Die Zertifizierungsstelle (CA) validiert den CSR, signiert ihn mit dem privaten Schlüssel der CA und gibt das signierte X.509-Zertifikat an das Gerät zurück. Das Gerät besitzt nun eine eindeutige kryptografische Identität. Wie wird dieses Zertifikat nun für die 802.1X-Authentifizierung verwendet? Wenn sich das Gerät mit Ihrer WiFi SSID verbindet, fungiert der Access Point – sei es Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist oder Ubiquiti UniFi – als Authentifikator. Er trifft die Authentifizierungsentscheidung nicht selbst. Er leitet den EAP-Austausch an Ihren RADIUS-Server weiter. Das kann Microsoft NPS, Cisco ISE oder Aruba ClearPass sein. Der RADIUS-Server initiiert einen EAP-TLS-Handshake. Das Gerät präsentiert sein per SCEP bereitgestelltes Client-Zertifikat. Der RADIUS-Server validiert drei Dinge: die Zertifikatskette zurück zur vertrauenswürdigen Root-CA, das Ablaufdatum des Zertifikats und ob das Zertifikat widerrufen wurde – geprüft anhand einer Zertifikatssperrliste (CRL) oder über das Online Certificate Status Protocol (OCSP). Wenn alle drei Prüfungen erfolgreich sind, sendet der RADIUS-Server eine EAP-Success-Nachricht und der Access Point öffnet den Port. Das Gerät ist im Netzwerk. Dies ist eine gegenseitige Authentifizierung. Das Gerät validiert auch das Zertifikat des RADIUS-Servers. Wenn jemand einen betrügerischen Access Point einrichtet, lehnt das Gerät diesen ab, da sich das Serverzertifikat nicht gegenüber der vertrauenswürdigen CA validieren lässt. Das ist Ihr Schutz vor Evil-Twin-Angriffen. Lassen Sie uns nun über die Bereitstellungsreihenfolge in Microsoft Intune sprechen, da dies die am häufigsten genutzte MDM-Plattform in Enterprise-Umgebungen ist. Sie stellen drei Intune-Konfigurationsprofile in einer strikten Reihenfolge bereit. Erstens: Das Trusted Root Certificate-Profil – dieses pusht Ihr Root-CA-Zertifikat auf jedes Gerät, damit diese Ihrer PKI vertrauen. Zweitens: Das SCEP-Zertifikatsprofil – dieses teilt den Geräten die SCEP-URL, das Format des Subject Name, die Schlüsselverwendung (Key Usage) und die erweiterte Schlüsselverwendung (Extended Key Usage) für die Client-Authentifizierung mit. Die OID für die Client-Authentifizierung lautet 1.3.6.1.5.5.7.3.2. Drittens: Das WiFi-Profil – dieses spezifiziert die SSID, legt den Sicherheitstyp auf WPA2-Enterprise oder WPA3-Enterprise fest, definiert den EAP-Typ als EAP-TLS und verknüpft das SCEP-Zertifikatsprofil. Die Reihenfolge ist entscheidend. Das WiFi-Profil hängt vom SCEP-Profil ab, welches wiederum vom Trusted Root-Profil abhängt. Wenn Sie diese in der falschen Reihenfolge bereitstellen, erhalten Sie Fehlermeldungen. Eine architektonische Entscheidung, die Sie treffen müssen, ist der Host-Ort des NDES-Servers. Er muss aus dem Internet erreichbar sein, damit sich Geräte registrieren können, bevor sie vor Ort sind. Der sichere Weg hierfür ist die Veröffentlichung der NDES-URL über den Microsoft Entra ID-Anwendungsproxy. Dies vermeidet das Öffnen eingehender Firewall-Ports und ermöglicht es Ihnen, Richtlinien für bedingten Zugriff (Conditional Access) auf den Registrierungs-Flow anzuwenden. Für Organisationen, die On-Premises-Infrastrukturen vollständig eliminieren möchten, entfernen Cloud-PKI-Anbieter – wie Microsofts eigene Cloud-PKI in Intune oder Drittanbieter-Optionen – die NDES-Abhängigkeit komplett. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Lassen Sie mich Ihnen die drei häufigsten Fehlerquellen nennen, die wir beobachten. Fehlerquelle eins: Diskrepanz bei der Gruppenzielrichtung. Dies ist die häufigste Ursache für Fehler bei der Bereitstellung von WiFi-Profilen in Intune. Wenn Ihr „Trusted Root“-Profil einer Benutzergruppe, Ihr SCEP-Profil einer Gerätegruppe und Ihr WiFi-Profil einer anderen Benutzergruppe zugewiesen ist, kann Intune die Abhängigkeitskette nicht auflösen. Alle drei Profile müssen auf dieselbe Azure AD-Gruppe ausgerichtet sein – entweder alle Benutzer oder alle Geräte. Wählen Sie eine Option und bleiben Sie konsistent. Fehlerquelle zwei: CRL-Verfügbarkeit. Ihr RADIUS-Server überprüft die CRL, um sicherzustellen, dass Zertifikate nicht widerrufen wurden. Wenn der CRL-Verteilungspunkt – die im Zertifikat eingebettete CDP-URL – nicht erreichbar ist, schlägt die Authentifizierung für jedes Gerät fehl. Dies ist eine häufige Ursache für Massenausfälle nach Netzwerkänderungen. Stellen Sie sicher, dass Ihre CDPs hochverfügbar sind, im Idealfall sowohl unter einer internen als auch einer externen URL für Remote-Geräte veröffentlicht. Ziehen Sie OCSP als robustere Alternative zur CRL-Prüfung in Betracht. Fehlerquelle drei: Keine Erzwingung der Serverzertifikatsvalidierung auf Clients. Dies ist die folgenschwerste Fehlkonfiguration in 802.1X-Bereitstellungen. Wenn Ihr über MDM bereitgestelltes WiFi-Profil nicht die vertrauenswürdige CA und den erwarteten RADIUS-Servernamen angibt, verbinden sich Geräte mit jedem Server, der ein beliebiges Zertifikat vorweist. Das macht den gesamten Zweck von EAP-TLS zunichte. Konfigurieren Sie in Ihrem WiFi-Profil immer die Servervalidierung. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Lassen Sie uns ein paar schnelle Fragen durchgehen. Frage: Benötigen wir WPA3? Ja. Migrieren Sie zu WPA3-Enterprise. Es schreibt Protected Management Frames vor, was Deauthentifizierungsangriffe blockiert. Die gesamte Hardware von Cisco Meraki, HPE Aruba, Ruckus und Juniper Mist unterstützt dies. Frage: Was ist mit Geräten, die 802.1X nicht unterstützen – wie IoT-Sensoren oder ältere Drucker? Nutzen Sie MAC Authentication Bypass als Fallback, aber platzieren Sie diese Geräte in einem stark eingeschränkten VLAN ohne Zugriff auf Unternehmensressourcen. Frage: Wie fügt sich Purple hier ein? Die Guest WiFi-Plattform von Purple übernimmt die Ebene für den Besucher- und Gastzugriff – das Captive Portal, die Datenerfassung, die Analysen. Ihre 802.1X- und SCEP-Infrastruktur verwaltet den Zugriff für Mitarbeiter und verwaltete Geräte. Diese laufen auf separaten SSIDs und separaten VLANs. Purple lässt sich in Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet integrieren – so bleibt Ihre Hardware-Investition geschützt. [SECTION: Summary and Next Steps - approximately 1 minute] Fazit. SCEP automatisiert die Zertifikatsausstellung in großem Maßstab. Der private Schlüssel bleibt auf dem Gerät – das ist der Sicherheitsvorteil gegenüber PKCS. Stellen Sie über MDM in strenger Reihenfolge bereit: erst „Trusted Root“, dann das SCEP-Profil, dann das WiFi-Profil, alle auf dieselbe Gruppe ausgerichtet. Veröffentlichen Sie NDES über den Anwendungsproxy oder wechseln Sie zu einer Cloud-PKI. Erzwingen Sie die CRL- oder OCSP-Prüfung auf Ihrem RADIUS-Server. Und konfigurieren Sie auf Client-Supplicants immer die Serverzertifikatsvalidierung. Wenn Sie für das Mitarbeiter-WiFi immer noch einen gemeinsam genutzten Pre-Shared Key verwenden, ist dies die Änderung, die Sie in diesem Quartal vornehmen sollten. Die Zertifikatsinfrastruktur bedeutet zwar im Vorfeld mehr Aufwand, eliminiert jedoch eine ganze Klasse von anmeldedatenbasierten Angriffen und reduziert WiFi-bezogene Helpdesk-Tickets nach der Bereitstellung in der Regel um 70 bis 80 Prozent. Den vollständigen technischen Leitfaden, Architekturdiagramme und Praxisbeispiele finden Sie auf purple dot ai. Vielen Dank fürs Zuhören.