Sicherheit & Datenschutz
Dieses Kapitel bietet einen Überblick über häufig gestellte Fragen zu Informationssicherheit, Datenschutz und Qualitätssicherung.
Datenverarbeitung und Berechtigungen
1. Aus welchem Rechenzentrum wird RADIUSaaS betrieben?
Der Kernservice von RADIUSaaS kann derzeit in den folgenden Regionen bereitgestellt werden:
Australien
Europa
Vereinigtes Königreich
Vereinigte Staaten von Amerika
Falls RADIUS-Proxys erforderlich sind, können diese in den folgenden Ländern/Regionen bereitgestellt werden:
2. Welche Daten werden von RADIUSaaS verarbeitet?
Zertifikate
RADIUSaaS verarbeitet X.509-Benutzer- oder Gerätezertifikate, um die Authentizität der Authentifizierungsanfrage zu validieren. Als Teil des Zertifikats kann jedes Attribut verarbeitet werden, das potenziell Informationen wie enthalten kann:
Benutzername
E-Mail
UPN
RADIUS-Protokoll
RADIUSaaS stützt sich auf das RADIUS-Protokoll, z. B. sind die folgenden Daten für RADIUSaaS sichtbar:
Client-MAC-Adresse
NAS (z. B. Access Point, Switch, ...) MAC-Adresse
WiFi-SSID
Anbieterspezifische Daten (z. B. VLAN, Tunneling-Gruppe, ...)
NAS-IP-Adresse
Vom ISP zugewiesene öffentliche IP-Adresse
RADIUS Shared Secret (nur relevant, wenn RadSec nicht nativ unterstützt wird)
Privater Schlüssel des RADIUS-Serverzertifikats
Verschiedenes
RADIUSaaS stellt optional Funktionen bereit, um Benutzername + Passwort-Paare für den Netzwerkzugang zu generieren. Diese Anmeldeinformationen werden ebenfalls vom Service gespeichert und verarbeitet.
3. Welche Daten werden dauerhaft von/im Auftrag von RADIUSaaS gespeichert und wie?
Berechtigungen
Die RADIUSaaS-Plattform speichert UPN/E-Mail-Informationen über die Benutzer, die berechtigt sind, auf die Plattform zuzugreifen. Es werden keine Passwörter von RADIUSaaS gespeichert oder verarbeitet.
Protokollierung
Zu Fehlerbehebungs- und Analysezwecken protokolliert die RADIUSaaS-Plattform alle relevanten Daten, die sie verarbeitet (siehe Frage 2 mit Ausnahme des RADIUS Shared Secret und des privaten Schlüssels des Serverzertifikats).
Die Protokolle werden direkt auf der RADIUSaaS-Plattform in einer Elasticsearch Datenbank gespeichert und für jeden Kunden über einen dedizierten Bereich getrennt. Aufbewahrungszeit für Protokolle: 75 Tage.
Zertifikate
RADIUSaaS benötigt mehrere Serverzertifikate sowie Root-Zertifikate, um einen ordnungsgemäßen Betrieb zu ermöglichen. Alle diese Zertifikate werden sicher in einem Azure KeyVault gespeichert.
Die optionalen Benutzername + Passwort-Zugangsdaten, die in Frage 2 erwähnt werden, in einem Azure KeyVault gespeichert.
Andere Geheimnisse und Konfigurationsdaten
Andere geheime Daten, z. B. das RADIUS Shared Secret sowie die Konfiguration des Dienstes, werden sicher in einem Azure KeyVault gespeichert.
4. Gibt es einen Archivierungsmechanismus für Protokolle?
Es gibt keinen eingebauten Log-Archivierungsmechanismus. Allerdings kann die Log Exporter Funktion verwendet werden, um RADIUS-Protokolle in Ihre eigenen Protokollierungs- und Archivierungsdienste zu übertragen.
5. Welchen Mandantenberechtigungen müssen Benutzer zustimmen, die auf das RADIUSaaS-Webportal zugreifen?
Basis-Benutzerprofil:Mit dieser Berechtigung ruft RADIUSaaS die UPN des Benutzers ab, der versucht, sich beim RADIUSaaS-Admin-Portal anzumelden.
Zugriff auf Daten beibehalten, auf die Sie ihm Zugriff gewährt habenMit dieser Berechtigung erhält RADIUSaaS das Recht, ein Refresh-Token anzufordern, damit der Benutzer eingeloggt bleiben kann.
Bitte siehe hier für Details.
6. Welche Daten werden durch das Gewähren der Zustimmung(en) aus Punkt 5. verfügbar gemacht?
Basis-Benutzerprofil:Für Details darüber, welche Daten abgerufen werden können, lesen Sie bitte diesen Artikel: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#profile
Zugriff auf Daten beibehalten, auf die Sie ihm Zugriff gewährt habenDurch das Gewähren der Zustimmung zu dieser Berechtigung werden keine spezifischen Daten verfügbar gemacht.
7. Welche extern zugänglichen Endpunkte stellt RADIUSaaS bereit?
RADIUS-Server-Backend-API
Stellt Konfigurationsinformationen für den RadSec-Proxy bereit.
RADIUS- und RadSec-Server-Ports
Um die Netzwerkauthentifizierung von überall im Internet zu ermöglichen, müssen diese Authentifizierungsschnittstellen öffentlich zugänglich gemacht werden.
RADIUSaaS-Admin-Portal
Ein Webportal, das die Verwaltung des Dienstes erleichtert.
Kubernetes-Cluster-Management-API
Erforderlich für den Betrieb des Dienstes.
8. Wie sind die Endpunkte aus Frage 7 geschützt?
RADIUS-Server-Backend-API
Gesichert durch JWT-Access-Tokens, die vom Kunden verwaltet (ausgestellt, gelöscht, widerrufen) werden können.
RADIUS-Proxy- und RadSec-Server-Ports
RadSec-Server-Ports: TLS-gesichert (>= Version 1.2).
RADIUS-Proxy-Server-Ports: Geschützt durch das RADIUS Shared Secret.
RADIUSaaS-Admin-Portal
Gesichert durch OAuth 2.0-Authentifizierung gegen einen unserer unterstützten IDPs.
Kubernetes-Cluster-Management-API
TLS-gesichert (>= Version 1.2).
9. Welche Ports und Protokolle werden von den Endpunkten aus Frage 7 verwendet?
RADIUS-Server-Backend-API
HTTPS (TCP / 443)
RADIUS-Proxy- und RadSec-Server-Ports
RadSec-Server-Ports: RadSec (TCP / 2083)
RADIUS-Proxy-Server-Ports: RADIUS (UDP / 1812, 1813)
RADIUSaaS-Admin-Portal
HTTPS (TCP / 443)
Kubernetes-Cluster-Management-API
HTTPS (TCP / 443)
Identität
1. Welche Autorisierungsschemata werden verwendet, um Zugriff auf RADIUSaaS zu erhalten?
Der administrative Zugriff erfolgt über OAuth 2.0-Authentifizierung gegen einen IDP für Identitäten oder Konten, die auf der Plattform registriert sind.
2. Gibt es bedingten Zugriff / rollenbasierte Zugriffskontrollen zum Schutz von RADIUSaaS?
Ja. Das RADIUSaaS-Admin-Portal bietet Funktionen, um jedem Benutzer Rollen zuzuweisen (verfügbare Rollen: Administrator, Betrachter, Gast).
Um den Dienst ordnungsgemäß zu betreiben und zu warten, gibt es Super-Admin-Konten für einen begrenzten Kreis von glueckkanja AG-Mitarbeitern, die vollen Zugriff auf alle Kundeninstanzen des RADIUSaaS-Dienstes haben.
3. Können Zugangsdaten wiederhergestellt werden? Wenn ja, wie?
Anmeldeinformationen: Hängt von den konfigurierten Microsoft Entra ID (Azure AD)-Richtlinien im Kundenant ab.
Benutzername + Passwort-Anmeldeinformationen sowie alle Zertifikate für den Netzwerkzugang können aus dem Azure KeyVault mit einer Aufbewahrungsfrist von 90 Tagen nach Löschung wiederhergestellt werden.
4. Was ist zu tun, um den verlorenen Zugriff auf die RADIUSaaS-Instanz wiederherzustellen?
Wenn Ihr Unternehmen den Zugriff auf die RADIUSaaS-Instanz verloren hat, weil der/die vorherige(n) Administratoren ausgeschieden sind oder sich die UPN/Domain geändert hat, ist der einfachste Weg zur Wiederherstellung des Zugriffs, ein Benutzerkonto neu zu erstellen, das der bestehenden UPN in RADIUSaaS > Berechtigungen > Administratoren entspricht. Dies ist bei weitem der schnellste Ansatz, da hierfür keine Maßnahmen unsererseits erforderlich sind.
Wenn das oben Genannte nicht möglich ist, unterliegt die Wiederherstellung des Zugriffs auf das Portal einem strengen Identitätsverifizierungsprozess, der nicht nur zeitaufwändig ist, sondern erhebliche Anstrengungen von beiden Seiten erfordert. Für diesen Prozess fällt eine einmalige Gebühr von 420,00 EUR (zzgl. MwSt.) an. Um den Prozess zu starten, erstellen Sie bitte ein technisches Support-Ticket.
Um den Verlust des Zugriffs auf Ihren RADIUSaaS-Mandanten zu verhindern, befolgen Sie bitte unsere Best Practices, indem Sie jeden Schritt unserer Erste Schritte-Anleitungen.
Datenschutz
1. Wie ist at-rest befindliche Daten gegen unbefugten Zugriff geschützt?
Konfigurationsdaten und Geheimnisse
Konfigurationsdaten werden in Azure KeyVault gespeichert und über Zugriffsdaten geschützt, die wiederum als Kubernetes-Secrets.
Kubernetes-Service
Die Volumes und Festplatten, die zur Bereitstellung unseres Dienstes verwendet werden, sind verschlüsselt.
Protokolle
Die Elasticsearch-Datenbank wird auf den verschlüsselten Kubernetes-Service-Festplatten gehostet.
Die Protokolle werden in einer Elasticsearch-Datenbank gespeichert und über dedizierte Bereiche getrennt.
Der Zugriff auf diese Bereiche erfolgt über Benutzername + Passwort-Anmeldeinformationen, die wiederum als Kubernetes-Secrets.
Die Elasticsearch-Datenbank selbst ist nicht verschlüsselt.
2. Wie ist Daten während der Übertragung gegen unbefugten Zugriff geschützt?
Die Authentifizierungsabläufe des Geräts, das versucht, auf das Netzwerk zuzugreifen, werden in einen TLS-Tunnel (>= TLS 1.2) eingeschlossen.
Die Zuordnung zwischen NAS und dem RADIUS-Server wird über das RADIUS Shared Secret (MD5-Hash-Algorithmus) verschleiert.
3. Wie werden Kundenmandanten voneinander getrennt?
Backend
Die RADIUSaaS-Backend-Services laufen auf mehreren Kubernetes-Clustern, die weltweit verteilt sind. Jede RADIUSaaS-Instanz eines Kunden hat ihren eigenen K8s-Namespace, ihren eigenen Logging-Bereich und eine dedizierte öffentliche IP. Es gibt eine Elasticsearch-Instanz mit dedizierten Kundenkonten zum Protokollieren und Lesen pro Cluster.
RADIUS-Proxys
Jeder RADIUSaaS-Proxy läuft auf seiner eigenen VM mit dedizierter öffentlicher IP.
Security by Design
1. Verfolgt RADIUSaaS eine Defense-in-Depth-Strategie?
RADIUSaaS stützt sich auf bewährte Protokolle zur Handhabung von Netzwerkauthentifizierungsabläufen (RADIUS, RadSec, EAP-TLS, EAP-TTLS-X). Aufgrund des starken Fokus auf zertifikatbasierte Authentifizierung ist das Abfangen des Datenverkehrs bedeutungslos, solange der Abhörende keinen Zugriff auf ein vertrauenswürdiges Zertifikat hat.
2. Ist das UDP-basierte RADIUS-Protokoll sicher?
Wir empfehlen die Verwendung des modernen RadSec Protokolls zur Authentifizierung gegen RADIUSaaS. Es gibt jedoch viele Netzwerkkomponenten, die RadSec noch nicht unterstützen.
Das folgende Diagramm zeigt den RADIUS-Authentifizierungsablauf:

Im ersten Teil der Authentifizierungssequenz ist die Kommunikation durch einen auf MD5 basierenden Hash-Algorithmus gesichert (teilweise mit dem Shared Secret verschlüsselt). Keine Geheimnisse werden in dieser Phase übertragen.
Im zweiten Teil der Authentifizierungssequenz verschlüsselt ein TLS-basiertes EAP (z. B. EAP-TLS) den Datenverkehr. Der EAP-TLS-Datenverkehr wird dann per UDP an den RADIUS-Proxy transportiert. Dies ist die Phase, in der Anmeldeinformationen wie das Zertifikat oder das Passwort mit RADIUSaaS ausgetauscht werden. Wenn Sie zertifikatbasierte Authentifizierung verwenden, werden in dieser Phase keine Geheimnisse übertragen, da nur der öffentliche Schlüssel ausgetauscht wird. Der private Schlüssel verbleibt jederzeit auf dem Client-Gerät.
Ein umfassender Vergleich zwischen RADIUS und RadSec in Bezug auf Transportsicherheit wird hier.
Schlussfolgerung: Die UDP-basierte RADIUS-Authentifizierung mit RADIUSaaS ist sicher, da
der relevante Datenverkehr verschlüsselt ist und
zusätzlich keine Geheimnisse übertragen werden, wenn zertifikatbasierte Authentifizierung verwendet wird.
3. Welche Technologien, Stacks, Plattformen wurden zur Gestaltung von RADIUSaaS verwendet?
KubernetesEFK-Stack (Elasticsearch, Filebeats, Kibana)PythonAzure (KeyVault)TerraformGit CI
DSGVO und Datenstandort
1. Verlassen Daten Europa?
Kernservices: Abhängig von der Konfiguration
Die Kernservices von RADIUSaaS können in den in Frage 1.
beschriebenen Rechenzentren gehostet werden. Wenn der Dienst in einem europäischen Rechenzentrum gehostet wird, verlassen keine Daten die Europäische Union.
RadSec-Proxy: Abhängig von der Konfiguration
Wenn Sie aufgrund von Einschränkungen der Netzwerkausrüstung in Bezug auf native RadSec-Unterstützung einen RadSec-Proxy benötigen, können Sie einen Proxy aus verschiedenen Regionen auswählen, unter anderem Europa. In diesem Fall bleiben Ihre Daten innerhalb der Grenzen der Europäischen Union.
2. Auf welche Drittanbieter-Cloud-Anbieter stützt sich RADIUSaaS und warum?
Microsoft Corporation
Cloud-Dienste (Azure)
Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Irland
Kubernetes-Service, Netzwerk, Speicher
Digital Ocean, Inc.
Cloud-Dienste
Y101 6th Ave, New York City, NY 10013, Vereinigte Staaten
Kubernetes-Service, Netzwerk, Speicher, VMs für RADIUS-Proxys
Vultr (Markenzeichen von The Constant Company, LLC)
Cloud-Dienste
319 Clematis Street - Suite 900 West Palm Beach, FL 33401, Vereinigte Staaten
VMs für RADIUS-Proxys
GitLab, Inc.
Git-Code-Repository, Integration, Testing und Release-Automatisierung
268 Bush Street #350,
San Francisco,
CA 94104-3503, Vereinigte Staaten
Code-Repository, CI/CD-Pipeline.
Verschiedenes
1. Ist RADIUSaaS Teil eines Bug-Bounty-Programms?
Nein
2. Welche QA-Maßnahmen sind implementiert?
Es gibt dedizierte RADIUSaaS-Labore für Entwicklungszwecke
Die Bereitstellung und Installation des Dienstes erfolgt über Terraform, was Konsistenz und Idempotenz jeder Instanzbereitstellung gewährleistet
Kibana APM wird zur Messung der Service-Gesundheit und zum Alert-Management verwendet
DigitalOcean-Monitoring überwacht die RadSec-Proxys
Jeder Produktions-Release muss zuerst den internen Kanal durchlaufen und die relevanten QA-Hürden im Rahmen unseres CI-Prozesses bestehen
Unit-Tests
Peer-Review (Sechs-Augen-Prinzip)
Integrationstests
Stresstests
Erfahrungsbasiertes Testen
3. Führen Sie regelmäßig Penetrationstests durch?
Nein.
Im Rahmen unserer Secure Development Practices setzen wir Werkzeuge ein (z. B. statische Code-Analyse), die den Codebestand auf CVEs und andere häufige Exploits (einschließlich Abhängigkeiten wie Drittanbieter-Bibliotheken) scannen, die die Sicherheit der von RADIUSaaS bereitgestellten Endpunkte beeinträchtigen könnten. Vor jeder Veröffentlichung werden alle relevanten Befunde bewertet und behoben, um sicherzustellen, dass RADIUSaaS frei von bekannten Schwachstellen bleibt. Wir führen weder selbst Penetrationstests durch, noch verwenden wir Drittanbieter-"Penetration Test-as-a-Service"-Tools. Für Ersteres sehen wir einen inhärenten Interessenkonflikt. Für Letzteres sehen wir, da typische Penetrationstestdienste oft einfach die exponierten Endpunkte gegen CVEs und andere bekannte Exploits prüfen, keinen Mehrwert gegenüber den Prüfungen, die wir bereits mittels statischer Code-Analyse durchführen. Wenn Sie eigene Penetrationstests durchführen möchten, bitte kontaktieren Sie uns und teilen Sie uns Ihre Anforderungen mit.
4. Gibt es einen Patch-Prozess?
Ja.
Patches, Hotfixes, Bugfixes und Feature-Updates werden über unseren CI/CD-Prozess eingeführt, der verschiedene Test-Pipelines nutzt, um sicherzustellen, dass nur Code, der unsere QA-Hürden erfüllt, veröffentlicht wird. Neu veröffentlichter Code wird automatisch allen unseren Kunden zur Verfügung gestellt. Die Verwendung von Infrastructure as Code (Terraform) ermöglicht es uns, konsistente, reproduzierbare und qualitativ hochwertige Updates an unsere Kunden zu liefern.
Die auf Kubernetes basierende Architektur unseres Dienstes stellt sicher, dass Code-Updates für unsere Kunden nahtlos erfolgen und nicht zu Ausfällen des Dienstes führen.
5. Wie sehen die SLAs für Patches aus?
Patches für CVEs / Sicherheitslücken: Sobald die Schwachstelle öffentlich bekannt wird oder sobald wir eine Schwachstelle in unserem eigenen Code identifizieren, wird innerhalb von maximal 24 Stunden nach Bekanntwerden der Schwachstelle ein Hotfix bereitgestellt.
Andere Patches: Keine SLA.
6. Führt RADIUSaaS Backups durch?
Geheimnisse und Konfigurationsdaten
Wir nutzen Azure KeyVault, um Geheimnisse (z. B. Zertifikate) und alle anderen Konfigurationsdaten des Dienstes sicher zu speichern. Azure KeyVault ist ein hochverfügbarer geo-redundanter Dienst der seinen gesamten Inhalt in einem zweiten Rechenzentrum repliziert und somit implizite Sicherungsdienste bereitstellt.
RADIUS- und RadSec-Server
Zustandslos. Keine Sicherung erforderlich.
Protokolle
Derzeit nicht gesichert.
7. Gibt es Tests zur Wiederherstellung von Backups?
Ja.
Die Wiederherstellung aus Backups wird bei jedem Update/Release des Dienstes getestet. Es gibt ungefähr 4 - 8 Releases pro Jahr.
Zuletzt aktualisiert
War das hilfreich?