Zertifikatsbasierte WiFi-Authentifizierung: Leitfaden zu EAP-TLS
Published
Jemand verlässt das Unternehmen und Ihr Team entscheidet, ob das Passwort für das Mitarbeiter-WiFi-WiFi erneut geändert werden soll. Die Änderung bedeutet, dass Laptops, Telefone, Empfangstablets und Geräte neu verbunden werden müssen, an deren Konfiguration sich niemand mehr erinnert. Das Passwort beizubehalten bedeutet zu akzeptieren, dass jemand außerhalb der Organisation weiterhin weiß, wie er sich verbinden kann.
Zertifikatsbasierte WiFi-Authentifizierung bietet Ihnen eine bessere Möglichkeit, vertrauenswürdige Geräte zu identifizieren. Sie ändert jedoch auch die Aufgaben Ihres Teams: Anstatt Passwörter zu verteilen, verwalten Sie Vertrauensketten, Zertifikatsverlängerungen, Sperrungen und Geräte, die monatelang im Lager verschwinden. Die Sicherheitsverbesserung ist real. Für einen zuverlässigen Betrieb reicht es nicht aus, einfach EAP-TLS in einem WLAN-Profil auszuwählen.
Inhaltsverzeichnis
- Bedeutung der zertifikatbasierten WiFi Authentifizierung
- Funktionsweise des EAP-TLS Handshakes Schritt für Schritt
- Vergleich von Zertifikaten mit geteilten Passwörtern und PEAP
- Aufbau der CA und Bereitstellung von Zertifikaten über MDM
- Verwaltung des Zertifikatslebenszyklus von der Ausstellung bis zur Erneuerung
- Entzug des Zugriffs bei Geräteverlust oder Ausscheiden von Personen
- Geräteberechtigung und Ausnahmenplanung
- Bestätigung Ihres Zertifikatsplans vor dem Rollout
Was zertifikatsbasierte WiFi-Authentifizierung bedeutet
Zertifikatsbasierte WiFi-Authentifizierung ersetzt ein gemeinsam genutztes WiFi-Passwort durch ein individuelles digitales Zertifikat, das vom Netzwerk vor der Gewährung des Zugriffs überprüft wird. Vergleichen Sie es mit einem gemeinsamen Türcode für ein Büro im Gegensatz zu einem Mitarbeiterausweis. Mit dem Code beweist jeder, dass er dasselbe Geheimnis kennt. Mit einem Ausweis kann der Sicherheitsdienst einen bestimmten Ausweis identifizieren und diesen unabhängig von anderen sperren.
Angenommen, ein verwalteter Laptop benötigt Zugriff auf das Mitarbeiter-Netzwerk. Sein Zertifikat identifiziert das Gerät oder seinen zugewiesenen Benutzer, und sein geschützter privater Schlüssel ermöglicht den Nachweis, dass es über diese Anmeldedaten verfügt. Das Zertifikat selbst ist kein geheimes Passwort, und das reine Kopieren des öffentlichen Zertifikats stellt nicht den entsprechenden privaten Schlüssel bereit.
Das Diagramm zeigt, wie individuelle Anmeldeinformationen das gemeinsame Passwort ersetzen.
Wo die Komponenten hineinpassen
Das zugrundeliegende Framework ist IEEE 802.1X, das ursprünglich für kabelgebundenes Ethernet entwickelt und für WLANs angepasst wurde. Die Übersicht von Microsoft zur Authentifizierung nach IEEE 802.1X beschreibt das Framework und die Rolle der zentralen Authentifizierung über RADIUS.
Der Access Point steuert den Zugang, während der Dienst RADIUS die Authentifizierungsanfrage auswertet. EAP-TLS ist die zertifikatsbasierte Authentifizierungsmethode, die über diese Anordnung ausgeführt wird. Das Gerät und der Authentifizierungsserver validieren sich gegenseitig, bevor Schlüsselmaterial für die Verbindung erstellt wird.
Halten Sie diese Komponenten voneinander getrennt:
- Gerätezertifikat: Identifiziert den Endpunkt oder Benutzer und funktioniert mit einem privaten Schlüssel, der sich auf dem Gerät befindet.
- Authentifizierungsserver-Zertifikat: Ermöglicht dem Gerät zu überprüfen, ob es mit einem zugelassenen Authentifizierungsdienst kommuniziert.
- Zertifizierungsstelle: Stellt Zertifikate aus, die jede Seite über eine explizit vertrauenswürdige Zertifikatskette validieren kann.
Das Gerät und der Server benötigen nicht zwingend Zertifikate von derselben Ausstellungsstelle. Wichtig ist, dass jede Seite der entsprechenden Ausstellungsstelle vertraut und die richtige Validierungsrichtlinie anwendet.
Praktische Regel: Betrachten Sie Zertifikate als ein Netzwerkidentitätssystem, nicht als komplizierte Passwörter.
Dieser Unterschied ändert die Art und Weise, wie Sie mit einem verlorenen Laptop umgehen. Sie können dessen Anmeldedaten widerrufen, ohne die Anmeldedaten auf den Geräten aller anderen Personen zu ersetzen. Der Besitz eines gültigen Zertifikats stellt jedoch eine Identität fest, keine unbegrenzte Berechtigung. Ihre Zugriffsrichtlinie muss weiterhin entscheiden, was diese Identität erreichen darf.
Wie der EAP-TLS-Handshake Schritt für Schritt funktioniert
Eine Verbindung umfasst den Supplicant des Geräts, den Access Point als Authentifikator und den Authentifizierungsserver. Der Supplicant ist die Betriebssystemkomponente, welche die Netzwerkauthentifizierung für Unternehmen verarbeitet.
Dieser vereinfachte Ablauf zeigt die wesentlichen Übergaben anstelle jeder einzelnen Protokollnachricht.
Nachverfolgung des Austauschs und seiner Fehlerquellen
Die gegenseitige Authentifizierung und Schlüsselableitung, die diesem Austausch zugrunde liegen, sind in der EAP-TLS-Spezifikation, RFC 5216, definiert.
Das Gerät verbindet sich mit dem Access Point. Es startet den Enterprise-Authentifizierungsaustausch und übermittelt eine Identität. Die Zuordnung allein gewährt noch keinen normalen Netzwerkzugriff. Eine falsche WiFi-Sicherheitseinstellung kann verhindern, dass das Gerät die Zertifikatsauthentifizierung überhaupt erreicht.
Der Access Point leitet EAP-Nachrichten an RADIUS weiter. Er leitet den Austausch zwischen dem Endgerät und dem Authentifizierungsdienst weiter, anstatt das Gerätezertifikat selbst auszustellen. Ein Verbindungsproblem mit RADIUS oder ein falsch registrierter Access Point kann den Austausch an dieser Stelle stoppen.
Der Server präsentiert sein Zertifikat. Das Gerät prüft die Zertifikatskette, die Gültigkeit und die erwartete Serveridentität. Ein nicht vertrauenswürdiger Aussteller, eine unvollständige Kette oder ein unerwarteter Servername sollten dazu führen, dass das Gerät die Verbindung verweigert.
Das Gerät legt sein Client-Zertifikat vor. Der Server validiert den Nachweis, prüft die maßgeblichen Sperrinformationen und wertet die Identität aus. Ein fehlendes Zertifikat oder ein nicht zugänglicher privater Schlüssel kann für den Benutzer wie ein allgemeiner Verbindungsfehler aussehen, selbst wenn die Serverprotokolle eine spezifische Ursache zeigen.
Der TLS-Austausch richtet gemeinsames Schlüsselmaterial ein. Das Endgerät muss den Besitz seines privaten Schlüssels nachweisen und nicht nur eine Zertifikatsdatei vorlegen. Inkompatible Kryptografie-Einstellungen können den Abschluss verhindern, selbst wenn beide Zertifikate ansonsten gültig sind.
RADIUS gibt das Authentifizierungsergebnis und die Richtlinienattribute zurück. Eine Akzeptanz kann eine VLAN-Zuweisung oder andere unterstützte Autorisierungsattribute enthalten. Eine erfolgreiche Authentifizierung gefolgt von einer nicht nutzbaren Verbindung kann eher auf ein VLAN- oder nachgelagertes Richtlinienproblem als auf ein Zertifikatsproblem hinweisen.
Konfigurieren Sie den Client für die Überprüfung des Servers
Wählen Sie im Supplicant-Profil explizit EAP-TLS aus, konfigurieren Sie die vertrauenswürdige CA und geben Sie die erwarteten RADIUS-Servernamen an. Lassen Sie die Serverzertifikat-Validierung aktiviert. Erlauben Sie Benutzern nicht, eine Warnung zu umgehen, nur um online zu gehen.
Verwenden Sie dieses Video zusammen mit dem Protokollablauf, wenn Sie den Austausch mit Ihrem Team besprechen.
Jede Verbindung hängt davon ab, dass zum Authentifizierungszeitpunkt Anmeldezeichen vorhanden, zugänglich und akzeptabel sind. Die Fehlerbehebung erfordert daher Nachweise sowohl vom Supplicant als auch vom RADIUS und nicht nur ein Access-Point-Dashboard, das anzeigt, dass die Verbindung eines Clients fehlgeschlagen ist.
Zertifikate im Vergleich zu gemeinsam genutzten Passwörtern und PEAP
WiFi-Authentifizierungsmethoden nach denselben Kriterien
| Methode | Anmeldeinformationen auf dem Gerät | Sperrbereich | Zurechenbarkeit | Einrichtungsaufwand |
|---|---|---|---|---|
| Gemeinsame WPA2- oder WPA3-Personal-Passphrase | Eine Passphrase, die jedem Benutzer bekannt ist | Ändert den Schlüssel für alle | Keine über die gemeinsam genutzte Anmeldeinformation selbst | Niedrig |
| WPA2-Enterprise mit PEAP-MSCHAPv2 | Benutzername und Passwort pro Benutzer | Deaktiviert ein Konto | Pro Benutzer | Mittel |
| EAP-TLS auf WPA2 oder WPA3-Enterprise | Eindeutiges Client-Zertifikat und privater Schlüssel pro Gerät | Sperrt ein Zertifikat | Pro Gerät und Benutzer bei Zuordnung | Hoch, erfordert PKI und verwaltetes Provisioning |
| WPA3-Enterprise 192-Bit mit EAP-TLS | Zertifikat, das den kryptografischen Anforderungen des Profils entspricht | Sperrt ein Zertifikat | Pro Gerät und Benutzer bei Zuordnung | Hoch, zzgl. Prüfungen der Chiffren-Kompatibilität |
EAP-TLS ist nicht synonym mit WPA3. Der Wi-Fi Alliance-Zertifizierungsnachweis identifiziert EAP-TLS unter den unterstützten Enterprise-Authentifizierungsmethoden. Die Zertifikatsauthentifizierung ist eine Option für die Enterprise-Authentifizierung, während das WPA-Profil auch die Anforderungen an die Drahtlossicherheit festlegt.
Vergleichen Sie die Anmeldedaten, nicht nur die Bezeichnung
Eine gemeinsam genutzte Passphrase beweist das Wissen über ein gemeinsames Geheimnis. Sie legt nicht fest, welcher Mitarbeiter sie eingegeben hat, obwohl Netzwerkgeräte dennoch Verbindungsdetails aufzeichnen können. Das Ausscheiden von Mitarbeitern wird problematisch, da das Ersetzen des Zugangsdatums bedeutet, dass jedes Gerät, das es verwendet, aktualisiert werden muss.
PEAP-MSCHAPv2 wechselt zu individuellen Benutzernamen und Passwörtern. Es verwendet einen server-authentifizierten TLS-Tunnel, um den inneren Authentifizierungsaustausch zu schützen, sodass die ordnungsgemäße Server-Validierung weiterhin wichtig ist. Es kann nützliche benutzerbezogene Datensätze bereitstellen, aber Passwortänderungen und Kontoprobleme bleiben Bestandteil des WLAN-Supports.
Bei EAP-TLS verwendet der Endpunkt während der Authentifizierung sein Zertifikat und seinen privaten Schlüssel anstelle eines Kontopassworts. Dadurch erhalten Administratoren ein gerätespezifisches Anmeldezeichen zur Verwaltung, sofern das Inventar Zertifikate den Endpunkten und Eigentümern korrekt zuordnet.
Wählen Sie die Methode, deren Anmeldedaten-Lebenszyklus Ihr Team tatsächlich verwalten kann - nicht einfach die stärkste Bezeichnung im Controller-Menü.
Stimmen Sie die Methode auf die Zielgruppe ab
Gemeinsam genutzte Passphrasen sind eine schlechte Standardlösung für den verwalteten Mitarbeiterzugriff, wenn es auf individuelle Entzusammenhänge und Rechenschaftspflicht ankommt. Selbst für Gäste und Geräte mit geringem Risiko erfordert ein allgemeines Passwort eine gezielte Verteilungs- und Ersetzungsrichtlinie.
Zertifikate eignen sich für verwaltete Laptops und Telefone, da Sie diese über ein vorhandenes Verwaltungssystem bereitstellen können. Das Enterprise-Profil mit höherer Sicherheit bringt zwar zusätzliche Kompatibilitätsarbeit mit sich, entbindet jedoch nicht von Aufgaben im Lebenszyklusmanagement. PEAP kann eine Migrationsoption bleiben, wenn individuelle Konten vorhanden sind, die Zertifikatsbereitstellung jedoch noch nicht bereit ist, anstatt ein Grund zu sein, ein identitätsbasiertes Zugriffskonzept auf unbestimmte Zeit zu verschieben.
Aufbau der CA und Bereitstellung von Zertifikaten über MDM
Eine verwaltbare Bereitstellung beginnt mit einer Public-Key-Infrastruktur (PKI), deren Zuständigkeit klar geregelt ist. Eine übliche Hierarchie hält eine Root-Zertifizierungsstelle offline und nutzt eine ausstellende CA für die routinemäßige Zertifikatsausstellung. Ein verwalteter PKI-Dienst kann diese Rollen erfüllen, ohne dass Ihr Team jede Komponente lokal betreiben muss.
Die ausstellende CA signiert Geräte- und Serverzertifikate. RADIUS muss der Client-Zertifikatskette vertrauen, während Endpunkte der entsprechenden Serverkette vertrauen müssen. Gehen Sie nicht davon aus, dass die Installation eines Stammzertifikats automatisch den Rest der Drahtlosrichtlinie konfiguriert.
Wählen Sie Profile aus, bevor Sie Zertifikate ausstellen
Eine Gerätevorlage benötigt die Nutzung zur Client-Authentifizierung, eine Geräte- oder Benutzeridentität, die Ihre Richtlinie auflösen kann, und einen Gültigkeitszeitraum, der von Ihrem Verlängerungs- und Wiederherstellungskonzept geregelt wird.
Zertifikatsprofile nach Sicherheitsstufe
| Profil | Schlüssel und Algorithmus | Typische Gültigkeit | Einsatzbereich |
|---|---|---|---|
| Verwaltetes Standard-Laptop oder -Smartphone | Von der Organisation genehmigter Algorithmus, der flottenweit unterstützt wird | Festgelegt durch Verlängerungs- und Wiederherstellungsrichtlinie | Gemischte Flotten auf WPA2-Enterprise |
| Strikter verwaltetes Gerät | Genehmigte stärkere Vorlage nach Endgeräteprüfung | Festgelegt durch Richtlinie und Verlängerungsfähigkeit | Moderne Flotten mit aktueller Firmware |
| WPA3-Enterprise 192-Bit | ECDSA P-384 oder RSA 3072 oder höher | Festgelegt durch Richtlinie und Verlängerungsfähigkeit | Standorte mit höherem Schutzbedarf nach Kompatibilitätsprüfung |
| Bildschirmloses oder veraltetes Gerät | Häufig nicht unterstützt | Vom Hersteller unterstützter Lebenszyklus oder Ausnahme-Ablaufdatum | Ausnahmepfad |
Der Wi-Fi Alliance-Bereitstellungsleitfaden gibt an, dass der WPA3-Enterprise 192-Bit-Modus die Authentifizierung auf EAP-TLS beschränkt und AES-256-GCM-Suites mit elliptischen Kurvenparametern von P-384 oder RSA/DH-Modulgrößen von mindestens 3072 Bit verwendet. Das Profil des höheren Schutzbedarfs in der Tabelle muss daher gegen die gesamte ausgewählte Suite geprüft werden, nicht nur gegen die Schlüsselbezeichnung des Zertifikats.
Zertifikatvorlagen, RADIUS-Software, Supplicants und Kryptografieanbieter müssen übereinstimmen. Ein Endpunkt, der normales EAP-TLS unterstützt, kann unter diesem strengeren Profil dennoch fehlschlagen.
Bereitstellung von Vertrauen, Anmeldedaten und Konfiguration aus einer Hand
Mit SCEP weist das Verwaltungsprofil das Gerät an, ein Schlüsselpaar zu generieren und ein Zertifikat anzufordern. Die CA signiert die Anforderung; das Gerät bewahrt seinen privaten Schlüssel im geschützten Speicher auf. Verteilen Sie dasselbe Client-Zertifikat und denselben privaten Schlüssel nicht auf mehrere Geräte.
Implementieren Sie die Abhängigkeiten in einer kontrollierten Reihenfolge:
- Zuerst Vertrauen: Installieren Sie die erforderlichen vertrauenswürdigen CA-Zertifikate.
- Als Nächstes Anmeldedaten: Bereitstellen der SCEP-Konfiguration und Bestätigen der erfolgreichen Ausstellung.
- Zulest das WLAN-Profil: Referenzieren Sie die vorgesehenen Client-Anmeldedaten und Server-Validierungseinstellungen.
Halten Sie das Gruppen-Targeting über abhängige Profile hinweg konsistent. Nutzen Sie den MDM-WiFiZertifikatsprofil-Vergleich, um Plattformunterschiede vor der Standardisierung des Rollouts zu überprüfen. Stellen Sie außerdem eine Registrierungsverbindung bereit, die nicht von dem Zertifikat abhängt, das das Gerät noch zu beziehen versucht.
Verwaltung des Zertifikatslebenszyklus von der Ausstellung bis zur Erneuerung
Ein Laptop, der sich heute erfolgreich verbindet, kann fehlschlagen, nachdem er während seines Verlängerungszeitraums im Schrank lag. Der Access Point ist möglicherweise intakt, das Passwort hat sich nicht geändert und der Benutzer hat keinen Fehler gemacht. Der Endpunkt verfügt lediglich über kein akzeptables Anmeldezeichen mehr.
Der EAP-Anforderungsleitfaden des NIST beschreibt die Notwendigkeit, dass Zertifikate vor der Authentifizierung bereitgestellt werden, während des Austauschs verfügbar und überprüfbar sind, einschließlich des Sperrstatus. Diese Anforderungen machen Abhängigkeiten im Lebenszyklus zu einem Bestandteil der Netzwerkverfügbarkeit.
Dieser Zeitplan ist nützlich, um die Verantwortlichkeiten über die initiale Bereitstellung hinaus zuzuweisen.
Weisen Sie jeder Phase eine betriebliche Kontrolle zu
| Phase | Steuerung | Verhinderter Fehler |
|---|---|---|
| Registrierung | MDM-Registrierung und Profil-Targeting überwachen | Gerät erhält nie eine Registrierungsanweisung |
| Ausstellung | Vorlagenberechtigungen und Anforderungsergebnisse validieren | CA lehnt Anfragen ab oder stellt unbrauchbare Zertifikate aus |
| Bereitstellung | Installation und geschützten Zugriff auf den privaten Schlüssel überprüfen | Zertifikat existiert, aber der Supplicant kann es nicht verwenden |
| Erneuerung | Frühzeitig beginnen, Fertigstellung überwachen und getestete Überlappung zulassen | Geräte erreichen das Ablaufdatum ohne Ersatz |
| Ablauf | Eigentümer benachrichtigen und eingeschränkten Wiederherstellungspfad bereitstellen | Abgelaufene Geräte haben keine Möglichkeit zur Wiederherstellung |
| Außerdienststellung | Anmeldeinformationen entziehen und veraltete Inventareinträge entfernen | Außer Dienst gestellte Geräte behalten eine akzeptierte Identität |
Eine Verlängerung erfordert den Nachweis des Abschlusses, nicht nur eine aktivierte Automatisierungseinstellung. Verfolgen Sie, ob ein Ersatzzertifikat ausgestellt, installiert und erfolgreich verwendet wurde. Bestätigen Sie während der Überschneidung, dass der Supplicant entsprechende Anmeldedaten auswählt, anstatt wiederholt veraltete zu wählen.
Planen Sie für Geräte, die nicht online sind
Legen Sie das Verlängerungsfenster basierend auf dem tatsächlichen Geräteverhalten fest. Geräte, die saisonal genutzt oder als Ersatzteil aufbewahrt werden, benötigen möglicherweise einen anderen Wiederherstellungsprozess als ein Laptop, der sich täglich anmeldet. Gehen Sie nicht davon aus, dass ein Offline-Endpunkt verlängert werden kann, nur weil sein altes Zertifikat weiterhin im MDM aufgeführt ist.
Führen Sie ein Inventar, das Zertifikatsseriennummer, Endpunkt-ID, Eigentümer, Aussteller, Ablauf- und Verlängerungsstatus verknüpft. Beziehen Sie die Zertifikate der ausstellenden CA und des Authentifizierungsservers ein, da deren Austausch eine weitaus größere Benutzergruppe betreffen kann.
Ein Erneuerungsauftrag, der erfolgreich ausgeführt wurde, ist nicht gleichbedeutend mit einem Gerät, das sich mit seinem Ersatzzertifikat authentifizieren kann.
Testen Sie Uhrzeitabweichungen, Betriebssystem-Neuinstallationen und Änderungen an der CA-Kette. Bei einer Neuinstallation kann der private Schlüssel verloren gehen; ein Uhrzeitfehler kann dazu führen, dass ein gültiges Zertifikat als noch nicht gültig erscheint; und eine Änderung der Kette kann dazu führen, dass Endpunkte nicht mehr über das erforderliche Vertrauen verfügen.
Weisen Sie Ausfällen im Zusammenhang mit MDM, PKI und Netzwerkdiensten benannte Verantwortliche zu. Andernfalls kann jedes Team melden, dass sein eigenes System voll funktionsfähig ist, während der Endpunkt getrennt bleibt. EAP-TLS verwandelt das Ausfallrisiko in ein Inventar-, Automatisierungs- und Abhängigkeitsmanagement-Problem. Es beseitigt dieses Risiko nicht.
Entzug des Zugriffs bei Geräteverlust oder Ausscheiden von Mitarbeitenden
Das Verzeichniskonto eines ausscheidenden Mitarbeiters wird deaktiviert, sein Laptop enthält jedoch weiterhin ein Zertifikat, das noch nicht abgelaufen ist. Ob eine erneute Verbindung möglich ist, hängt von Ihrer Autorisierungsintegration und den Sperrkontrollen ab. Das Deaktivieren eines Kontos und das Sperren eines Zertifikats sind unterschiedliche Aktionen, es sei denn, Ihr konfigurierter Workflow verknüpft diese explizit.
Definieren Sie das Offboarding-Ergebnis in betrieblicher Hinsicht: Neue Authentifizierungen müssen fehlschlagen, die Registrierung darf keine Ersatz-Anmeldezeichen ausstellen und bestehende Sitzungen müssen über einen unterstützten Mechanismus beendet werden. Ein abgeschlossenes HR-Ticket belegt keines dieser Ergebnisse.
Verstehen Sie die Statusprüfungen
Eine Zertifikatsperrliste (Certificate Revocation List, CRL) veröffentlicht Zertifikate, die von einer Ausstellungsstelle zurückgezogen wurden. Das Online Certificate Status Protocol (OCSP) ermöglicht es einer Validierungsinstanz, den Zertifikatsstatus bei einem Responder abzufragen.
Die Komponente, die das Zertifikat validiert, wendet die entsprechende Richtlinie zur Statusprüfung an. Bei Client-Zertifikaten ist dies in der Regel der Authentifizierungsdienst und nicht der Access Point. Wenn Statusinformationen nicht verfügbar sind, kann eine Fail-Closed-Richtlinie ansonsten gültige Geräte blockieren, während eine Fail-Open-Richtlinie Anmeldedaten akzeptieren kann, deren Widerruf nicht bestätigt werden kann.
Treffen Sie diese Entscheidung explizit. Beziehen Sie zwischengespeicherte Statusinformationen, Veröffentlichungsverzögerungen und Responder-Verfügbarkeit in Ihre Tests ein, anstatt davon auszugehen, dass das Klicken auf „Widerrufen“ jede Authentifizierungsentscheidung sofort ändert.
Nutzen Sie einen vollständigen Prozess für verlorene Geräte
Kordinieren Sie bei einem fehlenden Laptop die Maßnahmen, anstatt jede einzelne als letzten Schritt eines separaten Teams zu betrachten:
- Anmeldedaten identifizieren und entziehen. Ordnen Sie dem Endgerät seine tatsächliche Zertifikatseriennummer zu und widerrufen Sie die entsprechenden Anmeldedaten.
- Neuausstellung verhindern. Deaktivieren Sie die Registrierungsberechtigung des Geräts und wenden Sie den entsprechenden MDM-Außerbetriebnahme- oder Entfernungsprozess an.
- Aktiven Zugriff beenden. Nutzen Sie unterstützte Steuerelemente zur Sitzungsbeendigung, einschließlich RADIUS Change of Authorization, sofern die Infrastruktur dies unterstützt.
- Ergebnis überprüfen. Bestätigen Sie, dass die Sitzung beendet wurde und ein neuer Authentifizierungsversuch abgelehnt wird.
Die Sperrung allein beendet eine bestehende Drahtlossitzung nicht zwangsläufig. Auf Geräten ohne unterstützten Trennungsmechanismus kann die Sitzung bis zur erneuten Verbindung, Reauthentifizierung oder einer anderen erzwungenen Sitzungsgrenze fortgesetzt werden. Halten Sie diese Einschränkung im Vorfallverfahren fest.
Ihr Audit-Repertoire sollte Folgendes umfassen:
- Identität der Anmeldedaten: Gerätekennung, Zertifikatseriennummer und zugehöriger Eigentümer.
- Entscheidungsnachweis: Widerrufsgrund, Bediener und Zeitpunkt der Aktion.
- Durchsetzungsnachweis: Zeitpunkt der Sitzungsbeendigung und anschließendes Ablehnungsergebnis.
- Verbleibendes Risiko: Jede Sitzung, die nicht erzwungen beendet werden konnte, sowie die ergriffene Eindämmungsmaßnahme.
Planen Sie Übungen zum Zertifikatswiderruf ein. Führen Sie diese sowohl nach Änderungen der Authentifizierungsrichtlinie als auch bei routinemäßigen Betriebstests durch, damit ein tatsächlicher Vorfall mit einem verlorenen Gerät nicht Ihr erster Versuch ist, den gesamten Pfad zu überprüfen.
Planung der Geräteberechtigung und von Ausnahmen
Geräteklassen und ihre Eignung für EAP-TLS
| Geräteklasse | EAP-TLS Eignung | Typische Alternative | Wichtige Schlüsselfrage |
|---|---|---|---|
| Verwaltete Laptops und Telefone | Stark | Keine erforderlich, MDM-Registrierung | Ist die MDM-Registrierung zuverlässig? |
| Unternehmens-Tablets und Kioske | Gut, wenn per MDM verwaltet | Kiosk-spezifischer Schlüssel allein SSID | Kann der private Schlüssel in einem sicheren Speicher liegen? |
| Headless-IoT-Sensoren | Schlecht ohne geeignete Firmware | Gerätespezifischer Schlüssel in einem isolierten VLAN | Unterstützt die Firmware 802.1X? |
| Raumsysteme, AV und Konferenzen | Anbieterspezifische Unterstützung | Dedizierte SSID mit gerätespezifischem Schlüssel | Kann der Anbieter Zertifikate installieren und erneuern? |
| Medizinische Geräte | Oft eingeschränkt | Segmentiertes Netzwerk mit vom Anbieter genehmigter Methode | Ist das Gerät für diese Methode zertifiziert? |
| Endpunkte mit veralteten Betriebssystemen | Nicht unterstützt, wenn erforderliche Funktionen fehlen | Quarantäne-VLAN mit zeitlich begrenzter Ausnahme | Wann wird die Ausnahme überprüft? |
Die grundlegende Einschränkung besteht darin, dass jeder EAP-TLS Client sein eigenes Zertifikat benötigt und nicht nur das Vertrauen in den Server. Der Leitfaden für Drahtlosnetzwerke des NIST unterscheidet diese Client-Zertifikatsanforderung von der Authentifizierung rein serverseitiger Zertifikate.
Ein Gerät benötigt daher einen funktionierenden Supplicant, einen geeigneten Schutz für den privaten Schlüssel und einen unterstützten Weg zum Empfangen und Ersetzen seines Anmeldezeichens. Ein Datenblatt mit der Angabe „Enterprise-WiFi unterstützt“ reicht nicht aus, um diese Funktionen zu belegen.
Testen Sie den gesamten Lebenszyklus des Geräts
Bitten Sie bei einem Konferenzraumsystem den Anbieter, die Zertifikatsinstallation, -erneuerung und -wiederherstellung nach einem Zurücksetzen auf die Werkseinstellungen zu demonstrieren. Eine Weboberfläche, die das Hochladen von Zertifikaten akzeptiert, löst zwar möglicherweise das Onboarding, nicht aber die Wartung.
Wahren Sie bei medizinischen und betrieblichen Geräten die Supportanforderungen des Herstellers. Ändern Sie die Authentifizierungsmethode eines Produktionsgeräts nicht allein deshalb, weil ein anderes Produkt desselben Herstellers diese unterstützt.
Mitarbeitereigene Geräte erfordern eine separate Berechtigungsentscheidung. Ihr BYOD-Onboarding-Konzept sollte festlegen, welche Verwaltung oder Profilinstallation akzeptabel ist, bevor Sie Benutzer zur Registrierung auffordern.
Gestalten Sie Ausnahmen präzise und nachvollziehbar
Ein Gerät, das keine Zertifikate verwenden kann, sollte nicht die Zugriffsrechte eines verwalteten Mitarbeiter-Laptops erben. Weisen Sie seinen alternativen Anmeldedaten einen definierten Eigentümer zu und beschränken Sie das Netzwerk auf die erforderlichen Ziele.
Erfassen Sie für jede Ausnahme Folgendes:
- Technischer Grund: Die fehlende Funktion oder Herstellereinschränkung, belegt durch eine Konfigurationsprüfung.
- Kompensierende Steuerelemente: Segmentierung, zulässige Dienste und die individuell widerrufbare Alternative.
- Prüfdatum: Eine geplante Entscheidung zur Verlängerung, Änderung oder Aufhebung der Ausnahme.
- Ersatzplan: Das Firmware-Upgrade, die unterstützte Onboarding-Methode oder der Hardware-Austausch, womit die Ausnahme beendet würde.
Vermeiden Sie es, ein temporäres Quarantänenetzwerk in eine dauerhafte Umgebung für nicht identifizierte Geräte zu verwandeln. Eine Ausnahme ohne Verantwortlichen oder Ausstiegsbedingung wird zu einer undokumentierten Zugriffsrichtlinie. Der vertretbare Ansatz besteht nicht in Zertifikaten um jeden Preis, sondern in einer starken Authentifizierung verwalteter Geräte zusammen mit bewusst eingeschränkten Alternativen.
Bestätigen Sie Ihren Zertifikatsplan vor dem Rollout
Eine erfolgreiche Demonstration zeigt, dass sich ein funktionierender Laptop verbinden kann. Ein nützlicher Testbetrieb zeigt, was passiert, wenn die Registrierung fehlschlägt, ein Anmeldeinformations-Zertifikat abläuft, ein Gerät zurückgezogen wird und eine Abhängigkeit nicht verfügbar ist. Genehmigen Sie das Betriebsmodell und nicht nur den ersten erfolgreichen Handshake.
Wählen Sie einen Standort für den Pilotbetrieb und identifizieren Sie die relevanten Geräteklassen, bevor Sie den Produktionszugriff ändern. Erfassen Sie die Funktionen der Access Points, das Supplicant-Verhalten und die Firmware-Versionen. Wenn ein Profil mit höherer Sicherheit erforderlich ist, validieren Sie die ausgewählte Zertifikatvorlage, die Überprüfungen der Zertifikatskette und die erweiterte Schlüsselverwendung anhand repräsentativer Endpunkte.
Gestalten Sie die Bereitschaftsprüfung dieser Woche konkret
Nutzen Sie diese Checkliste, um fehlende Verantwortliche und ungeprüfte Annahmen aufzudecken.
- Geräteunterstützung bestätigen: Stellen Sie sicher, dass jedes betroffene Gerät einen geschützten privaten Schlüssel speichern und verwenden kann, statt nur ein Zertifikat zu importieren.
- Vertrauen und Erneuerung bestätigen: Weisen Sie Verantwortliche für die CA-Kette, den Registrierungsdienst, die Erneuerungsüberwachung und den Wiederherstellungspfad zu.
- Durchsetzung testen: Demonstrieren Sie Akzeptanz, Ablehnung, Widerruf und die unterstützte Beendigung aktiver Sitzungen.
- Ausnahmen genehmigen: Geben Sie jeder nicht unterstützten Klasse eine eingeschränkte Alternative, einen verantwortlichen Eigentümer und ein Überprüfungsdatum.
- Handlungsrelevante Warnmeldungen einrichten: Leiten Sie bevorstehende Ablaufdaten und fehlgeschlagene Erneuerungsereignisse an Personen weiter, die diese beheben können.
Verwenden Sie ein wiederholbares RADIUS Authentifizierungs-Testverfahren, damit Ingenieure vergleichbare Nachweise sammeln. Erfassen Sie den Client-Status, das erwartete Ergebnis, das tatsächliche Ergebnis und den relevanten Fehlercode.
Beurteilen Sie das Pilotprojekt nach der Supportfähigkeit
Führen Sie den Zertifikatspfad neben dem bestehenden Netzwerk mit einem definierten Rollback-Verfahren aus. Berücksichtigen Sie die Remoteregistrierung, einen neu aufgesetzten Endpunkt, ein Offline-Ersatzgerät und die Betriebssysteme, die Ihr Helpdesk unterstützt. Wählen Sie nicht nur kürzlich bereitgestellte Laptops aus.
Überprüfen Sie Helpdesk-Tickets zusammen mit Authentifizierungsprotokollen. Trennen Sie Zertifikatsfehler von Problemen mit der WLAN-Abdeckung, der Adresszuweisung und VLAN, damit das Team nicht die PKI neu konzipiert, um einen nicht damit zusammenhängenden Fehler zu beheben.
Die Abnahme des Testbetriebs sollte bedeuten, dass verwaltete Geräte in der Regel ohne Benutzereingriff beitreten, Fehler benannte Ursachen haben und der Entzug des Zugriffs demonstriert werden kann. Bewahren Sie Nachweise über erfolgreiche und abgelehnte Versuche mit ausreichend Identitätskontext auf, um die Entscheidung zu erklären.
Legen Sie das Überprüfungsdatum des Pilotbetriebs vor dessen Start fest. Bestätigen Sie diese Woche den Standort, die Geräteklassen, die Verantwortlichen und die Akzeptanzkriterien. Erweitern Sie den Rollout erst, nachdem das Team die Fehler behoben und die Wiederherstellung nachgewiesen hat. Eine kleinere Bereitstellung mit zuverlässiger Verlängerung und Sperrung ist eine bessere Grundlage als ein breiter Rollout, den niemand mit Sicherheit reparieren kann.
Purple Access bietet zertifikatsbasierten Mitarbeiterzugriff WiFi über MDM-bereitgestellte EAP-TLS sowie Gast- und gerätebasierten Zugriff auf Ihren bereits vorhandenen Access Points. Besuchen Sie Purple Access, um einen Pilotversuch an einem Standort zu planen, die Zertifikat- und Ausnahmepfade zu validieren und das Ergebnis anhand von Support-Tickets und Nachweisen zu beurteilen, bevor Sie den Rollout ausweiten.
