Wie Sie den WiFi-Zugang beim Ausscheiden eines Mitarbeiters widerrufen

Willkommen zum Purple Technical Briefing. Ich bin Ihr Host, und heute widmen wir uns einer der häufigsten Sicherheitslücken beim Enterprise-Offboarding: Was passiert eigentlich mit dem WiFi-Zugang, wenn ein Mitarbeiter das Unternehmen verlässt? Es klingt ganz einfach: Jemand gibt seinen Ausweis ab, die HR-Abteilung schließt das Konto, und das Thema ist erledigt. Aber wenn Ihr Netzwerk immer noch mit einem gemeinsam genutzten WPA2-Passwort betrieben wird, hat diese Person beim Verlassen des Gebäudes das Passwort immer noch im Kopf. Und solange Sie es nicht für alle Beteiligten ändern, kann sie sich vom Parkplatz aus wieder einwählen. Das ist das Problem, das wir heute lösen. Wir stellen die drei bewährten Modelle für die benutzerspezifische WiFi-Sperrung vor, gehen eine Checkliste für die Sperrung am selben Tag durch und erklären genau, was ein ISO 27001- oder SOC 2-Auditor in Ihren Protokollen sehen möchte. Fangen wir an. Abschnitt eins: Warum gemeinsam genutzte 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 geht, 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 Zugang zu sperren, besteht darin, das Passwort für das gesamte Netzwerk zu ändern und es an jeden verbleibenden Benutzer und jedes Gerät neu zu verteilen. In einem Hotel mit 200 Mitarbeitern bedeutet dies die Aktualisierung jedes Point-of-Sale-Terminals, jedes PCs im Backoffice und jedes Manager-Telefons. In einer Einzelhandelskette mit 50 Filialen bedeutet dies einen koordinierten Rollout über alle Standorte hinweg. Der betriebliche Aufwand ist hoch, die Unterbrechung ist spürbar, und das Zeitfenster zwischen dem letzten Tag des Ausscheidenden und der abgeschlossenen Änderung ist eine echte Sicherheitslücke. PCI DSS, der Sicherheitsstandard der Zahlungskartenindustrie, verlangt, dass Sie gemeinsam genutzte Zugangsdaten immer dann ändern, wenn Mitarbeiter, die diese kennen, das Unternehmen verlassen. Wenn sich Ihre Kassen im selben Netzwerk wie Ihr Mitarbeiter-WiFi befinden, führt das Ausscheiden eines Mitarbeiters zu einer Compliance-Verpflichtung und nicht nur zu einer Empfehlung für Best Practices. Die Ursache ist simpel: Mit einem gemeinsam genutzten Passwort ist keine Identität verknüpft. Das Netzwerk kann nicht zwischen einem aktuellen und einem ehemaligen Mitarbeiter unterscheiden. Um das zu beheben, benötigen Sie benutzerspezifische 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. Bei 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 überprüft den Sperrstatus in Echtzeit mithilfe von OCSP, dem 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 aus dem Netzwerk ausgeschlossen. Für aktive Sitzungen verwenden Sie RADIUS Change of Authorisation (oder CoA), um die bestehende Sitzung sofort zu beenden. In Kombination bedeuten OCSP und CoA, dass Sie den WiFi-Zugang für einen ausscheidenden Mitarbeiter in weniger als einer Minute sperren können – mit einem vollständigen Audit-Trail in Ihren RADIUS-Protokollen. Die Herausforderung bei EAP-TLS ist der PKI-Aufwand. 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 Widerruf. Für Organisationen 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 Benutzer 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 verwenden. Es ist außerdem einfacher zu betreiben als eine vollständige PKI-Bereitstellung, was es zur richtigen Wahl für mittelständische Unternehmen macht, die einen Widerruf pro Benutzer ohne den damit verbundenen Infrastrukturaufwand benötigen. Die Widerrufszeit für iPSK beträgt in der Regel einige Minuten, nicht Sekunden. Die Löschung des Schlüssels wird an den RADIUS-Server übertragen, aber aktive Sitzungen können so lange bestehen bleiben, bis sich das Gerät erneut authentifiziert oder bis Sie ein CoA-Paket senden, um die Trennung der Verbindung zu erzwingen. Modell drei ist die SCIM-gesteuerte Deaktivierung. SCIM steht für System for Cross-domain Identity Management. Es handelt sich um einen offenen Standard, der in RFC 7643 und RFC 7644 definiert ist und es Ihrem Identitätsanbieter ermöglicht, Benutzer-Lebenszyklus-Ereignisse in Echtzeit an nachgelagerte Systeme zu übermitteln. Und so funktioniert es in der Praxis: Ihr Identitätsanbieter – sei es Microsoft Entra ID, Okta oder Google Workspace – ist die maßgebliche Quelle für Benutzerkonten. Wenn die Personalabteilung das Konto eines ausscheidenden Mitarbeiters im Identitätsanbieter deaktiviert, sendet SCIM eine Anfrage an jedes verbundene System, einschließlich Ihrer WiFi-Verwaltungsplattform. 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 entzieht ihm bei der nächsten Authentifizierung seine WiFi-Zugangsdaten. 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 muss. SCIM ersetzt nicht 802.1X oder iPSK. Es ist ihnen übergeordnet. SCIM verwaltet den Identitätslebenszyklus; das Authentifizierungsprotokoll übernimmt die Durchsetzung im Netzwerk. Die Kombination aus SCIM und 802.1X bietet Ihnen eine automatische Echtzeit-Sperrung mit einem vollständigen Audit-Trail und ohne manuelle Schritte. Abschnitt drei: Die Checkliste für die Sperrung am selben Tag. Wenn der letzte Tag eines ausscheidenden Mitarbeiters ansteht, sollte Ihr IT-Team die folgende Reihenfolge einhalten. Schritt eins: Deaktivieren Sie das Konto in Ihrem Identitätsanbieter. Dies ist der Auslöser für alles andere. 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 Deprovisionierungsereignis ausgelöst wurde. Prüfen Sie Ihre SCIM-Protokolle oder Ihre WiFi-Verwaltungsplattform auf das entsprechende Ereignis. Wenn SCIM nicht eingerichtet ist, widerrufen Sie das Zertifikat manuell in Ihrer Zertifizierungsstelle oder löschen Sie den iPSK-Schlüssel aus Ihrer RADIUS-Datenbank. Schritt drei: Senden Sie ein RADIUS CoA, um alle aktiven WiFi-Sitzungen zu beenden. Die meisten RADIUS-Server für Unternehmen sowie Plattformen wie Purple können dies bei einem Deprovisionierungsereignis automatisch tun. Wenn Sie dies manuell tun, verwenden Sie die CoA-Schnittstelle Ihres RADIUS-Servers, um das Gerät des Benutzers über die MAC-Adresse oder die Sitzungs-ID zu trennen. Schritt vier: Bestätigen Sie, dass keine aktiven Sitzungen mehr vorhanden sind. Überprüfen Sie das Dashboard Ihres WiFi-Controllers. Auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet sollten Sie in der Lage sein, nach dem Benutzernamen oder dem Gerät zu suchen und zu bestätigen, 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 betreffenden Benutzer und das Datum. Speichern Sie diese in Ihrer ITSM- oder Sicherheitsinformations- und Ereignismanagement-Plattform. ISO 27001 Anhang A Kontrollziel A.9.2.6 fordert, dass Sie die Zugriffsrechte aller Mitarbeiter und Vertragspartner bei Beendigung des Arbeitsverhältnisses entziehen oder anpassen. Ihr Protokoll ist der Nachweis dafür. Schritt sechs: Wenn Sie WPA2 Shared PSK verwenden und nichts von den oben genannten Punkten zutrifft, ändern Sie das Passwort. Koordinieren Sie den Rollout auf allen Standorten und Geräten möglichst vor dem letzten Arbeitstag des ausscheidenden Mitarbeiters oder unmittelbar danach. Abschnitt vier: Was der Auditor erwartet. Sowohl ISO 27001 als auch SOC 2 verlangen den Nachweis, dass der Zugriff nach Beendigung des Arbeitsverhältnisses unverzüglich entzogen wird. Speziell für 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 ausgeschiedenen Mitarbeitern eingehalten wurde, typischerweise zehn bis fünfundzwanzig Personen, die aus den letzten zwölf Monaten ausgewählt wurden. Drittens: Ein Protokoll, das den Zeitstempel der Kontodeaktivierung und den Zeitstempel des Entzugs des WiFi-Zugriffs zeigt, wobei die Zeitspanne dazwischen klar erkennbar ist. Viertens: Die Bestätigung, dass keine Konten ehemaliger Mitarbeiter aktive WiFi-Sitzungen aufweisen. Wenn Sie WPA2 Shared PSK nutzen, können Sie für die Punkte drei und ein vier keine Nachweise erbringen. Es gibt kein benutzerbezogenes Protokoll. Das Beste, was Sie tun können, ist, das Datum der Passwortrotation vorzulegen und zu argumentieren, dass diese am oder vor dem letzten Arbeitstag des ausscheidenden Mitarbeiters abgeschlossen wurde. Auditoren weisen dies zunehmend zurück. Wenn Sie 802.1X mit SCIM nutzen, erfolgt die Protokollierung automatisch. Purple erfasst jedes SCIM-Deprovisionierungsereignis mit einem UTC-Zeitstempel, der Identity-Provider-Quelle, der eindeutigen Kennung des Benutzers und der resultierenden Aktion. Das ist ein sauberer, prüfbarer Nachweis. Abschnitt fünf: Fallstricke bei der Implementierung und wie man sie vermeidet. Der häufigste Fehler ist die Annahme, dass das Deaktivieren eines Kontos im Identity Provider ausreicht. Das ist nicht der Fall, es sei denn, Ihre WiFi-Plattform ist über SCIM oder eine ähnliche Echtzeitintegration mit diesem Identity Provider verbunden. Ohne diese Verbindung hat das WiFi-System keine Möglichkeit zu wissen, dass das Konto deaktiviert wurde. Der zweite Fallstrick ist das Certificate-Caching. Selbst mit OCSP weisen RADIUS-Server für einen konfigurierbaren Zeitraum (normalerweise 15 bis 60 Minuten) ein Cache-Verhalten für positive Antworten auf. Wenn Sie ein Zertifikat widerrufen und der RADIUS-Server eine positive Antwort im Cache gespeichert hat, authentifiziert sich das Gerät möglicherweise so lange weiter, bis der Cache abläuft. Stellen Sie Ihre OCSP-Cache-TTL in Hochsicherheitsumgebungen auf maximal 15 Minuten ein. Der dritte Fallstrick ist das Vergessen aktiver Sitzungen. Der Widerruf von Anmeldedaten verhindert neue Authentifizierungen, beendet jedoch keine bestehende WiFi-Sitzung. Senden Sie nach dem Widerruf von Anmeldedaten immer ein RADIUS CoA, um die Verbindung zum Gerät sofort zu trennen. Der vierte Fallstrick betrifft IoT- und gemeinsam genutzte Geräte. Ein Gerät, das auf die Identität eines ausscheidenden Mitarbeiters registriert ist, kann eine gemeinsam genutzte Workstation oder ein betriebliches Hardware-Teil sein. Überprüfen Sie vor dem Widerruf, ob 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 Anmeldedaten des ausscheidenden Mitarbeiters widerrufen. Abschnitt sechs: Fragen im Schnelldurchlauf. Frage: Wie schnell kann der zertifikatsbasierte WiFi-Zugang widerrufen werden? Mit OCSP und RADIUS CoA in unter 60 Sekunden ab dem Moment, in dem Sie das Zertifikat bei der Zertifizierungsstelle (CA) widerrufen. 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 Widerruf, ohne dass eine Zertifikatsinfrastruktur erforderlich ist. Purple kann iPSK-Schlüssel verwalten und eine Verbindung zu Ihrem Identity Provider herstellen, um den Lebenszyklus zu automatisieren. Zusammenfassung und nächste Schritte. Die Kernbotschaft lautet: Wenn Sie den WiFi-Zugang für eine einzelne Person nicht widerrufen können, ohne alle anderen zu beeinträchtigen, haben Sie ein Problem mit gemeinsam genutzten Anmeldedaten. Die Lösung sind benutzerspezifische Anmeldedaten – entweder Zertifikate über 802.1X EAP-TLS oder eindeutige Schlüssel über iPSK –, kombiniert mit einer SCIM-gesteuerten Deaktivierung, um den Widerruf in dem Moment zu automatisieren, in dem die HR-Abteilung handelt. Purple verbindet sich über SCIM mit Microsoft Entra ID, Okta und Google Workspace, läuft an 80.000 Live-Standorten und protokolliert jedes Deaktivierungsereignis für Audits. Wenn Sie sich auf ISO 27001 oder SOC 2 vorbereiten oder einfach die Lücke bei ausscheidenden Mitarbeitern schließen möchten, bevor es zu einem Vorfall kommt, ist dies der richtige Ausgangspunkt. Eine vollständige technische Analyse des Zertifikatswiderrufs und von OCSP finden Sie in unserem Leitfaden zu OCSP und Zertifikatswiderruf für die WiFi-Authentifizierung. Das umfassendere Bild zur Automatisierung von Eintritten, Wechseln und Austritten finden Sie in unserem Leitfaden für WiFi-Sicherheit in Unternehmen. Vielen Dank, dass Sie das Purple Technical Briefing gehört haben.