Die Compliance-Argumente für passwortfreies WiFi: HIPAA, PCI, ISO 27001

Kennwortloses WiFi, sprich 802.1X mit zertifikatsbasiertem EAP-TLS, ist weder durch HIPAA, PCI-DSS 4.0 noch ISO 27001:2022 zwingend vorgeschrieben. Alle drei Standards verlangen jedoch eine eindeutige Identifizierung, eine starke Verschlüsselung, einen unverzüglichen Widerruf und Audit-Protokolle. Ein gemeinsam genutztes Kennwort scheitert in jedem dieser Punkte. Gerätespezifische Zertifikate erfüllen diese Anforderungen konzeptbedingt und liefern genau die Protokolle, die ein Auditor stichprobenartig prüft.

Was bedeutet Compliance für kennwortloses WiFi tatsächlich?

Kennwortloses WiFi ersetzt ein gemeinsam genutztes Netzwerkkennwort durch ein Berechtigungsnachweis, der für jedes Gerät oder jede Person einzigartig ist. In Unternehmensnetzwerken bedeutet dies in der Regel IEEE 802.1X, den Standard für die portbasierte Netzwerkzugriffskontrolle. 802.1X übergibt die Entscheidung an einen RADIUS-Server. RADIUS ist das Protokoll, mit dem Access Points einen Authentifizierungsserver fragen, ob ein Gerät beitreten darf.

Die sicherste Methode ist EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security). Sowohl das Gerät als auch der Server weisen sich mit digitalen Zertifikaten aus. Es gibt kein Kennwort, das durch Phishing gestohlen, geteilt oder an eine Tafel im Personalraum geschrieben werden kann. Jede Sitzung leitet unter WPA2-Enterprise oder WPA3-Enterprise eigene Verschlüsselungsschlüssel ab.

Zwei verwandte Methoden müssen ebenfalls erwähnt werden:

• PEAP (Protected EAP) mit einem Kontonamen und Kennwort ist zwar 802.1X, aber nicht kennwortlos. Es erbt jede Schwachstelle des dahinterstehenden Kennworts.
• iPSK (identity pre-shared key) weist jedem Gerät seinen eigenen Schlüssel für einen einzigen Netzwerknamen zu. Dies ist eine praktische Brücke für Geräte, die kein Zertifikat speichern können.

"Compliance für kennwortloses WiFi" ist die Kurzform für eine einzige Frage: Erfüllt die Art und Weise, wie Ihre Mitarbeiter und Geräte dem Netzwerk beitreten, die Zugriffs-, Verschlüsselungs- und Protokollierungskontrollen, gegen die Sie geprüft werden? Keines der drei Frameworks in diesem Leitfaden nennt EAP-TLS explizit. Alle drei beschreiben jedoch Ergebnisse, die mit einem gemeinsam genutzten Kennwort nur schwer nachzuweisen sind.

Warum fällt ein gemeinsam genutztes WiFi-Kennwort bei einem Audit durch?

Ein Pre-Shared Key (PSK) ist ein einziges Geheimnis, das jedem im Netzwerk bekannt ist. Diese eine Tatsache führt zu vier Audit-Problemen.

• Keine Zuordnung. Jedes Gerät authentifiziert sich mit demselben Geheimnis. Protokolle zeigen eine MAC-Adresse, keine Person, und MAC-Adressen können manipuliert werden.
• Widerruf bedeutet Änderung. Das Entfernen eines einzelnen ausgeschiedenen Mitarbeiters bedeutet, dass der Schlüssel auf jedem Gerät geändert werden muss. Die PCI-DSS-Anforderung 2.3.2 schreibt diese Änderung auf Netzwerken, die mit Kartendaten verbunden sind, zwingend vor.
• Großer Schadensradius. Ein kompromittierter Schlüssel gefährdet das gesamte Netzwerk und oft alle Standorte, die ihn teilen.
• Lückenhafte Nachweise. Sie können einem Auditor nicht nachweisen, wer den Schlüssel kannte, wann er ihn erfahren hat oder dass ehemalige Mitarbeiter ihn nicht mehr besitzen.

Der zertifikatsbasierte Zugriff kehrt jeden dieser Punkte um. Jede Verbindung trägt eine eindeutige Identität. Durch den Widerruf eines einzelnen Zertifikats oder das Deaktivieren eines Kontos wird genau ein Gerät oder eine Person entfernt. Niemand kennt einen Schlüssel, also geht auch niemand mit einem.

Wie erfüllt zertifikatsbasiertes WiFi die Anforderungen von PCI-DSS 4.0?

PCI-DSS v4.0 wurde zur einzigen aktiven Version, als v3.2.1 am 31. März 2024 außer Kraft trat. Die mit einem zukünftigen Datum versehenen Anforderungen wurden am 31. März 2025 verbindlich. Die im Juni 2024 veröffentlichte begrenzte Überarbeitung v4.0.1 verwendet dieselben unten aufgeführten Anforderungsnummern.

Ist passwortloses WiFi PCI-konform?

Nicht von sich aus. Die PCI-Konformität bezieht sich auf die bewertete Umgebung, nicht auf ein Produkt. Passwortloses WiFi erfüllt oder vereinfacht jedoch diejenigen Anforderungen, die durch gemeinsam genutzte Passwörter mühsam werden:

• 1.3.3 erfordert Netzwerksicherheitskontrollen zwischen jedem drahtlosen Netzwerk und der Karteninhaber-Datenumgebung (CDE). Die CDE ist die Gesamtheit der Systeme, die Kartendaten speichern, verarbeiten oder übertragen. Drahtloser Datenverkehr in die CDE muss standardmäßig blockiert werden. Identitätsbasierter Zugriff ordnet autorisierte Geräte einem bestimmten VLAN (Virtual LAN) zu und verweigert alles andere.
• 2.3.1 und 2.3.2 verlangen, dass Sie die standardmäßigen Wireless-Schlüssel der Anbieter ändern. Sie müssen die Wireless-Verschlüsselungsschlüssel auch immer dann ändern, wenn eine Person, die diese kannte, das Unternehmen verlässt. Mit EAP-TLS kennt keine Person einen Schlüssel, sodass dieser Auslöser für das Ausscheiden von Mitarbeitern nie eintritt.
• 4.2.1.2 erfordert eine starke Kryptografie für die Authentifizierung und Übertragung in drahtlosen Netzwerken, die Kartendaten übertragen oder mit der CDE verbunden sind. PCI-DSS verbietet WEP seit 2010. Eine gegenseitige Zertifikatsauthentifizierung mit WPA2-Enterprise oder WPA3-Enterprise erfüllt diese Anforderung.
• 8.2.2 beschränkt gemeinsam genutzte und generische Konten auf Ausnahmefälle mit dokumentierter Begründung. Ein Netzwerkpasswort, das von 200 Mitarbeitern gemeinsam genutzt wird, ist schwer zu rechtfertigen.
• 8.2.5 verlangt, dass der Zugriff für ausgeschiedene Mitarbeiter unverzüglich gesperrt wird. Das Deaktivieren eines Kontos in Ihrem Identitätsanbieter erledigt dies.
• 10.2.1 und 10.5.1 erfordern Audit-Protokolle, die 12 Monate lang aufbewahrt werden müssen, wobei die letzten drei Monate sofort verfügbar sein müssen. RADIUS-Protokolle von 802.1X ordnen jede Verbindung einem Zertifikat oder Konto zu.

Passwortloses WiFi deckt die Anforderung 11.2.1 nicht ab. Diese Anforderung verlangt von Ihnen, mindestens alle drei Monate nach autorisierten und unautorisierten Access Points zu suchen. Dies bleibt Ihre Aufgabe, wie im Abschnitt zu den Einschränkungen erläutert.

Erfordert HIPAA zertifikatsbasiertes WiFi?

Nein. Die HIPAA-Sicherheitsregel (45 CFR Part 164, Subpart C) ist technologie-neutral und nennt kein bestimmtes Wireless-Protokoll. Sie legt Standards und Implementierungsspezifikationen fest, von denen einige "erforderlich" (required) und andere "adressierbar" (addressable) sind. Adressierbar bedeutet, dass Sie die Spezifikation dort implementieren, wo es angemessen und sinnvoll ist. Andernfalls dokumentieren Sie den Grund dafür und wählen eine gleichwertige Alternative.

Zertifikatsbasiertes WiFi lässt sich nahtlos auf die technischen Sicherheitsvorkehrungen in §164.312 übertragen:

• Eindeutige Identifizierung, §164.312(a)(2)(i), erforderlich. Jedes Gerät und jede Person im Netzwerk verfügt über eine eindeutige Identität.
• Verschlüsselung und Entschlüsselung, §164.312(a)(2)(iv), adressierbar. Schlüssel pro Sitzung schützen ePHI (elektronisch geschützte Gesundheitsinformationen), die über die Luft übertragen werden.
• Audit-Kontrollen, §164.312(b), erforderlich. RADIUS-Protokolle erfassen, welche Identität sich wann und von welchem Access Point aus angemeldet hat.- Authentifizierung von Personen oder Einrichtungen, §164.312(d), erforderlich. Ein Zertifikat beweist, dass das Gerät das ist, was es vorgibt zu sein. Die Verknüpfung mit dem Konto eines Identitätsanbieters weitet diesen Nachweis auf die Person aus.
• Übertragungssicherheit, §164.312(e)(1). Integritätskontrollen und Verschlüsselung sind beide adressierbare Spezifikationen unter diesem Standard.

Die administrativen Sicherheitsvorkehrungen sind ebenfalls wichtig. In der Risikoanalyse gemäß §164.308(a)(1)(ii)(A) dokumentieren Sie, warum Ihre Wireless-Kontrollen angemessen sind. Kündigungsverfahren gemäß §164.308(a)(3)(ii)(C) lassen sich leichter nachweisen, wenn das Deaktivieren eines einzelnen Kontos den Netzwerkzugriff entzieht.

Achten Sie auf die künftige Entwicklung. Im Januar 2025 hat das US-Gesundheitsministerium (HHS) einen Regelungsentwurf veröffentlicht. Dieser würde die Unterscheidung zwischen "erforderlich" und "adressierbar" weitgehend aufheben. Zudem würde er Verschlüsselung und Multi-Faktor-Authentifizierung mit wenigen Ausnahmen obligatorisch machen. Es handelt sich um einen Entwurf, nicht um eine endgültige Regelung. Zertifikatsbasierter Zugriff steht bereits auf der richtigen Seite dieser Entwicklung.

Was sagt ISO 27001 über Wireless?

Die ISO/IEC 27001:2022 enthält keine Kontrolle namens "Wireless". Anhang A listet 93 Kontrollen in vier Themenbereichen auf, von denen sich einige direkt darauf beziehen, wie Mitarbeiter einem Netzwerk beitreten. Die ISO/IEC 27002:2022, der Leitfaden für die Umsetzung, befasst sich unter Kontrolle 8.22 mit Wireless. Sie stellt fest, dass Wireless-Perimeter schlecht definiert sind. Für sensible Umgebungen wird empfohlen, den Wireless-Zugriff wie eine externe Verbindung zu behandeln, bis er ein Gateway passiert.

Die Kontrollen, die ein Auditor prüfen wird:

• 5.15 Zugriffskontrolle und 5.18 Zugriffsrechte. Regeln dafür, wer beitreten darf und wie dieser Zugriff bereitgestellt und entzogen wird.
• 5.16 Identitätsmanagement und 5.17 Authentifizierungsinformationen. Identitäten und Geheimnisse, die über ihren gesamten Lebenszyklus verwaltet werden. Ein gemeinsam genutztes Passwort ist eine Authentifizierungsinformation, die Sie keiner einzelnen Person zuordnen können.
• 8.5 Sichere Authentifizierung. Authentifizierungstechnologie, die der Sensibilität des Zugriffs entspricht.
• 8.15 Protokollierung und 8.16 Überwachung von Aktivitäten. Protokolle, die Ereignisse aufzeichnen, und Nachweise darüber, dass diese überprüft werden.
• 8.20 Netzwerksicherheit, 8.21 Sicherheit von Netzdiensten und 8.22 Segmentierung von Netzwerken.
• 8.24 Verwendung von Kryptographie.
• 5.19 und 5.23. Lieferantenbeziehungen und Cloud-Dienste, die gelten, wenn Ihre Authentifizierung als Cloud-Dienst läuft.

Organisationen, die nach ISO/IEC 27001:2013 zertifiziert sind, hatten bis zum 31. Oktober 2025 Zeit für den Übergang. Wenn Ihre Anwendbarkeitserklärung (Statement of Applicability) noch die Nummerierung von 2013 wie A.9 oder A.13 verwendet, aktualisieren Sie diese.

Wie sich die drei Frameworks auf passwortloses WiFi übertragen lassen

Kontrolle	Framework	Was gefordert wird	Gemeinsam genutztes Passwort (PSK)	Zertifikatsbasiert (EAP-TLS)
1.3.3	PCI DSS 4.0	Default-Deny-Prinzip zwischen Wireless und der CDE	Jedes Gerät mit dem Schlüssel landet im selben Segment	Identitätsbasiertes VLAN, standardmäßig blockieren
2.3.2	PCI DSS 4.0	Wireless-Schlüssel ändern, wenn jemand geht, der sie kannte	Bei jedem Abgang auf jedem Gerät rotieren	Keine Person besitzt einen Schlüssel; ein einzelnes Zertifikat widerrufen
4.2.1.2	PCI DSS 4.0	Starke Kryptografie für die drahtlose Authentifizierung und Übertragung	Die Stärke hängt von der Qualität des Passphrases ab	Gegenseitige Zertifikate, Schlüssel pro Sitzung
8.2.2	PCI DSS 4.0	Gemeinsam genutzte Konten nur bei dokumentierter Ausnahme	Systembedingt gemeinsam genutzt	Ein Anmeldedaten-Satz pro Gerät oder Person
10.5.1	PCI DSS 4.0	12 Monate Protokolle, drei Monate sofort verfügbar	Protokolle zeigen nur MAC-Adressen	Protokolle nennen das Zertifikat oder Konto
§164.312(a)(2)(i)	HIPAA	Eindeutige Identifizierung (erforderlich)	Durch die Netzwerk-Anmeldedaten nicht erfüllt	Systembedingt erfüllt
§164.312(b)	HIPAA	Audit-Kontrollen (erforderlich)	Schwache Zuordnung	Jede Sitzung ist zuordnungsbar
§164.312(e)(1)	HIPAA	Übertragungssicherheit	Verschlüsselt, aber der Schlüssel ist allen Mitarbeitern bekannt	Verschlüsselt mit Schlüsseln, die keine Person kennt
5.17	ISO 27001:2022	Zuweisung und Verwaltung von Authentifizierungsinformationen	Kann nicht einer einzelnen Person zugewiesen werden	Ausgestellt, erneuert und widerrufen pro Identität
5.18	ISO 27001:2022	Bereitstellung und Entzug von Zugriffsrechten	Der Entzug erfordert eine netzwerkweite Schlüsseländerung	Der Entzug folgt dem Identitätsanbieter
8.22	ISO 27001:2022	Segmentierung von Netzwerken	Ein Segment pro Schlüssel	Segment pro Rolle oder Gerätetyp

Welche Nachweise fordert ein Auditor an?

Auditoren prüfen das Design, die Konfiguration und den Betrieb. Das Design sind Ihre Diagramme. Die Konfiguration sind Ihre Exporte. Der Betrieb sind Ihre Protokolle und Stichproben. Stellen Sie das Paket vor der Feldarbeit zusammen, nicht erst währenddessen.

Nachweis-Element	Was es zeigt	PCI DSS 4.0	HIPAA	ISO 27001:2022
Netzwerk- und Datenflussdiagramme, die die Grenzen für Mitarbeiter, Gäste und CDE zeigen	Segmentierungsdesign	1.2.3, 1.2.4	§164.308(a)(1)	8.20, 8.22
Firewall- oder ACL-Regeln zwischen Mitarbeiter-WiFi-VLANs und der CDE	Default-Deny in der Praxis	1.3.3	§164.312(e)(1)	8.22
Export der SSID-Konfiguration, der den Enterprise-Modus und EAP-TLS zeigt	Starke Authentifizierung und Verschlüsselung	4.2.1.2	§164.312(a)(2)(iv)	8.5, 8.24
Zertifikatsrichtlinie: ausstellende CA, Gültigkeitsdauer, Erneuerung, Widerruf	Lebenszyklus von Authentifizierungsinformationen	4.2.1.2	§164.312(d)	5.17
Stichprobe von ausgeschiedenen Mitarbeitern: Zeitpunkt der Kontodeaktivierung im Vergleich zur letzten Netzwerkauthentifizierung	Rechtzeitiger Widerruf	8.2.5	§164.308(a)(3)(ii)(C)	5.18
RADIUS-Protokolle mit Aufbewahrungseinstellungen	Zuordnung und Aufbewahrung	10.2.1, 10.5.1	§164.312(b)	8.15
Inventar der Access Points und vierteljährliche Ergebnisse von Rogue-Scans	Kontrolle autorisierter und unautorisierter Access Points	11.2.1, 11.2.2	§164.308(a)(1)	8.16
Zertifikate und Verträge von Lieferanten	Absicherung durch Drittanbieter	12.8	§164.308(b) wenn der Lieferant ePHI verarbeitet	5.19, 5.23

Wie weisen Sie WiFi-Kontrollen gegenüber einem Auditor nach?

Führen Sie den Test für ausgeschiedene Mitarbeiter zuerst selbst durch. Das ist der Test, den ein gemeinsam genutztes Passwort nicht sauber bestehen kann.

1. Exportieren Sie Ihre HR-Liste der ausgeschiedenen Mitarbeiter für den Audit-Zeitraum.
2. Wählen Sie eine Stichprobe, zum Beispiel 10 bis 25 ausgeschiedene Mitarbeiter über verschiedene Standorte hinweg.
3. Rufen Sie für jeden den Zeitpunkt der Kontodeaktivierung von Ihrem Identitätsanbieter ab.4. Rufen Sie die letzte erfolgreiche Netzwerkauthentifizierung für diese Identität aus den RADIUS-Protokollen ab.
4. Jede Authentifizierung nach dem Deaktivierungszeitpunkt ist ein Befund. Beheben Sie die Ursache, bevor der Auditor sie findet.

In einem PSK-Netzwerk liefert Schritt vier keine brauchbaren Ergebnisse. Kein Protokoll verknüpft eine Verbindung mit der ausgeschiedenen Person, sodass Sie nicht beweisen können, dass sie aufgehört hat, sich zu verbinden.

Wo lässt sich passwortfreies WiFi in Ihre bestehende Infrastruktur integrieren?

Sie benötigen keine neuen Access Points. 802.1X ist eine Standardfunktion von Enterprise Access Points. Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet.

Purple Staff WiFi nutzt Identity-Based Networks. Der Netzwerkzugriff folgt Ihrem Identity Provider: Microsoft Entra ID, Okta oder Google Workspace. Neueinsteiger erhalten Zugriff, sobald ihr Konto erstellt wird. Rollenwechsler wechseln das Netzwerksegment, wenn sich ihre Rolle ändert. Ausscheidende Mitarbeiter verlieren den Zugriff, wenn das Konto deaktiviert wird. Dieser JML-Prozess (Joiners, Movers, Leavers) ist genau das, was saubere Belege für PCI DSS 8.2.5, HIPAA §164.308(a)(3)(ii)(C) und ISO 27001 Control 5.18 liefert.

Ihr Gastnetzwerk bleibt getrennt. PCI DSS 1.3.3 gilt hierfür ebenso wie für Mitarbeiternetzwerke: Gastverkehr in die CDE muss blockiert werden. Die Guest WiFi Pläne von Purple sind für Besucherdaten GDPR- und CCPA-konform, wie in Connect vs Capture dargelegt.

Für Ihre Lieferantenakte besitzt Purple eine ISO 27001- und Cyber Essentials-Zertifizierung und ist GDPR- und CCPA-konform. Die eigenen Plattformdaten von Purple zeigen eine Betriebszeit von 99,999 % an über 80.000 Live-Standorten. Ihr Auditor wird dies als Lieferantenzusicherung betrachten, nicht als Beweis für Ihre eigenen Kontrollen.

Wie sieht Compliance bei passwortfreiem WiFi in der Praxis aus?

Die drei folgenden Szenarien sind Praxisbeispiele. Jedes nennt seine Annahmen, damit Sie die Berechnung für Ihren eigenen Bestand nachvollziehen können.

Ein Hotel mit 200 Zimmern: Wegfall der PCI-Schlüsselrotation

Situation. Ein Hotel mit 200 Zimmern betreibt 140 Mitarbeiter in einem einzigen PSK-Netzwerk. Rezeptions-PCs und Restaurant-Tablets in diesem Netzwerk greifen auf das Zahlungssystem zu, was es in den PCI-Geltungsbereich bringt. Angenommen wird eine jährliche Personalfluktuation von 30 %, also 42 ausscheidende Mitarbeiter pro Jahr.

Was getan wurde. Das Mitarbeiternetzwerk wurde auf 802.1X mit EAP-TLS umgestellt, verknüpft mit dem Identity Provider der Hotelgruppe. Zahlungsgeräte wurden in ein dediziertes VLAN mit Default-Deny-Regeln für alle anderen Netzwerke verschoben. Das Gastnetzwerk wurde von beiden isoliert.

Ergebnis. Die Schlüsselrotationen nach Anforderung 2.3.2 sinken von 42 pro Jahr, die jedes Mal jedes Mitarbeitergerät betrafen, auf Null. Jeder ausscheidende Mitarbeiter wird durch Deaktivieren eines einzigen Kontos entfernt. Die Stichprobe der ausgeschiedenen Mitarbeiter verfügt nun über ein Protokoll zum Abgleich. Betreiber in Hotels mit Saisonarbeitskräften verzeichnen die größte Reduzierung, da die Fluktuation die Rotation antreibt.

Eine Einzelhandelskette mit 40 Filialen: Verringerung des Schadensradius

Situation. Eine Kette mit 40 Filialen nutzt in allen Stores einen einzigen PSK für Handscanner zur Bestandsaufnahme und Laptops im Backoffice. Die Filialleiter kennen den Schlüssel. Ein ehemaliger Manager postet ihn online.

Was getan wurde. Verwaltete Laptops wurden auf EAP-TLS mit Zertifikaten umgestellt, die über die Geräteverwaltung ausgestellt wurden. Scanner, die keine Zertifikate speichern konnten, wurden auf iPSK mit einem Schlüssel pro Gerät in einem eingeschränkten VLAN umgestellt. Das Access-Point-Inventar jeder Filiale wurde unter Anforderung 11.2.2 dokumentiert.

Ergebnis. Das Risiko durch ein einzelnes kompromittiertes Passwort sinkt von 40 Filialen auf ein einziges Gerät. Das Sperren dieses Geräts erfordert nur eine einzige Aktion und lässt die anderen Scanner verbunden. Die Kette kann einem Auditor nun ein Inventar pro Gerät anstelle eines einzigen gemeinsam genutzten Schlüssels vorlegen. Dasselbe Muster eignet sich für jedes Einzelhandelsunternehmen mit einer Mischung aus verwalteten und headless Geräten.

Ein Gesundheitsamt des Landkreises: HIPAA-Zuordnung in 12 Kliniken

Ausgangslage. Ein US-amerikanisches Gesundheitsamt betreibt 12 Kliniken. Das medizinische Personal nutzt gemeinsam genutzte Tablets, um auf die elektronische Patientenakte zuzugreifen. Jede Klinik hat ihr eigenes Netzwerkpasswort, was zu 12 gemeinsam genutzten Zugangsdaten und keinerlei Zuordnung in den Netzwerkprotokollen führt.

Was getan wurde. Tablets erhielten Gerätezertifikate. Das medizinische Personal meldet sich mit seinem Identity-Provider-Konto an, sodass jede Sitzung ein Gerät mit einer Person verknüpft. RADIUS-Protokolle speisen das Protokollmanagement der Abteilung. Die Aufbewahrungsfrist wurde auf den sechsjährigen Dokumentationszeitraum gemäß §164.316(b)(2) festgelegt, in dem die Abteilung Protokolle als Dokumentation klassifiziert.

Ergebnis. Die Anzahl der gemeinsam genutzten Netzwerk-Zugangsdaten sinkt von 12 auf Null. Die Risikoanalyse kann die Verschlüsselungsspezifikation als implementiert erfassen, anstatt eine Alternative zu dokumentieren. Die Audit-Kontrollen gemäß §164.312(b) zeigen nun, welche Person auf welchem Gerät sich wann in welchem Kliniknetzwerk angemeldet hat. Teams im öffentlichen Gesundheitswesen, die sowohl HIPAA als auch staatlichen Audits unterliegen, können dasselbe Nachweispaket wiederverwenden. Die Geräte der Besatzung in Zügen folgen demselben Modell mit einer Identität pro Tablet in jedem Waggon und Depot.

Welche Grenzen sollten Sie kennen?

• Es ist kein Compliance-Zertifikat. Passwortloses WiFi erfüllt bestimmte Kontrollen. Der Umfang, die Risikoanalyse und der Rest des jeweiligen Frameworks liegen weiterhin in Ihrer Verantwortung.
• Unbefugte Access Points müssen weiterhin getestet werden. PCI DSS 11.2.1 erfordert vierteljährliche Tests auf autorisierte und unbefugte Access Points. Der zertifikatsbasierte Zugriff erkennt kein unbefugtes Gerät, das an einen Switch in einer Filiale angeschlossen ist.
• Zertifikate laufen ab. Sie benötigen eine Zertifizierungsstelle, eine Registrierungsmethode und einen Erneuerungsprozess. Eine verpasste Erneuerung trennt jedes Gerät, dessen Zertifikat dasselbe Ablaufdatum hat.
• Nicht jedes Gerät kann ein Zertifikat speichern. Drucker, Scanner und einige medizinische Geräte können dies nicht. Nutzen Sie iPSK oder ein segmentiertes Netzwerk und dokumentieren Sie die Ausnahme.
• PEAP ist keine Abkürzung. PEAP mit Passwörtern behält das Passwortrisiko bei. Wenn Geräte das Serverzertifikat nicht validieren, kann ein gefälschter Access Point Zugangsdaten abfangen.
• Protokolle helfen nur, wenn sie aufbewahrt und überprüft werden. Legen Sie die Aufbewahrungsfrist für PCI DSS auf 12 Monate fest. Weisen Sie einen Überprüfungszyklus für die ISO 27001-Kontrolle 8.16 nach.

Was sollten Sie als Nächstes tun?

1. Klassifizieren Sie jeden Netzwerknamen. Kennzeichnen Sie, welche die CDE, ePHI oder keines von beiden berühren. Dies entscheidet, welches Framework für das jeweilige Netzwerk gilt.
2. Führen Sie den Leaver-Test jetzt aus. Wenn Sie ihn nicht abschließen können, haben Sie Ihr erstes Audit-Risiko identifiziert.
3. Wählen Sie Zugangsdaten pro Geräteklasse. EAP-TLS für verwaltete Laptops, Telefone und Tablets. iPSK für gerätelose Systeme.
4. Aktualisieren Sie Ihre Kontrolldokumentation. Bilden Sie die Änderung in Ihrer Anwendbarkeitserklärung, Ihrer HIPAA-Risikoanalyse oder Ihrem PCI DSS-Scoping-Dokument ab.
5. Führen Sie ein Pilotprojekt an einem Standort durch. Weisen Sie die Zertifikatsregistrierung, die VLAN-Zuweisung und den Widerruf für ausgeschiedene Mitarbeiter nach, bevor Sie die Lösung im gesamten Unternehmen einführen.
6. Erstellen Sie das Nachweis-Paket. Verwenden Sie die obige Nachweistabelle als Ihre Checkliste, drei Monate vor der Feldforschung.

Häufig gestellte Fragen

Ist passwortloses WiFi PCI-konform?

Passwortloses WiFi ist an sich nicht PCI-konform, da PCI DSS Ihre Umgebung und nicht ein bestimmtes Produkt bewertet. Es erfüllt die Anforderungen 2.3.2, 4.2.1.2, 8.2.2 und 8.2.5 jedoch sauberer als ein gemeinsam genutztes Passwort, und seine RADIUS-Protokolle unterstützen die Anforderung 10. Sie benötigen weiterhin Default-Deny-Kontrollen zwischen drahtlosen Netzwerken und der Karteninhaberdaten-Umgebung gemäß 1.3.3 sowie vierteljährliche Tests auf unbefugte Access Points gemäß 11.2.1.

Verlangt HIPAA zertifikatsbasiertes WiFi?

Nein, HIPAA nennt keine bestimmte drahtlose Technologie. Die Sicherheitsregel verlangt eine eindeutige Identifizierung, Audit-Kontrollen sowie die Authentifizierung von Personen oder Einheiten und behandelt die Verschlüsselung als adressierbar. Zertifikatsbasiertes WiFi erfüllt all diese Anforderungen standardmäßig, was die Verteidigung Ihrer Risikoanalyse erleichtert. Ein im Januar 2025 vom HHS vorgeschlagener Regelentwurf würde Verschlüsselung und Multi-Faktor-Authentifizierung mit wenigen Ausnahmen vorschreiben. Es handelt sich um einen Vorschlag, nicht um eine endgültige Regelung.

Was sagt ISO 27001 über drahtlose Netzwerke?

ISO/IEC 27001:2022 enthält keine spezifische Kontrolle für drahtlose Netzwerke. Auditoren prüfen drahtlose Netzwerke anhand der Annex A-Kontrollen 5.15 bis 5.18 für Zugriff und Identität, 8.5 für sichere Authentifizierung, 8.15 für Protokollierung und 8.20 bis 8.22 für Netzwerksicherheit und -segmentierung. Die Leitlinien von ISO/IEC 27002:2022 unter 8.22 empfehlen, den drahtlosen Zugriff in sensiblen Umgebungen als externe Verbindung zu behandeln, bis er ein Gateway passiert.

Wie weise ich einem Auditor WiFi-Kontrollen nach?

Sie weisen WiFi-Kontrollen durch Konfigurationen, Protokolle und einen Leaver-Test nach. Legen Sie Netzwerkdiagramme vor, die die Grenzen für drahtlose Netzwerke und CDE aufzeigen, SSID-Exporte, die die Enterprise-Authentifizierung belegen, Ihre Zertifikatsrichtlinie, RADIUS-Protokolle der letzten 12 Monate sowie vierteljährliche Ergebnisse von Scans nach unbefugten Netzwerken. Führen Sie dann einen Leaver-Test an einer Stichprobe durch, indem Sie den Zeitpunkt der Deaktivierung des Benutzerkontos mit der letzten erfolgreichen Netzwerkauthentifizierung des ausgeschiedenen Mitarbeiters vergleichen. Jede Authentifizierung nach der Deaktivierung gilt als Feststellung.

Funktioniert Purple Staff WiFi mit unseren vorhandenen Access Points?

Ja, Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Sie behalten Ihre Access Points und Switches. Purple verbindet den Netzwerkzugriff mit Microsoft Entra ID, Okta oder Google Workspace - so erfordert die Abkehr von einem gemeinsam genutzten Passwort kein aufwendiges Hardware-Austauschprojekt.

Was ist mit Geräten, auf denen kein Zertifikat installiert werden kann?

Verwenden Sie iPSK oder ein separates, segmentiertes Netzwerk für diese Geräte. iPSK weist jedem Gerät einen eigenen Schlüssel auf demselben Netzwerknamen zu. Wenn Sie also ein Gerät sperren, bleiben die anderen verbunden. Platzieren Sie bildschirmlose Geräte wie Drucker und Scanner in einem eingeschränkten VLAN. Dokumentieren Sie die geschäftliche Begründung in Ihrer Risikoanalyse oder Ihrer Erklärung zur Anwendbarkeit (Statement of Applicability) und überprüfen Sie jede Ausnahme bei jedem Audit-Zyklus.

Macht uns die ISO 27001 Zertifizierung von Purple konform?

Nein, die Zertifizierung eines Lieferanten geht nicht auf Sie über. Die Zertifizierungen von Purple nach ISO 27001, Cyber Essentials, GDPR und CCPA dienen als Nachweis für Ihre Lieferantenbewertung gemäß den ISO 27001 Kontrollen 5.19 und 5.23 sowie der PCI-DSS-Anforderung 12.8. Ihr eigener Umfang, Ihre Risikoanalyse, Konfiguration und Protokolle müssen weiterhin den jeweiligen Anforderungen entsprechen und werden von Ihrem Auditor direkt geprüft.