Migration von On-Premises RADIUS (NPS) zu RADIUS as a Service

PODCAST-SKRIPT: Migration von On-Premises-RADIUS (NPS) zu RADIUS as a Service Dauer: ~10 Minuten | Stimme: Britisches Englisch, männlich, Tonfall eines Senior Consultants --- SEGMENT 1: EINFÜHRUNG UND KONTEXT Willkommen zur technischen Briefing-Reihe von Purple WiFi. Heute befassen wir uns mit einer Migration, die derzeit auf der Roadmap einer beträchtlichen Anzahl von IT-Teams in Unternehmen steht: dem Wechsel von On-Premises-RADIUS – konkret dem Network Policy Server von Microsoft – zu einem Cloud-basierten RADIUS as a Service-Modell. Wenn Sie die WiFi-Authentifizierung in einer Hotelgruppe, einem Einzelhandelsnetz, einem Stadion oder einem Campus im öffentlichen Sektor verwalten, ist dies für Sie von direkter Relevanz. Das On-Premises-NPS-Modell hat uns fast zwei Jahrzehnte lang gute Dienste geleistet, aber der betriebliche Aufwand, das Risiko eines Single-Point-of-Failure und die Skalierungsbeschränkungen lassen sich immer schwerer rechtfertigen – insbesondere, da Cloud-native Alternativen mittlerweile Zuverlässigkeit auf Enterprise-Niveau zu einem Bruchteil der Gesamtbetriebskosten bieten. In den nächsten zehn Minuten werden wir die technische Architektur beider Ansätze behandeln, eine strukturierte Migrationsmethodik durchgehen, zwei reale Implementierungsszenarien betrachten und mit den wichtigsten Entscheidungsrahmen abschließen, die Sie benötigen, um diese Entscheidung mit gutem Gefühl zu treffen. Legen wir los. --- SEGMENT 2: TECHNISCHER DEEP-DIVE Zunächst sollten wir sicherstellen, dass wir uns einig sind, was RADIUS in Ihrem Netzwerk-Stack eigentlich tut. RADIUS – Remote Authentication Dial-In User Service – ist das in RFC 2865 definierte Protokoll, das die Authentifizierung, Autorisierung und Abrechnung für den Netzwerkzugriff übernimmt. Im WiFi-Kontext ist es das Rückgrat der portbasierten Zugriffskontrolle nach IEEE 802.1X. Wenn sich ein Gerät mit einer WPA2-Enterprise- oder WPA3-Enterprise-SSID verbindet, fungiert der Access Point als RADIUS-Client – was wir als Network Access Server bezeichnen – und leitet die Authentifizierungsanfrage an den RADIUS-Server weiter. Der Server validiert die Anmeldedaten, in der Regel gegen Active Directory oder ein LDAP-Verzeichnis, und gibt eine Access-Accept- oder Access-Reject-Antwort zurück. Das ist der grundlegende Ablauf. Beim On-Premises-NPS-Modell – Network Policy Server ist die in Windows Server integrierte RADIUS-Implementierung von Microsoft – führen Sie diese Authentifizierungslogik auf eigener Hardware aus, in einem Rechenzentrum oder Serverraum, den Sie selbst warten. Der NPS-Server enthält Ihre Netzwerkrichtlinien, Ihre Zertifikatsinfrastruktur für EAP-TLS oder PEAP-MSCHAPv2 und Ihre Verbindungsanforderungsrichtlinien. Es funktioniert. Es ist ausgereift. Aber es bringt eine Reihe von betrieblichen Realitäten mit sich, die sich im Laufe der Zeit summieren. Die erste ist die Hardware-Abhängigkeit. Ihr NPS-Server ist eine physische oder virtuelle Maschine, die Patches, Kapazitätsplanung und letztendlich einen Hardware-Austausch erfordert. Bei einer Bereitstellung an mehreren Standorten – beispielsweise einer Hotelgruppe mit Häusern in ganz Großbritannien – betreiben Sie entweder ein zentralisiertes NPS mit WAN-Abhängigkeit oder Sie stellen NPS-Instanzen an jedem Standort bereit und verwalten sie einzeln. Beides ist nicht elegant. Der zweite Punkt ist die Verfügbarkeit. Eine einzelne NPS-Instanz stellt einen Single Point of Failure für Ihre gesamte Authentifizierungsinfrastruktur dar. Natürlich können Sie NPS in einem Failover-Paar bereitstellen, aber das verdoppelt Ihren Hardware- und Lizenzierungsaufwand und bietet Ihnen immer noch nicht die geografische Redundanz, die ein Cloud-Dienst von Haus aus bietet. Der dritte Punkt ist die Skalierbarkeit. NPS wurde für Unternehmens-LAN-Umgebungen entwickelt. Wenn Sie während einer Stadionveranstaltung oder zu Spitzenzeiten in einem Konferenzzentrum Tausende von gleichzeitigen Authentifizierungsanfragen verarbeiten, werden die Durchsatzgrenzen einer einzelnen NPS-Instanz sehr deutlich. Die Authentifizierungslatenz steigt sprunghaft an, und Benutzer erleben Verbindungsfehler genau in dem Moment, in dem Sie es sich am wenigsten leisten können. RADIUS as a Service löst alle drei dieser Einschränkungen architektonisch. Der Cloud-RADIUS-Anbieter betreibt ein verteiltes, georedundantes Cluster von RADIUS-Servern. Ihre Access Points verweisen auf in der Cloud gehostete RADIUS-Endpunkte und nicht auf einen lokalen Server. Authentifizierungsanfragen werden über das Cluster hinweg lastverteilt, und das Failover erfolgt automatisch und transparent. Der Anbieter kümmert sich um Patching, Kapazitätsskalierung und Zertifikatsverwaltung. Aus Ihrer Sicht als Netzwerkbetreiber wird RADIUS zu einem konsumierten Dienst statt zu einer verwalteten Komponente. Die Authentifizierungsprotokolle selbst ändern sich nicht. Sie führen weiterhin IEEE 802.1X mit EAP-TLS, PEAP-MSCHAPv2 oder EAP-TTLS aus, je nach Ihrem Client-Geräte-Mix. Der Unterschied liegt darin, wo der RADIUS-Server betrieben wird und wer für dessen betriebliche Kontinuität verantwortlich ist. Es gibt hier einen wichtigen Sicherheitsaspekt, den ich direkt ansprechen möchte, da er in fast jedem Kundengespräch zur Sprache kommt. Die Verlagerung von RADIUS in die Cloud bedeutet, dass Ihr Authentifizierungsverkehr das öffentliche Internet durchquert, um den Cloud-RADIUS-Endpunkt zu erreichen. Dies wird durch zwei Mechanismen entschärft. Erstens wird der RADIUS-Verkehr zwischen dem Network Access Server und dem RADIUS-Server durch ein Shared Secret und eine MD5-basierte Nachrichtenauthentifizierung geschützt. Zweitens, und das ist für moderne Bereitstellungen noch wichtiger, sollten Sie RadSec nutzen – RADIUS über TLS, definiert in RFC 6614 –, wodurch die gesamte RADIUS-Kommunikation in einen TLS-Tunnel verpackt wird. Dies bietet Ihnen eine Verschlüsselung auf Transportebene, die mit HTTPS vergleichbar ist, wodurch die MD5-Schwachstelle beseitigt und eine gegenseitige Authentifizierung zwischen dem NAS und dem RADIUS-Server gewährleistet wird. Jeder Cloud-RADIUS-Anbieter, der in Betracht gezogen wird, sollte RadSec standardmäßig unterstützen. Auf der Seite der Identitätsintegration unterstützen Cloud-RADIUS-Dienste in der Regel LDAP- und LDAPS-Verbindungen zurück zu Ihrem lokalen Active Directory oder eine native Integration mit Azure Active Directory und Entra ID über SAML oder SCIM. Das bedeutet, dass Sie Ihr Benutzerverzeichnis nicht migrieren müssen – der Cloud-RADIUS-Dienst fragt Ihren vorhandenen Identitätsspeicher ab und behält Ihre bestehenden Prozesse für das Benutzer-Lifecycle-Management bei. Für compliance-bewusste Unternehmen – und das betrifft jeden, der Zahlungskartendaten unter PCI DSS oder personenbezogene Daten unter der GDPR verarbeitet – bieten Cloud-RADIUS-Anbieter mit SOC 2 Type II-Zertifizierung und ISO 27001-Akkreditierung ein höheres Sicherheits- und Compliance-Niveau, als es die meisten Organisationen mit einer selbstverwalteten NPS-Infrastruktur erreichen können. --- SEGMENT 3: IMPLEMENTIERUNGSEMPFEHLUNGEN UND STOLPERSTEINE Lassen Sie uns nun darüber sprechen, wie Sie diese Migration tatsächlich durchführen, ohne Ihre Authentifizierungsinfrastruktur offline zu nehmen. Die von mir empfohlene Methodik ist ein Fünf-Phasen-Ansatz. Phase eins ist die Auditierung und Inventarisierung. Dokumentieren Sie jeden RADIUS-Client – jeden Access Point, jeden Switch, jeden VPN-Konzentrator – zusammen mit seinem aktuellen Shared Secret, der verwendeten EAP-Methode und allen herstellerspezifischen Attributen in Ihren NPS-Richtlinien. Das ist zwar eine mühsame Arbeit, aber das Überspringen dieses Schritts ist die Hauptursache für das Scheitern von Migrationen. Phase zwei ist die Pilotbereitstellung. Richten Sie Ihre Cloud-RADIUS-Instanz ein und verweisen Sie mit einer Nicht-Produktions-SSID oder einem einzelnen Teststandort darauf. Validieren Sie, dass Ihre EAP-Methode durchgängig funktioniert, dass Ihre Identitätsintegration aktiv ist und dass Ihre Accounting-Daten korrekt fließen. Phase drei ist der Parallelbetrieb. Dies ist der entscheidende Schritt zur Risikominimierung. Konfigurieren Sie Ihre Access Points sowohl mit dem lokalen NPS-Server als auch mit dem Cloud-RADIUS-Server als Authentifizierungsziele, wobei der Cloud-Dienst als primärer Dienst und der NPS als Fallback dient. Führen Sie diese Konfiguration mindestens zwei Wochen lang über einen vollständigen Geschäftszyklus hinweg aus. Überwachen Sie die Erfolgsraten der Authentifizierung, die Latenzzeiten und etwaige Abweichungen bei den Richtlinien. Phase vier ist die Umstellung. Entfernen Sie die NPS-Fallback-Konfiguration und setzen Sie Cloud-RADIUS als Ihre einzige Authentifizierungsinfrastruktur ein. Führen Sie dies während eines geplanten Wartungsfensters durch und halten Sie ein dokumentiertes und getestetes Rollback-Verfahren bereit. Phase fünf ist die Außerbetriebnahme. Sobald Sie nach der Umstellung dreißig Tage lang einen stabilen Betrieb nachgewiesen haben, nehmen Sie die NPS-Server außer Betrieb und geben Sie die Hardware- oder VM-Ressourcen wieder frei. Die am häufigsten auftretenden Stolpersteine sind: Probleme mit der Zertifikatsvertrauenskette – insbesondere Client-Geräte, die dem Zertifikat des Cloud-RADIUS-Servers nicht vertrauen, weil sich die CA nicht in ihrem vertrauenswürdigen Speicher befindet. Beheben Sie dies vor der Umstellung über Ihr MDM oder Ihre Gruppenrichtlinien. Der zweite häufige Stolperstein sind Firewall-Regeln. Cloud-RADIUS erfordert ausgehendes UDP 1812 und 1813 von Ihren Access Points zu den Cloud-Endpunkten oder TCP 2083 für RadSec. Stellen Sie sicher, dass Ihre Netzwerkperipherie diesen Datenverkehr zulässt. Drittens: Die Komplexität von Shared Secrets. Wenn Ihre bestehenden NPS Shared Secrets schwach sind, nutzen Sie die Migration als Gelegenheit, auf kryptografisch starke Secrets umzustellen oder, noch besser, auf RadSec umzusteigen und Shared Secrets ganz abzuschaffen. --- SEGMENT 4: SCHNELLE FRAGEN & ANTWORTEN Lassen Sie mich die Fragen durchgehen, die mir zu diesem Thema am häufigsten gestellt werden. Können wir Active Directory lokal behalten? Ja, absolut. Cloud-RADIUS verbindet sich über LDAPS mit Ihrem lokalen AD. Ihr Verzeichnis bleibt genau dort, wo es ist. Was passiert, wenn unsere Internetverbindung ausfällt? Dies ist die entscheidende Verschiebung der Abhängigkeiten. Mit Cloud-RADIUS wird die Internetverbindung zu einer Voraussetzung für die Authentifizierung. Mindern Sie dieses Risiko durch redundante WAN-Verbindungen oder einen lokalen RADIUS-Proxy, der die Authentifizierung für bekannte Geräte bei Ausfällen zwischenspeichert. Beeinflusst dies unsere PCI DSS-Konformität? Der Wechsel zu einem zertifizierten Cloud-RADIUS-Anbieter verbessert in der Regel Ihr Compliance-Niveau. Stellen Sie sicher, dass Ihr Anbieter SOC 2 Typ II-Berichte bereitstellen kann und in Ihren jährlichen QSA-Bewertungsumfang einbezogen ist. Wie lange dauert eine vollständige Migration? Für einen einzelnen Standort zwei bis vier Wochen. Für ein standortübergreifendes Unternehmen mit fünfzig oder mehr Standorten sollten Sie drei bis sechs Monate für einen schrittweisen Rollout einplanen. --- SEGMENT 5: ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE Zusammenfassend lässt sich sagen: Die Argumente für eine Migration von On-Premises-NPS zu RADIUS as a Service sind aus betrieblicher, finanzieller und Compliance-Sicht überzeugend. Die Migration selbst ist risikoarm, wenn sie mit einer strukturierten Parallelbetriebsphase durchgeführt wird. Die wichtigsten technischen Entscheidungen sind die Wahl Ihrer EAP-Methode, Ihr Ansatz zur Identitätsintegration und die Frage, ob Sie RadSec für die Transportsicherheit implementieren – was ich für jede Neuinstallation dringend empfehlen würde. Ihre nächsten Schritte: Führen Sie ein Audit Ihrer aktuellen RADIUS-Clients und -Richtlinien durch, binden Sie Ihren Cloud-RADIUS-Anbieter für eine Pilotumgebung ein und überprüfen Sie Ihre Firewall-Regeln und Zertifikats-Vertrauensketten, bevor Sie beginnen. Für Unternehmen, die die Plattform für den Gastzugang von Purple WiFi nutzen, lässt sich die RADIUS as a Service-Funktion direkt in den Authentifizierungsfluss des Gast-WiFi integrieren. So erhalten Sie eine einzige Steuerungsebene sowohl für die 802.1X-Authentifizierung in Unternehmen als auch für die Verwaltung des Gastnetzwerkzugangs – inklusive integrierter Analysen und Compliance-Berichte. Vielen Dank fürs Zuhören. Der vollständige technische Leitfaden ist auf der Purple-Website verfügbar, und unser Solutions-Team steht Ihnen für ein Sondierungsgespräch zur Verfügung, wenn Sie bereit sind, den nächsten Schritt zu gehen. --- ENDE DES SKRIPTS