Authentification multifactorielle (MFA) en mode « air-gap » au titre de l'article 30 de la BSIG : comment un organisme public allemand procède à l'authentification sans recourir au cloud
Authentification multifacteur hors ligne selon le § 30 BSIG : comment une administration publique allemande s'authentifie sans le cloud
Certains environnements sont conçus pour n'avoir aucune issue. Pas de chemin sortant vers Internet, pas d'appel de retour vers le cloud, aucune dépendance qu'un opérateur réseau ne puisse pas voir et contrôler. Pour les équipes qui les gèrent, cet isolement est le contrôle de sécurité, et tout ce qui est ajouté à l'intérieur doit le respecter plutôt que de discrètement créer une brèche.
C'est la situation à laquelle était confronté un organisme public allemand, dans le cadre de la réglementation NIS2 en vigueur dans le pays, qui exploitait un environnement segmenté en réseaux où un ensemble d'applications métier sensibles était hébergé derrière une barrière physique. L’organisme était en train de migrer depuis un déploiement matériel SafeNet token dont l’exploitation était devenue trop lourde, pour une base d’utilisateurs de près d’un millier de personnes. L’exigence était simple à formuler mais difficile à satisfaire : une authentification forte sur l’environnement isolé, sans ajouter aucun élément dépendant d’un service situé en dehors du périmètre.
Pourquoi l'authentification multifacteur (AMF) délivrée par le cloud ne peut-elle pas fonctionner lorsqu'il n'y a pas d'issue ?
La plupart des authentifications multi-facteurs sont aujourd'hui fournies par le cloud d'un fournisseur. L'agent installé côté client doit atteindre un point de terminaison externe pour valider un facteur, acheminer une notification push, ou simplement vérifier que sa licence est toujours valide. À l'intérieur d'un segment sans connexion sortante, ces flux d'authentification dépendants du cloud ne peuvent pas aboutir.
Cela réduit le champ des possibilités aux logiciels fonctionnant entièrement sur les propres serveurs de l’organisation, licences comprises. OpenOTP, le serveur d’authentification RCDevs, et WebADM, la console centrale qui gère et pilote les services de la suite, ont été installés sur les propres serveurs Linux de l’organisation, au sein du segment isolé. L’activation et le renouvellement des licences ont été effectués hors ligne, de sorte que le service d’authentification n’a jamais eu besoin d’effectuer de requête vers l’extérieur pour se valider. En l’absence de voie de sortie, les notifications push et toute méthode transitant par le cloud sont d’emblée exclues : le deuxième facteur doit être un élément qui s’authentifie localement, sur du matériel déjà contrôlé par l’organisation.
Ce que demande le § 30 BSIG et où l'authentification multifacteur s'y situe
L'Allemagne a transposé la NIS2 tardivement. La loi de mise en œuvre de la NIS2 est entrée en vigueur le 6 décembre 2025, révisant la loi fédérale sur la cybersécurité (BSIG), plus d'un an après la date limite de transposition de l'UE en octobre 2024, et sans période de transition : les obligations s'appliquaient dès le jour de l'entrée en vigueur de la loi.
§30(2) BSIG dresse dix catégories de mesures minimales de gestion des risques que les entités concernées doivent mettre en place, appropriées et proportionnées à leurs risques. L'authentification multi-facteurs ou continue apparaît dans la dixième catégorie, et le contrôle d'accès est inclus dans la neuvième. Les huit autres couvrent l'analyse des risques, la gestion des incidents, la continuité des activités, la sécurité de la chaîne d'approvisionnement, l'acquisition et le développement sécurisés, la vérification de l'efficacité des mesures, la formation du personnel et la cryptographie.
À la lecture du texte de loi, la place de l'authentification multifacteur (MFA) est claire. Il s'agit d'une mesure requise en vertu du § 30 BSIG, et elle fait partie d'une catégorie parmi dix. L'authentification forte soutient les obligations d'une entité dans le cadre du régime ; elle ne les exempte pas en soi. Pour un organisme exploitant déjà un environnement isolé, la question pertinente est donc plus restreinte : peut-on ajouter un deuxième facteur fort à cet environnement sans introduire la dépendance sortante que l'isolement vise à prévenir.
Remplacement d'un produit MFA sans mettre au rebut le matériel existant tokens
L'organisation disposait déjà de près d'un millier de dispositifs matériels OATH token en service, fournis par SafeNet. Lors d'un changement de fournisseur, on part souvent du principe que le parc de token finit à la poubelle en même temps que l'ancien serveur, et que le projet n'est en réalité qu'une opération de renouvellement du matériel déguisée en migration.
Ce n'est pas une obligation. OpenOTP fonctionne avec du matériel OATH standard tokens ; ainsi, les appareils déjà en service ont été réenregistrés et conservés, et aucun achat ni remplacement n'a été nécessaire, hormis le renouvellement naturel des appareils hors service ou l'augmentation des effectifs. Pour un parc de cette taille, dans un environnement où chaque appareil doit être géré et enregistré au sein d’un réseau isolé, cela fait toute la différence entre un changement contrôlé de serveur d’authentification et un déploiement matériel complet.
Conserver les identités dans les annuaires de l'organisation
L'environnement exécutait plusieurs domaines Active Directory. Plutôt que de copier ces comptes dans un répertoire séparé qui nous serait propre, WebADM se connectait à chaque domaine via un point de montage LDAP : les comptes étaient lus sur place et jamais répliqués dans un répertoire tiers. Active Directory reste la source de vérité, et à la connexion OpenOTP valide le mot de passe par rapport à l'AD de l'organisation avant d'appliquer le second facteur.
Pour un organisme qui considère son annuaire comme sensible en soi, ce n'est pas un détail. Les identités ne quittent jamais le périmètre contrôlé par l'organisation, et il n'y a pas de copie fantôme de la base d'utilisateurs residing dans le système d'un fournisseur qui devrait être sécurisée, auditée ou demandée séparément. La couche d'authentification lit l'annuaire ; elle ne s'en saisit pas.
Cela s'étend également au fournisseur. OpenOTP est développé et publié en Europe par RCDevs. Dans ce déploiement, les identités et les données d'authentification sont restées au sein de l'infrastructure contrôlée par l'organisation, sans aucune dépendance vis-à-vis d'une plateforme d'identité SaaS non européenne.
Ce que ce déploiement a couvert et ce qu'il n'a pas couvert
Il convient d’être précis quant au périmètre d’intervention, car dans un environnement réglementé, les limites sont tout aussi importantes que le résultat. Dans ce périmètre, le déploiement a permis de mettre en place une authentification multifactorielle (MFA) validée localement, de conserver le parc existant de dispositifs OATH token, de maintenir Active Directory comme autorité d’identité et de supprimer toute dépendance vis-à-vis d’un service externe d’authentification ou de gestion des licences. Il n’a pas :
- à elle seule, rendre l'organisation conforme au §30 BSIG, qui couvre neuf catégories de mesures supplémentaires au-delà de l'authentification ;
- mettre en place un système d'authentification résistant au phishing, puisque les mots de passe à usage unique OATH (tokens) existants ont été conservés au lieu d'être remplacés par des dispositifs FIDO2 ;
- copier les identités Active Directory dans n'importe quel répertoire tiers;
- s'appuyer sur le push routé dans le cloud, ce qu'un segment isolé ne peut pas prendre en charge.
Après le déploiement isolé
Une fois le déploiement air-gapped mis en production, cette même plateforme d’authentification a été étendue à l’accès à distance sur d’autres segments de réseau non isolés, via RADIUS, sans exposer de fournisseur d’identité à ces segments. Le cœur du système n’a pas changé. Seule sa portée a évolué, passant d’un environnement conçu pour ne comporter aucune sortie à des segments nécessitant des voies d’accès contrôlées.
Résultats dans ce déploiement
Limité à ce projet, non présenté comme une garantie générale.
- La flotte existante de modèles token a été conservée Près d'un millier d'appareils OATH token déjà en service ont été maintenus en service, de sorte qu'il n'a pas été nécessaire d'en acheter ou d'en remplacer d'autres que ceux ayant subi une usure naturelle.
- Réduire les coûts opérationnels Authentification consolidée en une seule console sur site, WebADM, exécutant les services de la suite.
- Aucune dépendance externe Le service d'authentification s'exécute entièrement à l'intérieur du segment isolé, y compris l'activation et le renouvellement des licences, sans aucune connexion sortante requise.
- Les identités restent sur site Plusieurs domaines Active Directory lus directement via des points de montage LDAP, sans copie des comptes dans un répertoire tiers.
- Prend en charge la mesure d'authentification en vertu du §30 BSIG Authentification forte livrée comme l'une des dix catégories de mesures minimales de gestion des risques définies au §30 al. 2 BSIG, et non comme une conformité en soi.
Les résultats sont spécifiques à ce déploiement et ne constituent en aucun cas une promesse générale de conformité ou d'économies.
Pour en savoir plus
Sources réglementaires :
- §30 BSIG, texte consolidé officiel (mesures de gestion des risques)
- BSI, obligations pour les entités réglementées par la NIS2 (la présentation des mesures par le régulateur lui-même)
RCDevs :
- Authentification multifactorielle hors ligne et gestion des identités et des accès (IAM) pour les infrastructures critiques dans les environnements air-gapped
- Conformité NIS2 avec OpenOTP
- Comparaison des produits IAM et MFA cloud avec une solution sur site
Cela est possible, à condition que le logiciel s'exécute entièrement sur site et ne dépende d'aucun service externe. Dans ce projet, OpenOTP et WebADM s'exécutaient sur les propres serveurs Linux de l'organisation, l'activation et le renouvellement des licences étant effectués hors ligne, de sorte que le service d'authentification n'a jamais eu besoin d'une connexion sortante.
L'authentification multifacteur est l'une des dix catégories de mesures minimales de gestion des risques énumérées au §30(2) BSIG, et non l'intégralité de la conformité. Elle se situe aux côtés de l'analyse des risques, de la gestion des incidents, de la continuité, de la sécurité de la chaîne d'approvisionnement, de la cryptographie et des autres. Dans ce projet, l'AMF a soutenu les obligations de l'organisation dans le cadre du régime plutôt que de s'en acquitter à elle seule.
Les clés matérielles OATH standard token peuvent être réenregistrées au lieu d'être mises au rebut. Dans le cadre de ce projet, près d'un millier de clés SafeNet token déjà en service ont été réenregistrées dans OpenOTP ; il n'a donc pas été nécessaire d'acheter ou de remplacer quoi que ce soit, hormis les pertes naturelles.
Les comptes restent en place. Dans ce projet, WebADM s'est connecté à plusieurs domaines Active Directory via un point de montage LDAP et n'a jamais répliqué les comptes dans un magasin tiers ; Active Directory est resté la source de vérité.
L'activation et le renouvellement de la licence s'effectuent hors ligne, aucune sollicitation d'un service de licence externe n'est donc requise. Dans ce projet, c'est ce qui a permis au service d'authentification de s'exécuter à l'intérieur d'un segment isolé.
Lors de la connexion, OpenOTP valide le mot de passe par rapport à l'Active Directory de l'organisation avant d'appliquer le second facteur. Dans ce projet, l'annuaire est resté à l'intérieur du périmètre de l'organisation et a conservé son autorité de validation.
