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 Gastgewerbe, 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. Sich bei WiFi für Mitarbeiter und BYOD auf Pre-Shared Keys (PSKs) zu verlassen, ist eine Sicherheitslücke, die nur darauf wartet, ausgenutzt zu werden. Ein gemeinsam genutztes Passwort, wenn es erst einmal kompromittiert ist, gewährt jedem Zugriff auf Ihr Netzwerk. Und MAC Authentication Bypass (MAB) ist nicht besser. Moderne Smartphones verwenden standardmäßig randomisierte MAC-Adressen, was MAB völlig unbrauchbar macht, und MAC-Adressen können in Sekundenschnelle gefälscht werden. Moderne Netzwerkarchitektur erfordert eine 802.1X-Authentifizierung mittels EAP-TLS. Dies stellt sicher, dass jedes Gerät kryptografisch verifiziert wird, bevor es mit dem Netzwerk in Berührung kommt. 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 Enrollment Protocol, kurz SCEP. Beginnen wir mit der Architektur. SCEP ist der Industriestandard für die Registrierung von Unternehmensgerä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 auf elegante Weise löst. In einem SCEP-Workflow generiert das Gerät sein eigenes privates und öffentliches Schlüsselpaar lokal. Es erstellt eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) und sendet diese über einen Network Device Enrollment Service (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 hierbei ist, dass der private Schlüssel das Gerät niemals verlässt. Er wird lokal generiert und im Hardware-Sicherheitsenklave des Geräts gespeichert. Auf einem Windows-Laptop ist das das Trusted Platform Module (TPM). Auf einem iPhone ist es die Secure Enclave. Der private Schlüssel wird niemals über das Netzwerk übertragen. Dies macht SCEP für die Netzwerkauthentifizierung weitaus überlegener als Alternativen wie PKCS, bei denen die CA das Schlüsselpaar zentral generiert und an das Gerät überträgt. Lassen Sie uns nun über BYOD sprechen. Aus betrieblicher Sicht wird es hier erst richtig interessant. Sie möchten, dass Ihre Mitarbeiter ihre persönlichen Geräte nutzen können, um auf interne Tools zuzugreifen, aber Sie möchten sie nicht dazu zwingen, sich in Ihrem Unternehmens-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, das das Zertifikat, das Root-CA-Zertifikat und die Netzwerkeinstellungen enthält, wird auf das Gerät übertragen. 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. Sie 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 Zertifizierungsstelle vertrauen. Exportieren Sie Ihr Root-CA-Zertifikat als .cer-Datei und verteilen Sie es an Ihre Zielgerätegruppen. Dieser Schritt ist nicht verhandelbar. Ohne ihn schlägt die gesamte Kette fehl. Schritt zwei: Konfiguration des SCEP-Zertifikatsprofils. Dies weist die Geräte an, wie sie ihr Client-Zertifikat erhalten. Sie müssen das Format des Subject Name konfigurieren. Für die benutzergesteuerte Authentifizierung ist der Standard CN gleich UserPrincipalName. Für die Geräteauthentifizierung verwenden Sie CN gleich der 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. Dies 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, was Sie aus diesem gesamten Briefing mitnehmen sollten. 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 erhebliche Probleme 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. Anstatt eines Zertifikats mit einer Gültigkeit von drei Jahren sollten Sie Zertifikate ausstellen, die nur 90 Tage gültig sind. Wenn das Zertifikat abläuft, muss sich der Benutzer erneut über das Onboarding-Portal authentifizieren. Dadurch werden veraltete Geräte ganz natürlich aus dem Netzwerk entfernt. Ein Gerät, das 90 Tage lang nicht benutzt wurde, fällt einfach weg. Es ist 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 (CRL) erzwingt. Wenn ein Mitarbeiter das Unternehmen verlässt, führt die Deaktivierung seines Active Directory-Kontos möglicherweise nicht sofort zum Entzug des WiFi-Zugangs, solange sein Client-Zertifikat noch gültig ist. 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. Betrachten wir nun einige häufige Fehlerszenarien und wie man sie vermeidet. Das häufigste Problem ist, dass das WiFi-Profil nicht angewendet werden kann. Das Gerät empfängt die Trusted Root- und SCEP-Zertifikate, 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, das WiFi-Profil jedoch einer Gerätegruppe zugewiesen ist, kann das MDM die Abhängigkeit nicht auflösen. Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass alle drei Profile genau auf 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 Dienstkonto des Connectors die erforderlichen Berechtigungen für die Zertifikatsvorlage fehlen oder eine Firewall die spezifischen, von SCEP verwendeten Abfrage-String-Parameter blockiert. Vergewissern Sie sich, dass das Connector-Konto über Lese- und Registrierungsberechtigungen (Read und Enroll) 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 Praxisbeispiele geben, um zu veranschaulichen, wie sich dies in der Realität darstellt. Szenario eins: Ein Hotel mit 200 Zimmern und 50 Reinigungskräften, die ihre persönlichen Smartphones nutzen, um auf die Dienstplan-App zuzugreifen. Der IT-Manager möchte eine vollständige MDM-Registrierung vermeiden, um die Privatsphäre der Mitarbeiter zu respektieren. 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-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 stellt sicheres WiFi für unternehmenseigene Point-of-Sale-Tablets bereit. Der Netzwerkarchitekt muss sicherstellen, dass die Anmeldedaten selbst bei einem Diebstahl des Tablets nicht extrahiert 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 Hardware-Secure-Enclave 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 Anmeldedaten eines gestohlenen Tablets nirgendwo anders verwendet werden. Dies erfüllt die PCI DSS-Compliance-Anforderungen. Kommen wir nun zum Business Case. Der Übergang zur SCEP 802.1X-Zertifikatsbereitstellung liefert messbare Erträge in Bezug auf Sicherheit und Betrieb. Passwortbasiertes WiFi erzeugt ein erhebliches Volumen an Helpdesk-Tickets. Passwortabläufe, Sperrungen, 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 von Credential Harvesting und Man-in-the-Middle-Angriffen. Dies ist entscheidend für die Einhaltung von PCI DSS in Einzelhandelsumgebungen und der GDPR in allen Sektoren. Die Kosten einer Datenpanne übersteigen die Kosten für die Bereitstellung einer ordnungsgemäßen PKI-Infrastruktur bei Weitem. Und für Organisationen, 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 und Fortinet integrieren, sodass Sie nicht an einen einzigen Hardware-Anbieter gebunden sind. Purple ist an 80.000 Live-Standorten im Einsatz, hat im Jahr 2024 440 Millionen Logins verarbeitet und verfügt über ISO 27001-, GDPR-, CCPA- und Cyber Essentials-Zertifizierungen. Lassen Sie mich mit einer kurzen 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 der Benutzeranmeldung verbinden müssen. Verwenden Sie Benutzer-Targeting für BYOD, bei dem das Zertifikat an die jeweilige 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 eine konsistente Verbindungserfahrung über verschiedene Android-Hersteller hinweg. Und schließlich: Was ist die wichtigste Sache, die Sie richtig machen müssen? Die CRL-Prüfung auf Ihrem RADIUS-Server. Ohne sie kann ein widerrufenes Zertifikat immer noch Netzwerkzugriff gewähren. Das war das Ende des heutigen Briefings. Wenn Sie tiefer in eines dieser Themen einsteigen möchten, finden Sie die technischen Leitfäden von Purple zur WiFi-Sicherheit in Unternehmen und zur EAP-TLS-Zertifikatsauthentifizierung auf der Purple-Website unter purple.ai. Vielen Dank fürs Zuhören.