So konfigurieren Sie SCEP für sicheres Enterprise WiFi und BYOD-Provisionierung

Willkommen zu diesem technischen Briefing von Purple. Ich bin Ihr Gastgeber, und heute befassen wir uns eingehend mit der Konfiguration von SCEP für sicheres Enterprise WiFi und BYOD-Provisionierung. Für IT-Manager, Netzwerkarchitekten und CTOs in den Bereichen Hotellerie, Einzelhandel und im öffentlichen Sektor ist die Verwaltung des Netzwerkzugriffs ein ständiger Spagat zwischen Sicherheit und betrieblicher Effizienz. Sie haben es täglich mit Hunderten, manchmal Tausenden von Geräten zu tun, die sich mit Ihrem Netzwerk verbinden: Smartphones von Mitarbeitern, Laptops von Auftragnehmern, Point-of-Sale-Tablets. Und die alten Methoden, dies zu handhaben, sind einfach nicht mehr gut genug. Die Verwendung von Pre-Shared Keys oder PSKs für das WiFi von Mitarbeitern und BYOD ist eine Sicherheitslücke, die nur darauf wartet, ausgenutzt zu werden. Ein gemeinsam genutztes Passwort gibt nach einer Kompromittierung jedem Zugriff auf Ihr Netzwerk. Und MAC Authentication Bypass, oder MAB, ist nicht besser. Moderne Smartphones verwenden standardmäßig randomisierte MAC-Adressen, was MAB vollständig aushebelt, und MAC-Adressen können in Sekundenschnelle gefälscht werden. Moderne Netzwerkarchitekturen erfordern eine 802.1X-Authentifizierung mit EAP-TLS. Dadurch wird sichergestellt, dass jedes Gerät kryptografisch überprüft wird, bevor es eine Verbindung zum Netzwerk herstellt. Doch hier liegt die Herausforderung: Wie verteilen Sie eindeutige Client-Zertifikate an Tausende von nicht verwalteten Geräten, ohne Ihren Helpdesk zu überlasten? Die Antwort ist das Simple Certificate Enrolment Protocol, kurz SCEP. Beginnen wir mit der Architektur. SCEP ist der Industriestandard für die Registrierung von Enterprise-Geräten, definiert in RFC 8894. Es existiert seit 1999, wurde ursprünglich von VeriSign entwickelt und hat sich im Laufe der Zeit bewährt, weil es ein wirklich schwieriges Problem elegant löst. In einem SCEP-Workflow generiert das Gerät sein eigenes privates und öffentliches Schlüsselpaar lokal. Es erstellt eine Zertifikatsignierungsanforderung, oder CSR, und sendet diese über einen Network Device Enrolment Service, bekannt als NDES, an Ihre Zertifizierungsstelle (Certificate Authority, CA). Die CA validiert die Anforderung und sendet das signierte öffentliche Zertifikat an das Gerät zurück. Der entscheidende Sicherheitsvorteil besteht darin, dass der private Schlüssel das Gerät niemals verlässt. Er wird lokal generiert und im Hardware-Sicherheitsbereich des Geräts gespeichert. Auf einem Windows-Laptop ist das das Trusted Platform Module, oder TPM. Auf einem iPhone ist es die Secure Enclave. Der private Schlüssel wird niemals über das Netzwerk übertragen. Dies macht SCEP gegenüber Alternativen wie PKCS für die Netzwerkauthentifizierung, bei denen die CA das Schlüsselpaar zentral generiert und an das Gerät überträgt, weitaus überlegen. Lassen Sie uns nun über BYOD sprechen. Aus betrieblicher Sicht wird es hier erst richtig interessant. Sie möchten, dass Mitarbeiter ihre persönlichen Geräte für den Zugriff auf interne Tools nutzen können, aber Sie möchten sie nicht zwingen, sich in Ihrem Corporate MDM zu registrieren. Das ist ein Datenschutzproblem und stößt bei den Mitarbeitern auf starken Widerstand. Die Lösung ist ein Self-Service-Onboarding-Portal. Und so funktioniert es: Der Benutzer verbindet sein persönliches Gerät mit einer dedizierten Bereitstellungs-SSID. Dieses Netzwerk ist ein Walled Garden, der den Zugriff auf alles außer dem Onboarding-Portal und Ihrem Identity Provider einschränkt. Der Benutzer authentifiziert sich mit seinen Unternehmens-Anmeldedaten, in der Regel über eine SAML-Integration mit Microsoft Entra ID, Okta oder Google Workspace. Nach erfolgreicher Authentifizierung generiert das System über SCEP ein eindeutiges, gerätespezifisches Client-Zertifikat. Ein Konfigurationsprofil wird auf das Gerät übertragen, das das Zertifikat, das Root-CA-Zertifikat und die Netzwerkeinstellungen enthält. Das Gerät verbindet sich anschließend automatisch über EAP-TLS mit der sicheren Unternehmens-SSID. Das ist nahtlos für den Benutzer und sicher für das Unternehmen. Die Benutzer müssen nichts über Zertifikate oder 802.1X wissen. Sie melden sich einfach einmal an und sind verbunden. Lassen Sie uns nun die Implementierung im Detail durchgehen. Die Bereitstellungsreihenfolge ist entscheidend, und Fehler an dieser Stelle sind die häufigste Ursache für ein Scheitern. Schritt eins: Bereitstellung des Trusted Root-Zertifikats. Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Certificate Authority vertrauen. Exportieren Sie Ihr Root-CA-Zertifikat als .cer-Datei und verteilen Sie es an Ihre Zielgerätegruppen. Dieser Schritt ist unverzichtbar. Ohne ihn schlägt die gesamte Kette fehl. Schritt zwei: Konfiguration des SCEP-Zertifikatsprofils. Dieses weist die Geräte an, wie sie ihr Client-Zertifikat abrufen können. Sie müssen das Format des Subject Name konfigurieren. Für die benutzergesteuerte Authentifizierung ist der Standard "CN equals UserPrincipalName". Für die Geräteauthentifizierung verwenden Sie "CN equals the Azure AD Device ID". Legen Sie die Schlüsselverwendung auf digitale Signatur und Schlüsselverschlüsselung fest. Geben Sie unter der erweiterten Schlüsselverwendung die Client-Authentifizierung mit der OID 1.3.6.1.5.5.7.3.2 an. Verknüpfen Sie dieses Profil mit dem Trusted Root-Zertifikatsprofil aus Schritt eins. Und geben Sie die externe URL Ihres NDES-Servers an. Schritt drei: Bereitstellung des 802.1X WiFi-Profils. Dieses verknüpft die Zertifikate mit der Netzwerk-SSID. Geben Sie den Netzwerknamen genau so ein, wie er von Ihren Access Points ausgestrahlt wird. Stellen Sie den Sicherheitstyp auf WPA2-Enterprise oder WPA3-Enterprise ein. Stellen Sie den EAP-Typ auf EAP-TLS ein. Wählen Sie das SCEP-Zertifikatsprofil als Client-Authentifizierungszertifikat aus. Und geben Sie das Trusted Root-Zertifikat für die Servervalidierung an. Diese Reihenfolge ist das Wichtigste, woran Sie sich bei diesem gesamten Briefing erinnern müssen. Erst Vertrauen, dann Zertifikat, dann WiFi. In genau dieser Reihenfolge, jedes Mal. Lassen Sie mich nun einige Best Practices erläutern, die Ihnen in der Produktionsumgebung viel Ärger ersparen werden. Erstens: Veröffentlichen Sie Ihren NDES-Server über den Azure AD-Anwendungsproxy. Der NDES-Server muss aus dem Internet erreichbar sein, damit Remote-Geräte Zertifikate bereitstellen können, bevor sie vor Ort eintreffen. Die direkte Freigabe eines internen Servers im Internet stellt jedoch ein erhebliches Sicherheitsrisiko dar. Der Anwendungsproxy bietet Ihnen einen sicheren Remote-Zugriff, ohne dass eingehende Firewall-Ports geöffnet werden müssen. Zweitens: Implementieren Sie kurzlebige Zertifikate für BYOD-Geräte. Statt eines für drei Jahre gültigen Zertifikats stellen Sie Zertifikate mit einer Gültigkeit von 90 Tagen aus. Wenn das Zertifikat abläuft, muss sich der Benutzer erneut über das Onboarding-Portal authentifizieren. Dies entfernt automatisch inaktive Geräte aus dem Netzwerk. Ein Gerät, das 90 Tage lang nicht genutzt wurde, fällt einfach weg. Keine manuelle Bereinigung erforderlich. Drittens - und das ist absolut entscheidend - konfigurieren Sie Ihren RADIUS-Server so, dass er eine strenge Prüfung der Certificate Revocation List erzwingt. Wenn ein Mitarbeiter das Unternehmen verlässt, wird sein WiFi-Zugang durch das Deaktivieren seines Active Directory-Kontos unter Umständen nicht sofort gesperrt, solange sein Client-Zertifikat gültig bleibt. Ihr RADIUS-Server muss die CRL prüfen, bevor er den Zugriff gewährt. Stellen Sie sicher, dass Ihre CRL-Verteilungspunkte hochverfügbar sind. Wenn der RADIUS-Server die CRL nicht erreichen kann, schlägt die Authentifizierung für alle fehl. Das führt zu einem flächendeckenden Ausfall. Sehen wir uns nun einige häufige Fehlerszenarien an und wie man sie vermeidet. Das häufigste Problem ist, dass das WiFi-Profil nicht angewendet werden kann. Das Gerät empfängt das Trusted Root- und das SCEP-Zertifikat, aber das WiFi-Profil wird in der MDM-Konsole als Fehler angezeigt. In neun von zehn Fällen liegt dies an einer fehlerhaften Gruppenzuweisung. Wenn das SCEP-Profil einer Benutzergruppe zugewiesen ist, das WiFi-Profil jedoch einer Gerätegruppe, kann das MDM die Abhängigkeit nicht auflösen. Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass alle drei Profile auf genau dieselbe Gruppe ausgerichtet sind. Das zweite häufige Problem sind NDES 403 Forbidden-Fehler. Geräte können das SCEP-Zertifikat nicht abrufen, und die NDES-IIS-Protokolle zeigen HTTP-403-Fehler. Dies wird in der Regel dadurch verursacht, dass dem Connector-Dienstkonto die erforderlichen Berechtigungen für die Zertifikatsvorlage fehlen oder eine Firewall die spezifischen, von SCEP verwendeten Abfrage-String-Parameter blockiert. Stellen Sie sicher, dass das Connector-Konto über Lese- und Registrierungsberechtigungen (Read und Enrol) für die CA-Vorlage verfügt. Überprüfen Sie Ihre Firewall-Protokolle, um sicherzustellen, dass URLs, die den Parameter „operation equals GetCACaps“ enthalten, nicht blockiert werden. Lassen Sie mich Ihnen zwei praktische Szenarien vorstellen, um zu veranschaulichen, wie sich dies in der Praxis verhält. Szenario eins: ein Hotel mit 200 Zimmern und 50 Housekeeping-Mitarbeitern, die ihre persönlichen Smartphones für den Zugriff auf die Dienstplan-App nutzen. Der IT-Manager möchte eine vollständige MDM-Registrierung vermeiden, um die Privatsphäre der Mitarbeiter zu schützen. Die Lösung ist ein Self-Service-Portal, das in Microsoft Entra ID integriert ist. Die Mitarbeiter verbinden sich mit der Bereitstellungs-SSID, melden sich mit ihren Entra ID-Anmeldedaten an und laden ein SCEP-Profil herunter. Der SCEP-Server stellt ein 30 Tage gültiges Client-Zertifikat direkt für das Gerät aus. Das Gerät verbindet sich über EAP-TLS mit der Mitarbeiter-WiFi-SSID. Der RADIUS-Server weist diese Geräte einem eingeschränkten VLAN zu, das nur den Zugriff auf die Dienstplan-App erlaubt. Wenn ein Mitarbeiter ausscheidet, wird sein Entra ID-Konto deaktiviert, und der RADIUS-Server verweigert sofort den Netzwerkzugriff. Szenario zwei: eine nationale Einzelhandelskette mit 500 Filialen, die sicheres WiFi für unternehmenseigene Point-of-Sale-Tablets bereitstellt. Der Netzwerkarchitekt muss sicherstellen, dass die Zugangsdaten selbst bei einem Diebstahl des Tablets nicht ausgelesen werden können. Die Lösung ist Microsoft Intune, das Zertifikate über SCEP bereitstellt. Intune pusht das Trusted Root-Zertifikat, gefolgt von einem SCEP-Profil, das das Tablet anweist, seinen eigenen privaten Schlüssel in seiner sicheren Hardware-Enklave zu generieren. Das Tablet sendet einen CSR an den NDES-Server, erhält das Client-Zertifikat und verbindet sich über EAP-TLS mit der Retail POS SSID. Da der private Schlüssel lokal generiert und niemals übertragen wird, können die Zugangsdaten eines gestohlenen Tablets nirgendwo anders verwendet werden. Dies erfüllt die Compliance-Anforderungen von PCI-DSS. Kommen wir nun zum Business Case. Der Übergang zur SCEP 802.1X-Zertifikatsbereitstellung liefert messbare Renditen in den Bereichen Sicherheit und Betrieb. Passwortbasiertes WiFi verursacht ein erhebliches Aufkommen an Helpdesk-Tickets. Passwort-Abläufe, Sperren, Tippfehler. Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar. Geräte verbinden sich automatisch. Dies reduziert das WiFi-bezogene Helpdesk-Volumen in der Regel um 70 %. Das ist eine erhebliche Reduzierung der Betriebskosten. EAP-TLS eliminiert das Risiko des Abgreifens von Zugangsdaten und von Man-in-the-Middle-Angriffen. Dies ist entscheidend für die Einhaltung von PCI-DSS im Einzelhandel und der GDPR in allen Sektoren. Die Kosten einer Datenpanne übersteigen die Kosten für den Aufbau einer ordnungsgemäßen PKI-Infrastruktur bei Weitem. Und für Unternehmen, die bereits die Guest WiFi- und Analyseplattform von Purple nutzen, bietet die Ausweitung des sicheren Onboardings auf BYOD-Geräte der Mitarbeiter eine einheitliche Netzwerkmanagement-Strategie. Das hardwareunabhängige Cloud-Overlay von Purple lässt sich in Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet integrieren, sodass Sie nicht an einen einzigen Hardware-Hersteller gebunden sind. Purple ist an 80.000 Live-Standorten im Einsatz und hat im Jahr 2024 440 Millionen Logins verarbeitet, während es Zertifizierungen wie ISO 27001, GDPR, CCPA und Cyber Essentials besitzt. Lassen Sie mich mit einer schnellen Zusammenfassung der wichtigsten Entscheidungen schließen, die Sie treffen müssen. Sollten Sie SCEP oder PKCS verwenden? Verwenden Sie SCEP für die WiFi-Authentifizierung. Der private Schlüssel verbleibt auf dem Gerät. Verwenden Sie PKCS nur für die E-Mail-Verschlüsselung, bei der ein Key Escrow erforderlich ist. Wie lange sollten Zertifikate gültig sein? 90 Tage für BYOD. Ein bis zwei Jahre für unternehmensverwaltete Geräte. Sollten Sie in Ihrem MDM Benutzer- oder Geräte-Targeting verwenden? Verwenden Sie Geräte-Targeting für Unternehmensgeräte, die sich vor dem Benutzer-Login verbinden müssen. Verwenden Sie Benutzer-Targeting für BYOD, bei dem das Zertifikat an die Person gebunden sein soll. Wie gehen Sie mit der Android-Fragmentierung um? Verwenden Sie nach Möglichkeit Passpoint, auch bekannt als Hotspot 2.0. Es bietet ein konsistentes Verbindungserlebnis über verschiedene Android-Hersteller hinweg. Und schließlich, was ist die wichtigste Sache, die Sie richtig machen müssen? Die CRL-Überprüfung auf Ihrem RADIUS-Server. Ohne sie kann ein widerrufenes Zertifikat immer noch Netzwerkzugriff gewähren. Damit ist das heutige Briefing beendet. Wenn Sie sich näher mit diesen Themen befassen möchten, finden Sie die technischen Leitfäden von Purple zu WiFi-Sicherheit in Unternehmen und EAP-TLS-Zertifikatsauthentifizierung auf der Website von Purple unter purple.ai. Vielen Dank fürs Zuhören.