RADIUS-as-a-Service-Leitfaden für Netzwerke mit mehreren Standorten

Das Gäste-WiFi des Hotels funktioniert, aber die Mitarbeiter-SSID verwendet an jedem Standort ein anderes geteiltes Passwort, eine Kasse ist im falschen VLAN gelandet und niemand kann bestätigen, ob das Gerät eines ehemaligen Dienstleisters noch Zugriff hat. Das Netzwerk-Team kann jedes Problem lokal beheben, aber dieselbe Arbeit fällt an verschiedenen Standorten, Etagen und Access-Point-Plattformen immer wieder an.

RADIUS-as-a-Service verlagert Authentifizierungsentscheidungen auf eine gehostete Plattform, während Access Points, Switches und Controller für deren Durchsetzung zuständig bleiben. Das kann die Richtlinienverwaltung über einen verteilten Standortbestand hinweg vereinfachen, macht das Netzwerk jedoch nicht unabhängig vom WAN, Identity Provider oder der Zertifikatsinfrastruktur. Eine fundierte Bewertung beginnt mit einer schwierigeren Frage als der, ob der Dienst ein SLA hat: Was passiert mit jeder Benutzer- und Geräteklasse, wenn eine Abhängigkeit ausfällt?

Inhaltsverzeichnis

• Warum die Zentralisierung von Netzwerkentscheidungen alles verändert
  • Der Pager ist nach wie vor wichtig
• Die Ursprünge und Standards hinter modernem gehostetem RADIUS
  • Warum alte Standards immer noch wichtig sind
• Wie eine RADIUS-as-a-Service-Architektur tatsächlich funktioniert
  • Vom Verbindungsaufbau zur Netzwerkrichtlinie
  • Accounting ist kein optionales Extra
• Vergleich von gehostetem RADIUS mit On-Premises-Bereitstellungen
  • Entscheiden Sie nach Ausfallmodus, nicht nach Slogans
• SLA, Multi-Region-Failover und was tatsächlich bricht
  • Bewerten Sie die Ausfallreaktion nach Benutzer und Gerät
  • Multi-Region ist eine Designvorgabe, kein Beweis
• Sicherheit, Compliance und Migration von Legacy-RADIUS
  • Fordern Sie Nachweise an, nicht nur Zusicherungen
• Auswahl und Einführung eines gehosteten RADIUS-Dienstes

Warum die Zentralisierung von Netzwerkentscheidungen alles verändert

Ein bekanntes Muster in einer Hotelkette ist eine Guest-SSID, die sich im Laufe der Zeit vervielfacht hat, Anmeldedaten von Mitarbeitern, die zwischen Teams weitergegeben werden, und Switch-Ports, die je nach der Person konfiguriert wurden, die zuletzt auf diesem Stockwerk gearbeitet hat. Das Problem ist nicht nur die Unübersichtlichkeit der Konfiguration. Es liegt daran, dass lokale Geräte Teile der Zugangsrichtlinie enthalten, sodass eine Änderung an einem Standort möglicherweise nicht mit der Änderung an einem anderen übereinstimmt.

RADIUS bietet eine Möglichkeit, diese Entscheidung zu zentralisieren. Ein Access Point oder Network Access Server sendet eine Authentifizierungsanfrage an einen gemeinsamen Dienst, der die Identität prüft und eine Zugriffsentscheidung zurückgibt. Das Netzwerkgerät setzt diese Entscheidung weiterhin durch, aber der Betreiber kann Identitäten und Richtlinien zentral verwalten, anstatt Regeln auf jedem Controller oder Switch zu duplizieren.

Diese Aufteilung ist der Kerngedanke von gehostetem RADIUS. Ein zentraler Dienst kann Attribute zurückgeben, die einen Mitarbeiter, Gast, Dienstleister oder ein Gerät einem entsprechenden Netzwerk oder VLAN zuordnen. Wenn jemand das Unternehmen verlässt, kann eine zentral verwaltete Identität widerrufen werden, anstatt sich darauf zu verlassen, dass jeder Standort die lokalen Einstellungen aktualisiert. Accounting-Datensätze können Betreibern auch dabei helfen, zu untersuchen, welche Identität ein Netzwerk wann genutzt hat.

Der Pager ist nach wie vor wichtig

Zentralisierung reduziert bestimmte betriebliche Aufgaben, entbindet aber nicht von der Verantwortung für das Netzwerkdesign. Der gehostete Dienst kann weder einen fehlerhaften Identitätsdatensatz noch ein falsch zugewiesenes VLAN oder einen Access Point korrigieren, der seinen konfigurierten Endpoint nicht erreichen kann. Er entscheidet auch nicht automatisch, welche Geräte ihren Zugang behalten sollen, wenn eine Filiale die Verbindung verliert.

Für das zuständige Team verlagert sich die Aufgabe von der Wartung lokaler Authentifizierungsserver und -richtlinien hin zur Verwaltung der Abhängigkeiten und des Ausfallverhaltens eines gemeinsamen Dienstes. Dazu gehören das Testen der Erreichbarkeit, das Validieren zurückgegebener Attribute, das Überwachen des Accounting und die Vereinbarung, was bei einem Ausfall geschehen soll.

Betriebsregel: Zentralisieren Sie routinemäßige Richtlinien, aber definieren Sie die Ausfallrichtlinie für jede Benutzer- und Gerätegruppe explizit.

Die Sitzung eines Gastes, der Laptop eines Mitarbeiters, eine Kasse, eine Kamera und ein Gebäudesensor benötigen nicht zwangsläufig dieselbe Ausfallsicherung. Wenn Sie diese als eine einzige generische "WiFi"-Gruppe behandeln, kann ein Authentifizierungsausfall entweder zu einer Betriebsunterbrechung oder zu einer vermeidbaren Sicherheitsausnahme führen.

Ursprünge und Standards hinter modernem gehosteten RADIUS

RADIUS entstand im Jahr 1991, nachdem Merit Network ein zentralisiertes Authentifizierungssystem für den Wählleitungszugriff auf das NSFNET angefordert hatte. Livingston Enterprises entwickelte die erste Implementierung für seine PortMaster-Netzwerkzugriffsserver. Die Entwurfsentscheidung, die Bereitstellungen bis heute prägt, war die Kombination von Authentifizierung, Autorisierung und Accounting in einem einzigen Client-Server-Modell anstelle separater proprietärer Systeme für jede Funktion. RADIUS-Historie und Protokollhintergrund

Diese Trennung ist für mehr als nur die Kompatibilität von Bedeutung. Da die Trennung zwischen NAS und Authentifikator im Protokoll verankert ist, ändert ein WAN- oder Identitätsanbieter-Ausfall lediglich, wer den gemeinsamen Server erreichen kann, nicht aber die Rollen selbst. Aus diesem Grund entscheidet das Ausfallkonzept und nicht die Protokollwahl darüber, was am Standort passiert.

Die Dokumentation der Standards zeigt, wie das Modell interoperabel wurde. Die IETF dokumentierte RADIUS im Januar 1997 als RFC 2058 für Authentifizierung und RFC 2059 für Accounting. RFC 2138 und RFC 2139 lösten diese später im selben Jahr ab, gefolgt von RFC 2865 und RFC 2866 im Jahr 2000. RFC 2865 verfeinerte das Protokoll, nachdem frühe Bereitstellungen Probleme bei größerer Skalierung aufdeckten - eine nützliche Erinnerung daran, dass diese Spezifikation durch betriebliche Ausfälle gehärtet und nicht rein theoretisch entworfen wurde. IETF RADIUS-Arbeitsgruppen-Dokumente

Warum alte Standards nach wie vor wichtig sind

Für eine Hotelgruppe oder einen Veranstaltungsbetreiber bleibt die Trennung zwischen Zugriffsgerät und Authentifizierungsserver äußerst nützlich. Ein WLAN-Controller eines Herstellers und Switches eines anderen können Anfragen an einen gemeinsamen Richtliniendienst senden, sofern sie ein kompatibles RADIUS-Verhalten implementieren. Zentralisierte Identitäts- und Zugriffsentscheidungen werden möglich, ohne den vollständigen Zugriffskontroll-Stack eines einzigen Anbieters kaufen zu müssen.

Port-Zuweisungen zeigen, wie sich Standardisierungsarbeiten auf den täglichen Betrieb auswirken. Frühe Implementierungen nutzten üblicherweise UDP-Port 1645, während UDP-Port 1812 gemäß RFC 2865 zur offiziellen Zuweisung für die Authentifizierung wurde. Geräte, die standardmäßig weiterhin 1645 verwenden, schlagen bei der Verbindung mit einem gehosteten Endpunkt fehl, der 1812 erwartet. Überprüfen Sie daher die Unterstützung der einzelnen Geräte, bevor Sie Firewalls, regionale Endpunkte und Migrationspläne konfigurieren.

Transportsicherheit ist ein aktuelles Thema. RFC 6614 definiert RADIUS over TLS, oder RadSec, mit TCP-Port 2083 als Standardziel und Anforderungen an den Integritätsschutz. Es warnt auch davor, dass TLS-Verbindungsstatus und -Verarbeitung eine höhere Last als traditionelles UDP erzeugen können. Ein sicheres Design erfordert daher Verbindungswiederverwendung, begrenzte Wiederholungsversuche und Kapazitätsplanung - nicht bloß einen neuen Port. Betrachten Sie diese Lastwarnung als eine Frage des Fehlerverhaltens: Ein Endpunkt, der zusammenbricht, wenn sich Hunderte von Access Points nach einer WAN-Störung gleichzeitig wieder verbinden, ist schlimmer als einer, der stufenweise skaliert. RFC 6614 zu RADIUS over TLS

Der 2025 RFC 9813 der IETF dokumentiert betriebliche Überlegungen für TLS Pre-Shared Keys und die Migration von RADIUS/UDP zu RADIUS/TLS. Diese Arbeit ist relevant bei der Bewertung, wie ein Anbieter Zertifikats- oder Schlüsselverwaltung, Proxy-Grenzen und eine gestufte Migration handhabt. IETF RADIUS-Standards und verwandte Arbeiten

Wie eine RADIUS-as-a-Service-Architektur tatsächlich funktioniert

Ein gehostetes RADIUS-Design lässt sich leichter bewerten, wenn Sie seine drei Funktionen von seinen drei Ebenen trennen. Die Funktionen sind Authentifizierung, Autorisierung und Accounting. Die Ebenen sind Identität, Transport und Berichterstellung. Ein Anbietorangebot fasst diese möglicherweise zusammen, aber Betreiber müssen dennoch wissen, welche Komponente die Identität überprüft, welche die Anfrage überträgt und wo die Sitzungsdaten verbleiben.

Von der Verbindungsanfrage zur Netzwerkrichtlinie

Wenn ein Benutzer oder ein Gerät versucht, eine Verbindung herzustellen, fungiert ein Access Point oder Controller als Network Access Server. Er sendet die Anfrage an RADIUS. Der Dienst prüft die übermittelten Identitäts- oder Geräteanmeldedaten - oft unter Nutzung eines angebundenen Identitätsanbieters oder einer Zertifikats-Vertrauensstellung - und gibt dann eine Zusage- oder Ablehnungsentscheidung zurück.

Eine akzeptierte Anfrage kann Autorisierungsattribute wie VLAN-Zuweisungen oder andere Netzwerkparameter enthalten. Der Access Point oder Controller wendet diese Anweisungen an. In einer Hotel-Analogie ist der Access Point der Pförtner, der gehostete RADIUS-Dienst das Identitätsverzeichnis und die zurückgegebenen Attribute entsprechen dem Armband, das festlegt, welche Bereiche die Person betreten darf.

Der gehostete Dienst verbindet die Identitätsebene mit Systemen wie Microsoft Entra ID, Okta, Google Workspace, einer Mobile-Device-Management-Plattform oder einem Property-Management-System. Die genaue Integration hängt vom Dienst und der Zugriffsmethode ab. Gehen Sie nicht davon aus, dass ein Connector bedeutet, dass jede Richtlinie so ausgewertet werden kann, wie es Ihr Standort erfordert. Testen Sie Identitäts- und Anwendungsfälle für Geräte, einschließlich ausscheidender Mitarbeiter, geteilter Geräte und externer Mandanten.

Accounting ist kein optionales Extras

Accounting erfasst Sitzungsereignisse und Nutzungsinformationen unabhängig von der ursprünglichen Authentifizierungsentscheidung. Diese Datensätze können Audits, Kapazitätsplanung, Weiterverrechnung und Untersuchungen unterstützen, auch wenn ein anderes System einen Teil der Identitätsprüfung durchführt. Vereinbaren Sie bei standortübergreifenden Betriebsabläufen, wie mit verzögerten Aktualisierungen, erneuten Übertragungen, fehlenden Stop-Datensätzen und regionalem Endpoint-Failover umgegangen werden soll.

Die Transportschicht überträgt Anfragen zwischen dem Netzwerkgerät und RADIUS. Herkömmliches RADIUS nutzt in der Regel UDP; RadSec verwendet TCP und TLS. Die Berichtsebene sammelt Authentifizierungs- und Accounting-Nachweise, sodass Betreiber Entscheidungen überprüfen können, anstatt den Zugriff nur aus WLAN-Assoziierungsprotokollen abzuleiten.

Beim Vergleich von Diensten sollten Sie jede Komponente und jeden Datenfluss vor dem Abschluss kartieren. Eine nützliche Ergänzung ist dieser Leitfaden für Network Access Control Solutions, insbesondere wenn RADIUS Teil eines umfassenderen Richtlinien- und Durchsetzungskonzepts ist.

Gehostetes RADIUS im Vergleich zu On-Premises-Bereitstellungen

Gehostetes und lokales RADIUS nutzen dasselbe Protokoll. Zugriffsgeräte bleiben in beiden Fällen Network Access Server. Was sich ändert, ist die Frage, wer den gemeinsamen Authentifizierungsserver betreibt und was sich zwischen ihm und Ihren Standorten befindet. Betreiben Sie ihn selbst, ist die Verfügbarkeit ein technisches Problem in Ihrem Serverraum. Nutzen Sie eine gehostete Lösung, verlagert sich dasselbe Problem auf Ihre WAN-Pfade, die Identitätskette und das Zertifikatsvertrauen - nichts davon übernimmt der Anbieter in Ihrem Namen.

Kriterium	Hosted RADIUS	On-Premises RADIUS
Infrastrukturaufwand	Der Anbieter betreibt die gehostete Plattform; Ihr Team verwaltet weiterhin Client-Konfiguration, Richtlinien und Integration.	Ihr Team betreibt den Server, die Software, das Betriebssystem, die Überwachung und die Wiederherstellungsvorkehrungen.
Standortübergreifende Richtlinien	Zentrale Richtlinien können Geräte an allen Standorten bedienen, sofern Konnektivität und kompatible Implementierungen gegeben sind.	Ein zentraler Server oder eine Bereitstellung Standort für Standort ist möglich, aber Sie sind für die Replizierung und das Konsistenzmodell verantwortlich.
Netzwerkgeräte-Kompatibilität	Hängt von den unterstützten RADIUS-Attributen, Transportoptionen und den von Ihnen eingesetzten Zugangsgeräten ab.	Sie steuern die Serverkonfiguration, müssen aber dennoch das Verhalten über Switches, Controller und Access Points hinweg validieren.
Transportsicherheit	Die RadSec-Unterstützung kann den Transport schützen, wobei Zertifikatsverwaltung und TLS-Kapazität einzurichten sind.	RadSec kann auch lokal bereitgestellt werden, aber Ihr Team verwaltet Zertifikate, Verbindungen und Skalierung.
Verantwortung bei Ausfällen	Der Anbieter kümmert sich um den Plattformbetrieb; Ihr Team muss WAN, Identität, Endpunkte und lokales Fallback-Verhalten testen.	Ihr Team steuert die lokale Verfügbarkeit, muss jedoch Redundanz und Wiederherstellung konzipieren und warten.
Kostenstruktur	Wird oft als SaaS-Abonnement bereitgestellt; prüfen Sie den Vertrag und den enthaltenen betrieblichen Umfang.	Möglicherweise kann bestehende Infrastruktur genutzt werden, aber Personalaufwand, Wartung und Ersatz bleiben in Ihrer Verantwortung.

Entscheiden Sie nach Ausfallverhalten, nicht nach Slogans

RFC 2865 kodifiziert die Trennung zwischen Zugangsgerät und gemeinsam genutztem Authentifizierungsserver (RFC 2865); eine gehostete Bereitstellung ändert, wo dieser Server läuft, nicht welche Rolle Ihre Switches, Controller und Access Points spielen. Die entscheidende Frage ist daher für beide Modelle identisch: Wenn die Authentifizierung nicht mehr erreichbar ist, was funktioniert am Standort noch?

Nutzen Sie gehostete Lösungen, wenn Sie akzeptieren können, dass ein WAN-Pfadausfall in einem Hotel oder einer Arena lokal gelöst werden muss - durch ausfallsichere SSIDs, gecachte oder Fallback-Richtlinien und getestetes AP-Verhalten. Nutzen Sie On-Premises-Lösungen, wenn Sie den Serverbetrieb rund um die Uhr personell besetzen können sowie Zertifikatsrotation, Patching und Redundanz selbst übernehmen. Ein lokal verwalteter Server ist nicht automatisch ausfallsicherer. Ich habe zahlreiche einzelne On-Premises-Systeme auditiert, auf denen abgelaufene Zertifikate ohne Failover liefen und die ein Netzwerk eher aus Gewohnheit als durch durchdachtes Design zusammenhielten.

Das Bereitstellungsmodell entscheidet weniger als das darum herum entwickelte Ausfallkonzept.

Das Sicherheitsniveau folgt der Implementierung und nicht dem Standort. Fragen Sie, wo Shared Secrets und Zertifikate gespeichert werden, wer Accounting-Daten lesen kann, wie Anfragen während der Übertragung geschützt werden und wie der Dienst Anfragen weiterleitet, die er nicht selbst beantworten kann. Kassen, Gäste-WiFi, Kameras und IoT-Geräte teilen sich gewöhnlich einen Authentifizierungspfad, sodass eine Schwachstelle in jedem Modell meist überall gleichzeitig auftritt. Wenn Sie eine gehostete Plattform gegen eine vom Kunden betriebene Infrastruktur abwägen, hilft ein Self-Hosted RADIUS-Vergleich dabei zu definieren, welche betrieblichen Verantwortlichkeiten bei Ihnen verbleiben würden.

SLA, Multi-Regionen-Failover und was tatsächlich ausfällt

Die Plattform-Betriebszeit eines Anbieters, sein RADIUS-Service-Commitment und die Verfügbarkeit der Authentifizierung an einem bestimmten Standort hängen zusammen, sind jedoch nicht austauschbar. Eine gehostete Plattform kann einwandfrei funktionieren, während ein Hotel sie aufgrund eines WAN- oder DNS-Ausfalls nicht erreichen kann. Ebenso kann ein Standort den RADIUS-Dienst erreichen, während sein Identitätsanbieter oder seine Zertifikatskette eine erfolgreiche Authentifizierung verhindert.

Bewerten Sie die Ausfallreaktion nach Benutzer und Gerät

• WAN-Ausfall: Neue Cloud-Authentifizierungen schlagen möglicherweise fehl. Bestehende Sitzungen können je nach lokalem Netzwerkverhalten und Sitzungsrichtlinie fortgesetzt werden. Fragen Sie nach, ob die lokale Überlebensfähigkeit auf Ihren Access Points getestet wurde.
• DNS-Ausfall: Geräte können Service-Endpunkte möglicherweise nicht auflösen, wenn ihre Konfiguration von DNS abhängt. Bestätigen Sie, wie Endpunkte bereitgestellt werden und wie die Zugangsgeräte reagieren, wenn die Auflösung fehlschlägt.
• Identitätsanbieter-Ausfall: Der RADIUS-Dienst ist möglicherweise erreichbar, kann aber eine neue Identität nicht validieren. Zwischengespeicherte Anmeldeinformationen können helfen, halten jedoch möglicherweise auch den Zugriff aufrecht, nachdem sich der Status eines Benutzers geändert hat.
• Zertifikatsablauf oder CA-Störung: Die zertifikatsbasierte Authentifizierung kann fehlschlagen, wenn ein erforderliches Zertifikat ungültig, abgelaufen oder nicht vertrauenswürdig ist. Die Überwachung des Zertifikatslebenszyklus muss die beteiligten Geräte und die Vertrauenskette umfassen, nicht nur den RADIUS-Server.
• Ausfall der Verwaltungsebene: Betreiber können die Möglichkeit verlieren, Richtlinien zu ändern oder den Zugriff zu widerrufen, selbst wenn die Authentifizierung weiterhin funktioniert. Legen Sie fest, wie Notfalländerungen vorgenommen und dokumentiert werden.

Eine Notfall-SSID mit geteiltem Passwort, MAC-basierter Zugriff und zwischengespeicherte Anmeldedaten sind keine gleichwertigen Formen der Ausfallsicherheit. Jede Option wägt die sofortige Verfügbarkeit gegen die Sicherheit ab: Geteilte Schlüssel lassen sich nur schwer gezielt widerrufen, MAC-Kennungen können gefälscht werden und zwischengespeicherte Entscheidungen können länger bestehen als der Identitätsstatus, den sie eigentlich widerspiegeln sollten.

Fordern Sie eine Ausfallrichtlinie pro Benutzer an: Sollen Mitarbeiter, Gäste, Kassen, Kameras, Bewohner und IoT-Geräte bei einem Ausfall blockiert werden (Fail-Closed), eine begrenzte lokale Ausfallsicherung nutzen oder mit einer zuvor autorisierten Sitzung fortfahren?

Multi-Region ist eine Designvorgabe, kein Beweis

Multi-Region-RADIUS-Endpunkte können die Abhängigkeit von einer einzelnen Dienstregion verringern, aber die Zugriffsgeräte benötigen eine funktionierende Möglichkeit, diese zu erreichen und ein Failover zwischen ihnen durchzuführen. Überprüfen Sie, ob die bereitgestellten Access Points und Controller automatisch erneute Versuche starten, wie sie einen alternativen Endpunkt auswählen und ob der Ausfall einer Region ein manuelles Eingreifen erfordert. Testen Sie auch, wie das Accounting während der erneuten Übertragung und Wiederherstellung aussieht.

Fragen Sie vor der Beschaffung, wie lange eine zwischengespeicherte Authentifizierung gültig bleibt, wer den Notfallzugriff widerrufen kann, wie oft ein Failover getestet wird und welche Nachweise der Anbieter aus Tests vorlegen kann. Führen Sie den Test für Hotels und große Veranstaltungsorte mit repräsentativen Geräten und Diensten durch, nicht nur mit dem Laptop eines Mitarbeiters. Ein nützliches Ergebnis ist eine schriftliche Fehlermatrix, die die betroffene Gruppe, das erwartete Verhalten, den Verantwortlichen und die Wiederherstellungsmaßnahme nennt.

Sicherheit, Compliance und die Migration von Legacy-RADIUS

Betrachten Sie die Migration als Sicherheitsprojekt, nicht nur als Änderung einer Serveradresse. Die Aussage "Sicherer RADIUS" kann sich auf verschiedene Dinge beziehen: den Schutz des Transports, die Authentifizierung von Netzwerkgeräten, die Validierung der Benutzer- oder Geräteidentität oder die Rückgabe der korrekten Autorisierung. Diese Kontrollen lösen unterschiedliche Probleme.

RadSec nutzt TLS zum Schutz des RADIUS-Transports, und eine gegenseitige Zertifikatsauthentifizierung kann dazu beitragen, dass dem Server und dem Client-Gerät vertraut wird. Verschlüsselung allein garantiert jedoch nicht, dass der richtige Benutzer das richtige VLAN erhält oder dass der Zugriff eines ausscheidenden Mitarbeiters umgehend widerrufen wird. Betreiber sollten auch prüfen, wie der Dienst Message-Authenticator, Replay- und Spoofing-Schutz, Proxy-Inspektion und Accounting-Integrität handhabt, wenn Pakete erneut gesendet werden oder sich Endpunkte ändern.

Fordern Sie Nachweise, nicht nur Zusicherungen

Stellen Sie bei der Bewertung eines Anbieters direkte Fragen:

• Zertifikatsverwaltung: Werden Zertifikate pro Kunde, Mandant, Standort oder Netzwerkgerät verwaltet? Wie werden Ablauf und Rotation überwacht?
• Transportgrenzen: Wo wird TLS terminated? Können zwischengeschaltete Proxys Anfragen prüfen oder weiterleiten, und welcher Schutz bleibt Ende-zu-Ende bestehen?
• Audit-Nachweise: Können Sie Authentifizierungsentscheidungen, Richtlinienänderungen, administrative Zugriffe und Accounting-Datensätze überprüfen?
• Sicherheitsniveau: Welche Zertifizierungen hält der Anbieter und welchen Umfang decken sie ab? Wenn Sie ISO 27001 oder Cyber Essentials benötigen, prüfen Sie die aktuellen Nachweise und deren Anwendbarkeit, anstatt sich auf ein Logo zu verlassen.
• Migration und Rollback: Kann der Anbieter einen gestuften Übergang von UDP zu TLS unterstützen, und wie sieht der getestete Rollback-Pfad aus, falls sich ein Zugangsgerätemodell anders verhält?

Eine Migrationssequenz sollte mit einer Bestandsaufnahme von RADIUS-Clients, Identitätsquellen, Authentifizierungsmethoden, VLAN-Regeln, Shared Secrets, Zertifikaten und Accounting-Empfängern beginnen. Dokumentieren Sie als Nächstes die Zielrichtlinie und testen Sie diese mit repräsentativen Identitäten und Geräten. Führen Sie ein Pilotprojekt an einem Standort durch, vergleichen Sie die zurückgegebenen Entscheidungen mit den beabsichtigten Ergebnissen und stellen Sie dann Dienst für Dienst um. Halten Sie einen Rollback-Pfad bereit, bis das Accounting- und Zugriffsverhalten in der Produktion vollständig verstanden ist.

Compliance muss den Datenverkehr und die Datensätze abdecken, die Ihre Umgebung verarbeitet. Aus einer praktischen Perspektive der Netzwerksteuerung finden Sie hier weitere Hinweise zu PCI-Compliance und WiFi. Die entscheidende Frage ist nicht, ob ein Produkt Compliance beansprucht, sondern ob Ihre Bereitstellung Nachweise für die Kontrollen liefert, die Ihre Organisation nachweisen muss.

Ein weiteres Risiko liegt zwischen der Protokollspezifikation und dem installierten Netzwerk. Sicherheitsrichtlinien können Prüfungen verlangen, die von einigen Zugriffsgeräten oder Proxys nicht konsistent umgesetzt werden. Fragen Sie die Anbieter, welche Kontrollen sie durchsetzen, welche von der Client-Firmware abhängen und wie sie das Verhalten auf Ihrer Hardware validieren.

Auswahl und Rollout eines gehosteten RADIUS-Dienstes

Wählen Sie einen Anbieter anhand des Ausfallverhaltens und der nachweisbaren Betriebsdaten aus, nicht allein nach dem Cloud-Label. Überprüfen Sie die regionale Abdeckung, die Unterstützung von Identitätsanbietern, die Schlüsselverwaltung pro Mandant bei Bedarf, Audit-Zugriffe, RadSec- und Zertifikatsprozesse sowie die Abläufe bei Vertragsende.

Führen Sie die Bereitstellung in einer kontrollierten Reihenfolge durch: Inventarisieren Sie die aktuellen AAA- und Geräteabhängigkeiten; definieren Sie die Richtlinien für die Zuordnung von Identität zu Netzwerk; testen Sie repräsentative Standorte und Gerätetypen in einem Pilotprojekt; stellen Sie schrittweise um; und validieren Sie anschließend Zugriffsentscheidungen und Accounting anhand von Identitäts- oder Property-Management-Datensätzen. Verfolgen Sie fehlgeschlagene Authentifizierungen, die Handhabung von Widerrufen, den Accounting-Abgleich und die Performance des Gastnetzwerks als betriebliche Signale - nicht als alleinigen Beweis für Ausfallsicherheit.

Purple Access bietet gehostetes Cloud RADIUS zusammen mit offenen, sicheren und xPSK-Netzwerkoptionen sowie identitätsgesteuertem Zugriff über bestehende Access Points. Bewerten Sie die Lösung anhand derselben Ausfalltests, Richtlinienanforderungen und Nachweise, die Sie von jedem anderen Anbieter anfordern würden.

---

Wenn Sie einen standortübergreifenden RADIUS-Rollout planen, kartieren Sie Ihre WAN-, Identitäts-, Zertifikats- und lokalen Fallback-Abhängigkeiten, bevor Sie den Authentifizierungspfad ändern. Besuchen Sie Purple Access, um die Cloud RADIUS- und Netzwerkzugriffsoptionen für Gäste-, Mitarbeiter- und Gerätenetzwerke zu prüfen.