Zum Hauptinhalt springen

EAP-TLS-Authentifizierung erklärt: Zertifikatsbasierte WiFi-Sicherheit

EAP-TLS ist der Goldstandard für die WiFi-Sicherheit in Unternehmen und ersetzt die anfällige passwortbasierte Authentifizierung durch robuste, gegenseitig authentifizierte digitale Zertifikate. Dieser Leitfaden bietet IT-Managern und Netzwerkarchitekten einen umfassenden technischen Einblick in den EAP-TLS-Handshake, die Architekturanforderungen und praktische Bereitstellungsstrategien für gemischte Geräteumgebungen.

📖 6 Min. Lesezeit📝 1,285 Wörter🔧 2 ausgearbeitete Beispiele3 Übungsfragen📚 8 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
Willkommen zum technischen Briefing von Purple. Ich bin Ihr Gastgeber, und heute tauchen wir tief in die EAP-TLS-Authentifizierung ein – den Goldstandard für zertifikatsbasierte WiFi-Sicherheit. Wenn Sie IT-Manager, Netzwerkarchitekt oder CTO sind und mit Unternehmensumgebungen wie Hotels, Einzelhandelsketten oder öffentlichen Einrichtungen zu tun haben, ist diese Session genau das Richtige für Sie. Wir werden behandeln, was EAP-TLS ist, wie es im Vergleich zu älteren Methoden wie PEAP abschneidet und was genau Sie benötigen, um es erfolgreich in einer gemischten Geräteflotte bereitzustellen. Beginnen wir mit dem Kontext. Warum sprechen wir gerade jetzt über EAP-TLS? Jahrelang verließen sich viele Organisationen auf PEAP-MSCHAPv2 – im Wesentlichen eine Authentifizierung über Benutzername und Passwort im WiFi. Doch in der heutigen Bedrohungslandschaft sind Passwörter eine enorme Schwachstelle. Sie können durch Phishing erlangt, geteilt oder gestohlen werden. Hier kommt EAP-TLS ins Spiel. EAP steht für Extensible Authentication Protocol und TLS für Transport Layer Security. Zusammen bilden sie ein Framework für gegenseitige Authentifizierung, das digitale X.509-Zertifikate anstelle von Passwörtern verwendet. Stellen Sie sich das wie eine digitale Passkontrolle vor. Der Netzwerkzugriffspunkt oder Authentifikator fragt das Gerät nach seiner ID. Das Gerät übergibt nicht einfach ein Passwort, sondern präsentiert ein kryptografisch signiertes Zertifikat. Entscheidend ist jedoch, dass dies gegenseitig geschieht. Auch der Server präsentiert dem Gerät sein Zertifikat. Beide Seiten verifizieren sich gegenseitig gegenüber einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority), bevor ein Netzwerkzugriff gewährt wird. Dies verhindert den Diebstahl von Anmeldedaten und macht Man-in-the-Middle-Angriffe praktisch unmöglich. Kommen wir nun zum technischen Deep-Dive. Wie funktioniert der Handshake eigentlich? Wenn ein Gerät, der sogenannte Supplicant, versucht, eine Verbindung herzustellen, blockiert der Access Point den gesamten Datenverkehr mit Ausnahme von EAP-Nachrichten. Der AP sendet einen EAP-Request/Identity. Das Gerät antwortet, und der AP leitet dies an den RADIUS-Server weiter. Der RADIUS-Server initiiert daraufhin einen TLS-Tunnel. Er sendet sein Serverzertifikat an das Gerät. Das Gerät validiert dieses Zertifikat. Wenn alles korrekt ist, sendet das Gerät sein eigenes Client-Zertifikat über den Tunnel zurück. Der RADIUS-Server validiert das Client-Zertifikat gegenüber der CA oder dem Identity Provider. Sobald beide Seiten zufrieden sind, ist der TLS-Handshake abgeschlossen, ein Master-Secret für die Verschlüsselung wird erstellt und der RADIUS-Server sendet eine Access-Accept-Nachricht. Der AP öffnet dann den Port und das Gerät ist im Netzwerk. Wie schneidet das nun im Vergleich zu PEAP ab? PEAP erfordert nur ein serverseitiges Zertifikat. Der Client verwendet weiterhin ein Passwort innerhalb des TLS-Tunnels. Dies macht PEAP anfangs einfacher bereitzustellen, insbesondere für unmanaged Geräte, lässt Sie jedoch anfällig für das Abgreifen von Anmeldedaten, wenn sich ein Benutzer mit einem gefälschten AP verbindet. EAP-TLS erfordert Zertifikate auf beiden Seiten. Ja, die Bereitstellung ist etwas komplexer, aber das Sicherheitsniveau ist unendlich viel höher. Aus diesem Grund ist EAP-TLS der empfohlene Standard für die PCI-DSS-Compliance im Einzelhandel und ISO 27001 in Unternehmensumgebungen. Sprechen wir über die Implementierung. Die Bereitstellung von EAP-TLS erfordert drei Hauptkomponenten: eine Public-Key-Infrastruktur (PKI) zur Ausstellung von Zertifikaten, einen RADIUS-Server zur Abwicklung der Authentifizierung und eine Mobile-Device-Management- (MDM) Plattform zur Verteilung der Zertifikate an Ihre Endpunkte. Wenn Sie eine Flotte von Firmen-Laptops und -Smartphones verwalten, ist Ihr MDM hier Ihr bester Freund. Sie konfigurieren ein Profil, das sowohl das Root-CA-Zertifikat als auch das individuelle Client-Zertifikat zusammen mit dem WiFi-Profil auf das Gerät pusht. Der Benutzer muss nichts tun. Er öffnet einfach seinen Laptop und verbindet sich sicher. Es gibt jedoch Fallstricke, die es zu vermeiden gilt. Der größte ist das Lifecycle-Management von Zertifikaten. Zertifikate laufen ab. Wenn Sie keinen automatisierten Erneuerungsprozess über Ihr MDM oder ein automatisiertes Registrierungsprotokoll wie SCEP oder EST haben, werden Sie einen schlechten Tag haben, wenn alle Ihre Geräte gleichzeitig die Verbindung zum Netzwerk verlieren. Ein weiteres häufiges Problem ist die gefürchtete „gemischte Geräteflotte“. Was tun Sie mit BYOD- oder Gastgeräten? Sie können Zertifikate nicht einfach auf nicht verwaltete Geräte pushen. Für Gäste nutzen Sie ein Captive Portal – wie die Guest WiFi-Lösung von Purple. Für BYOD-Mitarbeiter können Sie ein Onboarding-Portal nutzen, das vorübergehend ein Zertifikat bereitstellt, oder Sie halten sie auf einer separaten, weniger privilegierten SSID mit einer anderen Authentifizierungsmethode. Zeit für ein schnelles Q&A basierend auf häufigen Kundenfragen. Frage eins: Muss ich meine eigene On-Premise-CA aufbauen? Antwort: Nicht mehr. Cloud-PKI-Lösungen, die in Azure AD oder Okta integriert sind, sind viel einfacher zu verwalten und zu skalieren. Frage zwei: Beeinträchtigt EAP-TLS die Roaming-Leistung? Antwort: Der erste Handshake ist aufgrund des Zertifikatsaustauschs etwas schwerfälliger als bei PEAP, aber sobald die Verbindung hergestellt ist, wickeln schnelle Roaming-Protokolle wie 802.11r die AP-Übergänge nahtlos ab. Frage drei: Kann ich EAP-TLS für IoT-Geräte verwenden? Antwort: Ja, wenn das Gerät 802.1X und die Zertifikatsinstallation unterstützt. Viele ältere IoT-Geräte tun dies jedoch nicht, weshalb Sie für diese speziellen Geräte oft ein separates MAC-Auth-Bypass- oder Pre-Shared-Key-Netzwerk benötigen. Zusammenfassend lässt sich sagen: EAP-TLS ist der definitive Standard für sicheres Enterprise-WiFi. Es ersetzt anfällige Passwörter durch robuste, gegenseitig authentifizierte digitale Zertifikate. Während die Ersteinrichtung eine Abstimmung zwischen Ihrer PKI, RADIUS und MDM erfordert, sind die langfristigen Vorteile in Bezug auf Sicherheit, Compliance und Benutzererfahrung unbestreitbar. Es verhindert den Diebstahl von Anmeldedaten vollständig und bietet ein nahtloses Zero-Touch-Verbindungserlebnis für verwaltete Geräte. Vielen Dank, dass Sie an diesem technischen Briefing von Purple teilgenommen haben. Weitere Einblicke in die Sicherung Ihres Netzwerks und die Nutzung von WiFi-Analysen finden Sie in unserem Resource Center.

header_image.png

Executive Summary

Für Enterprise-Umgebungen, die von Unternehmenszentralen über Retail -Ketten bis hin zu Einrichtungen im Healthcare -Bereich reichen, ist die Absicherung des drahtlosen Zugangs nicht mehr nur eine betriebliche Anforderung – sie ist ein kritisches Compliance-Mandat. In der Vergangenheit haben sich Unternehmen auf PEAP-MSCHAPv2 verlassen, das einen Benutzernamen und ein Passwort innerhalb eines TLS-Tunnels sichert. In Zeiten von grassierendem Diebstahl von Zugangsdaten und hochentwickelten Phishing-Angriffen stellt die passwortbasierte Authentifizierung über WiFi jedoch eine erhebliche Schwachstelle dar.

Hier kommt EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) ins Spiel. EAP-TLS stellt den Goldstandard bei der 802.1X-Netzwerkzugriffskontrolle dar. Anstatt sich auf benutzergenerierte Passwörter zu verlassen, schreibt EAP-TLS eine gegenseitige Authentifizierung mittels digitaler X.509-Zertifikate vor. Sowohl das Client-Gerät als auch der Authentifizierungsserver müssen ihre Identität nachweisen, bevor ein Netzwerkzugriff gewährt wird. Dieser Ansatz eliminiert das Risiko des Diebstahls von Zugangsdaten, mindert Man-in-the-Middle-Angriffe (MitM) und bietet ein nahtloses, berührungsloses Verbindungserlebnis für verwaltete Geräte. Dieser technische Leitfaden untersucht die Funktionsweise des EAP-TLS-Handshakes, vergleicht ihn mit älteren Methoden und skizziert eine praktische Bereitstellungsarchitektur für moderne Unternehmen.

Hören Sie sich unseren begleitenden Podcast zum technischen Briefing für einen Überblick auf Führungsebene an:

Technischer Deep-Dive

Der EAP-TLS-Handshake erklärt

Der grundlegende Vorteil von EAP-TLS liegt in seiner kryptografischen Strenge. Der Authentifizierungsprozess ist ein mehrstufiger Dialog zwischen dem Supplicant (dem Client-Gerät), dem Authenticator (dem WiFi Access Point oder Switch) und dem Authentifizierungsserver (in der Regel ein RADIUS-Server).

eap_tls_handshake_diagram.png

  1. Initialisierung: Wenn ein Gerät versucht, eine Verbindung mit der SSID herzustellen, blockiert der Access Point den gesamten Datenverkehr mit Ausnahme von EAP-over-LAN-Frames (EAPoL). Der AP sendet ein EAP-Request/Identity an das Gerät.
  2. Identitätsantwort: Das Gerät antwortet mit einer EAP-Response/Identity (oft eine anonyme äußere Identität zum Schutz der Privatsphäre), die der AP an den RADIUS-Server weiterleitet.
  3. Aufbau des TLS-Tunnels: Der RADIUS-Server initiiert den TLS-Handshake, indem er ein TLS ServerHello zusammen mit seinem eigenen digitalen Zertifikat sendet.
  4. Server-Validierung: Das Client-Gerät überprüft das Zertifikat des Servers. Es prüft die Gültigkeitsdaten, den Subject Alternative Name (SAN) und verifiziert vor allem, ob das Zertifikat von einer vertrauenswürdigen Root Certificate Authority (CA) signiert wurde, die in seinem lokalen Trust Store installiert ist.
  5. Präsentation des Client-Zertifikats: Sobald der Server validiert ist, sendet das Client-Gerät sein eigenes X.509-Zertifikat (und optional seine Zertifikatskette) zurück an den RADIUS-Server.
  6. Gegenseitige Authentifizierung: Der RADIUS-Server validiert das Zertifikat des Clients anhand seiner CA- oder Identity Provider (IdP)-Integration. Er prüft auf Sperrung (via CRL oder OCSP) und verifiziert die Identität des Benutzers oder Geräts.
  7. Schlüsselableitung: Nach erfolgreicher gegenseitiger Validierung wird der TLS-Handshake abgeschlossen. Beide Seiten leiten unabhängig voneinander einen Master Session Key (MSK) ab.
  8. Netzwerkzugriff: Der RADIUS-Server sendet eine RADIUS Access-Accept-Nachricht an den AP, die den MSK enthält. Der AP verwendet diesen Schlüssel, um die endgültigen WPA2/WPA3-Verschlüsselungsschlüssel (PTK/GTK) mit dem Client zu etablieren, und öffnet den Netzwerkport für den Standard-IP-Verkehr.

EAP-TLS vs. PEAP-MSCHAPv2

Das Verständnis des Unterschieds zwischen EAP-TLS und PEAP ist für Netzwerkarchitekten, die eine Migration planen, von entscheidender Bedeutung.

eap_tls_vs_peap_comparison.png

Während PEAP einen sicheren TLS-Tunnel aufbaut (serverseitige Authentifizierung), basiert die innere Authentifizierung immer noch auf MSCHAPv2, einem passwortbasierten Protokoll. Wenn sich ein Benutzer mit einem bösartigen "Evil Twin" Access Point verbindet und die Warnung zum Serverzertifikat ignoriert, kann sein gehashtes Passwort abgefangen und offline geknackt werden. EAP-TLS eliminiert diesen Vektor vollständig; ohne den privaten Schlüssel, der zum Client-Zertifikat gehört, kann sich ein Angreifer nicht authentifizieren, selbst wenn er das Passwort des Benutzers besitzt.

Implementierungsleitfaden

Die Bereitstellung von EAP-TLS erfordert die Orchestrierung über drei primäre Infrastruktursäulen hinweg: die Netzwerkschicht, die Authentifizierungsschicht und die Identitäts-/Endpoint-Management-Schicht.

eap_tls_deployment_architecture.png

1. Public Key Infrastructure (PKI)

Sie benötigen einen Mechanismus zur Ausstellung und Verwaltung von X.509-Zertifikaten. In der Vergangenheit bedeutete dies die Bereitstellung einer On-Premise-Umgebung für Microsoft Active Directory Certificate Services (AD CS). Heutzutage nutzen moderne Architekturen Cloud-PKI-Lösungen, die in Identity Provider (IdPs) wie Azure AD, Okta oder Google Workspace integriert sind. Diese Cloud-nativen CAs vereinfachen den Ausstellungs- und Sperrungs-Lebenszyklus.

2. RADIUS-Authentifizierungsserver

Der RADIUS-Server (z. B. FreeRADIUS, Cisco ISE, Aruba ClearPass oder ein Cloud-basierter RADIUS) muss so konfiguriert sein, dass er EAP-TLS unterstützt. Er benötigt sein eigenes Serverzertifikat, das von einer CA signiert ist, der alle Client-Geräte vertrauen. Wenn Sie eine Integration mit einem modernen IdP durchführen, finden Sie unseren Leitfaden zu Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication besonders nützlich, um Cloud-Identitäten mit lokaler Netzwerkhardware zu verknüpfen.

3. Mobile Device Management (MDM)

Die größte Hürde bei der EAP-TLS-Bereitstellung ist die Bereitstellung von Zertifikaten auf Client-Geräten. Eine manuelle Installation ist nicht skalierbar. Sie müssen eine MDM-Plattform (wie Microsoft Intune, Jamf Pro oder VMware Workspace ONE) nutzen, um diesen Prozess zu automatisieren. Das MDM-Profil muss Folgendes bereitstellen:

  • Das Root-CA-Zertifikat (um dem RADIUS-Server zu vertrauen).
  • Das individuelle Client-Zertifikat (häufig über SCEP- oder EST-Protokolle generiert).
  • Das WiFi-Profil, das für die Verwendung von WPA2/WPA3-Enterprise und EAP-TLS konfiguriert ist und sich speziell auf die bereitgestellten Zertifikate bezieht.

Best Practices

  1. Zertifikats-Lifecycle-Management automatisieren: Zertifikate laufen ab. Wenn Sie keinen automatisierten Erneuerungsmechanismus (wie SCEP/EST über MDM) haben, verlieren Geräte geräuschlos die Verbindung zum Netzwerk, sobald ihre Zertifikate ablaufen, was zu einem massiven Anstieg von Support-Tickets führt. Legen Sie Gültigkeitszeiträume fest, die ein ausgewogenes Verhältnis zwischen Sicherheit (z. B. 1 Jahr) und operativem Aufwand bieten.
  2. Strikte Server-Validierung erzwingen: Konfigurieren Sie Client-WiFi-Profile so, dass sie das Zertifikat des RADIUS-Servers strikt validieren. Geben Sie die genauen Servernamen und vertrauenswürdigen Root-CAs im Profil an. Erlauben Sie Benutzern nicht, Zertifikatswarnungen zu umgehen.
  3. Robuste Sperrung implementieren: Stellen Sie sicher, dass Ihr RADIUS-Server Zertifikatssperrlisten (CRLs) prüft oder das Online Certificate Status Protocol (OCSP) verwendet. Wenn ein Mitarbeiter das Unternehmen verlässt oder ein Gerät verloren geht, muss der Netzwerkzugriff durch den Widerruf des Zertifikats sofort beendet werden.
  4. Umgang mit gemischten Geräteflotten: EAP-TLS ist perfekt für verwaltete Unternehmensgeräte. Sie werden jedoch auf unverwaltete BYOD- (Bring Your Own Device) und Gastgeräte stoßen. Stellen Sie für Gäste eine robuste Captive Portal-Lösung wie das Guest WiFi von Purple bereit. Ziehen Sie für BYOD-Geräte von Mitarbeitern ein Onboarding-Portal in Betracht, das vorübergehend ein Zertifikat bereitstellt, oder nutzen Sie eine separate SSID mit einer anderen Authentifizierungsmethode, die vom Kernnetzwerk des Unternehmens isoliert ist.

Fehlerbehebung & Risikominimierung

Wenn EAP-TLS fehlschlägt, sind die Symptome für den Endbenutzer oft unklar. Das Gerät stellt einfach keine Verbindung her. IT-Teams müssen sich bei der Diagnose auf RADIUS-Protokolle verlassen.

  • Fehler: "Unknown CA" oder "Untrusted Root": Das Client-Gerät hat das Root-CA-Zertifikat, das das Zertifikat des RADIUS-Servers signiert hat, nicht in seinem Vertrauensspeicher. Überprüfen Sie die MDM-Payload.
  • Fehler: "Certificate Expired": Entweder das Client-Zertifikat oder das Server-Zertifikat hat sein NotAfter-Datum überschritten. Überprüfen Sie die Automatisierung des Zertifikats-Lifecycles.
  • Fehler: "Client Certificate Not Found": Das Gerät versucht eine EAP-TLS-Verbindung, kann jedoch kein gültiges Zertifikat finden, das den im WiFi-Profil angegebenen Kriterien entspricht. Stellen Sie sicher, dass das Zertifikat erfolgreich vom MDM bereitgestellt wurde und dass der Subject Alternative Name (SAN) dem erwarteten Format entspricht (z. B. User Principal Name oder MAC-Adresse).
  • Uhrzeit-Abweichung (Clock Skew): TLS ist auf eine genaue Zeiterfassung angewiesen. Wenn die Systemzeit eines Geräts erheblich asynchron zum RADIUS-Server läuft, schlägt die Zertifikatsprüfung fehl, da die Zertifikate als "noch nicht gültig" oder "abgelaufen" eingestuft werden.

ROI & geschäftlicher Nutzen

Der Übergang zu EAP-TLS stellt eine erhebliche Weiterentwicklung der Sicherheitsstruktur eines Unternehmens dar. Der primäre Return on Investment (ROI) liegt in der Risikominimierung. Durch den Verzicht auf passwortbasierte WiFi-Authentifizierung reduzieren Sie die Angriffsfläche für den Diebstahl von Anmeldedaten und laterale Bewegungen innerhalb des Netzwerks drastisch. Dies ist besonders kritisch im Bereich Hospitality und in Unternehmensumgebungen, in denen die Netzwerksegmentierung von entscheidender Bedeutung ist.

Darüber hinaus verbessert EAP-TLS die Benutzererfahrung. Nach der Bereitstellung über das MDM erfolgt die Verbindung völlig berührungslos (Zero-Touch). Benutzer müssen ihre WiFi-Passwörter nie aktualisieren, wenn ihr Unternehmenspasswort abläuft, was die Anzahl der Support-Anfragen im Zusammenhang mit Verbindungsproblemen reduziert. Durch die Kombination von EAP-TLS für verwaltete Mitarbeitergeräte mit intelligenten WiFi Analytics und Captive Portals für Gäste können Veranstaltungsorte eine sichere, leistungsstarke drahtlose Umgebung schaffen, die sowohl die Betriebssicherheit als auch die Kundenbindung unterstützt.

Schlüsseldefinitionen

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Eine 802.1X-Authentifizierungsmethode, die eine gegenseitige Authentifizierung mithilfe digitaler Zertifikate sowohl auf dem Client als auch auf dem Server erfordert, wodurch Passwörter überflüssig werden.

Der sicherste Standard für die WiFi-Authentifizierung in Unternehmen, der in Hochsicherheitsumgebungen für die Compliance weitgehend vorgeschrieben ist.

Supplicant

Das Client-Gerät (Laptop, Smartphone, Tablet), das versucht, eine Verbindung mit dem sicheren Netzwerk herzustellen.

Die Supplicant-Software muss EAP-TLS unterstützen und Zugriff auf den Zertifikatsspeicher des Geräts haben.

Authenticator

Das Netzwerkgerät (in der Regel ein WiFi Access Point oder Netzwerk-Switch), das den Authentifizierungsprozess erleichtert, indem es EAP-Nachrichten zwischen dem Supplicant und dem Authentifizierungsserver weiterleitet.

Der AP führt die Authentifizierung nicht selbst durch; er fungiert als Gatekeeper, bis der RADIUS-Server ein Access-Accept ausgibt.

RADIUS-Server

Remote Authentication Dial-In User Service. Der zentrale Server, der die Anmeldedaten (im Fall von EAP-TLS Zertifikate) validiert und den Netzwerkzugriff autorisiert.

Der RADIUS-Server lässt sich in die PKI oder den Identity Provider integrieren, um die Gültigkeit und den Widerrufsstatus des Client-Zertifikats zu überprüfen.

PKI (Public Key Infrastructure)

Das System aus Rollen, Richtlinien, Hardware, Software und Verfahren, das zur Erstellung, Verwaltung, Verteilung, Nutzung, Speicherung und zum Widerruf digitaler Zertifikate erforderlich ist.

Sie benötigen eine PKI (entweder lokal oder Cloud-basiert), um die für EAP-TLS erforderlichen Zertifikate auszustellen.

X.509-Zertifikat

Ein Standardformat für Public-Key-Zertifikate – digitale Dokumente, die kryptografische Schlüsselpaare sicher mit Identitäten wie Websites, Personen oder Organisationen verknüpfen.

Dies ist der „digitale Reisepass“, der bei EAP-TLS anstelle eines Passworts verwendet wird.

SCEP / EST

Simple Certificate Enrollment Protocol / Enrollment over Secure Transport. Protokolle, die von MDM-Plattformen verwendet werden, um die Anforderung und Installation von Zertifikaten auf Client-Geräten zu automatisieren.

Entscheidend für die Skalierung von EAP-TLS-Bereitstellungen, um sicherzustellen, dass Geräte Zertifikate ohne Benutzereingriff erhalten und erneuern.

Evil Twin Attack

Ein betrügerischer WiFi Access Point, der sich als legitimes Unternehmensnetzwerk ausgibt, um die drahtlose Kommunikation abzuhören oder Anmeldedaten abzugreifen.

EAP-TLS verhindert Evil Twin Attacks, da der betrügerische AP kein gültiges Serverzertifikat vorlegen kann, das von der vertrauenswürdigen Root-CA des Unternehmens signiert ist.

Ausgearbeitete Beispiele

Eine große [Einzelhandelskette](/industries/retail) mit 500 Standorten muss den WiFi-Zugang für ihre vom Unternehmen bereitgestellten Point-of-Sale-Tablets (POS) sichern. Derzeit verwenden sie einen einzigen Pre-Shared Key (PSK) in allen Filialen, der vor Kurzem durchgesickert ist. Sie nutzen Microsoft Intune für die Geräteverwaltung. Wie sollten sie das Netzwerk sichern?

  1. Bereitstellen einer Cloud-PKI, die in ihre Azure AD-Umgebung integriert ist.
  2. Konfigurieren von Intune zur Verwendung von SCEP (Simple Certificate Enrollment Protocol), um automatisch eindeutige Gerätezertifikate zu generieren und auf jedes POS-Tablet zu übertragen.
  3. Übertragen eines neuen WiFi-Profils via Intune, das für WPA3-Enterprise und EAP-TLS konfiguriert ist, unter Angabe des neuen Client-Zertifikats und der vertrauenswürdigen Root-CA.
  4. Konfigurieren des zentralen RADIUS-Servers zur Authentifizierung der Tablets auf Basis dieser Zertifikate.
  5. Sobald sich alle Tablets erfolgreich über EAP-TLS authentifizieren, Deaktivieren der alten PSK-SSID.
Kommentar des Prüfers: Dies ist der optimale Ansatz für verwaltete Geräte. Der Wechsel von einem globalen PSK zu EAP-TLS eliminiert das Risiko, dass ein einziges durchgesickertes Passwort das gesamte Netzwerk gefährdet. Die Verwendung von SCEP über Intune gewährleistet eine Zero-Touch-Bereitstellung, was für die Skalierung über 500 Standorte hinweg ohne manuelles Eingreifen der IT vor Ort unerlässlich ist.

Ein [Transportknotenpunkt](/industries/transport) (Flughafen) möchte sicheres WiFi für sein Betriebspersonal (Gepäckabfertiger, Sicherheitsdienst) über verwaltete iPads bereitstellen, während der Gastdatenverkehr vollständig getrennt bleiben soll.

  1. Implementieren von EAP-TLS auf einer dedizierten, versteckten SSID (z. B. 'Airport-Ops-Secure') für die verwalteten iPads, wobei Zertifikate über deren MDM-Plattform übertragen werden.
  2. Sicherstellen, dass der RADIUS-Server diese authentifizierten Geräte einem spezifischen, eingeschränkten VLAN zuweist, das nur Zugriff auf die erforderlichen Betriebsserver hat.
  3. Bereitstellen einer separaten, offenen SSID (z. B. 'Airport-Free-WiFi') für Passagiere unter Verwendung eines Captive Portal zur Akzeptanz der Nutzungsbedingungen und zur Bandbreitenbegrenzung.
Kommentar des Prüfers: Dies demonstriert eine ordnungsgemäße Netzwerksegmentierung. EAP-TLS bietet eine starke Authentifizierung für die kritischen Betriebsgeräte, während das Gastnetzwerk völlig separat gehalten wird. Die Verwendung einer versteckten SSID für den Betrieb fügt eine kleine Ebene der Unkenntlichkeit hinzu, aber die tatsächliche Sicherheit beruht auf den kryptografischen Zertifikaten.

Übungsfragen

Q1. Ihr Unternehmen migriert von PEAP zu EAP-TLS. Während der Pilotphase schlägt die Verbindung bei mehreren Windows-Laptops fehl. Die RADIUS-Protokolle zeigen während des TLS-Handshakes den Fehler "Unknown CA" an. Was ist die wahrscheinlichste Ursache?

Hinweis: Denken Sie an den Aspekt der gegenseitigen Authentifizierung (Mutual Authentication). Was benötigt der Client, um dem Server zu vertrauen?

Musterlösung anzeigen

Den Client-Geräten fehlt das Root-CA-Zertifikat in ihrem lokalen Vertrauensspeicher, das das Zertifikat des RADIUS-Servers signiert hat. Die MDM-Payload muss aktualisiert werden, um sicherzustellen, dass die Root-CA zusammen mit dem Client-Zertifikat auf die Geräte übertragen wird.

Q2. Ein Hotel möchte EAP-TLS für alle Geräte, einschließlich der Smartphones von Gästen, nutzen, um maximale Sicherheit zu gewährleisten. Ist dies eine tragfähige Strategie?

Hinweis: Berücksichtigen Sie den Bereitstellungsprozess für EAP-TLS.

Musterlösung anzeigen

Nein, das ist keine tragfähige Strategie. EAP-TLS erfordert die Installation von Client-Zertifikaten auf dem Gerät. Während dies für verwaltete Unternehmensgeräte über ein MDM einfach ist, können Sie Gäste nicht dazu zwingen, Zertifikate oder MDM-Profile auf ihren persönlichen Geräten zu installieren. Für Gäste ist ein Captive Portal (wie Purple Guest WiFi) in Kombination mit WPA2/WPA3-Personal (oder OWE) der Branchenstandard.

Q3. Sie haben EAP-TLS erfolgreich implementiert. Ein Mitarbeiter meldet, dass sein Firmen-Laptop gestohlen wurde. Welche sofortige technische Maßnahme ist erforderlich, um das Netzwerk zu sichern?

Hinweis: Wie erklären Sie ein digitales Zertifikat vor Ablauf seines Gültigkeitsdatums für ungültig?

Musterlösung anzeigen

Sie müssen das mit diesem spezifischen Laptop verknüpfte Client-Zertifikat innerhalb Ihrer PKI/CA widerrufen. Stellen Sie sicher, dass Ihr RADIUS-Server so konfiguriert ist, dass er die Zertifikatssperrliste (CRL) überprüft oder OCSP verwendet, damit das widerrufene Zertifikat beim nächsten Verbindungsversuch sofort abgelehnt wird.

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.

Leitfaden lesen →

Captive Portal Authentifizierungsmethoden im Vergleich

Dieser maßgebliche technische Leitfaden bewertet die architektonischen, betrieblichen und Compliance-bezogenen Vor- und Nachteile von fünf zentralen Captive Portal Authentifizierungsmethoden. Er bietet Netzwerkarchitekten, IT-Leitern und Marketingmanagern die quantitativen Daten und Entscheidungsrahmen, die erforderlich sind, um die Reibung beim Onboarding von Gästen mit den Anforderungen an die Datenerfassung in Unternehmensstandorten abzuwägen.

Leitfaden lesen →

Was ist MAC-Adressen-Authentifizierung? Wann man sie einsetzt und wann man sie vermeidet

Dieser maßgebliche technische Leitfaden behandelt die MAC-Adressen-Authentifizierung in Enterprise-WiFi-Umgebungen – wie die RADIUS-basierte MAC-Authentifizierung auf Layer 2 funktioniert, ihre inhärenten Sicherheitsrisiken (einschließlich MAC-Spoofing und den Auswirkungen der MAC-Randomisierung auf Betriebssystemebene) und die genauen betrieblichen Kontexte, in denen sie ein legitimes Tool zur Verwaltung von IoT- und Headless-Geräten bleibt. Er bietet praxisnahe Bereitstellungsrichtlinien für IT-Manager und Netzwerkarchitekten in den Bereichen Hotellerie, Einzelhandel, Gesundheitswesen und im öffentlichen Sektor, ergänzt durch praxisnahe Fallbeispiele, Entscheidungsmatrizen und Integrationskontexte für die Guest-WiFi- und Analytics-Plattform von Purple.

Leitfaden lesen →