Sécurité et confidentialité

Ce chapitre fournit un aperçu des questions fréquemment posées concernant la sécurité de l'information, la confidentialité et l'assurance qualité.

Traitement des données et autorisations

1. Depuis quel centre de données RADIUSaaS fonctionne-t-il ?

Le service principal de RADIUSaaS peut actuellement être déployé dans les régions suivantes :

• Australie

• Europe

• Royaume-Uni

• États-Unis d'Amérique

Dans le cas où des proxys RADIUS sont nécessaires, ils peuvent être déployés dans les pays/régions suivants :

2. Quelles données sont traitées par RADIUSaaS ?

Certificats

RADIUSaaS traite des certificats utilisateur ou appareil X.509 pour valider l'authenticité de la requête d'authentification. Dans le cadre du certificat, chaque attribut peut être traité, pouvant potentiellement contenir des informations telles que :

• Nom d'utilisateur

• E-mail

• UPN

Protocole RADIUS

RADIUSaaS s'appuie sur le protocole RADIUS, par exemple les données suivantes sont visibles par RADIUSaaS :

• Adresse MAC du client

• Adresse MAC du NAS (par ex. point d'accès, commutateur, ... )

• SSID Wi‑Fi

• Données spécifiques au fournisseur (par ex. VLAN, groupe de tunneling, ... )

• Adresse IP du NAS

• Adresse IP publique attribuée par le FAI

• Secret partagé RADIUS (pertinent uniquement si RadSec n'est pas pris en charge nativement)

• Clé privée du certificat du serveur RADIUS

Divers

RADIUSaaS fournit (optionnellement) une fonctionnalité pour générer des paires nom d'utilisateur + mot de passe pour l'accès au réseau. Ces identifiants sont également stockés et traités par le service.

3. Quelles données sont stockées de manière persistante par/au nom de RADIUSaaS et comment ?

1. Autorisations

   La plateforme RADIUSaaS stocke les informations UPN/e-mail des utilisateurs autorisés à accéder à la plateforme. Aucun mot de passe n'est stocké ni traité par RADIUSaaS.

2. Journalisation

   À des fins de dépannage et d'analyse, la plateforme RADIUSaaS journalise toutes les données pertinentes qu'elle traite (voir Question 2 à l'exception du secret partagé RADIUS et de la clé privée du certificat serveur).

   Les journaux sont stockés directement sur la plateforme RADIUSaaS au sein d'un Elasticsearch et sont segregés pour chaque client via un espace dédié. Durée de conservation des journaux : 75 jours.

3. Certificats

   RADIUSaaS nécessite plusieurs certificats serveur ainsi que des certificats racine pour permettre un fonctionnement correct. Tous ces certificats sont stockés de manière sécurisée dans un Azure KeyVault.

4. Les identifiants optionnels nom d'utilisateur + mot de passe mentionnés dans Question 2 sont dans un Azure KeyVault.

5. Autres secrets et données de configuration

   D'autres données secrètes, par ex. le secret partagé RADIUS ainsi que la configuration du service sont stockés de manière sécurisée dans un Azure KeyVault.

4. Existe-t-il un mécanisme d'archivage pour les journaux ?

Il n'existe pas de mécanisme d'archivage des journaux intégré. Cependant, la Exportation de journaux fonctionnalité peut être utilisée pour ingérer les journaux RADIUS dans vos propres services de journalisation et d'archivage.

5. Quelles autorisations de locataire doivent consentir les utilisateurs qui accèdent au portail web RADIUSaaS ?

1. Profil utilisateur de base:

   Avec cette autorisation, RADIUSaaS récupère l'UPN de l'utilisateur qui tente de se connecter au portail d'administration RADIUSaaS.

2. Maintenir l'accès aux données auxquelles vous lui avez donné accès

   Avec cette autorisation, RADIUSaaS obtient le droit de demander un jeton d'actualisation afin que l'utilisateur puisse rester connecté.

Veuillez voir ici Vous n’avez pas les permissions dans votre locataire Azure pour acheter via Azure Marketplace. Vous devez être assigné au rôle de Propriétaire ou Contributeur dans l’abonnement Azure que vous souhaitez utiliser pour le paiement.

6. Quelles données sont rendues disponibles en accordant le(s) consentement(s) de la question 5 ?

1. Profil utilisateur de base:

   Pour des détails sur les données pouvant être récupérées, veuillez vous référer à cet article : https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#profile

2. Maintenir l'accès aux données auxquelles vous lui avez donné accès

   Aucune donnée spécifique n'est rendue disponible en accordant le consentement à cette autorisation.

7. Quels points de terminaison accessibles depuis l'extérieur RADIUSaaS expose-t-il ?

1. API backend du serveur RADIUS

   • Fournit des informations de configuration au proxy RadSec.

2. Ports serveur RADIUS et RadSec

   • Pour permettre l'authentification réseau depuis n'importe où sur Internet, ces interfaces d'authentification doivent être exposées publiquement.

3. Portail d'administration RADIUSaaS

   • Un portail web qui facilite l'administration du service.

4. API de gestion du cluster Kubernetes

   • Nécessaire pour exploiter le service.

8. Comment les points de terminaison de la question 7 sont-ils protégés ?

1. API backend du serveur RADIUS

   • Sécurisés via des jetons d'accès JWT qui peuvent être gérés (émis, supprimés, révoqués) par le client.

2. Ports du proxy RADIUS et du serveur RadSec

   • Ports serveur RadSec : sécurisés par TLS (>= version 1.2).

   • Ports serveur proxy RADIUS : protégés via le secret partagé RADIUS.

3. Portail d'administration RADIUSaaS

   • Sécurisés via une authentification OAuth 2.0 contre l'un de nos IDP pris en charge.

4. API de gestion du cluster Kubernetes

   • Sécurisé par TLS (>= version 1.2).

9. Quels ports et protocoles sont utilisés par les points de terminaison de la question 7 ?

• API backend du serveur RADIUS

  • HTTPS (TCP / 443)

• Ports du proxy RADIUS et du serveur RadSec

  • Ports serveur RadSec : RadSec (TCP / 2083)

  • Ports serveur proxy RADIUS : RADIUS (UDP / 1812, 1813)

• Portail d'administration RADIUSaaS

  • HTTPS (TCP / 443)

• API de gestion du cluster Kubernetes

  • HTTPS (TCP / 443)

Identité

1. Quels schémas d'autorisation sont utilisés pour accéder à RADIUSaaS ?

• L'accès administratif est réalisé via une authentification OAuth 2.0 contre un IDP pour les identités ou comptes qui sont enregistrés sur la plateforme.

2. Existe-t-il des contrôles d'accès conditionnels / basés sur les rôles pour protéger RADIUSaaS ?

• Oui. Le portail d'administration RADIUSaaS fournit des fonctionnalités pour attribuer des rôles à chaque utilisateur (rôles disponibles : administrateur, lecteur, invité).

• Afin d'exploiter et maintenir correctement le service, il existe des comptes super-admin pour un cercle restreint d'employés de glueckkanja AG, qui ont un accès complet à toutes les instances clients du service RADIUSaaS.

3. Les identifiants d'accès peuvent-ils être récupérés ? Si oui, comment ?

• Identifiants de connexion : Dépend des politiques Microsoft Entra ID (Azure AD) configurées dans le locataire du client.

• Les identifiants nom d'utilisateur + mot de passe ainsi que tous les certificats pour l'accès au réseau peuvent être récupérés depuis Azure KeyVault avec une politique de rétention de 90 jours après leur suppression.

Protection des données

1. Comment les données au repos sont-elles protégées contre l'accès non autorisé ?

Données de configuration et secrets

• Les données de configuration sont stockées dans Azure KeyVault et protégées via des identifiants d'accès qui sont eux-mêmes stockés en tant que Secrets Kubernetes.

Service Kubernetes

• Les volumes et disques utilisés pour héberger notre service sont chiffrés.

Journaux

• La base de données Elasticsearch est hébergée sur les disques du Service Kubernetes chiffrés.

• Les journaux sont stockés dans une base de données Elasticsearch et segregés via des espaces dédiés.

• L'accès à ces espaces est donné via des identifiants nom d'utilisateur + mot de passe qui sont eux-mêmes stockés en tant que Secrets Kubernetes.

• La base de données Elasticsearch elle-même n'est pas chiffrée.

2. Comment les données en transit sont-elles protégées contre l'accès non autorisé ?

• Les flux d'authentification de l'appareil tentant d'accéder au réseau sont encapsulés dans un tunnel TLS (>= TLS 1.2).

• L'association entre le NAS et le serveur RADIUS est obscurcie via le secret partagé RADIUS (algorithme de hachage MD5).

3. Comment les locataires clients sont-ils séparés les uns des autres ?

Backend

Les services backend de RADIUSaaS s'exécutent sur plusieurs clusters Kubernetes répartis dans le monde. L'instance RADIUSaaS de chaque client dispose de son propre namespace K8s, d'un espace de journalisation et d'une IP publique dédiée. Il existe une instance Elasticsearch avec des comptes client dédiés pour la journalisation et la lecture par cluster.

Proxys RADIUS

Chaque proxy RADIUS s'exécute sur sa propre VM avec une IP publique dédiée.

Sécurité dès la conception

1. RADIUSaaS emploie-t-il une stratégie de défense en profondeur ?

RADIUSaaS s'appuie sur des protocoles bien établis pour gérer les flux d'authentification réseau (RADIUS, RadSec, EAP-TLS, EAP-TTLS-X). En raison de l'accent fort sur l'authentification par certificat, capturer le trafic est dénué de sens tant que l'intercepteur n'a pas accès à un certificat de confiance.

2. Le protocole RADIUS basé sur UDP est-il sécurisé ?

Nous recommandons d'utiliser le protocole moderne RadSec pour l'authentification contre RADIUSaaS. Cependant, de nombreux composants d'infrastructure réseau existants ne prennent pas encore en charge RadSec.

Le schéma suivant montre le flux d'authentification RADIUS :

Dans la première partie de la séquence d'authentification, la communication est sécurisée par un algorithme de hachage basé sur MD5 (partiellement chiffré avec le secret partagé). Aucun secret n'est transporté dans cette phase.

Dans la deuxième partie de la séquence d'authentification, une EAP basée sur TLS (par ex. EAP-TLS) chiffre le trafic. Le trafic EAP-TLS est ensuite transporté via UDP vers le proxy RADIUS. C'est la phase où des identifiants tels que le certificat ou le mot de passe sont échangés avec RADIUSaaS. Si vous utilisez l'authentification par certificat, aucun secret n'est transporté dans cette phase car seul la clé publique est échangée. La clé privée reste sur l'appareil client en tout temps.

Une comparaison complète entre RADIUS et RadSec en termes de sécurité de transport est fournie ici.

Conclusion : L'authentification RADIUS basée sur UDP avec RADIUSaaS est sécurisée, puisque

• le trafic pertinent est chiffré et

• de plus aucun secret n'est transporté, si l'authentification par certificat est utilisée.

3. Quelles technologies, stacks, plateformes ont été utilisées pour concevoir RADIUSaaS ?

• Kubernetes

• Stack EFK (Elasticsearch, Filebeats, Kibana)

• Python

• Azure (KeyVault)

• TerraForm

• Git CI

RGPD et localisation des données

1. Les données quittent-elles l'Europe ?

• Services cœur : dépend de la configuration

  • Les services principaux de RADIUSaaS peuvent être hébergés dans les centres de données décrits dans Question 1.

  • Si le service est hébergé dans un centre de données européen, alors aucune donnée ne quitte l'Union européenne.

• Proxy RadSec : dépend de la configuration

  • Si vous exigez un proxy RadSec en raison des limitations de l'équipement réseau concernant la prise en charge native de RadSec, vous pouvez sélectionner un proxy parmi diverses régions, y compris l'Europe. Dans ce cas, vos données restent à l'intérieur des frontières de l'Union européenne.

2. Sur quels fournisseurs cloud tiers RADIUSaaS s'appuie-t-il et pourquoi ?

Entreprise	Services	Contact	Objectif
Microsoft Corporation	Services cloud (Azure)	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Irlande	Service Kubernetes, réseau, stockage
Digital Ocean, Inc.	Services cloud	Y101 6th Ave, New York City, NY 10013, États-Unis	Service Kubernetes, réseau, stockage, machines virtuelles pour les proxys RADIUS
Vultr (marque de The Constant Company, LLC)	Services cloud	319 Clematis Street - Suite 900 West Palm Beach, FL 33401, États-Unis	Machines virtuelles pour les proxys RADIUS
GitLab, Inc.	dépôt de code git, intégration, tests et automatisation des releases	268 Bush Street #350, San Francisco, CA 94104-3503, États-Unis	Dépôt de code, pipeline CI/CD.

Divers

1. RADIUSaaS fait-il partie d'un programme de bug-bounty ?

Non

2. Quelles mesures d'assurance qualité sont en place ?

• Il existe des laboratoires RADIUSaaS dédiés à des fins de développement

• Le déploiement et l'installation du service sont réalisés via TerraForm, assurant la cohérence et l'idempotence de chaque déploiement d'instance

• Kibana APM est utilisé pour la mesure de la santé du service et la gestion des alertes

• La supervision Digital Ocean surveillant les proxys RadSec

• Chaque version de production doit d'abord passer par le canal interne, franchissant les étapes QA pertinentes dans le cadre de notre processus CI

  • Tests unitaires

  • Relecture par les pairs (principe des six yeux)

  • Tests d'intégration

  • Tests de charge

  • Tests basés sur l'expérience

3. Effectuez-vous régulièrement des tests de pénétration ?

Non.

Dans le cadre de nos pratiques de développement sécurisé, nous utilisons des outils (par ex. l'analyse statique du code) qui scannent la base de code à la recherche de CVE et d'autres exploits courants (y compris les dépendances telles que les bibliothèques tierces) pouvant impacter la sécurité des points de terminaison exposés par RADIUSaaS. Avant toute publication, les éventuelles découvertes pertinentes sont évaluées et corrigées, afin de garantir que RADIUSaaS reste exempt de vulnérabilités connues. Nous ne réalisons pas nous-mêmes de tests de pénétration, ni n'utilisons d'outils tiers de « Penetration Test-as-a-Service ». Pour le premier, nous considérons qu'il existe un conflit d'intérêts inhérent. Pour le second, comme les services typiques de test d'intrusion vérifient souvent simplement les points de terminaison exposés contre des CVE et autres exploits connus, nous ne voyons pas de valeur ajoutée par rapport aux vérifications que nous effectuons déjà via l'analyse statique du code. Si vous souhaitez effectuer vos propres tests d'intrusion, veuillez nous contacter et informez-nous de vos exigences.

4. Existe-t-il un processus de correction (patching) ?

Oui.

Les correctifs, hot-fixes, corrections de bugs et mises à jour de fonctionnalités sont introduits via notre processus CI/CD qui exploite différentes pipelines de test pour s'assurer que seul le code satisfaisant nos exigences QA est publié. Le code nouvellement publié est automatiquement mis à la disposition de tous nos clients. L'utilisation de l'infrastructure en tant que code (Terraform) nous permet de fournir des mises à jour cohérentes, reproductibles et de haute qualité à nos clients.

L'architecture basée sur Kubernetes de notre service garantit que les mises à jour de code sont transparentes pour nos clients et ne provoquent aucune interruption de service.

5. Quels sont les SLA pour les correctifs ?

• Correctifs pour CVE / vulnérabilités de sécurité : Dès que la vulnérabilité devient publique ou dès que nous identifions une vulnérabilité dans notre propre code, un correctif d'urgence sera fourni au plus tard 24 heures après que nous ayons pris connaissance de la vulnérabilité.

• Autres correctifs : Aucun SLA.

6. RADIUSaaS effectue-t-il des sauvegardes ?

Secrets et données de configuration

Nous utilisons Azure KeyVault pour stocker en toute sécurité les secrets (par ex. certificats) et toutes les autres données de configuration du service. Azure KeyVault est un service géorédondant à haute disponibilité qui réplique tout son contenu dans un second centre de données, fournissant ainsi des services de sauvegarde implicites.

Serveurs RADIUS et RadSec

Sans état. Aucune sauvegarde requise.

Journaux

Actuellement non sauvegardé.

7. Des tests de restauration des sauvegardes existent-ils ?

Oui.

La restauration à partir des sauvegardes est testée à chaque mise à jour/publication du service. Il y a environ 4 à 8 versions par an.