Was ist PKI? Wie Public Key Infrastructure die WiFi-Sicherheit stärkt
Dieser maßgebliche technische Leitfaden erklärt die Public Key Infrastructure (PKI) und ihre entscheidende Rolle bei der Absicherung von Enterprise-WiFi-Netzwerken in den Bereichen Gastgewerbe, Einzelhandel und öffentlicher Sektor. Er wurde für IT-Manager, Netzwerkarchitekten und CTOs entwickelt und bietet praxisnahe Anleitungen zur zertifikatsbasierten Authentifizierung, zur Bereitstellung von IEEE 802.1X mit EAP-TLS und dazu, wie die Plattform von Purple diese Standards für eine skalierbare, konforme Konnektivität nutzt. Die Leser erhalten einen konkreten Bereitstellungsfahrplan, praxisnahe Fallstudien und ein klares Verständnis dafür, wie PKI die Schwachstellen von WiFi mit gemeinsam genutzten Schlüsseln (Shared Secrets) eliminiert.
Diesen Leitfaden anhören
Podcast-Transkript ansehen
Management-Zusammenfassung
Für IT-Verantwortliche in Unternehmen, die großflächige Bereitstellungen im Gastgewerbe, im Einzelhandel oder in öffentlichen Einrichtungen verwalten, ist die Absicherung des drahtlosen Zugangs eine grundlegende Anforderung – kein optionales Upgrade. Herkömmliche Pre-Shared Keys (PSKs) sind für Unternehmensumgebungen ungeeignet: Sie bieten keine individuelle Zurechenbarkeit, können nicht überprüft werden und verursachen bei einer Änderung erheblichen betrieblichen Aufwand. Die Public Key Infrastructure (PKI) bietet die kryptografische Grundlage, die für eine robuste, skalierbare Netzwerksicherheit erforderlich ist. Dieser Leitfaden beschreibt, was eine PKI ist, wie sie die Enterprise-WiFi-Sicherheit durch zertifikatsbasierte Authentifizierung stärkt und welche konkreten Schritte für die Bereitstellung von IEEE 802.1X mit EAP-TLS erforderlich sind. Durch den Übergang zu einer PKI-gestützten Architektur können Unternehmen den Diebstahl von Anmeldedaten eliminieren, das Onboarding von Geräten automatisieren und einen nahtlosen, sicheren Zugriff sowohl für Unternehmensgeräte als auch für Gäste gewährleisten – und gleichzeitig die Anforderungen von PCI DSS, GDPR und ISO 27001 erfüllen.
Technischer Deep-Dive: PKI im Enterprise-WiFi verstehen
Die Public Key Infrastructure (PKI) ist das Framework aus Hardware, Software, Richtlinien und Verfahren, das zum Erstellen, Verwalten, Verteilen, Nutzen, Speichern und Widerrufen digitaler Zertifikate sowie zur Verwaltung der Public-Key-Verschlüsselung erforderlich ist. Im Kontext von Enterprise-WiFi ist die PKI der Motor für die Identitätsprüfung und Verschlüsselung. Sie ersetzt das von Natur aus unsichere, gemeinsam genutzte Passwort durch eine kryptografische Identität, die für jedes Gerät oder jeden Benutzer eindeutig ist.
Die Kernkomponenten einer PKI
Im Kern basiert die PKI auf asymmetrischer Kryptografie, bei der zwei mathematisch miteinander verbundene Schlüssel verwendet werden: ein öffentlicher Schlüssel (öffentlich geteilt) und ein privater Schlüssel (geheim gehalten). Daten, die mit dem öffentlichen Schlüssel verschlüsselt wurden, können nur mit dem entsprechenden privaten Schlüssel entschlüsselt werden und umgekehrt. Die Hauptkomponenten einer PKI-Bereitstellung sind wie folgt aufgebaut.
| Komponente | Rolle | Kontext im Enterprise-WiFi |
|---|---|---|
| Certificate Authority (CA) | Stellt digitale Zertifikate aus und signiert diese | Der Vertrauensanker (Root of Trust) für Ihr Netzwerk; alle Geräte müssen der CA vertrauen |
| Digitales Zertifikat (X.509) | Bindet einen öffentlichen Schlüssel an eine Identität | Auf jedem Unternehmensgerät installiert; wird während der 802.1X-Authentifizierung vorgelegt |
| RADIUS-Server | Validiert Zertifikate und gewährt Netzwerkzugriff | Die Entscheidungs-Engine, die Verbindungsanfragen akzeptiert oder ablehnt |
| Registration Authority (RA) | Überprüft die Identität vor der Zertifikatsausstellung | Wird bei automatisierten Bereitstellungen oft von MDM/UEM übernommen |
| CRL / OCSP | Prüft, ob ein Zertifikat widerrufen wurde | Entscheidend, um kompromittierte oder gestohlene Geräte in Echtzeit zu blockieren |
Wie PKI 802.1X und EAP-TLS ermöglicht
Die WiFi-Sicherheit in Unternehmen basiert auf dem Standard IEEE 802.1X für die portbasierte Netzwerkzugriffskontrolle. In Kombination mit dem Extensible Authentication Protocol (EAP), insbesondere EAP-TLS (Transport Layer Security), bietet PKI das höchste Maß an drahtloser Sicherheit: gegenseitige Authentifizierung.
Bei einer EAP-TLS-Bereitstellung legt das Client-Gerät dem Netzwerk sein digitales Zertifikat vor, um seine Identität nachzuweisen, und der RADIUS-Server legt dem Client sein Zertifikat vor, um zu beweisen, dass das Netzwerk legitim ist und es sich nicht um einen gefälschten „Evil Twin“-Access-Point handelt. Dieses gegenseitiges Vertrauen wird hergestellt, weil beide Parteien der Root-CA vertrauen, die die Zertifikate ausgestellt hat. Nach der Authentifizierung wird die Sitzung mithilfe der ausgehandelten TLS-Verschlüsselungssuite verschlüsselt, was Abhören und Man-in-the-Middle-Angriffe verhindert.
Der EAP-TLS-Ablauf erfolgt über vier logische Instanzen: das Client-Gerät (Supplicant), den Access Point (Authenticator), den RADIUS-Server (Authentication Server) und die Certificate Authority. Der Access Point fungiert als transparentes Relay – er trifft die Authentifizierungsentscheidung nicht selbst. Diese Entscheidung liegt allein beim RADIUS-Server, der die Zertifikatskette bis zur vertrauenswürdigen Root-CA validiert.
Implementierungsleitfaden: Bereitstellung von zertifikatsbasiertem WiFi
Der Übergang zu einer PKI-gestützten WiFi-Architektur erfordert eine sorgfältige Planung in vier Phasen.
Phase 1: Architektur und CA-Auswahl
Entscheiden Sie, ob Sie eine interne PKI aufbauen (z. B. Microsoft Active Directory Certificate Services) oder einen verwalteten Cloud-PKI-Anbieter nutzen möchten. Für moderne, skalierbare Bereitstellungen reduziert eine Cloud-PKI den administrativen Aufwand erheblich und bietet eine integrierte hohe Verfügbarkeit. Stellen Sie sicher, dass sich die gewählte CA nahtlos in Ihre Mobile-Device-Management- (MDM) oder Unified-Endpoint-Management-Lösung (UEM) integrieren lässt. Für Umgebungen, die Guest WiFi nutzen, muss die RADIUS-Infrastruktur so ausgelegt sein, dass sie sowohl den geschäftlichen 802.1X-Verkehr als auch die Captive Portal-Authentifizierung für Gäste auf separaten SSIDs verarbeiten kann.
Phase 2: Konfiguration des RADIUS-Servers
Stellen Sie einen robusten RADIUS-Server bereit – zu den Optionen gehören FreeRADIUS, Cisco ISE, Aruba ClearPass oder ein Cloud-nativer RADIUS-as-a-Service. Konfigurieren Sie den RADIUS-Server mit einem eigenen Serverzertifikat, das von Ihrer CA ausgestellt wurde. Dies ist von entscheidender Bedeutung: Ohne ein gültiges Serverzertifikat kann der Client keine gegenseitige Authentifizierung durchführen und ist anfällig für Evil-Twin-Angriffe. Ziehen Sie für große Bereitstellungen an Veranstaltungsorten RADIUS-Proxy-Konfigurationen in Betracht, um das Roaming zwischen Standorten zu unterstützen. Veranstaltungsorte, die Plattformen für WiFi Analytics einsetzen, sollten sicherstellen, dass die RADIUS-Accounting-Daten in die Analytics-Pipeline einfließen, um eine genaue Sitzungszuordnung zu gewährleisten.
Phase 3: Automatisierte Zertifikatsbereitstellung
Die manuelle Installation von Zertifikaten ist nicht skalierbar und fehleranfällig. Nutzen Sie ProtocTools wie SCEP (Simple Certificate Enrollment Protocol) oder EST (Enrollment over Secure Transport) über Ihr MDM, um Zertifikate im Hintergrund auf Unternehmensgeräte zu übertragen. Implementieren Sie für BYOD-Szenarien ein Onboarding-Portal, das nach der ersten Identitätsprüfung ein Zertifikat sicher auf dem Gerät des Benutzers bereitstellt. Für Headless-IoT-Geräte – wie medizinische Geräte, Point-of-Sale-Terminals oder Digital Signage – müssen Zertifikate während der Bereitstellungsphase (Staging) vor dem Rollout bereitgestellt werden.
Phase 4: Durchsetzung von Netzwerkrichtlinien
Konfigurieren Sie Ihre Wireless-Controller und Access Points so, dass 802.1X auf der Unternehmens-SSID erzwungen wird. Ordnen Sie Zertifikatsattribute (wie den Subject Alternative Name oder das OU-Feld) über RADIUS-Attribute bestimmten VLANs oder Firewall-Richtlinien zu, um einen Netzwerkzugriff mit minimalen Rechten (Least Privilege) zu gewährleisten. Für Standorte, die Hardware bestimmter Hersteller verwenden, finden Sie plattformspezifische Konfigurationsschritte in herstellerspezifischen Anleitungen wie Ihr Leitfaden für einen Ruckus Wireless Access Point .
Best Practices für Enterprise-PKI
Schützen Sie die Root-CA. Bei Verwendung einer internen PKI muss die Root-CA offline aufbewahrt und physisch gesichert werden. Nur Intermediate-CAs sollten online sein und aktiv Zertifikate ausstellen. Eine kompromittierte Root-CA macht Ihre gesamte PKI ungültig.
Implementieren Sie eine robuste Sperrprüfung. Stellen Sie sicher, dass Ihre RADIUS-Server bei jedem Authentifizierungsversuch aktiv CRLs prüfen oder OCSP verwenden, um den Zertifikatsstatus zu verifizieren. Einem kompromittierten Gerät muss das Zertifikat sofort entzogen werden, um den Zugriff zu sperren. Wenn RADIUS so konfiguriert ist, dass CRL-Antworten zu lange zwischengespeichert werden, entsteht ein Sicherheitsrisiko.
Automatisieren Sie Verlängerungen vor dem Ablauf. Zertifikate laufen ab. Implementieren Sie automatisierte Verlängerungsprozesse, die bei 60–70 % der Gültigkeitsdauer des Zertifikats ausgelöst werden, um Netzwerkausfälle durch abgelaufene Zertifikate zu verhindern. Der Ablauf von Zertifikaten ist eine der häufigsten Ursachen für ungeplante WiFi-Ausfälle in Unternehmensumgebungen.
Nutzen Sie OpenRoaming für öffentliche Standorte. Für Standorte in den Bereichen Gastgewerbe , Einzelhandel , Transportwesen und Gesundheitswesen bietet die Teilnahme an OpenRoaming nahtlose, sichere Gastkonnektivität in großem Maßstab. Purple fungiert unter der Connect-Lizenz als kostenloser Identity Provider für OpenRoaming, sodass sich Benutzer mit bestehenden Profilen ohne Captive Portal oder Passwort sicher verbinden können – gestützt auf dasselbe PKI-Vertrauensmodell, das in diesem Leitfaden beschrieben wird.
Fehlerbehebung & Risikominderung
Selbst bei sorgfältiger Planung treten bei PKI-Bereitstellungen vorhersehbare Fehlerszenarien auf. Die folgende Tabelle fasst die häufigsten Probleme und deren Lösungen zusammen.
| Fehlerszenario | Symptom | Ursache | Lösung |
|---|---|---|---|
| Fehler bei der Zeitsynchronisation | Zertifikatsvalidierungsfehler auf allen Geräten | NTP-Fehlkonfiguration auf Client oder RADIUS | NTP-Richtlinie über MDM und Netzwerkinfrastruktur erzwingen |
| Fehler in der Vertrauenskette | Bestimmte Gerätetypen (z. B. Android) können keine Verbindung herstellen | Root-CA nicht im vertrauenswürdigen Root-Speicher des Geräts | Root-CA über MDM-Profil übertragen |
| CRL nicht erreichbar | Sporadische Authentifizierungsfehler | Firewall blockiert CRL/OCSP-Endpunkte | Firewall-Regeln für CA-Verteilungspunkte öffnen |
| Zertifikatsablauf | Plötzliche Massentrennung der Verbindungen | Automatisierung der Verlängerung nicht konfiguriert | MDM-gesteuerte Verlängerung bei 60 % Gültigkeit implementieren |
| RADIUS-Zertifikatskonflikt | Gegenseitige Authentifizierung schlägt bei allen Clients fehl | RADIUS-Serverzertifikat abgelaufen oder falsche CA | RADIUS-Serverzertifikat erneuern und neu bereitstellen |
Speziell für Umgebungen im Gesundheitswesen, in denen Netzwerkausfälle direkte Auswirkungen auf die Patientensicherheit haben, finden Sie unter WiFi in Krankenhäusern: Ein Leitfaden für sichere klinische Netzwerke Empfehlungen für Ausfallsicherheit auf klinischem Niveau.
ROI & geschäftliche Auswirkungen
Die Implementierung einer PKI für die WiFi-Sicherheit liefert messbaren geschäftlichen Nutzen in drei Dimensionen.
Risikominderung und Compliance. Durch den Verzicht auf gemeinsam genutzte Passwörter entfällt der häufigste Vektor für laterale Netzwerkbewegungen. Die zertifikatsbasierte Authentifizierung erfüllt direkt die Anforderungen von PCI DSS (Anforderung 8.6), GDPR (technische Maßnahmen nach Artikel 32) und ISO 27001 (Anhang A.9). Die Möglichkeit, ein Zertifikat sofort zu entziehen, wenn ein Mitarbeiter das Unternehmen verlässt oder ein Gerät gestohlen wird, bietet eine überprüfbare, nachweisbare Kontrolle, die Umgebungen mit gemeinsam genutzten Schlüsseln schlichtweg nicht bieten können.
Operative Effizienz. Die automatisierte Zertifikatsbereitstellung über MDM reduziert IT-Helpdesk-Tickets im Zusammenhang mit WiFi-Verbindungsproblemen – wie Passwort-Resets, Schlüsselrotationen und Onboarding-Verzögerungen – erheblich. In Einzelhandelsumgebungen mit hoher Personalfluktuation führt dies direkt zu geringeren IT-Supportkosten und schnelleren Bereitstellungszeiten für Geräte.
Verbesserte Benutzer- und Gasterfahrung. Die zertifikatsbasierte Authentifizierung ist für den Endbenutzer unsichtbar. Unternehmensmitarbeiter verbinden sich automatisch und sicher ohne manuelle Schritte. Für Gäste übernehmen Plattformen wie die Guest WiFi -Lösung von Purple die Trennung zwischen verwaltetem Unternehmenszugriff und Gast-Onboarding. So wird sichergestellt, dass jede Zielgruppe die passende Authentifizierungserfahrung erhält, ohne die Sicherheit in einem der beiden Netzwerke zu gefährden.
Schlüsseldefinitionen
Public Key Infrastructure (PKI)
Das umfassende Framework aus Rollen, Richtlinien, Hardware und Software zur Verwaltung digitaler Zertifikate und der Public-Key-Verschlüsselung. Es stellt die Vertrauensbeziehungen her, die es Geräten und Servern ermöglichen, die Identität des jeweils anderen kryptografisch zu überprüfen.
Die grundlegende Architektur, die erforderlich ist, um von gemeinsam genutzten Passwörtern wegzukommen und eine identitätsbasierte Netzwerksicherheit einzuführen. Jede Enterprise-WiFi-Bereitstellung, die 802.1X nutzt, hängt von einer PKI ab.
Certificate Authority (CA)
Eine vertrauenswürdige Instanz, die digitale Zertifikate ausstellt, signiert und verwaltet. Sie fungiert als Vertrauensanker (Root of Trust) in einer PKI: Jedes von der CA signierte Zertifikat wird von allen Parteien als vertrauenswürdig eingestuft, die der CA vertrauen.
Die zentrale Säule Ihrer Netzwerksicherheit. Wenn die CA kompromittiert wird, sind potenziell alle von ihr ausgestellten Zertifikate kompromittiert. Der Schutz der Root-CA ist die wichtigste Sicherheitsmaßnahme bei einer PKI-Bereitstellung.
X.509
Der ITU-T-Standard, der das Format von Public-Key-Zertifikaten definiert. X.509-Zertifikate enthalten Felder wie Subject, Issuer, Public Key, Validity Period und die digitale Signatur der CA.
Bei der Konfiguration von RADIUS-Serverrichtlinien ordnen IT-Teams bestimmte X.509-Felder – wie den Subject Alternative Name (SAN) oder die Organisational Unit (OU) – VLAN-Zuweisungen und Zugriffsrichtlinien zu.
IEEE 802.1X
Der IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle (PNAC). Er bietet einen Authentifizierungsmechanismus, der den gesamten Netzwerkverkehr am Access Point blockiert, bis die Identität des verbindenden Geräts durch einen Authentifizierungsserver überprüft wurde.
Das Protokoll, das die zertifikatsbasierte Authentifizierung am Wireless Access Point erzwingt. Ohne 802.1X kann sich ein Gerät mit der SSID verbinden, ohne seine Identität nachzuweisen.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Eine EAP-Methode, die Client- und Serverzertifikate verwendet, um eine gegenseitig authentifizierte, verschlüsselte TLS-Sitzung aufzubauen. Es ist die sicherste verfügbare EAP-Methode für Enterprise-WiFi.
Der Goldstandard für die WiFi-Authentifizierung in Unternehmen. Im Gegensatz zu PEAP oder EAP-TTLS, die Passwörter innerhalb eines TLS-Tunnels verwenden, eliminiert EAP-TLS Passwörter vollständig und ersetzt sie durch kryptografische Zertifikate.
RADIUS (Remote Authentication Dial-In User Service)
Ein Netzwerkprotokoll, das eine zentralisierte Verwaltung von Authentifizierung, Autorisierung und Abrechnung (AAA) bietet. Bei 802.1X-Bereitstellungen empfängt der RADIUS-Server das Zertifikat des Clients vom Access Point, validiert es gegenüber der CA und liefert eine Zugriffsentscheidung zurück.
Die Entscheidungs-Engine des WiFi-Authentifizierungs-Stacks in Unternehmen. RADIUS übernimmt auch die dynamische VLAN-Zuweisung und ermöglicht so eine Netzwerksegmentierung basierend auf der Geräteidentität oder der Benutzerrolle.
Certificate Revocation List (CRL)
Eine regelmäßig veröffentlichte Liste von Zertifikaten, die von der ausstellenden CA vor ihrem geplanten Ablaufdatum widerrufen wurden. RADIUS-Server prüfen die CRL, um sicherzustellen, dass sie kompromittierten oder außer Betrieb genommenen Geräten keinen Zugriff gewähren.
Entscheidend für die Aufrechterhaltung der Sicherheit, wenn Geräte verloren gehen, gestohlen oder außer Betrieb genommen werden. Die CRL-Prüfung muss auf dem RADIUS-Server konfiguriert werden – sie erfolgt nicht automatisch.
Mutual Authentication
Ein Sicherheitsprozess, bei dem sich beide Parteien in einer Kommunikationsverbindung gleichzeitig gegenseitig authentifizieren. Bei EAP-TLS authentifiziert sich der Client gegenüber dem Netzwerk und das Netzwerk gegenüber dem Client.
Verhindert „Evil Twin“-Angriffe, bei denen ein Hacker einen gefälschten Access Point mit derselben SSID wie das Unternehmensnetzwerk einrichtet, um Anmeldedaten abzufangen. Ohne gegenseitige Authentifizierung hat der Client keine Möglichkeit zu überprüfen, ob er sich mit dem legitimen Netzwerk verbindet.
SCEP (Simple Certificate Enrollment Protocol)
Ein Protokoll, das die automatisierte, skalierbare Verteilung digitaler Zertifikate an Geräte über ein MDM oder ein Netzwerkgeräte-Managementsystem ermöglicht.
Der Mechanismen, der PKI-Bereitstellungen in Unternehmen im großen Maßstab betrieblich rentabel macht. Ohne SCEP oder ein ähnliches automatisiertes Registrierungsprotokoll würde die Bereitstellung von Zertifikaten auf Tausenden von Geräten manuelle Eingriffe erfordern.
Ausgearbeitete Beispiele
Eine große Einzelhandelskette mit 500 Filialen muss ihr Unternehmens-WiFi für die Point-of-Sale-Tablets (POS) und Inventarscanner der Mitarbeiter absichern. Derzeit verwenden sie in allen Filialen einen einzigen WPA2-PSK, der häufig an Nicht-Mitarbeiter weitergegeben wird und nicht überprüft werden kann. Wie sollten sie ihre Authentifizierungsarchitektur neu gestalten?
Die Einzelhandelskette muss auf WPA3-Enterprise unter Verwendung von 802.1X und EAP-TLS migrieren. Schritt 1: Wählen Sie einen Cloud-basierten PKI-Anbieter und integrieren Sie ihn in die bestehende MDM-Lösung, die die POS-Tablets und Scanner verwaltet. Schritt 2: Konfigurieren Sie SCEP, um automatisch eindeutige, gerätegebundene digitale Zertifikate über das MDM auf jedes Unternehmensgerät zu übertragen. Schritt 3: Stellen Sie einen Cloud-RADIUS-Dienst bereit und konfigurieren Sie ihn so, dass er Zertifikate mit aktivierter OCSP-Prüfung gegen die PKI validiert. Schritt 4: Rekonfigurieren Sie die Wireless-Controller in jeder Filiale, um die 802.1X-Authentifizierung auf der Unternehmens-SSID zu erzwingen. Schritt 5: Nehmen Sie das PSK-Netzwerk außer Betrieb. Schritt 6: Konfigurieren Sie die VLAN-Zuweisung über RADIUS-Attribute, um POS-Geräte auf der Netzwerkschicht von den Geräten des allgemeinen Personals zu segmentieren.
Ein großes Krankenhausnetzwerk führt an drei Standorten neue drahtlose medizinische Infusionspumpen ein. Diesen Geräten fehlt eine Benutzeroberfläche zur Eingabe von Anmeldedaten oder zur Bestätigung von Captive Portal-Aufforderungen. Wie können sie sicher mit dem klinischen WiFi-Netzwerk verbunden werden, ohne eine Schwachstelle durch gemeinsam genutzte Schlüssel zu schaffen?
Implementieren Sie eine PKI-basierte Architektur speziell für headless IoT-Medizinprodukte. Schritt 1: Generieren Sie gerätespezifische X.509-Zertifikate für jede Infusionspumpe, wobei die Seriennummer des Geräts als Subject Common Name verwendet wird. Schritt 2: Installieren Sie die Zertifikate während der Staging- und Bereitstellungsphase auf den Pumpen, noch vor dem klinischen Einsatz. Schritt 3: Konfigurieren Sie die klinische WiFi-SSID für 802.1X EAP-TLS. Schritt 4: Konfigurieren Sie den RADIUS-Server so, dass er den Subject CN des Gerätezertifikats einem spezifischen, für medizinische Geräte reservierten VLAN zuweist. Schritt 5: Implementieren Sie die CRL-Prüfung, um einen sofortigen Widerruf zu ermöglichen, falls ein Gerät außer Betrieb genommen oder zurückgerufen wird.
Übungsfragen
Q1. Ihre Organisation migriert für die Unternehmens-SSID von PEAP (Benutzername/Passwort) zu EAP-TLS (Zertifikate). Während der Tests verbinden sich Windows-Laptops erfolgreich, aber Android-Geräte schlagen konsequent fehl. Die RADIUS-Protokolle zeigen, dass die Android-Geräte das Zertifikat des Servers während des TLS-Handshakes ablehnen. Was ist die wahrscheinlichste Ursache und wie lösen Sie das Problem?
Hinweis: Berücksichtigen Sie das Konzept der gegenseitigen Authentifizierung und der Vertrauenskette. Was benötigt das Android-Gerät, um dem Zertifikat des RADIUS-Servers zu vertrauen?
Musterlösung anzeigen
Auf den Android-Geräten ist das Root-CA-Zertifikat nicht im vertrauenswürdigen Root-Speicher installiert. Windows-Laptops erhalten die Root-CA automatisch über Gruppenrichtlinien, aber bei Android-Geräten muss die Root-CA über ein MDM-Profil übertragen werden. Ohne die Root-CA im vertrauenswürdigen Speicher kann das Android-Gerät die Zertifikatskette des RADIUS-Servers nicht überprüfen, was dazu führt, dass es das Serverzertifikat ablehnt und den TLS-Handshake abbricht. Lösung: Erstellen Sie ein MDM-Konfigurationsprofil, das das Root-CA-Zertifikat im vertrauenswürdigen Root-Speicher auf allen verwalteten Android-Geräten installiert, und testen Sie es erneut.
Q2. Der Firmen-Laptop eines kürzlich entlassenen Mitarbeiters verbindet sich zwei Tage nach der Deaktivierung seines Active Directory-Kontos immer noch erfolgreich mit dem Enterprise-WiFi-Netzwerk. Das Netzwerk verwendet EAP-TLS. Warum passiert das und was muss getan werden, um dies zu verhindern?
Hinweis: Das Deaktivieren eines Active Directory-Kontos führt nicht automatisch zur Ungültigkeit eines kryptografischen Zertifikats. Überlegen Sie, was der RADIUS-Server tatsächlich validiert.
Musterlösung anzeigen
Der RADIUS-Server validiert das Zertifikat, nicht den Status des Active Directory-Kontos. Da das Zertifikat mathematisch noch gültig ist und nicht widerrufen wurde, gewährt der RADIUS-Server Zugriff. Zur sofortigen Behebung muss das für diesen Laptop ausgestellte spezifische Zertifikat in der Certificate Authority widerrufen werden. Um dies systematisch zu verhindern, integrieren Sie den HR-Offboarding-Prozess in das MDM und die PKI: Wenn ein Mitarbeiter das Unternehmen verlässt, sollte das MDM das Gerätezertifikat automatisch widerrufen und die Registrierung des Geräts aufheben. Stellen Sie außerdem sicher, dass der RADIUS-Server so konfiguriert ist, dass er bei jedem Authentifizierungsversuch – und nicht nur periodisch – OCSP oder die CRL überprüft, damit der Widerruf sofort wirksam wird.
Q3. Sie entwerfen die Netzwerkarchitektur für ein großes Stadion, das 60.000 Besuchern ein nahtloses, sicheres WiFi bieten möchte, ohne dass jeder Einzelne ein Captive Portal durchlaufen muss. Der Veranstaltungsort möchte auch Aussteller unterstützen, die einen über 802.1X gesicherten Zugriff für ihre POS-Geräte benötigen. Wie spielt PKI bei beiden Anforderungen eine Rolle?
Hinweis: Bedenken Sie, dass es zwei verschiedene Zielgruppen mit unterschiedlichen Authentifizierungsanforderungen gibt. OpenRoaming deckt die eine ab; eine dedizierte Unternehmens-SSID mit 802.1X die andere.
Musterlösung anzeigen
Es sind zwei separate SSIDs erforderlich. Implementieren Sie für die 60.000 Besucher OpenRoaming. Das Netzwerk des Stadions muss so konfiguriert sein, dass es den OpenRoaming-Root-CAs vertraut. Wenn sich das Gerät eines Besuchers verbindet – das von einem Identitätsanbieter wie Purple oder einem Mobilfunkanbieter bereitgestellt wurde –, legt es ein Zertifikat vor. Der RADIUS-Server validiert dieses gegen die OpenRoaming-Vertrauenskette und gewährt sicheren, verschlüsselten Zugriff ohne ein Captive Portal. Für Aussteller mit POS-Geräten stellen Sie eine separate 802.1X-SSID unter Verwendung von EAP-TLS bereit. Den Ausstellern werden während ihres Akkreditierungsprozesses temporäre Gerätezertifikate ausgestellt, die nach der Veranstaltung automatisch widerrufen werden. RADIUS-Attribute weisen die POS-Geräte einem dedizierten VLAN zu, was die PCI-DSS-Anforderungen zur Netzwerksegmentierung erfüllt.
Weiterlesen in dieser Reihe
Per-Device PSK nach Anbieter: iPSK, DPSK, MPSK und PPSK im Vergleich (und WPA3-Unterstützung)
Ein umfassender Vergleich von Per-Device-PSK-Implementierungen bei Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet und Ubiquiti UniFi. Erfahren Sie, wie sich WPA3-SAE auf Per-Device-Key-Strategien auswirkt und wann Übergangsmodi im Vergleich zum Wechsel zu 802.1X eingesetzt werden sollten.
What Is MAC Address Authentication? When to Use It and When to Avoid It
Dieser maßgebliche technische Leitfaden behandelt die MAC-Adressauthentifizierung in Unternehmens-WiFi-Umgebungen – wie RADIUS-basierte MAC-Authentifizierung auf Layer 2 funktioniert, ihre inhärenten Sicherheitslücken (einschließlich MAC-Spoofing und die Auswirkungen der MAC-Randomisierung auf OS-Ebene) und die genauen operativen Kontexte, in denen sie ein gültiges Werkzeug zur Verwaltung von IoT- und kopflosen Geräten bleibt. Er bietet umsetzbare Bereitstellungsanleitungen für IT-Manager und Netzwerkarchitekten in den Bereichen Gastgewerbe, Einzelhandel, Gesundheitswesen und öffentlicher Sektor, mit realen Fallbeispielen, Entscheidungsrahmen und Integrationskontext für die Gast-WiFi- und Analyseplattform von Purple.
How to Set Up Enterprise WiFi on iOS and macOS with 802.1X
Dieser maßgebliche Leitfaden bietet leitenden IT-Führungskräften umsetzbare Schritte für die Bereitstellung von 802.1X Enterprise WiFi auf iOS- und macOS-Geräten. Er behandelt die zertifikatbasierte Authentifizierung (EAP-TLS), MDM-Konfigurationsprofile und die Architekturintegration zur Sicherung von Unternehmensnetzwerken bei gleichzeitiger Unterstützung von BYOD-Initiativen.