EAP-TLS vs PEAP: Sicherheit, Zertifikate und Eignung
Published
Der gebräuchlichste Rat zum Thema eap tls vs peap ist zwar übersichtlich, aber falsch. Wählen Sie EAP-TLS, weil es "sicherer" ist, und überlassen Sie PEAP den Teams, die noch nicht auf dem neuesten Stand sind. Das ignoriert die Frage, die darüber entscheidet, ob ein standortübergreifendes WLAN am Montagmorgen noch funktioniert: Können Sie für jedes Gerät, das es nutzen soll, ein Zertifikat ausstellen, erneuern und widerrufen?
Ich würde nicht eine einzige Methode für den gesamten Bestand einsetzen. EAP-TLS gehört auf Geräte, die Sie registrieren und erneuern können. PEAP, fast immer mit internem EAP-MSCHAPv2, gehört dorthin, wo bereits ein Verzeichnis-Passwort existiert und eine Zertifikatsregistrierung nicht praktikabel ist. Die schwierigere Methode ist nicht immer diejenige, die Sie ausführen können. Ein abgelaufenes Zertifikat im Backoffice eines Hotels sperrt Mitarbeiter aus, während ihre Konten gültig bleiben. Ein PEAP-Profil, das die Serverprüfung überspringt, kann ein Verzeichnis-Passwort an einen Rogue Access Point übergeben. Beide Fehler sind betrieblicher Natur. Weisen Sie die Methode der jeweiligen Benutzergruppe zu, anstatt nach einem netzwerkweiten Favoriten zu suchen.
Inhaltsverzeichnis
- EAP-TLS und PEAP im Vergleich
- Wie jede Methode authentifiziert und wo Passwörter durchsickern
- Zertifikatsanforderungen vor der Einführung
- Zertifikatslebenszyklus und Bereitstellungsaufwand
- Sperrung, Roaming-Geschwindigkeit und Client-Unterstützung
- Weisen Sie jede Benutzergruppe zu und belegen Sie die Aufteilung
EAP-TLS und PEAP im Vergleich
Der praktische Unterschied zwischen EAP-TLS und PEAP liegt in den Anmeldeinformationen, die jeder Endpunkt unterstützen kann, und dem Aufwand, der erforderlich ist, um diese nutzbar zu halten. Verwenden Sie EAP-TLS für Geräte, die Sie registrieren und erneuern können. Verwenden Sie PEAP, wenn Benutzer bereits über Verzeichnis-Passwörter verfügen und eine Zertifikatsregistrierung nicht praktikabel ist. Keine der beiden Methoden ist die richtige Antwort für jede Benutzergruppe.
| Kriterium | EAP-TLS | PEAP |
|---|---|---|
| EAP-Typ-ID | 13 | 26 |
| Client-Anmeldedaten | X.509 Client-Zertifikat | Benutzername und Passwort, meist EAP-MSCHAPv2 oder EAP-GTC |
| Server-Anmeldedaten | RADIUS-Serverzertifikat | RADIUS-Serverzertifikat auf dem äußeren TLS-Tunnel |
| Wechselseitige Authentifizierung | Client- und Serverzertifikate | Serverzertifikat plus innere Benutzer- oder Geräteauthentifizierung |
| Passwort über das Netzwerk | Keines | Ja, innerhalb des TLS-Tunnels |
| Was ein Rogue AP stehlen kann, wenn der Client Serverprüfungen überspringt | Nichts Passwortähnliches; Authentifizierung schlägt sicher fehl | Verzeichnispasswort |
| Widerruf eines einzelnen Geräts | Zertifikat widerrufen oder ablaufen lassen | Konto deaktivieren oder ein möglicherweise wiederverwendetes Passwort zurücksetzen |
| PKI-Aufwand | Server- und Clientzertifikate, Erneuerung und Wiederherstellung | Nur Serverzertifikat |
| Beste Erstkonfiguration | Über MDM verwaltetes Personal und privilegierte Geräte | Unverwaltete Endgeräte, die keine Zertifikate registrieren können |
Ein technischer Artikel von Authentik aus dem Jahr 2025 identifiziert EAP-TLS als EAP-Typ-ID 13 und PEAP als Typ-ID 26. Diese IDs identifizieren die Methoden gegenüber RADIUS und dem Supplicant. Sie legen nicht fest, welche Personen oder Geräte sie verwenden sollten.
Was die Zeilen tatsächlich verändern
Anmeldeinformationen des Clients legen die operative Grenze fest. EAP-TLS weist ein X.509-Client-Zertifikat vor. PEAP nutzt Benutzername und Passwort, gewöhnlich über EAP-MSCHAPv2 oder EAP-GTC. Dadurch werden Zertifikatsregistrierung und -erneuerung zum entscheidenden Arbeitsaufwand, anstatt einer theoretischen Rangfolge der Methoden.
Auch die Vertrauensprüfungen unterscheiden sich. EAP-TLS authentifiziert sowohl das Client- als auch das Serverzertifikat. PEAP überprüft das RADIUS-Serverzertifikat im äußeren TLS-Tunnel und authentifiziert dann den Benutzer oder das Gerät mit einer inneren Methode.
Die Offenlegung von Passwörtern hängt von der Supplicant-Konfiguration ab. EAP-TLS überträgt kein Passwort über das Netzwerk. PEAP überträgt ein Passwort innerhalb seines Tunnels. Ein Client, der die Serverüberprüfung überspringt, kann daher ein Verzeichnis-Passwort an einen Rogue Access Point preisgeben. Bei EAP-TLS führt ein fehlendes oder nicht vertrauenswürdiges Client-Zertifikat dazu, dass die Authentifizierung fehlschlägt.
Das Offboarding hängt ebenfalls davon ab, was verwaltet wird. Ein Gerätezertifikat kann widerrufen werden oder ablaufen, ohne dass das Verzeichnispasswort einer Person zurückgesetzt werden muss. Das Deaktivieren eines Kontos oder das Ändern eines mehrfach verwendeten Passworts kann sich auf andere Anmeldungen auswirken, die an diese Anmeldedaten gebunden sind.
Der betriebliche Kompromiss ist klar: EAP-TLS erfordert Client-Zertifikate, Erneuerungen und einen Wiederherstellungspfad, während PEAP das Server-Zertifikat und eine sorgfältige Supplicant-Konfiguration erfordert. Weisen Sie EAP-TLS registrierten Mitarbeitern und privilegierten Geräten zu; nutzen Sie PEAP für unverwaltete Endgeräte, die nicht in das Zertifikatsmanagement eingebunden werden können. Teams, die Serverless-Infrastruktur für Mitgliedsplattformen betreiben, verfügen möglicherweise über unterschiedliche Mitglieder-, Mitarbeiter- und Gerätegruppen, aber das Hosting-Modell bestimmt nicht die Authentifizierungsmethode. Anmeldeinformationen müssen dazu passen, wen Sie verwalten können.
Wie jede Methode authentifiziert und wo Passwörter durchsickern
EAP-TLS ist nicht automatisch für jeden Benutzer die richtige Lösung. Die entscheidende Frage ist, ob Ihr Team Zertifikate für jede Benutzergruppe zuverlässig ausstellen, erneuern und widerrufen kann. PEAP vereinfacht das Onboarding für unverwaltete Benutzer, aber die Sicherheit des Passworts hängt von der korrekten Supplicant-Konfiguration ab.
Beide Methoden nutzen 802.1X. Der Supplicant ist das Gerät, das Zugriff anfordert, der Authenticator ist der Access Point oder Switch, der diese Anfrage weiterleitet, und der RADIUS-Server akzeptiert oder lehnt sie ab. Sie teilen sich das EAP-Framework, nicht jedoch die Anmeldeinformationen.
Der IETF EAP-Spezifikationsindex beschreibt EAP-TLS, definiert in IETF RFC 5216, als zertifikatsbasierte Client- und Serverauthentifizierung mit wechselseitiger Authentifizierung, integritätsgeschützter Cipher-Suite-Aushandlung und Schlüsselableitung. Die Spezifikation wurde im März 2008 veröffentlicht. In der Praxis erfordert EAP-TLS ein über eine PKI ausgestellt Client-Zertifikat neben dem RADIUS-Serverzertifikat.
Zwei Sequenzen, ein Framework
EAP-TLS authentifiziert beide Endpunkte in einem einzigen TLS-Austausch:
- Der Supplicant startet EAP mit dem Authenticator, der die Anfrage an RADIUS weiterleitet.
- Die Server- und Client-Zertifikate werden während des TLS-Austauschs überprüft.
- Der Austausch schützt die Aushandlung der Cipher-Suite und leitet Schlüssel ab, ohne ein Passwort zu senden, das per Phishing, Replay oder Brute-Force angegriffen werden kann.
- Ein fehlendes oder nicht vertrauenswürdiges Client-Zertifikat führt dazu, dass das Gerät abgelehnt wird. Es kann nicht auf die Eingabe eines Passworts zurückgegriffen werden.
PEAP erstellt einen äußeren TLS-Tunnel, der den Server authentifiziert, und führt dann eine innere Methode aus, gewöhnlich EAP-MSCHAPv2 oder EAP-GTC. Da die innere Methode Benutzername und Passwort verwenden kann, benötigen Endpunkte in der Regel keine Client-Zertifikate. Der IETF-EAP-Spezifikationsindex beschreibt ebenfalls den Standardrahmen, den diese Methoden nutzen.
Benutzer sehen den äußeren Tunnel von PEAP nicht. Die innere Identität, typischerweise ein Benutzername und ein Passwort oder ein Token, wird erst übertragen, nachdem TLS aufgebaut wurde. Das macht PEAP für verzeichnisbasierte Supplicants vertraut, setzt jedoch ein Passwort einem Risiko aus, wenn der Client den Tunnel nicht korrekt überprüft.
PEAP mit innerem EAP-TLS ist ein aufwendigerer Spezialfall, der eine Zertifikatsmethode mit einem äußeren TLS-Tunnel kombiniert. Eine als „PEAP“ gekennzeichnete Bereitstellung bedeutet in der Regel PEAP-MSCHAPv2.
Wo der Supplicant über das Ergebnis entscheidet
Ein Beitrag zu EAP-Methoden in Enterprise-WLANs erklärt den Unterschied: EAP-TLS nutzt gegenseitige X.509-Authentifizierung. RADIUS überprüft das Client-Zertifikat und der Client überprüft das Server-Zertifikat. Es gibt kein Passwort, das gefischt, wiederholt oder per Brute-Force angegriffen werden kann. Der Beitrag hebt außerdem hervor, dass NIST vorschreibt, dass sowohl die WLAN-Station als auch der Authentifizierungsserver gültige Zertifikate besitzen müssen.
Bei PEAP muss der Client die RADIUS-Zertifikatskette und den erwarteten Servernamen validieren. Wenn eine dieser Prüfungen fehlt, kann ein gefälschter Access Point ein Verzeichnispasswort abfangen. Ein Supplicant-Profil, das auf „nicht validieren“ eingestellt ist, schützt das Passwort nicht.
Praktische Regel: Pinne den RADIUS-Servernamen und die ausstellende CA im WiFi-Profil. Ohne diese Prüfungen kann PEAP ein Passwort an einen gefälschten Server übermitteln.
Erfasste MS-CHAPv2-Antworten können offline geknackt werden, nachdem ein Angreifer sie über einen gefälschten Tunnel erlangt hat. Die Validierung des Tunnels ist die Kontrollmaßnahme; die innere Methode rettet kein Profil, das einen nicht vertrauenswürdigen Server akzeptiert. Das gleiche Passwort-Risiko reicht über WiFi hinaus. Berichte über kompromittierte Anmeldeinformationen in australischen Kleinunternehmen unterstreichen, warum ein wiederverwendetes Verzeichnis-Passwort für einen Angreifer wertvoll bleibt.
Weisen Sie EAP-TLS verwalteten Geräten und Benutzern zu, deren Zertifikatslebenszyklus Sie steuern können. Nutzen Sie PEAP dort, wo Benutzer oder Geräte Zertifikate nicht zuverlässig empfangen und erneuern können, setzen Sie jedoch die Servernamen- und CA-Validierung über das Supplicant-Profil durch. Der betriebliche Kompromiss ist direkt: Zertifikate erfordern Registrierungs- und Wiederherstellungsaufwand, während Passwörter Verwaltung bei Wiederverwendung und Kontoänderungen nach sich ziehen. Die bessere Methode hängt davon ab, wen Sie verwalten können - nicht davon, einen einzigen Gewinner für jede SSID zu erklären.
Zertifikatsanforderungen vor dem Rollout
Bestätige diese sechs Punkte in einer Testumgebung, bevor das erste Produktionsgerät beitritt. Eine fehlende Kette oder ein falscher Name sieht wie "WiFi ist offline" aus, nicht wie ein Zertifikatsfehler.
- RADIUS-Serverzertifikat. Stellen Sie es über Ihre private Zertifizierungsstelle (CA) aus. Tragen Sie den Namen, den das Supplicant-Profil verankert, im Betreff oder SAN ein. Legen Sie die Serverauthentifizierungs-Nutzung fest und liefern Sie die vollständige Zwischenkette mit dem Zertifikat aus. Eine öffentliche CA, die jeden übereinstimmenden Namen signiert, ist das falsche Vertrauensmodell für einen internen RADIUS-Namen.
- Clientzertifikat. Ein Zertifikat pro Gerät oder Benutzer mit der Nutzung Clientauthentifizierung. Tragen Sie eine eindeutige Identität im SAN ein, wie z. B. einen User Principal Name oder eine Geräteseriennummer. Speichern Sie den privaten Schlüssel im TPM oder in der Secure Enclave, sofern die Plattform dies unterstützt.
- Vertrauensanker. Installieren Sie die interne Stamm- oder Ausstellungs-CA über das MDM-Profil. Richten Sie Geräte nicht auf ein öffentliches Stammzertifikat aus in der Hoffnung, dass die Namensprüfung ausreicht.
- Gültigkeit und Erneuerung. Veröffentlichen Sie eine Laufzeit für das Serverzertifikat und für Clientzertifikate. Richten Sie ein Überschneidungsfenster ein, damit das Ersatzzertifikat installiert wird, bevor das alte abläuft.
- Sperrung (Revocation). Stellen Sie dem RADIUS-Server einen erreichbaren CRL- oder OCSP-Endpunkt zur Verfügung. Legen Sie schriftlich fest, ob die Authentifizierung fehlschlägt oder fortgesetzt wird, wenn dieser Endpunkt offline ist. Testen Sie den Offline-Fall. Entdecken Sie dessen Verhalten nicht erst bei einer WAN-Störung.
- Bereitstellungskanal. Übermitteln Sie Zertifikate mit SCEP oder PKCS#12 über das MDM. Weisen Sie die Funktion auf einem einzelnen Gerät nach - einschließlich der Erneuerung -, bevor Sie eine Gruppe ansprechen.
Angenommen, eine Klinik nutzt Okta für die Mitarbeiteridentität und Intune für Laptops. Der RADIUS-Name im Profil muss mit dem Zertifikat übereinstimmen, und die Okta-Gruppe, die im klinischen VLAN landen soll, muss dieselbe Gruppe sein, die das MDM für die Registrierung verwendet. Unsere Hinweise zur Okta WiFi authentication erläutern diese Identitätsübergabe, ohne das Labor in ein Passwort-SSID zu verwandeln.
Verbinde einen Test-Laptop, widerrufe sein Zertifikat und bestätige, dass die nächste Zuordnung fehlschlägt, bevor du eine produktive Etage anfasst.
Zertifikatslebenszyklus und Rollout-Aufwand
Die EAP-TLS-Sicherheit führt zu einem Ausfall, wenn ein Zertifikat abläuft oder ein Client keine Sperrinformationen erreichen kann, obwohl das Benutzerkonto noch vollkommen gültig ist. Das ist die entscheidende Frage. "Zertifikate sind schwieriger" ist kein Designkonzept.
NIST Special Publication 800-120 beschreibt dasselbe Risiko. EAP-TLS erfordert eine zuverlässige Ausstellung, Verteilung, Erneuerung, Vertrauenskettenverwaltung und Widerrufsprüfung. Ein Gerät mit einem abgelaufenen Zertifikat oder einem nicht erreichbaren Widerrufsdienst kann den Netzwerkzugriff verlieren, selbst wenn die Identität des Benutzers weiterhin gültig ist. PEAP authentifiziert typischerweise den Server in der äußeren TLS-Phase und einen Benutzernamen sowie ein Passwort über eine innere Methode wie MS-CHAPv2, wodurch dieser Lebenszyklus des Clients entfällt. Der einfachere erste Tag verlagert den Aufwand in Passwort-Resets und fehlerhafte Profile.
Verhindere, dass Zertifikate zum Ausfall führen
Die Design-Antwort ist Automatisierung, kein längeres Betriebshandbuch.
- Über MDM registrieren. Übertragen Sie das Profil, den Trust Anchor und das Zertifikat zusammen. Manuelle WiFi-Einrichtung führt dazu, dass Servernamensprüfungen deaktiviert werden.
- Erneuerung überschneiden. Installieren Sie das neue Zertifikat, bevor das alte abläuft. Ein Wochenende, an dem jeder Laptop gleichzeitig den Zugriff verliert, bedeutet eine zu kurze Überschneidung.
- Offline-Widerruf testen. Prüfen Sie, ob RADIUS bei Nichterreichbarkeit von CRL oder OCSP den Zugriff verweigert oder gewährt.
- Wiederherstellungspfad vorhalten. Ein fehlerhafter Endpunkt benötigt einen Rückweg, der nicht daraus besteht, "sich das PEAP-Passwort von jemandem zu leihen." Ein verkabelter Helpdesk-Port oder eine eng begrenzte Wiederherstellungs-SSID ist besser als ein geteiltes Passwort auf einem Whiteboard.
Purple Access bezieht EAP-TLS-Zertifikate von Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru und Addigy, geliefert über SCEP - mit einer Einrichtung, die für das gesamte Unternehmen einmalig fünf bis zehn Minuten dauert, statt für jedes einzelne Gerät. Das sichere Netzwerk ist passwortlos und zertifikatsbasiert. Ein Gerät, das die Statusprüfung nicht besteht, wird bei der Authentifizierung über Conditional Access abgelehnt. Das ist ein von Compliance-Regeln gesteuerter Beitritt, keine zweite Passwortabfrage.
PEAP bleibt die unkomplizierte Wahl, wenn die PKI nicht ausreichend ausgebaut ist, wenn externe Dienstleister nicht in das MDM eingebunden werden können oder wenn gemischte BYOD-Umgebungen kein Zertifikat akzeptieren. Das Gesundheitswesen, das Bildungswesen, das Gastgewerbe und andere Netzwerke mit vielen Standorten stehen häufig vor allen drei Herausforderungen gleichzeitig. Nutzen Sie EAP-TLS für verwaltete Unternehmens-, Mitarbeiter- und Hochrisikogeräte. Halten Sie eine streng kontrollierte Alternative für nicht verwaltete oder temporäre Endgeräte bereit. Die Identitätsverwaltung auf Standortebene ist die entscheidende Weichenstellung - nicht die Parole, dass TLS Passwörter abgelöst hat.
Wenn RADIUS selbst der anfällige Punkt ist, eliminiert ein gehostetes Backend das Ausfallrisiko des "einen Servers im Zentrale-Schrank". Unser Artikel zu RADIUS-as-a-Service ist die richtige Anlaufstelle, um Erreichbarkeit und Redundanz zu prüfen, bevor Sie die EAP-Methode verantwortlich machen.
Die kurze Anleitung unten zeigt die Zertifikatregistrierung neben einer inneren Passwort-Methode - genau der Unterschied, den Helpdesks sehen, wenn eine Verlängerung verspätet ist.
Sperrung, Roaming-Geschwindigkeit und Client-Unterstützung
Unterstützung und Geschwindigkeit sind Nachschlageprobleme. Aktuelle Supplicants von Windows, macOS, iOS, Android und ChromeOS beherrschen beide Methoden. Der Unterschied liegt im Fehlerverhalten.
EAP-TLS schlägt fehl, wenn das Profil, die ausstellende CA oder die Gültigkeitsdaten falsch sind. PEAP schlägt fehl, wenn die innere Methode, das Identitätsformat oder die Servernamen-Prüfung nicht mit der RADIUS-Richtlinie übereinstimmen. Keines dieser Fehlerszenarien bedeutet, dass der Access Point „Enterprise nicht unterstützt“.
Bei der Sperrung zeigt sich dieselbe Aufteilung. Die Deaktivierung eines einzelnen Gerätezertifikats trennt diesen Laptop ab, ohne die anderen Logins der Person zu beeinträchtigen. Das Zurücksetzen eines Verzeichnis-Passworts betrifft hingegen jeden nicht verwalteten Client, der es noch verwendet. Die sofortige, gerätespezifische Trennung ist der Vorteil von EAP-TLS. Harte Ausfälle durch abgelaufene Zertifikate sind der Preis dafür.
Handshakes statt Markennamen
Ein ACM-Papier zur Latenz bei der drahtlosen Authentifizierung zeigt, dass die Leistung mehr von Handshake-Anzahl, Roaming, Zertifikatsvalidierung und Backend-Latenz abhängt als vom Namen der Methode. Standard-EAP-TLS schließt die Client- und Server-Zertifikatsauthentifizierung in seinem TLS-Austausch ab. PEAP baut einen TLS-Tunnel auf und führt dann die innere Authentifizierung aus, was eine zusätzliche Phase bedeutet. Technische Unterlagen von Cisco, die in diesem Papier zitiert werden, besagen, dass PEAP mit innerem EAP-TLS zwei TLS-Handshakes beinhaltet und langsam sein kann, wenn beim Roaming eine vollständige Reauthentifizierung stattfindet.
Messen Sie diese Werte separat. Erklären Sie keinen Gewinner basierend auf einer einzigen durchschnittlichen Anmeldezeit.
- 95. Perzentil der Assoziations-zu-IP-Zeit
- Latenz der vollständigen Authentifizierung im Vergleich zur Roaming-Wiederaufnahme
- RADIUS-Umlaufzeit (Round-Trip Time)
- Authentifizierungs-Fehlerrate
- Fehler bei der Zertifikatserneuerung
Sitzungswiederaufnahme, PMK-Caching oder 802.11r, lokale RADIUS-Erreichbarkeit und eine kurze Zertifikatskette beeinflussen diese Zahlen stärker als das Auswechseln einer Cipher-Suite. PEAP mag am ersten Tag einfach wirken, kann aber durch wiederholte Passwortabfragen und Benutzerunterstützung dennoch Verzögerungen verursachen. EAP-TLS kann sich nach der Registrierung extrem schnell anfühlen und dann bei einem abgelaufenen Zertifikat komplett fehlschlagen.
| Symptom | Wahrscheinlichere Methode | Übliche Ursache | Praktische Lösung |
|---|---|---|---|
| Passwortaufforderung wiederholt sich in der Nähe eines unbekannten APs | PEAP | Supplicant validiert Servernamen oder -kette nicht | Profil bereitstellen, das den RADIUS-Namen und die CA fest verankert |
| Zugriff auf einem Laptop nach Rollenwechsel unterbrochen | EAP-TLS | Zertifikat widerrufen oder Gerät aus MDM entfernt | Widerruf bestätigen und nur dieses Gerät neu registrieren |
| Gesamtes Team an einem Montag ausgesperrt | EAP-TLS | Zertifikate gleichzeitig abgelaufen oder Erneuerungsüberschneidung zu kurz | Erneuerung vor Ablauf staffeln und Wiederherstellungspfad vorhalten |
| Roaming fühlt sich nur bei vollständiger Neuauthentifizierung langsam an | PEAP mit innerem EAP-TLS | Zwei TLS-Handshakes | Wiederaufnahme, PMK-Caching oder 802.11r bevorzugen; inneres EAP-TLS vermeiden, außer wenn erforderlich |
| Zufällige Ablehnungen an nur einem Standort | Beide | RADIUS-Laufzeit oder Kettenabruf, nicht der EAP-Name | RTT und 95. Perzentil der Zeit von Zuordnung bis IP messen, bevor Methode geändert wird |
Ein langsames Roaming an einem Standort liegt normalerweise an der RADIUS-Entfernung oder am Abrufen der Zertifikatskette, ist aber kein Beweis dafür, dass du den falschen EAP-Typ gewählt hast.
Jede Gruppe zuweisen und die Trennung nachweisen
In einem einzigen Gebäude können sich Laptops von Mitarbeitern, ein Konferenzgast, das Mac eines externen Dienstleisters und eine Kasse befinden. Diese sollten nicht dieselbe Anmeldeart teilen. Kartieren Sie jede Zielgruppe, testen Sie einen Standort parallel zu Ihrem bestehenden Netzwerk und bewerten Sie Support-Tickets sowie das Authentifizierungsprotokoll, bevor Sie das Design flächendeckend übernehmen.
| Zielgruppe | Verwenden | Nicht verwenden | Grund |
|---|---|---|---|
| Über MDM verwaltetes Personal und privilegierte Benutzer | EAP-TLS auf einer WPA-Enterprise SSID | Geteilter PSK oder PEAP | Zertifikatsidentität, VLAN nach Gruppe, Zugriff endet mit der Deaktivierung des Kontos |
| Gäste und Besucher mit kurzem Aufenthalt | Captive Portal oder Passpoint auf einem Gäste-VLAN | PEAP- oder EAP-TLS-Registrierung am Empfang | Kein Zertifikatslebenszyklus und kein Verzeichnispasswort zum Phishen |
| Unverwaltete Laptops und externe Dienstleister | Nur PEAP-MSCHAPv2 mit erzwungener Servervalidierung | EAP-TLS, wenn Sie diese nicht registrieren oder erneuern können | Passwörter existieren bereits, aber das Profil muss das RADIUS-Zertifikat prüfen |
| Drucker, TV-Geräte, Kassen, CCTV und Sensoren | Gerätespezifischer PSK mit eigenem VLAN | EAP-TLS oder ein gemeinsames PEAP-Passwort | Diese Geräte können meist keine Zertifikate speichern, und ein gemeinsamer Schlüssel ist schwer zu rotieren |
| Gemischte Nutzung in einem Gebäude | Aufteilung nach Identität über separate VLANs | Eine SSID und eine Methode für alle | Mitarbeiter, Gäste und IoT-Geräte bergen unterschiedliche Risiken und sollten keine gemeinsamen Anmeldedaten nutzen |
Wer bei Passwörtern bleibt und wer nicht darf
Verwaltetes Personal und privilegierte Benutzer erhalten EAP-TLS auf einer WPA-Enterprise SSID. Reinigungspersonal, Rezeption und Betriebspersonal können sich mit Zertifikaten von einem MDM über SCEP authentifizieren, basierend auf ihrer Verzeichnisgruppe in einem VLAN landen und verlieren den Zugriff, wenn das Konto deaktiviert wird. Ein gemeinsam genutzter PSK oder ein PEAP-Passwort führt genau das wieder ein, was Sie eigentlich ablösen wollten.
Gäste und Besucher verbleiben auf einem Captive Portal oder Passpoint in einem Gäste-VLAN. Registrieren Sie keine Zertifikate an der Rezeption und nutzen Sie für diese kein PEAP. Es gibt keinen Lebenszyklus, den Sie verwalten werden, und es gibt ein Verzeichnis-Passwort, das Sie vor Phishing schützen müssen. Ein Passpoint-Profil kann sich beim nächsten Besuch ohne neues Ticket automatisch wieder verbinden.
Nicht verwaltete Laptops und externe Dienstleister können auf PEAP-MSCHAPv2 verbleiben - und zwar nur dann, wenn das Profil die Servervalidierung erzwingt. Wenn Sie diese nicht registrieren oder erneuern können, wird EAP-TLS sie aussperren. Wenn Sie die Serverüberprüfung nicht erzwingen können, überwiegt das Passwort-Risiko den Komfort, und sie sollten sich überhaupt nicht in der Mitarbeiter-SSID befinden.
Drucker, TVs, Kassen, EPOS, CCTV, Sensoren und Türsteuerungen erhalten einen iPSK pro Gerät und ein eigenes VLAN. Diese Geräte können in der Regel keine Zertifikate speichern. Ein gemeinsam genutztes PEAP-Passwort bringt das Problem geteilter Schlüssel zurück. PCI DSS v4.0.1 Req 2.3.2 verlangt, dass WLAN-Schlüssel geändert werden, sobald eine Person ausscheidet, die sie kennt - was bei einem gemeinsam genutzten Schlüssel unpraktisch ist. xPSK ist hierfür die passende Lösung. Zimmer-TVs, Thermostate und Kassen gehören in schlüsselgebundene VLANs, die für Gäste niemals sichtbar sind.
Beweisen Sie es an einem Standort
Wende das neue Design auf die Access Points an, die der Standort bereits hat, parallel zum heutigen Netzwerk. Beurteile es anhand von Tickets und Audit-Nachweisen, nicht anhand einer Demo-Anmeldung.
Fordern Sie ein Authentifizierungsprotokoll an, das jede Annahme und Ablehnung mit Identität, Gerät, MDM-Registrierungsstatus, Methode, Access Point, SSID, Standort, VLAN, Rolle, Grund und Uhrzeit aufzeichnet. Genau dasselbe Protokoll dient als Nachweis für die Zugriffs- und Protokollierungskontrollen nach ISO 27001 sowie für die PCI-DSS-Anforderungen 8 und 10. Schränken Sie ohne MDM zuerst die PEAP-Profile ein und planen Sie Zertifikate nur für die verwaltete Benutzergruppe.
Wir können diese Aufteilung als drei Netzwerke pro Objekt betreiben. Gäste nutzen das Portal, einschließlich eines PMS-Zimmerabgleichs, sofern das Objekt über ein solches verfügt. Mitarbeiter nutzen EAP-TLS oder Passpoint. Geräte nutzen gerätespezifische Schlüssel. Cloud RADIUS leitet jedes Gerät anhand seiner Identität in das richtige Netzwerk und VLAN und weist ausscheidende Personen ab, deren Konto deaktiviert ist. Der Migrationspfad weg von einem gemeinsam genutzten Mitarbeiter-Passwort entspricht dem in unserem Leitfaden beschriebenen Weg zur Umstellung von Multi-Site-Mitarbeiter-WiFi auf 802.1X.
Ich würde den Pilotversuch mit der SSID für verwaltete Mitarbeiter sowie den gerätespezifischen Schlüsseln für Kassen starten und externe Dienstleister auf einem validierten PEAP-Profil belassen, bis die Registrierung vollständig eingerichtet ist. Eine einzige Methode für alle sieht im Diagramm sauberer aus, schlägt im Alltag jedoch auf drei verschiedene Arten fehl.
Purple Access betreibt zertifikatsbasiertes Mitarbeiter-WiFi und gerätespezifische Schlüssel für Objekte auf den Access Points, die Sie bereits besitzen. So wird eap tls vs peap zu einer Entscheidung nach Benutzergruppe statt zu einem risikobehafteten Wagnis für die gesamte Infrastruktur. Sie können den offenen, sicheren und xPSK-Zugriff an einem einzelnen Standort testen und anschließend Tickets sowie das Authentifizierungsprotokoll auswerten, bevor Sie einen umfassenderen Rollout starten. Besuchen Sie Purple Access, um Ihre Mitarbeiter-, Gäste- und Gerätenetzwerke zu planen.
