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 central 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 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 WiFi

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

• 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 (en option) une fonctionnalité pour générer des paires nom d'utilisateur + mot de passe pour l'accès 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 enregistre 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 au sein d'un 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 assurer le bon fonctionnement. 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 Fonction d'exportation des journaux peut être utilisée pour ingérer les journaux RADIUS dans vos propres services de journalisation et d'archivage.

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

1. Profil d'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 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 rendues disponibles en accordant le(s) consentement(s) de la question 5 ?

1. Profil d'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. 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 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 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 proxy RADIUS et 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é 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 proxy RADIUS et 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. Des contrôles d'accès conditionnels / basés sur les rôles sont-ils en place pour protéger RADIUSaaS ?

• Oui. Le portail d'administration RADIUSaaS offre 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 réseau peuvent être récupérés depuis Azure KeyVault avec une politique de rétention 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(s) administrateur(s) précédent(s) 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 > Autorisations > Administrateurs. C'est de loin l'approche la plus rapide, car elle ne nécessite aucune action de notre part.

• Si ce qui précède n'est pas possible, la récupération d'accès au portail fera l'objet d'un processus rigoureux de vérification d'identité qui est non seulement chronophage mais exigera un effort significatif des deux parties. Des frais uniques de 420,00 EUR (HT) sont facturés pour ce processus. Pour lancer la procédure, veuillez créer un ticket de support technique.

• Pour éviter la perte d'accès à votre locataire RADIUSaaS, veuillez suivre nos bonnes pratiques en parcourant attentivement 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 via des identifiants d'accès qui sont à leur tour 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 donné via des identifiants nom d'utilisateur + mot de passe qui sont à leur tour 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 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 obfusquée 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 entier. 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 clients dédiés pour la journalisation et la lecture par cluster.

Proxys RADIUS

Chaque proxy RADIUSaaS 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 du fort accent sur l'authentification basée sur des certificats, capturer le trafic n'a pas de sens tant que l'écoutant 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, il existe encore de nombreux composants d'infrastructure réseau qui ne prennent pas en charge RadSec.

Le diagramme 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 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 une authentification basée sur certificat, aucun secret n'est transporté dans cette phase car seul la clé publique est échangée. La clé privée reste sur le dispositif client en permanence.

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 basée sur certificat est utilisée.

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

• Kubernetes

• EFK Stack (Elasticsearch, Filebeats, Kibana)

• Python

• Azure (KeyVault)

• TerraForm

• Git CI

RGPD et résidence des données

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

• Services centraux : dépend de la configuration

  • Les services centraux 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 avez besoin d'un proxy RadSec en raison des limitations des équipements réseau concernant la prise en charge native de RadSec, vous pouvez sélectionner un proxy dans diverses régions, dont l'Europe. Dans ce cas, vos données restent à l'intérieur des frontières de l'Union européenne.

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

Entreprise	Services	Contact	Objectif
Microsoft Corporation	Services cloud (Azure)	Bâtiment 3, Carmanhall Road Sandyford, Parc industriel 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, VMs pour proxys RADIUS
Vultr (marque de The Constant Company, LLC)	Services cloud	319 Clematis Street - Suite 900 West Palm Beach, FL 33401, États-Unis	VMs pour 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 QA 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 la santé du service et la gestion des alertes

• La surveillance Digital Ocean supervise les proxys RadSec

• Chaque release de production doit d'abord passer par le canal interne, franchissant les obstacles QA pertinents dans le cadre de notre processus CI

  • Tests unitaires

  • Revue par les pairs (principe des six yeux)

  • Tests d'intégration

  • Tests de stress

  • 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. analyse statique de code) qui scannent la base de code pour les CVE et 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 résultats pertinents sont évalués et corrigés, 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, et nous n'utilisons pas non plus d'outils tiers de type « Penetration Test-as-a-Service ». Pour le premier, nous voyons un conflit d'intérêt inhérent. Pour le second, comme les services typiques de tests de pénétration 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 contrôles que nous effectuons déjà via l'analyse statique de code. Si vous souhaitez effectuer vos propres tests de pénétration, veuillez nous contacter et nous faire part de vos exigences.

4. Existe-t-il un processus de patching en place ?

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 garantir que seuls les codes satisfaisant nos exigences QA sont publiés. Le code nouvellement publié est automatiquement mis à disposition de tous nos clients. L'utilisation d'Infrastructure as 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 du code sont transparentes pour nos clients et ne conduisent à 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 de notoriété publique ou dès que nous identifions une vulnérabilité dans notre propre code, un correctif 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 de manière sécurisée les secrets (par ex. certificats) et toutes les autres données de configuration du service. Azure KeyVault est un service géorédondant qui réplique tout son contenu dans un deuxième 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 de sauvegarde sont-ils effectués ?

Oui.

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