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

Hallo und herzlich willkommen zu diesem technischen Briefing von Purple. Ich bin Ihr Gastgeber, und heute befassen wir uns im Detail mit SCEP - dem Simple Certificate Enrollment Protocol - und wie man es für sicheres BYOD und die 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 im öffentlichen Sektor tragen, ist dies für Sie von direkter Relevanz. Wir beschäftigen sich heute nicht mit Theorie. Wir befassen uns mit 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 Subunternehmern und persönliche Mobiltelefone, die alle Netzwerkzugriff benötigen. Wahrscheinlich haben Sie eine Mischung aus verwalteten und nicht verwalteten 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 die portbasierte Netzwerkzugriffskontrolle. Er stellt sicher, dass kein Gerät Datenverkehr überträgt, bevor es nicht explizit authentifiziert wurde. Aber 802.1X ist nur das Framework. Die eigentliche Frage ist, welche Authentifizierungsmethode darin verwendet wird. Und für BYOD im großen Stil lautet die Antwort EAP-TLS mit Zertifikaten, die über SCEP bereitgestellt werden. Das ist es, was wir heute genauer betrachten. [SECTION: Technical Deep-Dive - approximately 5 minutes] Beginnen wir damit, was SCEP eigentlich tut. SCEP - Simple Certificate Enrollment Protocol - wurde ursprünglich 1999 als Internet Draft von der IETF veröffentlicht und von VeriSign entwickelt. Es wurde als RFC 8894 formalisiert. Seine Aufgabe ist unkompliziert: die Automatisierung des Prozesses zur Ausstellung digitaler X.509-Zertifikate an Geräte im großen Stil, ohne dass ein Mensch jedes einzelne Zertifikat manuell erstellen und installieren muss. Hier ist der Ablauf in vier Schritten. Schritt eins: Das Gerät verbindet sich mit einem SCEP Endpunkt - 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 Zertifizierungsstelle. Schritt zwei: 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 pro 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 diese 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 Enklave-Speicher des Geräts gespeichert - das ist das TPM unter Windows oder die 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 die CSR, signiert sie mit dem privaten Schlüssel der CA und gibt das signierte X.509-Zertifikat an das Gerät zurück. Das Gerät verfügt nun über 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 - ob 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 legt sein per SCEP bereitgestelltes Client-Zertifikat vor. Der RADIUS-Server überprüft 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 OCSP (Online Certificate Status Protocol). 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 das Serverzertifikat nicht mit der vertrauenswürdigen CA validiert werden kann. Das ist Ihr Schutz vor Evil-Twin-Angriffen. Sprechen wir nun über die Bereitstellungsreihenfolge in Microsoft Intune, da dies die am häufigsten genutzte MDM-Plattform in Enterprise-Umgebungen ist. Sie stellen drei Intune-Konfigurationsprofile in strikter Reihenfolge bereit. Erstens das vertrauenswürdige Stammzertifikatprofil - dieses überträgt Ihr Root-CA-Zertifikat auf jedes Gerät, damit diese Ihrer PKI vertrauen. Zweitens das SCEP-Zertifikatprofil - dieses teilt den Geräten die SCEP-URL, das Format des Subject-Namens, die Schlüsselverwendung und die erweiterte Schlüsselverwendung 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 verweist auf das SCEP-Zertifikatprofil. Die Reihenfolge ist wichtig. Das WiFi-Profil ist vom SCEP-Profil abhängig, welches wiederum vom Profil für das vertrauenswürdige Stammzertifikat abhängt. Wenn Sie diese außerhalb der 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 auf den Registrierungs-Flow anzuwenden. Für Unternehmen, die ihre On-Premises-Infrastruktur vollständig eliminieren möchten, beseitigen Cloud-PKI-Anbieter - Microsofts eigene Cloud PKI in Intune oder Optionen von Drittanbietern - die NDES-Abhängigkeit vollständig. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Lassen Sie mich Ihnen die drei häufigsten Fehlermuster vorstellen, die wir beobachten. Fehlermuster eins: Falsche Gruppenzuordnung. 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 genau dieselbe Azure AD-Gruppe ausgerichtet sein - entweder nur auf Benutzer oder nur auf Geräte. Wählen Sie eine Option und bleiben Sie konsistent. Fehlermuster zwei: CRL-Verfügbarkeit. Ihr RADIUS-Server prüft die CRL, um sicherzustellen, dass Zertifikate nicht gesperrt 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 URL als auch unter einer externen URL für Remote-Geräte veröffentlicht. Erwägen Sie OCSP als robustere Alternative zur CRL-Prüfung. Fehlermuster drei: Keine erzwungene Serverzertifikatsvalidierung auf den Clients. Dies ist die folgenschwerste Fehlkonfiguration bei 802.1X-Bereitstellungen. Wenn Ihr per 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. Alle Hardware-Komponenten von Cisco Meraki, HPE Aruba, Ruckus und Juniper Mist unterstützen dies. Frage: Was ist mit Geräten, die kein 802.1X unterstützen - wie IoT-Sensoren oder ältere Drucker? Nutzen Sie MAC Authentication Bypass als Ausweichlösung, 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 Besucher- und Gastzugänge - 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] Zusammenfassend lässt sich sagen: SCEP automatisiert die Zertifikatsausstellung in großem Umfang. Der private Schlüssel verbleibt auf dem Gerät - das ist der Sicherheitsvorteil gegenüber PKCS. Stellen Sie die Profile über MDM in einer strengen Reihenfolge bereit: Trusted Root, dann SCEP-Profil, dann WiFi-Profil, alle auf dieselbe Gruppe ausgerichtet. Veröffentlichen Sie NDES über den Anwendungsproxy oder wechseln Sie zu Cloud-PKI. Erzwingen Sie die CRL- oder OCSP-Prüfung auf Ihrem RADIUS-Server. Und konfigurieren Sie auf den Client-Supplicants immer die Serverzertifikatsvalidierung. Wenn Sie für Ihr Mitarbeiter-WiFi immer noch einen gemeinsam genutzten Pre-Shared-Key verwenden, ist dies die wichtigste Änderung für dieses Quartal. Die Zertifikatsinfrastruktur bedeutet zwar im Vorfeld mehr Arbeit, eliminiert jedoch eine ganze Kategorie von anmeldedatenbasierten Angriffen und reduziert die WiFi-bezogenen 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.