So entziehen Sie den WiFi-Zugang, wenn ein Mitarbeiter das Unternehmen verlässt

Willkommen beim Purple Technical Briefing. Ich bin Ihr Host, und heute widmen wir uns einer der häufigsten Lücken beim Offboarding in Unternehmen: Was passiert eigentlich mit dem WiFi-Zugang, wenn ein Mitarbeiter das Unternehmen verlässt? Es klingt ganz einfach. Jemand gibt seinen Ausweis ab, die Personalabteilung schließt das Konto, und das Thema ist erledigt. Aber wenn Ihr Netzwerk immer noch mit einem gemeinsamen WPA2-Passwort betrieben wird, hat diese Person das Gebäude verlassen und kennt das Passwort immer noch. Und solange Sie es nicht für alle ändern, kann sie sich vom Parkplatz aus wieder verbinden. Das ist das Problem, das wir heute lösen. Wir behandeln die drei bewährten Modelle für den benutzerbezogenen WiFi-Entzug, gehen eine Checkliste für den Entzug am selben Tag durch und erklären genau, was ein ISO 27001- oder SOC 2-Auditor in Ihren Protokollen sehen möchte. Legen wir los. Abschnitt eins: Warum gemeinsame Passwörter das falsche Werkzeug für diese Aufgabe sind. WPA2-Personal, die Standardkonfiguration für Heimrouter, verwendet einen einzigen Pre-Shared Key. Jeder im Netzwerk kennt dasselbe Passwort. Wenn eine Person das Unternehmen verlässt, ist dieses Passwort auf ihrem Telefon, ihrem Laptop und jedem Gerät, das sie jemals verbunden hat, weiterhin gültig. Die einzige Möglichkeit, ihren Zugriff zu sperren, besteht darin, das Passwort für das gesamte Netzwerk zu ändern und es an alle verbleibenden Benutzer und Geräte neu zu verteilen. In einem Hotel mit 200 Mitarbeitern bedeutet das, jedes Point-of-Sale-Terminal, jeden Backoffice-PC und jedes Smartphone der Manager zu aktualisieren. In einer Einzelhandelskette mit 50 Filialen bedeutet dies einen koordinierten Rollout an jedem Standort. Die Betriebskosten sind hoch, die Unterbrechung ist spürbar und das Zeitfenster zwischen dem letzten Arbeitstag des Ausscheidenden und der abgeschlossenen Passwortänderung ist eine echte Sicherheitslücke. PCI-DSS, der Standard der Zahlungskartenindustrie, verlangt, dass Sie gemeinsame Zugangsdaten ändern, sobald Mitarbeiter mit Kenntnis darüber das Unternehmen verlassen. Wenn sich Ihre Kassen also im selben Netzwerk wie Ihr Mitarbeiter-WiFi befinden, löst ein Ausscheiden eine Compliance-Verpflichtung aus, nicht nur eine Best-Practice-Empfehlung. Die Ursache ist einfach: Einem gemeinsamen Passwort ist keine Identität zugeordnet. Das Netzwerk kann nicht zwischen einem aktuellen und einem ehemaligen Mitarbeiter unterscheiden. Um das zu beheben, benötigen Sie benutzerbezogene Zugangsdaten. Abschnitt zwei: Die drei Modelle, die tatsächlich funktionieren. Modell eins ist 802.1X mit EAP-TLS-zertifikatsbasierter Authentifizierung. Dies ist der Goldstandard für die WiFi-Sicherheit in Unternehmen. In diesem Modell besitzt jeder Benutzer oder jedes Gerät ein eindeutiges digitales Zertifikat, das von Ihrer Zertifizierungsstelle (CA) ausgestellt wurde. Wenn sie sich mit dem WiFi verbinden, validiert der RADIUS-Server dieses Zertifikat kryptografisch. Das Zertifikat ist an eine Identität gebunden, nicht an ein Passwort. Um den Zugriff zu sperren, widerrufen Sie das Zertifikat auf CA-Ebene. Der RADIUS-Server prüft den Sperrstatus in Echtzeit über OCSP, das Online Certificate Status Protocol. Wenn Sie ein Zertifikat als gesperrt markieren, fragt der RADIUS-Server beim nächsten Authentifizierungsversuch dieses Geräts den OCSP-Responder ab, erhält eine Rückmeldung über die Sperrung und sendet ein Access-Reject an den Access Point. Das Gerät ist innerhalb von Sekunden nach dem nächsten Authentifizierungsversuch vom Netzwerk getrennt. Für aktive Sitzungen nutzen Sie RADIUS Change of Authorisation (CoA), um die bestehende Sitzung sofort zu beenden. In Kombination bedeuten OCSP und CoA, dass Sie den WiFi-Zugang für einen Ausscheidenden in weniger als einer Minute sperren können – mit einem lückenlosen Audit-Trail in Ihren RADIUS-Protokollen. Die Herausforderung bei EAP-TLS ist der PKI-Overhead. Sie benötigen eine Zertifizierungsstelle, einen Mechanismus zur Ausstellung von Zertifikaten an Geräte – in der Regel über ein MDM wie Microsoft Intune – und einen Prozess zu deren Sperrung. Für Unternehmen mit einer ausgereiften MDM- und Identitätsinfrastruktur ist dies die richtige Lösung. Für kleinere Teams oder Umgebungen mit IoT-Geräten, die keine Zertifikatsauthentifizierung unterstützen, benötigen Sie einen anderen Ansatz. Modell zwei ist iPSK, Identity Pre-Shared Key. Cisco nennt es iPSK, Ruckus nennt es DPSK, Aruba nennt es MPSK, aber das Konzept ist dasselbe: Jeder Benutzer oder jedes Gerät erhält ein eindeutiges Passwort, obwohl sich alle mit derselben SSID verbinden. Der RADIUS-Server ordnet jeden eindeutigen Schlüssel einer bestimmten Identität und optional einem bestimmten VLAN zu. Wenn Sie diesen Schlüssel aus der RADIUS-Datenbank löschen, kann sich das Gerät nicht mehr authentifizieren. Der Auswirkungsbereich eines Ausscheidenden beschränkt sich auf genau eine Person. Die Schlüssel aller anderen bleiben gültig. iPSK eignet sich besonders gut für Umgebungen mit gemischten Gerätetypen. IoT-Geräte, Point-of-Sale-Terminals und ältere Hardware, die keine 802.1X-Zertifikate unterstützen, können alle iPSK nutzen. Zudem ist es einfacher zu betreiben als eine vollständige PKI-Bereitstellung, was es zur richtigen Wahl für mittelständische Unternehmen macht, die einen benutzerbezogenen Entzug ohne den Infrastruktur-Overhead benötigen. Die Sperrzeit bei iPSK beträgt in der Regel einige Minuten, nicht Sekunden. Die Schlüssellöschung wird an den RADIUS-Server übertragen, aber aktive Sitzungen können fortbestehen, bis sich das Gerät erneut authentifiziert oder bis Sie ein CoA-Paket senden, um die Trennung zu erzwingen. Modell drei ist die SCIM-gesteuerte De-Provisionierung. SCIM steht für System for Cross-domain Identity Management. Es ist ein offener Standard, definiert in RFC 7643 und RFC 7644, der es Ihrem Identitätsanbieter ermöglicht, Ereignisse des Benutzerlebenszyklus in Echtzeit an nachgelagerte Systeme zu übertragen. So funktioniert es in der Praxis: Ihr Identitätsanbieter, sei es Microsoft Entra ID, Okta oder Google Workspace, ist die maßgebliche Quelle der Wahrheit (Source of Truth) für Benutzerkonten. Wenn die Personalabteilung das Konto eines Ausscheidenden im Identitätsanbieter deaktiviert, sendet SCIM eine Anfrage an jedes verbundene System, einschließlich Ihrer WiFi-Management-Plattform. Purple verbindet sich über SCIM mit Ihrem Identitätsanbieter. In dem Moment, in dem Sie einen Benutzer in Entra ID, Okta oder Google Workspace deaktivieren, empfängt Purple das SCIM-Ereignis und sperrt dessen WiFi-Zugangsdaten bei der nächsten Authentifizierung. Das Ereignis wird mit einem Zeitstempel, der Identität des Benutzers und der durchgeführten Aktion protokolliert. Dieser Protokolleintrag ist genau das, was ein ISO 27001-Auditor sehen möchte. SCIM ersetzt 802.1X oder iPSK nicht. Es setzt darauf auf. SCIM verwaltet den Identitätslebenszyklus; das Authentifizierungsprotokoll übernimmt die Durchsetzung im Netzwerk. Die Kombination aus SCIM und 802.1X bietet Ihnen einen automatischen Entzug in Echtzeit mit einem lückenlosen Audit-Trail und ohne manuelle Schritte. Abschnitt drei: Die Checkliste für den Entzug am selben Tag. Wenn der letzte Arbeitstag eines Ausscheidenden ansteht, sollte Ihr IT-Team folgende Schritte durchführen. Schritt eins: Deaktivieren Sie das Konto in Ihrem Identitätsanbieter. Dies ist der Auslöser für alles Weitere. Setzen Sie das Konto in Microsoft Entra ID auf deaktiviert. Deaktivieren Sie den Benutzer in Okta. Sperren Sie das Konto in Google Workspace. Schritt zwei: Wenn Sie SCIM nutzen, überprüfen Sie, ob das De-Provisioning-Ereignis ausgelöst wurde. Prüfen Sie Ihre SCIM-Protokolle oder Ihre WiFi-Management-Plattform auf das entsprechende Ereignis. Wenn kein SCIM eingerichtet ist, sperren Sie das Zertifikat manuell in Ihrer CA oder löschen Sie den iPSK-Schlüssel aus Ihrer RADIUS-Datenbank. Schritt drei: Senden Sie ein RADIUS CoA, um jede aktive WiFi-Sitzung zu beenden. Die meisten Enterprise-RADIUS-Server und Plattformen wie Purple können dies bei einem De-Provisioning-Ereignis automatisch tun. Wenn Sie dies manuell tun, nutzen Sie die CoA-Schnittstelle Ihres RADIUS-Servers, um das Gerät des Benutzers anhand der MAC-Adresse oder der Sitzungs-ID zu trennen. Schritt vier: Bestätigen Sie, dass keine aktiven Sitzungen mehr bestehen. Überprüfen Sie das Dashboard Ihres WiFi-Controllers. Bei Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet sollten Sie nach dem Benutzernamen oder dem Gerät suchen und bestätigen können, dass keine aktiven Verbindungen mehr bestehen. Schritt fünf: Archivieren Sie den Audit-Protokolleintrag. Exportieren oder markieren Sie das RADIUS-Authentifizierungsprotokoll, das SCIM-Ereignisprotokoll und das CoA-Protokoll für den entsprechenden Benutzer und das Datum. Speichern Sie diese in Ihrem ITSM oder Ihrer SIEM-Plattform (Security Information and Event Management). Die ISO 27001 Annex A-Maßnahme A.9.2.6 verlangt, dass Sie die Zugriffsrechte aller Mitarbeiter und externen Dienstleister bei Beendigung des Arbeitsverhältnisses entziehen oder anpassen. Ihr Protokoll ist der Nachweis. Schritt sechs: Wenn Sie einen gemeinsamen WPA2-PSK nutzen und nichts des oben Genannten zutrifft, ändern Sie das Passwort. Koordinieren Sie den Rollout über alle Standorte und Geräte hinweg möglichst vor dem letzten Arbeitstag des Ausscheidenden oder unmittelbar danach. Abschnitt vier: Was der Auditor erwartet. ISO 27001 und SOC 2 verlangen den Nachweis, dass der Zugriff nach Beendigung des Arbeitsverhältnisses unverzüglich entzogen wird. Speziell beim WiFi achten Auditoren auf vier Dinge: Erstens ein dokumentierter Offboarding-Prozess, der den Netzwerkzugriff explizit einschließt. Zweitens der Nachweis, dass dieser Prozess für eine Stichprobe von Ausscheidenden – in der Regel zehn bis fünfundzwanzig Personen aus den letzten zwölf Monaten – eingehalten wurde. Drittens ein Protokoll, das den Zeitstempel der Kontodeaktivierung und den Zeitstempel des WiFi-Zugangsentszugs zeigt, wobei die Zeitspanne dazwischen klar erkennbar ist. Viertens die Bestätigung, dass keine Konten ehemaliger Mitarbeiter aktive WiFi-Sitzungen aufweisen. Wenn Sie einen gemeinsamen WPA2-PSK nutzen, können Sie für die Punkte drei und vier keine Nachweise erbringen. Es gibt kein benutzerbezogenes Protokoll. Das Beste, was Sie tun können, ist, das Datum der Passwortänderung vorzulegen und zu argumentieren, dass diese vor oder am letzten Arbeitstag des Ausscheidenden abgeschlossen wurde. Auditoren weisen dies zunehmend zurück. Wenn Sie 802.1X mit SCIM nutzen, erfolgt die Protokollierung automatisch. Purple erfasst jedes SCIM-De-Provisioning-Ereignis mit einem UTC-Zeitstempel, der Quelle des Identitätsanbieters, der eindeutigen Kennung des Benutzers und der resultierenden Aktion. Das ist ein sauberer, prüfbarer Nachweis. Abschnitt fünf: Implementierungsfehler und wie man sie vermeidet. Der häufigste Fehler ist die Annahme, dass das Deaktivieren eines Kontos im Identitätsanbieter ausreicht. Das ist nicht der Fall, es sei denn, Ihre WiFi-Plattform ist über SCIM oder eine ähnliche Echtzeit-Integration mit diesem Identitätsanbieter verbunden. Ohne diese Verbindung hat das WiFi-System keine Möglichkeit zu erfahren, dass das Konto deaktiviert wurde. Die zweite Falle ist das Caching von Zertifikaten. Selbst mit OCSP speichern RADIUS-Server positive Antworten für einen konfigurierbaren Zeitraum zwischen, in der Regel 15 bis 60 Minuten. Wenn Sie ein Zertifikat sperren und der RADIUS-Server eine positive Antwort zwischengespeichert hat, kann sich das Gerät weiterhin authentifizieren, bis der Cache abläuft. Setzen Sie Ihre OCSP-Cache-TTL in hochsicheren Umgebungen auf 15 Minuten oder weniger. Die dritte Falle ist das Vergessen aktiver Sitzungen. Das Sperren von Zugangsdaten verhindert neue Authentifizierungen, beendet aber keine bestehende WiFi-Sitzung. Senden nach dem Sperren von Zugangsdaten immer ein RADIUS CoA, um das Gerät sofort zu trennen. Die vierte Falle sind IoT- und gemeinsam genutzte Geräte. Ein Gerät, das auf die Identität eines Ausscheidenden registriert ist, kann eine gemeinsam genutzte Workstation oder ein betriebliches Hardware-Teil sein. Bestätigen Sie vor dem Entzug, dass es sich um ein persönliches und nicht um ein gemeinsam genutztes Gerät handelt. Wenn es gemeinsam genutzt wird, registrieren Sie es unter einem Dienstkonto neu, bevor Sie die Zugangsdaten des Ausscheidenden sperren. Abschnitt sechs: Schnelle Fragen und Antworten. Frage: Wie schnell kann ein zertifikatsbasierter WiFi-Zugang gesperrt werden? Mit OCSP und RADIUS CoA in weniger als 60 Sekunden ab dem Moment, in dem Sie das Zertifikat in der CA sperren. Die OCSP-Prüfung erfolgt beim nächsten Authentifizierungsversuch. Das CoA beendet die aktive Sitzung sofort. Frage: Funktioniert SCIM mit jeder WiFi-Hardware? SCIM arbeitet auf der Identitätsverwaltungsebene, nicht auf der Hardwareebene. Purple ist hardwareunabhängig und funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Die SCIM-Integration erfolgt mit Purple, nicht direkt mit den Access Points. Frage: Was ist, wenn wir kein MDM haben und keine Zertifikate bereitstellen können? iPSK ist Ihre Lösung. Es bietet Ihnen einen benutzerbezogenen Entzug, ohne dass eine Zertifikatsinfrastruktur erforderlich ist. Purple kann iPSK-Schlüssel verwalten und sich mit Ihrem Identitätsanbieter verbinden, um den Lebenszyklus zu automatisieren. Zusammenfassung und nächste Schritte. Die Kernbotschaft lautet: Wenn Sie den WiFi-Zugang für eine Person nicht sperren können, ohne alle anderen zu beeinträchtigen, haben Sie ein Problem mit gemeinsamen Zugangsdaten. Die Lösung sind benutzerbezogene Zugangsdaten, entweder Zertifikate über 802.1X EAP-TLS oder eindeutige Schlüssel über iPSK, kombiniert mit einer SCIM-gesteuerten De-Provisionierung, um den Entzug in dem Moment zu automatisieren, in dem die Personalabteilung handelt. Purple verbindet sich über SCIM mit Microsoft Entra ID, Okta und Google Workspace, läuft an über 80.000 Live-Standorten und protokolliert jedes De-Provisioning-Ereignis für Audits. Wenn Sie sich auf ISO 27001 oder SOC 2 vorbereiten oder einfach die Sicherheitslücke bei ausscheidenden Mitarbeitern schließen möchten, bevor es zu einem Vorfall kommt, ist dies der richtige Ausgangspunkt. Eine vollständige technische Analyse der Zertifikatssperrung und von OCSP finden Sie in unserem Leitfaden zu OCSP und Zertifikatssperrung für die WiFi-Authentifizierung. Für das größere Bild der Joiner-Mover-Leaver-Automatisierung lesen Sie unseren Leitfaden zur WiFi-Sicherheit in Unternehmen. Vielen Dank, dass Sie das Purple Technical Briefing gehört haben.