Durcissement Windows et Linux : méthode ANSSI pour un parc réel
Le durcissement consiste à réduire les possibilités d’attaque d’un système tout en conservant les fonctions nécessaires au métier. Sur Windows comme sur Linux, cela signifie connaître les services actifs, limiter les privilèges, protéger l’administration, maintenir les composants et vérifier les changements. L’article 32 du RGPD impose un niveau de sécurité adapté au risque ; il ne publie pas une liste universelle de paramètres. Les guides de l’ANSSI sont des références techniques pour préparer une configuration, non une certification automatique du poste qui les suit.
La décision utile n’est donc pas « quel benchmark appliquer partout ? », mais « quelle configuration standard répond aux menaces de ce parc et comment prouver qu’elle reste en place ? ». Un serveur de soins, un poste d’enseignant et une station d’administration ne peuvent pas recevoir sans analyse les mêmes restrictions. Ce guide relie les recommandations publiques de l’ANSSI à une procédure de déploiement, de dérogation et de contrôle. Les sujets de chiffrement, de sauvegarde et de détection sont traités comme des tâches liées mais distinctes.
1. Définir le parc et son exposition
Commencez par une cartographie du SI qui relie chaque système à son propriétaire, sa version, ses applications, son réseau, son mode d’administration et ses données. Repérez les postes nomades, les serveurs exposés, les contrôleurs de domaine et les systèmes industriels ou médicaux qui ne peuvent pas être redémarrés librement. Notez aussi les machines oubliées : environnements de test, terminaux de prestation, images de déploiement et instances cloud éphémères. Une configuration standard ne peut être contrôlée si l’effectif auquel elle s’applique n’est pas connu.
Classez les systèmes par rôle. Une station d’administration reçoit des restrictions et une surveillance renforcées ; un poste partagé a besoin d’une séparation des sessions et d’un nettoyage approprié ; un serveur applicatif a peu de raisons d’exécuter des services bureautiques. Cette classification évite la politique artificielle « mêmes 200 paramètres partout ». Pour chaque catégorie, documentez le scénario dominant : vol du poste, hameçonnage, accès distant illégitime, déplacement latéral ou exploitation d’un service réseau.
Exemple hypothétique : une PME possède 80 postes Windows, deux contrôleurs de domaine et 12 serveurs Linux. Elle commence par les comptes d’administration, les services exposés et les sauvegardes des contrôleurs. Elle pilote ensuite une image Windows de référence sur quelques postes métier. Elle ne désactive pas à l’aveugle un protocole ancien utilisé par un automate ; elle isole cette dépendance et fixe un calendrier de remplacement. Le résultat est traçable dans la PSSI.
2. Lire correctement les guides ANSSI
L’ANSSI publie des recommandations pour la configuration GNU/Linux, datées de février 2019, couvrant installation, services et cloisonnement. Son guide d’administration sécurisée des SI reposant sur Active Directory, publié en octobre 2023, traite du cloisonnement des zones de confiance et des pratiques d’administration. Le guide de journalisation Windows en environnement AD explique la collecte et la protection des événements. Ces publications n’ont pas le même objectif ; un guide de journaux n’est pas une liste complète de durcissement Windows.
Vérifiez la date et le périmètre de chaque document avant de reprendre un paramètre. Un texte écrit pour une version antérieure de Windows peut garder une valeur de principe, mais sa mise en œuvre peut avoir changé. De même, la disponibilité de Credential Guard, de l’intégrité de la mémoire ou de certaines règles de contrôle applicatif dépend de l’édition, du matériel et de la configuration. Contrôlez la documentation actuelle du fournisseur et testez sur le parc réel. L’inscription « activé par défaut » dans un article ne remplace jamais une mesure de l’état effectif.
Les référentiels CIS ou STIG peuvent aider à établir une base technique, avec leur propre champ et leurs propres hypothèses. Ils ne deviennent pas automatiquement une obligation RGPD ou NIS 2. Si un audit contractuel exige un benchmark, consignez précisément l’édition, le profil retenu, les exclusions et les preuves. Sans ces précisions, un score global donne une fausse impression de sécurité.
3. Windows : identité et poste de travail
Sur un poste Windows, la priorité est de contenir la compromission d’un compte utilisateur. Limitez les comptes administrateurs locaux, donnez à chaque machine un secret distinct lorsque ce type de compte reste nécessaire et utilisez les capacités Windows LAPS adaptées à votre environnement. Séparez le compte quotidien et le compte d’administration. Protégez les sessions privilégiées par une authentification forte et des postes dédiés ou correctement isolés. Une élévation de droits permanente pour installer des logiciels contourne rapidement la configuration du système.
Activez les protections pertinentes après un pilote : pare-feu, antivirus ou EDR, protection contre les modifications non autorisées, contrôle des applications lorsque sa maintenance est possible, protection des identifiants et chiffrement des postes nomades. Validez les effets sur les pilotes, logiciels métiers et méthodes de récupération. Pour BitLocker, gardez une procédure contrôlée d’accès à la clé de récupération ; la perte de cette clé peut interrompre une activité. Pour les postes exposés au vol, reliez le chiffrement à un verrouillage de session et au retrait rapide des accès à distance.
Réduisez les services et protocoles inutiles. L’ancien SMBv1 mérite un examen prioritaire, mais sa désactivation doit s’accompagner de l’identification des équipements dépendants. Les connexions d’administration à distance ne doivent pas être publiées directement sur Internet sans architecture de protection. Vérifiez la configuration effective plutôt qu’une valeur de GPO prévue : une unité d’organisation mal ciblée ou un poste rarement connecté peut rester hors de la politique. Conservez la dernière remontée de conformité et un traitement des machines silencieuses.
4. Active Directory : protéger l’administration
Un annuaire AD concentre les identités et devient une cible de déplacement latéral. Le guide ANSSI sur l’administration sécurisée recommande de cloisonner les environnements d’administration et de réduire les ponts entre niveaux de confiance. Dans la pratique, inventoriez les groupes privilégiés, les comptes de service, les délégations et les systèmes où ils ouvrent des sessions. Une machine utilisateur ne devrait pas devenir le point d’entrée habituel d’un administrateur de domaine. La revue doit aussi couvrir les comptes créés pour les prestataires et jamais supprimés.
Pour les comptes de service, consultez aussi la politique de mots de passe ANSSI ; privilégiez des mécanismes adaptés, tels que les comptes gérés lorsqu’ils sont compatibles, et éliminez les secrets partagés en clair dans les scripts. Vérifiez les délégations Kerberos et les comptes sans préauthentification selon le risque et l’usage. Les termes Kerberoasting, AS-REP roasting ou DCSync désignent des techniques d’attaque ou d’abus ; aucune case cochée ne les « élimine » à elle seule. Les contrôles conjuguent configuration, droits, journaux et réaction aux alertes.
Protégez aussi les sauvegardes d’AD et répétez une restauration contrôlée. La fréquence d’une sauvegarde dépend du rythme de changement, du délai de reprise et de l’architecture ; « quotidienne hors ligne » n’est pas une obligation universelle de l’ANSSI. La procédure doit préciser qui peut restaurer, comment les secrets restaurés sont sécurisés et comment vérifier l’intégrité de l’annuaire après l’opération.
5. Linux : réduire services et privilèges
Sur GNU/Linux, partez d’une image minimale maintenue par la distribution. Désinstallez ou désactivez les services qui n’ont pas de fonction. Établissez un pare-feu en fonction des flux réellement nécessaires et limitez les interfaces d’administration. Pour SSH, contrôlez l’authentification, les comptes autorisés, les clés et les accès réseau ; changer seulement le numéro de port ne constitue pas un contrôle de sécurité suffisant. Les comptes techniques doivent recevoir les droits requis par leur tâche et pouvoir être retirés sans casser le service.
Les mécanismes SELinux et AppArmor apportent un cloisonnement supplémentaire là où les profils et la capacité de maintenance le permettent. Un passage brutal en mode strict peut interrompre un service et conduire à une désactivation durable. Commencez par observer les refus, adapter les politiques et vérifier les opérations normales, les sauvegardes et les mises à jour. Le même raisonnement vaut pour les options de montage et les paramètres sysctl : certaines réduisent une exposition, d’autres cassent un logiciel ou n’ont pas de pertinence dans une machine virtuelle donnée.
La journalisation doit permettre d’enquêter sans collecter indéfiniment des données inutiles. Définissez les événements nécessaires, synchronisez les horloges, protégez l’accès aux logs et assurez leur transfert quand le serveur peut être détruit par l’attaquant. Le SOC et le SIEM décrivent le traitement de ces signaux. Le durcissement réduit la surface ; il ne remplace pas la capacité à détecter une compromission.
6. Vulnérabilités et correctifs : raisonner en priorité
Aucun délai « 48 heures pour CVSS 9 » ne découle automatiquement du RGPD, des guides ANSSI ou de NIS 2 pour tous les systèmes. Une politique interne peut fixer des cibles plus exigeantes, mais elle doit être réaliste et dotée d’une procédure d’exception. Classez une vulnérabilité selon l’exploitation connue, l’exposition de l’actif, la présence de données sensibles, les privilèges obtenus et les mesures compensatoires. Le score CVSS seul ne décrit pas votre risque. Une faille activement exploitée sur une passerelle exposée peut passer avant une faille théoriquement plus grave sur un serveur isolé.
Planifiez le correctif, testez-le, prévoyez un retour arrière, puis vérifiez l’installation réelle. Une mise à jour annoncée par la console qui n’a jamais atteint le poste ne clôt pas le risque. Si le correctif est impossible immédiatement, limitez l’exposition réseau, désactivez la fonction vulnérable ou renforcez la surveillance, et donnez une date de réévaluation à l’exception. L’analyse EBIOS Risk Manager peut aider à formaliser les scénarios complexes.
La directive européenne NIS 2 évoque notamment la gestion des vulnérabilités et les pratiques de sécurité. En France, au 27 septembre 2026, l’ANSSI présente encore la transposition et le ReCyF comme des travaux en cours. La page sur la transposition française doit être lue à cette date : un projet de loi ou un document de travail ne crée pas à lui seul un « SLA NIS 2 » opposable. Les obligations sectorielles préexistantes et les engagements contractuels restent à examiner séparément.
7. Déployer sans interrompre le métier
Écrivez une configuration de référence par famille de système, puis comparez l’état réel à cette référence. Sur Windows, les politiques de groupe ou la gestion moderne des postes peuvent distribuer les paramètres ; sur Linux, une gestion de configuration peut produire le même résultat. Versionnez les paramètres, nommez leur propriétaire et reliez chaque changement à un essai fonctionnel. Une configuration reproductible réduit les dérives lorsqu’un serveur est reconstruit en urgence.
Le pilote doit représenter de vrais usages : poste distant, utilisateur handicapé ayant besoin d’un outil d’assistance, application ancienne, administrateur d’astreinte et restauration de sauvegarde. Mesurez les échecs d’ouverture de session, les refus applicatifs et les demandes de support. Toute dérogation indique l’actif, la raison, le contrôle compensatoire, le décideur et la date de fin. Une dérogation permanente sans revue n’est qu’une suppression silencieuse du contrôle.
Exemple hypothétique : une règle de contrôle applicatif bloque une macro utilisée pour l’import quotidien d’un laboratoire. L’équipe ne désactive pas la règle pour tout l’hôpital. Elle vérifie l’origine du fichier, signe ou remplace la macro, restreint son exécution aux postes nécessaires et documente la solution transitoire. Ce cas montre pourquoi un indicateur de « conformité à 100 % » peut masquer un risque transféré ailleurs.
8. Mesurer et revoir la configuration
Suivez quelques indicateurs liés au risque : systèmes inventoriés avec propriétaire, versions sans support, comptes privilégiés inutilisés, correctifs critiques en attente sur actifs exposés, services réseau non justifiés et dérogations dépassées. Échantillonnez les paramètres effectivement appliqués, pas seulement le déploiement annoncé. Une revue de sécurité du traitement doit inclure les résultats des restaurations et des exercices de réponse aux incidents.
Lorsqu’un incident révèle un accès par un compte de service ou un port oublié, mettez à jour la référence et les images de déploiement. Une configuration qui n’évolue pas avec l’environnement devient une photographie historique. La preuve la plus utile pour un auditeur reste un lien clair entre le risque, le paramètre choisi, son déploiement vérifié et la correction des écarts.