Der Enterprise-Leitfaden für SCEP: Bereitstellung des Simple Certificate Enrollment Protocol für automatisierte Campus WiFi-Sicherheit

Guten Morgen. Wenn Sie die WiFi Infrastruktur einer Hotelgruppe, einer Einzelhandelskette, eines Stadions oder eines Universitätsgeländes verwalten, ist dieses Briefing genau das Richtige für Sie. Wir befassen uns heute mit SCEP - Simple Certificate Enrollment Protocol - und insbesondere damit, wie es eine der hartnäckigsten Herausforderungen im Bereich Enterprise WiFi löst: die automatische Verteilung von Zertifikaten auf Tausende von Geräten, ohne dass Ihr Helpdesk in Tickets ertrinkt. [short pause] Lassen Sie mich die Ausgangslage beschreiben. Sie haben sich - völlig zu Recht - entschieden, dass Pre-Shared Keys für das WiFi von Mitarbeitern nicht mehr akzeptabel sind. Ein einziges kompromittiertes Passwort gefährdet Ihr gesamtes Netzwerksegment. Sie sind bereits zu einer 802.1X Authentifizierung gewechselt oder planen diesen Schritt. Das ist der IEEE Standard, der vorschreibt, dass jedes Gerät seine Identität nachweisen muss, bevor es Netzwerkzugriff erhält. Die sicherste Variante von 802.1X ist EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - bei der digitale Zertifikate anstelle von Passwörtern verwendet werden. Zertifikate sind kryptografisch eindeutig pro Gerät, sie können nicht geteilt werden und sie können sofort widerrufen werden, wenn ein Gerät verloren geht oder ein Mitarbeiter das Unternehmen verlässt. [short pause] So weit, so gut. Das Problem ist die Verteilung. Wie bekommen Sie ein eindeutiges Zertifikat auf jeden Laptop, jedes Telefon, jedes Tablet in Ihrem Bestand - und zwar über Windows, iOS, Android, macOS hinweg - ohne dass ein Techniker jedes einzelne Gerät anfassen muss? Genau dieses Problem löst SCEP. [medium pause] SCEP wurde 2020 von der Internet Engineering Task Force im RFC 8894 formalisiert, obwohl es in Enterprise Umgebungen bereits seit den frühen 2000er Jahren im Einsatz ist. Es ist ein Protokoll, das es einem verwalteten Gerät ermöglicht, sein eigenes Zertifikat direkt von Ihrer Zertifizierungsstelle anzufordern, und zwar über eine vorkonfigurierte URL und ein Challenge Passwort. Der entscheidende Sicherheitspunkt dabei: Der private Schlüssel wird auf dem Gerät selbst generiert und im sicheren Bereich des Geräts gespeichert - das ist der TPM Chip auf Windows Geräten oder die Secure Enclave auf Apple Hardware - und er wird niemals über das Netzwerk übertragen. Das Gerät generiert einen Certificate Signing Request, sendet diesen an das SCEP Gateway, das Gateway validiert die Challenge, leitet die Anfrage an Ihre Zertifizierungsstelle weiter, die CA signiert sie und das signierte Zertifikat geht zurück an das Gerät. Der gesamte Prozess läuft für den Endbenutzer unsichtbar ab. [short pause] In einer Microsoft Umgebung ist das SCEP Gateway in der Regel NDES - Network Device Enrollment Service - eine Windows Server Rolle, die als Vermittler zwischen Ihrer MDM Plattform und Ihrer CA fungiert. Microsoft Intune pusht das SCEP Profil an die verwalteten Geräte, wodurch diese die NDES URL und das Challenge Passwort erhalten. Den Rest erledigen die Geräte automatisch. [medium pause] Lassen Sie mich Ihnen zeigen, wie eine echte Implementierung aussieht. Nehmen wir eine Hotelgruppe mit 150 Standorten - denken Sie an die Dimensionen von Premier Inn. Dort gibt es einen Mix aus Windows-Laptops für das Personal an der Rezeption, iOS-Geräten für die Hauswirtschaftsleitung und Android-Tablets an den POS-Kassen der Restaurants. Vor SCEP nutzten sie WPA2-Personal mit einem gemeinsam genutzten Passwort, das vierteljährlich geändert wurde. Jede Änderung löste eine Welle von Anfragen beim Helpdesk aus. Mit SCEP und Intune stellen sie drei Profile nacheinander bereit. Erstens das vertrauenswürdige Stammzertifikatsprofil - dieses weist jedes Gerät an, der Zertifizierungsstelle des Unternehmens zu vertrauen. Zweitens das SCEP-Zertifikatsprofil - dieses weist die Geräte an, ihr individuelles Client-Zertifikat abzurufen. Drittens das WiFi-Profil - dieses konfiguriert die SSID, setzt den Sicherheitstyp auf WPA2-Enterprise oder WPA3-Enterprise und verweist auf das SCEP-Zertifikat für die Authentifizierung. Wenn Sie diese drei Profile derselben Gerätegruppe in Intune zuweisen, verbindet sich jedes verwaltete Gerät automatisch mit der Unternehmens-SSID, mit einem eindeutigen Zertifikat und ganz ohne Interaktion der Benutzer. [short pause] Der RADIUS-Server - in der Regel Microsoft NPS oder ein Cloud-RADIUS-Dienst - empfängt die EAP-TLS-Authentifizierungsanfrage, validiert das Zertifikat gegenüber der Zertifizierungsstelle, prüft die Zertifikatssperrliste und gewährt oder verweigert den Zugriff. Wenn ein Mitarbeiter das Unternehmen verlässt, widerrufen Sie sein Zertifikat in der Zertifizierungsstelle. Sein Gerät verliert beim nächsten Authentifizierungszyklus den WiFi-Zugriff. Kein Zurücksetzen von Passwörtern erforderlich. Kein Warten auf die vierteljährliche Passwortänderung. [medium pause] Nun wird oft nach dem Unterschied zwischen SCEP und PKCS - Public Key Cryptography Standards - gefragt. Beide funktionieren mit Intune. Der Hauptunterschied liegt darin, wo der private Schlüssel generiert wird. Bei SCEP wird er direkt auf dem Gerät generiert. Bei PKCS generiert die Zertifizierungsstelle beide Schlüssel zentral und überträgt den privaten Schlüssel auf das Gerät. Das bedeutet, dass der private Schlüssel über das Netzwerk übertragen wird, was ein theoretisches Abfangrisiko birgt. PKCS hat seine Berechtigung - es eignet sich besser für die S/MIME-E-Mail-Verschlüsselung, bei der eine Hinterlegung der Schlüssel wichtig ist. Für die WiFi-Authentifizierung ist SCEP die richtige Wahl. Jedes Mal. [short pause] Lassen Sie mich Ihnen ein zweites Szenario beschreiben - ein Filialnetz im Einzelhandel. Stellen Sie sich einen Modehändler mit 200 Geschäften in ganz Großbritannien vor, in denen jeweils Cisco Meraki Access Points im Einsatz sind. Die Kassensysteme basieren auf Windows und werden über Intune verwaltet. Sie benötigen PCI-DSS-Konformität, was eine Netzwerksegmentierung und eine starke Authentifizierung für jedes Gerät erfordert, das Karteninhaberdaten verarbeitet. SCEP-basiertes EAP-TLS bietet ihnen eine Authentifizierung auf Geräteebene auf der SSID für Mitarbeiter, wobei die VLAN-Zuweisung durch die RADIUS-Richtlinie gesteuert wird. Die Kassenterminals landen automatisch im VLAN für den PCI-Bereich. Das Gäste-WiFi - das separat über eine Plattform wie Purple verwaltet wird - läuft auf einer völlig isolierten SSID mit eigenem Authentifizierungsprozess. Die beiden Netzwerke berühren sich nie. Die Auditoren sind zufrieden. Das Sicherheitsteam schläft ruhiger. [medium pause] Gut, sprechen wir über die Fallstricke, denn es gibt einige, die Teams immer wieder vor Probleme stellen. [short pause] Der häufigste Fehlergrund sind falsche Gruppenzuordnungen in Intune. Ihr Trusted Root-Profil, Ihr SCEP-Profil und Ihr WiFi-Profil müssen alle derselben Azure AD-Gruppe zugewiesen sein. Wenn das SCEP-Profil einer Benutzergruppe und das WiFi-Profil einer Gerätegruppe zugewiesen ist, kann Intune die Abhängigkeit nicht auflösen, und das WiFi-Profil meldet einen Fehler. Prüfen Sie zuerst Ihre Zuweisungen - dies ist fast immer die Ursache. [short pause] Zweite Fehlerquelle: Verfügbarkeit des NDES-Servers. Ihr NDES-Server muss aus dem Internet erreichbar sein, damit sich Remote-Geräte registrieren können, bevor sie vor Ort eintreffen. Der sichere Weg dorthin führt über den Azure AD-Anwendungsproxy, der Ihnen Remote-Zugriff ermöglicht, ohne eingehende Firewall-Ports zu öffnen. Geben Sie NDES nicht direkt für das Internet frei. [short pause] Dritte Fehlerquelle: CRL-Verfügbarkeit. Ihr RADIUS-Server prüft bei jeder Geräteauthentifizierung die Zertifikatssperrliste (CRL). Wenn der CRL-Verteilungspunkt nicht erreichbar ist - etwa weil ein Server offline ist oder eine Firewall-Regel geändert wurde - schlägt die Authentifizierung für alle Benutzer fehl. Gestalten Sie Ihre CRL-Endpunkte hochverfügbar und testen Sie diese regelmäßig. [short pause] Vierte Fehlerquelle: Berechtigungen für Zertifikatsvorlagen. Wenn das Dienstkonto Ihres NDES-Connectors keine Lese- und Registrierungsberechtigungen (Read und Enroll) für die Zertifikatsvorlage besitzt, erhalten Geräte HTTP-403-Fehler beim Versuch, ihr Zertifikat abzurufen. Dies lässt sich durch eine einfache Berechtigungskorrektur beheben, wird aber bei der Ersteinrichtung leicht übersehen. [medium pause] Kommen wir nun zu einer kurzen Fragerunde. [short pause] Kann SCEP mit Nicht-Microsoft-MDMs verwendet werden? Ja - Jamf für Apple-Geräteflotten, VMware Workspace ONE und die meisten Enterprise-MDM-Plattformen unterstützen SCEP-Profile. Das Protokoll ist herstellerneutral. [short pause] Funktioniert SCEP mit Cloud-PKI? Ja. Die Microsoft-eigene Cloud-PKI in der Intune-Suite macht einen lokalen NDES-Server vollständig überflüssig. Auch Cloud-PKI-Drittanbieter wie SecureW2 und Keyfactor bieten Cloud-SCEP-Endpunkte an. [short pause] Wie verhält es sich mit WPA3-Enterprise? WPA3-Enterprise nutzt denselben Authentifizierungs-Stack auf Basis von 802.1X und EAP-TLS. Über SCEP ausgestellte Zertifikate funktionieren exakt genauso. Das Upgrade erfolgt auf der Ebene des Wireless-Protokolls, nicht auf der Zertifikatsebene. [short pause] Wie lange sind Zertifikate gültig? In der Regel ein Jahr, obwohl Sie auch kürzere Gültigkeitsdauer konfigurieren können. Intune übernimmt die automatische Verlängerung vor dem Ablaufdatum, sodass für die Benutzer keinerlei Unterbrechung entsteht. [medium pause] Zusammenfassend lässt sich sagen: SCEP automatisiert die Zertifikatsverteilung im großen Stil und eliminiert den manuellen Aufwand für die PKI-Bereitstellung auf großen Geräteflotten. Der private Schlüssel verbleibt auf dem Gerät - das ist das Sicherheitsfundament von EAP-TLS. Gehen Sie bei der Bereitstellung der Reihe nach vor: Erst das Trusted Root-Profil, dann das SCEP-Profil und als drittes das WiFi-Profil, alle zugewiesen an dieselbe Gruppe. Veröffentlichen Sie Ihren NDES-Endpunkt sicher über den Anwendungsproxy. Halten Sie Ihre CRL-Endpunkte hochverfügbar. Und wenn Sie ein neues Projekt starten, prüfen Sie eine Cloud-PKI, um die Abhängigkeit von einem lokalen NDES-Server komplett zu beseitigen. [short pause] Für Gäste WiFi - das separate, auf Besucher ausgerichtete Netzwerk - ist die zertifikatsbasierte Authentifizierung nicht das richtige Modell. Gäste besitzen keine verwalteten Geräte. Hier übernimmt eine Plattform wie Purple den Authentifizierungsfluss: Captive Portal, Social Login, E-Mail-Erfassung oder SMS-Verifizierung - alles fließt in eine First-Party-Datenebene ein, die Ihr Marketingteam tatsächlich nutzen kann. Beide Ansätze ergänzen sich gegenseitig: SCEP für Ihren verwalteten Mitarbeiterbestand, Purple für Ihr Gäste-Netzwerk. Beide laufen auf derselben Hardware, sauber segmentiert nach VLAN. [kurze Pause] Das war Ihr Briefing zum SCEP Enterprise WiFi Onboarding. Der vollständige schriftliche Leitfaden mit Architekturdiagrammen, Schritt-für-Schritt-Konfiguration für Intune und praktischen Beispielen ist auf der Purple Website verfügbar. Vielen Dank fürs Zuhören.