> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/fr/autre/faqs/security-and-privacy.md). # 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 Si des proxys RADIUS sont nécessaires, ils peuvent être déployés dans les pays/régions suivants : | Continent | Région | | ---------------- | -------------------------------------------------------------------- | | Afrique | Johannesburg | | Asie |

Bangalore
Singapour
Tel Aviv
Tokyo
Séoul
Osaka

| | Australie |

Sydney
Melbourne

| | Europe |

Francfort
Londres
Madrid
Stockholm

| | Amérique du Nord |

Dallas
New York
Seattle
Toronto

| | Amérique du Sud |

Santiago
São Paulo

| ### 2. Quelles données sont traitées par RADIUSaaS ? #### **Certificats** RADIUSaaS traite des certificats utilisateur ou d'appareil X.509 afin de valider l'authenticité de la requête 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 (pertinent uniquement si RadSec n'est pas pris en charge nativement) * Clé privée du certificat du serveur RADIUS #### **Divers** RADIUSaaS fournit (facultativement) 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 manière 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 journalise toutes les données pertinentes qu'elle traite (voir [Question 2](#2.-which-data-is-processed-by-radiusaas) à 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 *Elasticsearch* base de données 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 de serveur ainsi que des certificats racine pour assurer un fonctionnement correct. Tous ces certificats sont sécurisés **stockés dans un Azure KeyVault**. 4. Les identifiants facultatifs nom d'utilisateur + mot de passe mentionnés dans [Question 2](#2.-which-data-is-processed-by-radiusaas) sont **stockés dans un Azure KeyVault**. 5. Autres secrets et données de configuration Les autres données secrètes, p. ex. le Secret partagé RADIUS ainsi que la configuration du service, sont sécurisées **stockés 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é. Cependant, le [Log Exporter](/fr/portail-dadministration/settings/log-exporter.md) peut être utilisé 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 consentir ? 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 obtient le droit de demander un jeton d'actualisation afin que l'utilisateur puisse rester connecté. Veuillez consulter [ici](/fr/portail-dadministration/acces-et-regles/permissions.md#permissions-consent) pour plus de détails. ### 6. Quelles données sont mises à disposition en accordant le(s) consentement(s) 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 : 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 du backend 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 pour faire fonctionner le service. ### 8. Comment les points de terminaison de la question 7 sont-ils protégés ? 1. API du 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 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](/fr/portail-dadministration/acces-et-regles/permissions.md#supported-idps). 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 du backend du serveur RADIUS * HTTPS (TCP / 443) * Ports du proxy RADIUS et 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 obtenir l'accès à RADIUSaaS ? * L'accès administratif est réalisé via une authentification OAuth 2.0 auprès d'un [IDP](/fr/portail-dadministration/acces-et-regles/permissions.md#supported-idps) pour les identités ou comptes enregistrés sur la plateforme. ### 2. Existe-t-il en place des contrôles d'accès conditionnel / 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 de faire fonctionner et maintenir correctement le service, il existe des comptes super-administrateurs pour un cercle restreint d'employés de glueckkanja AG, qui ont 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épend des stratégies Microsoft Entra ID (Azure AD) configurées dans le tenant du client. * Les identifiants nom d'utilisateur + mot de passe ainsi que tous les certificats d'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) précédent(s) administrateur(s) est/sont parti(s) 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 cela 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 n'est pas seulement chronophage mais nécessitera également un effort important des deux côtés. Des frais uniques de 420,00 EUR (hors TVA) s'appliquent pour ce processus. Pour lancer le processus, veuillez créer un ticket d'assistance technique. * Pour éviter toute perte d'accès à votre tenant RADIUSaaS, veuillez suivre nos bonnes pratiques en parcourant soigneusement chaque étape de nos [Guides de démarrage](/fr/configuration/get-started.md). ## 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](https://learn.microsoft.com/en-us/azure/aks/enable-host-encryption). #### **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 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 tenants 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. Chaque instance RADIUSaaS d'un 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. #### 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 applique-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 mis sur l'authentification basée sur des certificats, la capture du trafic est inutile tant que l'espion 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](/fr/overview.md#what-is-radsec) 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 : ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/byiGM49uzq0vRK6ny2KM/radius-authentication-sequence.png) 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 la phase durant laquelle des identifiants tels que le certificat ou le mot de passe sont échangés avec RADIUSaaS. Si vous utilisez une authentification basée sur des certificats, aucun secret n'est transporté dans 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](/fr/autre/faqs/security-and-privacy/securite-du-transport-dans-radius-par-rapport-a-radsec.md). {% hint style="success" %} Conclusion : l'authentification RADIUS basée sur UDP avec RADIUSaaS est sécurisée, car * le trafic pertinent est chiffré\ et * en outre, aucun secret n'est transporté si une authentification basée sur des certificats est utilisée. {% endhint %} ### 3. Quelles technologies, piles et plateformes ont été utilisées pour concevoir RADIUSaaS ? * `Kubernetes` * `Pile EFK (Elasticsearch, Filebeats, Kibana)` * `Python` * `Azure (KeyVault)` * `TerraForm` * `Git CI` ## Conformité ### 1. glueckkanja est-elle certifiée ISO 27001 ? Oui. Le système de gestion de la sécurité de l'information (SMSI) de glueckkanja AG est certifié conformément à **ISO/IEC 27001:2022**. Le périmètre de la certification couvre : * Développement de produits * Services managés Vous pouvez consulter le certificat actuel [ici](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf). ### 2. glueckkanja fait-elle tester sa sécurité par des experts externes ? Oui. En 2026, glueckkanja AG a mandaté une société indépendante spécialisée en sécurité offensive pour mener une évaluation Red Team couvrant l'ensemble de notre entreprise. Nous avons délibérément choisi cette approche holistique plutôt qu'un test d'intrusion classique. Au lieu de vérifier des systèmes ou points de terminaison individuels contre des vulnérabilités connues, la Red Team a simulé une cyberattaque réaliste et avancée menée par un attaquant interne contre notre infrastructure informatique, en enchaînant les techniques comme le font de véritables adversaires. L'évaluation s'est concentrée sur : * l'identification de vulnérabilités à fort impact, * la cartographie de chemins d'attaque complets à travers notre environnement, * l'évaluation de vecteurs potentiels pour obtenir un accès non autorisé aux environnements clients, * l'évaluation de vecteurs potentiels pour exécuter des attaques sur la chaîne d'approvisionnement. Tous les constats ont été documentés avec des recommandations d'atténuation et sont traités dans le cadre de notre système de gestion de la sécurité de l'information certifié ISO 27001. Nous répéterons cette évaluation Red Team chaque année. ## 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](#1.-from-what-data-center-is-radiusaas-operating). * 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 du matériel réseau concernant la prise en charge native de RadSec, vous pouvez sélectionner un proxy dans différentes régions, notamment en Europe. Dans ce cas, vos données restent à l'intérieur des frontières de l'Union européenne. ### 2. Quels fournisseurs de cloud tiers RADIUSaaS utilise-t-il et pourquoi ? | Entreprise | Services | Contact | Finalité | | --------------------------------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | Microsoft Corporation | Services cloud (Azure) |

Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
Ireland

| Service Kubernetes, mise en réseau, stockage | | Digital Ocean, Inc. | Services cloud |

Y101 6th Ave,
New York City,
NY 10013,
United States

| Service Kubernetes, mise en réseau, stockage, VM pour les proxys RADIUS | | Vultr (marque déposée de The Constant Company, LLC) | Services cloud |

319 Clematis Street - Suite 900
West Palm Beach, FL 33401,
United States

| VM pour les proxys RADIUS | | GitLab, Inc. | référentiel de code git, intégration, tests et automatisation des mises en production |

268 Bush Street #350,

San Francisco,

CA 94104-3503, États-Unis

| Référentiel 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 QA pertinentes 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 fondés sur l'expérience ### 3. Effectuez-vous régulièrement des tests d'intrusion ? Pas sous la forme d'un test d'intrusion classique de SCEPman. En revanche, glueckkanja AG fait l'objet d'une évaluation Red Team annuelle réalisée par un spécialiste externe indépendant, qui va au-delà d'un test d'intrusion classique (voir [glueckkanja fait-elle tester sa sécurité par des experts externes ?](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)). Dans le cadre de nos pratiques de développement sécurisé, nous utilisons des outils (p. 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) susceptibles d'avoir un impact sur la sécurité des points de terminaison exposés par RADIUSaaS. Avant toute publication, toute découverte pertinente est évaluée et corrigée, 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 ». Pour le premier cas, nous voyons un conflit d'intérêts inhérent. Pour le second, comme les services de test d'intrusion typiques se contentent souvent de vérifier les points de terminaison exposés par rapport aux CVE et autres exploits connus, nous ne voyons aucune valeur ajoutée par rapport aux vérifications que nous effectuons déjà au moyen de l'analyse statique du code. Au lieu de cela, nous nous appuyons sur une approche holistique : en 2026, une Red Team indépendante a simulé une attaque réaliste et avancée contre glueckkanja AG, incluant explicitement des chemins d'attaque vers les environnements clients et des attaques sur la chaîne d'approvisionnement. Plutôt que de tester des points de terminaison isolés, cette évaluation examine des chemins d'attaque complets à travers notre organisation, ce que nous considérons comme bien plus pertinent pour la sécurité de nos clients. Nous répétons cette évaluation chaque année. Si vous souhaitez effectuer vos propres tests d'intrusion, veuillez [nous contacter](https://support.radiusaas.com/support/tickets/new?ticket_form=technical_support_request_%28radiusaas%29) et nous faire part de vos besoins. ### 4. Existe-t-il un processus de correction des correctifs ? Oui. Les correctifs, hotfixes, corrections de bugs et mises à jour de fonctionnalités sont introduits via notre processus CI/CD qui s'appuie sur différentes chaînes de tests afin de garantir que seul le code satisfaisant nos critères QA soit publié. Le code nouvellement publié est automatiquement mis à disposition de tous nos clients. L'utilisation de l'infrastructure en tant que code (Terraform) nous permet de fournir à nos clients des mises à jour cohérentes, reproductibles et de haute qualité. L'architecture basée sur Kubernetes de notre service garantit que les mises à jour de code sont transparentes pour nos clients et n'entraînent aucune interruption de service. ### 5. Quels sont les SLA pour les correctifs ? * Correctifs pour les CVE / vulnérabilités de sécurité : dès que la vulnérabilité devient publiquement connue 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 avons 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 (p. ex. les certificats) et toutes les autres données de configuration du service. Azure KeyVault est un service hautement उपलब्ध? [service géoredondant](https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance) qui réplique l'ensemble de 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 des sauvegardes ? Oui. La restauration à partir des sauvegardes est testée à chaque mise à jour/version du service. Il y a environ 4 à 8 versions par an. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/fr/autre/faqs/security-and-privacy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.