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. À partir de 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

Si 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 les certificats X.509 de l’utilisateur ou de l’appareil afin de valider l’authenticité de la demande d’authentification. Dans le cadre du certificat, chaque attribut peut être traité et contenir potentiellement 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 pour RADIUSaaS :

• Adresse MAC du client

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

• SSID Wi‑Fi

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

• Adresse IP du NAS

• Adresse IP publique attribuée par le FAI

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

• Clé privée du certificat du serveur RADIUS

Divers

RADIUSaaS fournit (en option) une fonctionnalité permettant de 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 façon persistante par/pour le compte 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 consigne 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 du serveur).

   Les journaux sont stockés directement sur la plateforme RADIUSaaS dans une base de données Elasticsearch et séparé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 garantir un fonctionnement correct. Tous ces certificats sont stockés en toute sécurité 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

   Les autres données secrètes, par exemple le secret partagé RADIUS ainsi que la configuration du service, sont stockées en toute sécurité dans un Azure KeyVault.

4. Existe-t-il un mécanisme d’archivage des journaux ?

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

5. Quelles autorisations de locataire les utilisateurs accédant au portail web RADIUSaaS doivent-ils accepter ?

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. Conserver l’accès aux données auxquelles vous lui avez donné accès

   Avec cette autorisation, RADIUSaaS reçoit le droit de demander un jeton d’actualisation afin que l’utilisateur puisse rester connecté.

Veuillez consulter ici pour plus de détails.

6. Quelles données sont mises à disposition en accordant le ou les consentements de la question 5 ?

1. Profil utilisateur de base:

   Pour plus de 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. Conserver l’accès aux données auxquelles vous lui avez donné accès

   Aucune donnée spécifique n’est mise à disposition en accordant le consentement à cette autorisation.

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

1. API back-end du serveur RADIUS

   • Fournit des informations de configuration au proxy RadSec.

2. Ports du serveur RADIUS et RadSec

   • Pour faciliter 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 au fonctionnement du service.

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

1. API back-end du serveur RADIUS

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

2. Proxy RADIUS et ports du serveur RadSec

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

   • Ports du 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 auprès de l’un de nos IDP pris en charge.

4. API de gestion du cluster Kubernetes

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

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

• API back-end du serveur RADIUS

  • HTTPS (TCP / 443)

• Proxy RADIUS et ports du serveur RadSec

  • Ports du serveur RadSec : RadSec (TCP / 2083)

  • Ports du 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 auprès d’un IDP pour les identités ou comptes 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 offre des fonctionnalités permettant d’attribuer des rôles à chaque utilisateur (rôles disponibles : administrateur, lecteur, invité).

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

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

• Identifiants de connexion : dépendent des stratégies 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 réseau peuvent être récupérés depuis Azure KeyVault avec une politique de conservation de 90 jours après leur suppression.

4. Que faire pour récupérer l’accès perdu à l’instance RADIUSaaS ?

• Si votre entreprise a perdu l’accès à l’instance RADIUSaaS parce que le ou les administrateurs précédents sont partis ou que l’UPN / le domaine a changé, le moyen le plus simple de récupérer l’accès est de recréer un compte utilisateur correspondant à l’UPN existant dans RADIUSaaS > Permissions > Administrateurs. C’est de loin l’approche la plus rapide, car elle ne nécessite aucune action de notre part.

• Si ce n’est pas possible, la récupération de l’accès au portail sera soumise à un processus rigoureux de vérification d’identité, qui est non seulement chronophage mais demandera également des efforts importants des deux côtés. Des frais uniques de 420,00 EUR (hors TVA) s’appliquent à ce processus. Pour lancer le processus, veuillez créer un ticket de support technique.

• Pour éviter toute perte d’accès à votre locataire RADIUSaaS, veuillez suivre nos bonnes pratiques en parcourant soigneusement chaque étape de nos Guides de démarrage.

Protection des données

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

Données de configuration et secrets

• Les données de configuration sont stockées dans Azure KeyVault et protégées par 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 chiffrés du service Kubernetes.

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

• L’accès à ces espaces est accordé 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 les accès non autorisés ?

• Les flux d’authentification de l’appareil qui tente 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 ?

Back-end

Les services back-end de RADIUSaaS fonctionnent sur plusieurs clusters Kubernetes répartis dans le monde entier. L’instance RADIUSaaS de chaque client dispose de son propre espace de noms K8s, de son propre espace de journalisation et de sa propre 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.

Les proxys RADIUS

Chaque proxy RADIUSaaS fonctionne sur sa propre VM avec une IP publique dédiée.

Conception sécurisée

1. RADIUSaaS utilise-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 mis sur l’authentification par certificat, la capture du trafic est inutile tant que l’écouteur 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 moderne RadSec protocole pour l’authentification auprès de RADIUSaaS. Cependant, il existe encore de nombreux composants d’infrastructure réseau qui ne prennent pas 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, un EAP basé sur TLS (par exemple EAP-TLS) chiffre le trafic. Le trafic EAP-TLS est ensuite transporté via UDP vers le proxy RADIUS. C’est à cette phase que les identifiants tels que le certificat ou le mot de passe sont échangés avec RADIUSaaS. Si vous utilisez une authentification basée sur certificat, aucun secret n’est transporté à cette phase, car seule la clé publique est échangée. La clé privée reste à tout moment sur l’appareil client.

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

Conclusion : l’authentification RADIUS basée sur UDP avec RADIUSaaS est sécurisée, car

• le trafic pertinent est chiffré

• et

de plus, aucun secret n’est transporté si l’authentification basée sur certificat est utilisée.

• 3. Quelles technologies, piles et plateformes ont été utilisées pour concevoir RADIUSaaS ?

• Kubernetes

• Pile EFK (Elasticsearch, Filebeats, Kibana)

• Python

• Azure (KeyVault)

• TerraForm

RGPD et résidence des données

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

• Services principaux : 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, aucune donnée ne quitte l’Union européenne.

• Proxy RadSec : dépend de la configuration

  • Si vous avez besoin d’un proxy RadSec en raison des limites de l’équipement réseau concernant la prise en charge native de RadSec, vous pouvez sélectionner un proxy dans différentes 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, mise en réseau, stockage
Digital Ocean, Inc.	Services cloud	Y101 6th Ave, New York City, NY 10013, États-Unis	Service Kubernetes, mise en réseau, stockage, VM 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	VM pour les proxys RADIUS
GitLab, Inc.	dépôt de code git, intégration, tests et automatisation des versions	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, garantissant la cohérence et l’idempotence de chaque déploiement d’instance

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

• Surveillance Digital Ocean supervisant les proxys RadSec

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

  • Tests unitaires

  • Revue par les pairs (principe des six yeux)

  • Tests d’intégration

  • Tests de charge

  • Tests fondés sur l’expérience

3. Effectuez-vous régulièrement des tests d’intrusion ?

Non.

Dans le cadre de nos pratiques de développement sécurisé, nous utilisons des outils (par ex. analyse statique du code) qui analysent 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 affecter la sécurité des points de terminaison exposés par RADIUSaaS. Avant toute mise en production, les résultats pertinents sont évalués et corrigés afin de garantir que RADIUSaaS reste exempt de toute vulnérabilité connue. Nous n’effectuons nous-mêmes aucun test d’intrusion, et nous n’utilisons pas non plus d’outils tiers de type « Penetration Test-as-a-Service ». Dans le premier cas, nous considérons qu’il existe un conflit d’intérêts inhérent. Dans le second cas, comme les services de test d’intrusion classiques se contentent souvent de vérifier les points de terminaison exposés par rapport aux CVE et à d’autres exploits connus, nous ne voyons aucune valeur ajoutée par rapport aux contrôles que nous effectuons déjà à l’aide de l’analyse statique du code. Si vous souhaitez effectuer vos propres tests d’intrusion, veuillez nous contacter et nous faire part de vos besoins.

4. Existe-t-il un processus de correctifs ?

Oui.

Les correctifs, hotfixes, correctifs de bogues et mises à jour de fonctionnalités sont introduits via notre processus CI/CD qui s’appuie sur différentes chaînes de tests pour garantir que seul le code satisfaisant à nos critères d’assurance qualité est publié. Le code nouvellement publié est automatiquement mis à disposition de tous nos clients. L’utilisation de l’Infrastructure as Code (Terraform) nous permet de fournir à nos clients des mises à jour cohérentes, reproductibles et de haute qualité.

L’architecture de notre service basée sur Kubernetes garantit que les mises à jour de code sont transparentes pour nos clients et n’entraînent aucune interruption de service.

5. Quelles sont les SLA pour les correctifs ?

• Correctifs pour les 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 hotfix sera fourni au plus tard 24 heures après que nous ayons pris connaissance de la vulnérabilité.

• Autres correctifs : pas de 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 exemple les certificats) et toutes les autres données de configuration du service. Azure KeyVault est un service hautement disponible géoredondant qui réplique tout son contenu dans un second centre de données, fournissant ainsi implicitement des services de sauvegarde.

Serveurs RADIUS et RadSec

Sans état. Aucune sauvegarde requise.

Journaux

Actuellement non sauvegardé.

7. Existe-t-il des tests de restauration de sauvegarde ?

Oui.

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