Sur un parc de serveurs NAS QNAP ou sur une infrastructure réseau exposée au web, le basculement vers une authentification renforcée ne se planifie pas la veille d’un contrôle. Depuis la recommandation CNIL du 20 mars 2025, reprise et durcie dans les exigences NIS2 déclinées par l’ANSSI, le simple mot de passe ne protège plus suffisamment les accès distants.
Pour les équipes qui gèrent des certificats TBS X509, des agents TBSCertBot ou des accès QTS en production, la question n’est plus « faut-il du MFA ? » mais « comment le déployer sans casser l’existant ».
Changement de chaîne TBS X509 et impact sur l’authentification serveur
Depuis le 1er mai 2026, les certificats serveur TBS X509 sont émis sur de nouveaux intermédiaires. Ces intermédiaires ne disposent plus de l’EKU client. En pratique, cela signifie que tout certificat utilisé à la fois pour le chiffrement serveur et l’authentification client doit être revu.
On rencontre ce cas de figure sur les NAS QNAP configurés en accès HTTPS avec authentification par certificat, ou sur des appliances réseau qui cumulent les deux rôles. Si votre infrastructure repose sur un certificat TBS émis avant mai 2026 avec l’ancien intermédiaire, il continue de fonctionner jusqu’à expiration. En revanche, tout renouvellement produira un certificat sans EKU client.
La migration demande de séparer les certificats : un certificat serveur pour le chiffrement TLS, et un mécanisme d’authentification distinct (FIDO2, TOTP ou certificat client dédié). C’est un changement d’architecture, pas un simple renouvellement.
WebAuthn et FIDO2 sur TBS Auth : ce qui compte vraiment comme MFA
Déployer des passkeys FIDO2 via WebAuthn sur une interface TBS Auth semble cocher la case MFA. La réalité est plus nuancée. Un dispositif FIDO2 prouve la possession d’une clé matérielle et vérifie l’utilisateur par biométrie ou PIN local. Selon la recommandation CNIL, le MFA exige la combinaison de facteurs véritablement indépendants : connaissance, possession et inhérence.
Un token FIDO2 protégé uniquement par un PIN court sur le même appareil peut être considéré comme un facteur unique par un auditeur rigoureux. Les retours varient sur ce point selon les interprétations des contrôleurs CNIL.
Critères pour qu’un déploiement FIDO2 soit reconnu MFA
- Le facteur de possession (clé physique ou smartphone distinct) doit être séparé du poste de travail qui initie la session
- Le facteur d’inhérence (biométrie) ou de connaissance (PIN) doit être vérifié localement sur le dispositif, pas sur le serveur
- La liaison entre le navigateur et le dispositif FIDO2 doit passer par un canal authentifié (USB, NFC ou BLE avec appairage vérifié)
Sur un NAS QNAP accessible via QTS, l’intégration WebAuthn native n’existe pas encore sur tous les modèles. On passe alors par un reverse proxy ou un portail d’authentification intermédiaire, ce qui ajoute une couche de complexité réseau.
NIS2 et accès distants : la clause de repli qui change la donne
Les lignes directrices ENISA de juin 2025, toujours en vigueur, et la déclinaison française NIS2 portée par l’ANSSI imposent le MFA sur tous les accès distants des entités importantes : VPN, RDP, bureaux virtuels, consoles cloud. Les communications doivent être chiffrées.
La clause de repli prévue par ce cadre mérite attention. Si des contraintes techniques empêchent le déploiement MFA (matériel ancien, firmware non compatible, environnement industriel isolé), l’organisation doit démontrer des mesures compensatoires réduisant clairement le risque. Concrètement, cela peut prendre la forme de restrictions réseau strictes, de journalisation renforcée ou de segmentation VLAN sur les interfaces de gestion.
Pour une infrastructure NAS en RAID avec surveillance Station activée, l’accès distant au flux vidéo constitue un cas typique. Un serveur de surveillance exposé sans MFA sur le web devient un point d’entrée privilégié. La documentation QNAP recommande déjà l’activation du 2FA sur QTS, mais le paramétrage par défaut reste souvent sans second facteur.
Connexion Windows et comptes locaux : l’angle mort des déploiements TBS Auth
Le point noir identifié sur le terrain reste la connexion Windows et les comptes locaux. On déploie du MFA sur les applications web, sur les VPN, sur les consoles d’administration Linux, mais la session Windows locale reste souvent protégée par un simple mot de passe Active Directory.
Sur un poste qui accède à des fichiers partagés via un NAS QNAP, à des snapshots de sauvegarde ou à des disques SSD chiffrés, l’absence de MFA à l’ouverture de session annule une partie de la chaîne de sécurité. Un attaquant qui compromet le compte Windows accède ensuite aux partages réseau sans repasser par le second facteur.
Actions concrètes pour combler cette faille
- Activer Windows Hello for Business ou un fournisseur de credentials FIDO2 compatible avec le poste (Intel vPro facilite l’intégration matérielle sur certaines gammes)
- Configurer une politique de groupe (GPO) qui exige le MFA pour les connexions réseau aux partages SMB du NAS
- Séparer les comptes d’administration locale des comptes utilisateurs et appliquer le MFA uniquement sur les comptes à privilèges en priorité
- Vérifier que les agents TBSCertBot installés sur les serveurs utilisent des accès API avec authentification par certificat client dédié, pas un compte partagé
Recommandations pour un déploiement TBS Auth compatible 2026
Après le changement de chaîne TBS X509 et le durcissement réglementaire, la séquence de migration la plus fiable consiste à traiter les certificats d’abord, puis l’authentification utilisateur.
Renouvelez vos certificats TBS en séparant explicitement le rôle serveur du rôle client. Testez la compatibilité avec vos équipements réseau (QNAP, switches managés, firewalls) avant la mise en production. Déployez ensuite le MFA par couches : d’abord les accès distants et les consoles d’administration, puis les sessions locales à privilèges.
Documentez chaque exception et chaque mesure compensatoire pour satisfaire la clause de repli NIS2. Un tableau interne listant chaque service, son niveau d’authentification actuel et la cible prévue reste le meilleur outil pour piloter cette transition sans mauvaise surprise lors d’un audit.
