Aller au contenu

Guide d'hygiène informatique ANSSI en 42 mesures, mode d'emploi

Guide d’hygiène informatique ANSSI en 42 mesures, mode d’emploi

Section intitulée « Guide d’hygiène informatique ANSSI en 42 mesures, mode d’emploi »

Le guide d’hygiène informatique de l’ANSSI (Agence nationale de la sécurité des systèmes d’information) aligne 42 mesures présentées comme le minimum à tenir sur un système d’information. Cette page parle de la version 2.0, en vigueur : le document porte la date « Septembre 2017 », la page de l’ANSSI qui le diffuse indique une publication le 23 janvier 2017 (site consulté le 11 octobre 2026), et le texte n’a pas été révisé depuis. Elle dit à quoi il sert vraiment (un socle vérifiable avant une analyse de risque ou une mise en conformité à la directive NIS 2, pour Network and Information Security, deuxième du nom), dans quel ordre l’attaquer, et ce qu’il ne remplacera jamais.

→ Lire l’explication complète de la marmotte

Version 2.0 du guide d’hygiène informatique : dates, public visé et statut

Section intitulée « Version 2.0 du guide d’hygiène informatique : dates, public visé et statut »

Le titre complet est « Guide d’hygiène informatique : renforcer la sécurité de son système d’information en 42 mesures ». La première version est parue en janvier 2013, d’après l’avant-propos. La version 2.0 porte donc deux dates, janvier et septembre 2017, et rien n’oblige à trancher : dans les deux cas, le texte ignore les pratiques apparues depuis et les textes adoptés depuis. Un guide de 2017 qui parlerait de 2026 relèverait de la voyance, discipline que l’agence ne qualifie pas.

Le public est nommé par l’avant-propos : les « entités publiques ou privées dotées d’une direction des systèmes d’information (DSI) ou de professionnels dont la mission est de veiller à leur sécurité ». Le guide suppose donc quelqu’un capable de lire une matrice de flux et de modifier une politique de sécurité centralisée. Pour une structure qui ne connaît pas assez son système pour répondre, le mode d’emploi prévoit la sortie : solliciter un spécialiste pour un diagnostic, et lire le « Guide des bonnes pratiques de l’informatique » publié en mars 2015 par l’ANSSI et la CGPME (Confédération générale des petites et moyennes entreprises).

L’origine du texte explique sa forme. L’avant-propos le dit né d’un constat : si ces mesures avaient été appliquées, « la majeure partie des attaques informatiques ayant requis une intervention de l’agence aurait pu être évitée ». Ce n’est pas un catalogue théorique, c’est la liste de ce que les attaquants trouvent ouvert. Le même avant-propos borne le périmètre : l’objet n’est pas « la sécurité de l’information en tant que telle », mais celle du système d’information. Pas de classification des données, pas de gouvernance : de la technique et de l’organisation au ras des machines.

Côté statut, le guide est une recommandation de l’ANSSI, pas une norme, et rien ne s’y certifie. Deux faits lui donnent pourtant du poids. Le mode d’emploi précise que si ses mesures doivent être appliquées parce qu’un référentiel de l’ANSSI le demande, il s’agit, sauf mention explicite, des mesures de niveau « standard ». Et le référentiel SecNumCloud v3.2 écrit, dans son chapitre 4, que le respect de ses exigences « assure notamment le respect des bonnes pratiques de sécurité relevant de l’hygiène informatique », telles que les décrit ce guide, qu’il cite en référence. L’hygiène est donc le plancher sur lequel les référentiels de l’agence posent leurs étages.

Les dix chapitres et les 42 mesures : ce que le guide couvre

Section intitulée « Les dix chapitres et les 42 mesures : ce que le guide couvre »

Les 42 mesures sont rangées en dix chapitres. Le tableau donne la répartition et ce qui s’y vérifie concrètement.

ChapitreMesuresCe qui s’y vérifie
I. Sensibiliser et former1 à 3Formation des équipes opérationnelles, sensibilisation des utilisateurs, exigences contractuelles d’infogérance (réversibilité, audits, plan d’assurance sécurité)
II. Connaître le système d’information4 à 7Données et serveurs sensibles, schéma du réseau, inventaire des comptes privilégiés, procédures d’arrivée et de départ, équipements maîtrisés seuls admis sur le réseau
III. Authentifier et contrôler les accès8 à 13Comptes nominatifs, compte d’administration distinct, droits sur les ressources sensibles, mots de passe (choix, stockage, valeurs par défaut), authentification forte
IV. Sécuriser les postes14 à 18Socle minimal du parc, supports amovibles, gestion centralisée des politiques, pare-feu local, chiffrement de ce qui part sur Internet
V. Sécuriser le réseau19 à 26Segmentation, Wi-Fi, protocoles sécurisés, passerelle d’accès à Internet, cloisonnement des services exposés, messagerie, interconnexions partenaires, accès physique aux salles
VI. Sécuriser l’administration27 à 29Pas d’Internet sur les postes d’administration, réseau d’administration dédié, pas de droits d’administration pour l’utilisateur sur son poste
VII. Gérer le nomadisme30 à 33Protection physique, chiffrement des supports, tunnel non débrayable vers l’entité, politique pour les terminaux mobiles
VIII. Maintenir le système d’information à jour34 et 35Politique de mise à jour, anticipation des fins de support, isolement de l’obsolète
IX. Superviser, auditer, réagir36 à 40Journaux, sauvegardes, audits, référent sécurité, gestion des incidents
X. Pour aller plus loin41 et 42Analyse de risques formelle, produits et services qualifiés

La plupart des mesures sont formulées en obligations de moyens. Les rares seuils chiffrés méritent d’être relevés, parce qu’ils se vérifient sans débat :

  • mesure 34 : correctifs de sécurité appliqués « dans le mois qui suit leur publication par l’éditeur » ;
  • mesure 36 : événements critiques pour la sécurité conservés « pendant au moins un an » ;
  • mesure 37 (niveau renforcé) : au moins un exercice de restauration par an, avec trace technique des résultats ;
  • mesure 38 : audits réguliers, « au moins une fois par an » ;
  • mesure 17 (niveau renforcé) : blocage des ports d’administration par défaut des postes (135, 445 et 3389 sous Windows, 22 sous Unix), sauf depuis les ressources explicitement identifiées.

Chaque mesure se lit à deux niveaux, « standard » et « renforcé », que le mode d’emploi traite comme deux plans d’actions successifs. La répartition n’est pas uniforme : beaucoup de mesures n’ont qu’un niveau standard, et quelques-unes n’existent qu’au niveau renforcé, dont la 38 sur les audits, la 41 sur l’analyse de risques et la 42 sur les produits qualifiés. La mesure 28 montre la gradation la plus lisible : au minimum, un cloisonnement logique du réseau d’administration par VLAN (Virtual Local Area Network), niveau standard ; à défaut de mieux, des tunnels IPsec (Internet Protocol Security), niveau standard aussi ; en premier choix, un cloisonnement physique, niveau renforcé. Le sujet se prolonge dans la page sur le filtrage et la segmentation réseau.

Le guide a aussi le mérite de ne pas se raconter d’histoires sur l’accueil réservé à ses mesures. La mesure 7 (« Autoriser la connexion au réseau de l’entité aux seuls équipements maîtrisés ») est décrite comme « souvent perçue comme inacceptable ou rétrograde », façon courtoise de noter que personne n’a jamais gagné en popularité en la proposant.

Niveaux standard et renforcé : la démarche du mode d’emploi et l’ordre d’attaque

Section intitulée « Niveaux standard et renforcé : la démarche du mode d’emploi et l’ordre d’attaque »

Le mode d’emploi tient en quatre étapes. Le schéma montre la boucle : l’état des lieux n’est pas un point de départ ponctuel, il se recote après chaque lot de corrections, et le niveau renforcé ne s’ouvre qu’une fois le standard atteint partout.

Schéma de flux en boucle. L'outil de suivi alimente l'état des lieux : une ligne par mesure, niveau standard atteint ou non, niveau renforcé le cas échéant. Depuis l'état des lieux partent trois branches : vers un diagnostic par un spécialiste si le système d'information est trop mal connu pour répondre ; vers un premier plan d'actions si des mesures sont sous le niveau standard, traitées en priorité, avec retour à l'état des lieux pour une nouvelle cotation après chaque lot de corrections ; vers un second plan d'actions, qui vise le niveau renforcé, une fois le niveau standard atteint partout.

Le compromis central du guide : il échange le contexte contre la vitesse. On gagne une liste applicable sans étude préalable, identique partout, vérifiable mesure par mesure. On paie l’absence de proportionnalité : dans l’outil de suivi, le filtre de confidentialité sur l’écran d’un portable (mesure 30) occupe une ligne, exactement comme le réseau d’administration cloisonné (mesure 28). Le marché est bon au niveau standard et il faut l’accepter tel quel, sans négocier mesure par mesure. Il devient mauvais au niveau renforcé, où le coût grimpe : là, c’est l’analyse de risque qui doit arbitrer, et la mesure 41 le dit elle-même en rappelant que toute mesure a un coût et doit réduire « au bon niveau un risque identifié ».

Quand tout est à faire, l’outil de suivi ne donne aucun ordre. En voici un, avec sa justification.

  1. Chapitre II d’abord (mesures 4 et 5). Sans schéma du réseau ni inventaire des comptes privilégiés, l’état des lieux des 40 autres mesures est une œuvre de fiction. La mesure 5 demande aussi une nomenclature des comptes de service et d’administration : c’est elle qui rend les revues et la détection praticables.
  2. Comptes et administration ensuite (mesures 8, 27, 28, 29). Compte d’administration nominatif et distinct, utilisé sur un environnement dédié, sans accès à Internet, sur un réseau cloisonné. C’est le lot qui coupe le chemin entre un poste bureautique compromis et le contrôle de tout le système.
  3. Correctifs et sauvegardes (mesures 34 et 37). Le délai d’un mois de la mesure 34 suppose un inventaire des composants ; les systèmes hors support s’isolent par filtrage et par secrets d’authentification dédiés. Le détail relève du durcissement des systèmes.
  4. Segmentation (mesure 19). Chantier long : le guide admet que le cloisonnement a posteriori n’est « pas aisé » et recommande de l’intégrer à chaque extension ou renouvellement d’équipements. À lancer tôt, précisément parce qu’il finit tard.
  5. Journaux (mesure 36). Source de temps identique sur tous les composants, puis un an de rétention. Sans horodatage commun, la corrélation entre équipements ne vaut rien.

Le chapitre I se mène en parallèle et ne remplace rien : un utilisateur parfaitement sensibilisé et administrateur de son poste reste un administrateur, avec en prime la conscience tranquille.

Dernier jugement, qui s’écarte de la lettre du mode d’emploi. La frontière standard/renforcé reflète un effort de mise en œuvre, pas une hiérarchie de gravité. Trois éléments classés « renforcé » gagnent à être anticipés dès que le niveau standard de la même mesure tient : les sauvegardes stockées sur des équipements déconnectés avec restauration vérifiée (mesure 14), la centralisation des journaux sur un dispositif dédié, qui empêche un attaquant d’effacer ses traces sur les machines compromises (mesure 36), et l’audit annuel (mesure 38). Attendre le niveau standard sur 42 lignes avant de mettre une sauvegarde hors ligne, c’est respecter la procédure avec une rigueur que l’attaquant saura apprécier.

Exemple d’état des lieux : cotation des mesures preuve à l’appui

Section intitulée « Exemple d’état des lieux : cotation des mesures preuve à l’appui »

L’outil de suivi annexé au guide est une grille à deux cases par mesure. Telle quelle, elle invite au déclaratif. Deux colonnes de plus la rendent exploitable : la preuve et l’action. Extrait type, sur cinq mesures :

MesureNiveau standard atteint ?PreuveAction
5. Disposer d’un inventaire exhaustif des comptes privilégiés et le maintenir à jourNonExport daté des groupes à privilèges de l’annuaire ; aucun rattachement des comptes de service à un responsableCompléter l’inventaire, fixer une nomenclature, planifier la revue périodique
8. Identifier nommément chaque personne accédant au système et distinguer les rôles utilisateur/administrateurNon (partiel)Comptes d’administration distincts sur les serveurs ; compte générique partagé sur les équipements réseauComptes nominatifs sur les équipements ; rattacher le compte générique restant à une liste fermée de personnes
27. Interdire l’accès à Internet depuis les postes ou serveurs utilisés pour l’administration du système d’informationNonRègle de la passerelle autorisant la navigation depuis les postes d’administrationPoste distinct pour la bureautique, suppression de la règle
34. Définir une politique de mise à jour des composants du système d’informationOui, avec dérogationRapport de déploiement des correctifs dans le mois ; systèmes hors support listés, filtrés, secrets dédiésSuivre la date de retrait des systèmes dérogatoires (mesure 35)
37. Définir et appliquer une politique de sauvegarde des composants critiquesOuiPolitique écrite, procès-verbal du dernier test de restaurationNiveau renforcé : exercice annuel avec trace technique

La règle de cotation appliquée à chaque ligne se résume ainsi. Le schéma montre qu’une mesure ne peut être déclarée atteinte qu’après deux contrôles successifs (la preuve, puis le périmètre), et que « partiel » se range du côté de « non ».

Arbre de décision pour coter une mesure évaluée. Premier contrôle, la preuve : existe-t-il un élément vérifiable par un tiers (export, configuration, procès-verbal de test) ? Sans preuve, la mesure est non atteinte, la déclaration orale ne compte pas. Si la preuve est présente, second contrôle, le périmètre : couvre-t-elle tout le parc concerné ? Couverture partielle sans dérogation écrite : non atteint, en notant le taux réel dans la colonne preuve. Exceptions listées, isolées et datées : atteint avec dérogation. Couverture complète : atteint.

La branche « dérogation » vient du guide lui-même : la mesure 14 exige que les postes dérogeant aux règles globales soient isolés du système, la mesure 34 fait de même pour les composants obsolètes. Une dérogation sans isolement n’est pas une dérogation, c’est un écart avec un nom plus présentable.

Guide d’hygiène, analyse de risque et NIS 2 : qui précède qui

Section intitulée « Guide d’hygiène, analyse de risque et NIS 2 : qui précède qui »

Le guide se place lui-même avant l’analyse de risque. La mesure 41, « Mener une analyse de risques formelle », est rangée dans le chapitre « Pour aller plus loin » et n’existe qu’au niveau renforcé. Elle distingue trois approches : le recours aux bonnes pratiques, une analyse fondée sur les retours d’expérience des utilisateurs, et une gestion structurée par une méthode dédiée. Le guide est la première, et renvoie pour la troisième à la méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) telle qu’elle existait à l’époque, c’est-à-dire la version de 2010. La méthode actuelle, EBIOS RM (Risk Manager), est traitée dans la page sur l’analyse de risque EBIOS RM et ses limites ; le guide n’en dit rien, faute de l’avoir connue.

L’ordre a une raison pratique. Une analyse de risque menée sur un système sans inventaire, sans cloisonnement et sans journaux produit toujours le même plan de traitement : les mesures du guide. Autant commencer par elles et réserver l’analyse à ce qu’elle seule sait faire : décider où le niveau standard ne suffit pas, et où le niveau renforcé serait du luxe.

Pour NIS 2, la prudence s’impose. Le guide est antérieur à la directive et ne la mentionne pas ; il n’existe dans le texte aucune correspondance mesure par mesure, et en fabriquer une relève de l’interprétation. Ce que le guide apporte est d’un autre ordre : un socle technique vérifiable, avec des preuves déjà rassemblées, avant d’ouvrir le dossier des obligations. Les obligations elles-mêmes, leur périmètre et leurs sanctions sont dans la page NIS 2. Même raisonnement pour la norme ISO (International Organization for Standardization) 27001 : le guide n’est pas un système de management et ne se certifie pas, voir ce que garantit une certification ISO 27001.

Angles morts du guide de 2017 et failles de l’auto-évaluation

Section intitulée « Angles morts du guide de 2017 et failles de l’auto-évaluation »

Vérification faite dans le corps des 42 mesures, plusieurs sujets sont absents ou traités avec les références de l’époque.

  • L’informatique en nuage apparaît comme un risque externe, jamais comme une infrastructure à sécuriser : la mesure 18 demande de chiffrer les données avant de les confier à un outil d’hébergement en ligne, la mesure 3 déconseille les solutions non maîtrisées « hébergées dans le nuage » pour les informations sensibles, la mesure 42 cite la qualification SecNumCloud. Rien sur la configuration d’un environnement hébergé, ses identités ou ses clés.
  • Les conteneurs, l’orchestration et les chaînes de déploiement automatisées ne figurent dans aucune mesure. La protection des secrets (mesure 11) vise les mots de passe des personnes et le coffre-fort numérique, pas les secrets manipulés par des programmes.
  • L’authentification forte (mesure 13) range « un téléphone pour recevoir un code SMS » (Short Message Service) parmi les facteurs de possession, et réserve la préférence pour la carte à puce au niveau renforcé.
  • Le Wi-Fi (mesure 20) s’arrête au mode WPA2 (Wi-Fi Protected Access 2), et la mesure 10 sur les mots de passe renvoie à une note technique de juin 2012.
  • Le poste de travail (mesure 14) est protégé par un pare-feu local et un antivirus, sans autre mécanisme de détection.

La règle à en tirer : les principes du guide vieillissent bien (inventorier, cloisonner, séparer l’administration), ses références techniques datées se revérifient une par une avant d’être recopiées dans une politique.

  • Une analyse de risque : il la classe lui-même après lui.
  • Une homologation : c’est une décision prise par une autorité sur un système donné, pas une grille remplie.
  • Un référentiel certifiable : aucun organisme ne délivre de certificat d’hygiène.
  • Une obligation légale : appliquer le guide ne démontre le respect d’aucun texte ; chaque obligation se lit dans son texte.
  • Un audit : la mesure 38 rappelle que les audits « ne constituent jamais une preuve » de l’absence de vulnérabilités. La préparation et l’exploitation d’un audit externe sont traitées dans la page dédiée.

L’auto-évaluation a sa propre surface d’attaque, et elle est interne.

  • La case cochée sans preuve. Elle ne résiste à aucun attaquant ; elle résiste très bien, en revanche, à un comité de pilotage. Contre-mesure : la colonne preuve, obligatoire.
  • Le périmètre implicite. Une mesure « atteinte » sur les postes du siège et ignorée sur les sites distants est une mesure non atteinte. Contre-mesure : écrire le périmètre en tête de l’état des lieux et coter au plus bas.
  • La dérogation sans échéance. Vingt ans de métier apprennent que la dérogation temporaire est l’objet le plus durable d’un système d’information, loin devant les serveurs. Contre-mesure : date de fin et isolement, ou rien.
  • L’état des lieux lui-même. Schéma du réseau, liste des comptes privilégiés, mesures non tenues : le fichier de suivi est une carte au trésor. La mesure 9 range déjà la documentation technique parmi les informations sensibles à protéger ; elle s’applique à ce document en premier.

Suivi des 42 mesures dans la durée : preuves, revues et dérives

Section intitulée « Suivi des 42 mesures dans la durée : preuves, revues et dérives »

Un état des lieux fait une fois décrit un système qui n’existe plus six mois plus tard. Les conditions d’exploitation tiennent en quatre points.

Un responsable nommé. La mesure 39 demande un référent en sécurité des systèmes d’information, soutenu par la direction et connu des utilisateurs, chargé entre autres de vérifier l’application des règles. C’est lui qui tient l’outil de suivi. Sans propriétaire, la grille meurt dans un partage réseau, de préférence ouvert à tous.

Un calendrier calé sur les seuils du guide. Mensuel pour les correctifs (mesure 34), périodique pour la revue des comptes privilégiés (mesure 5) et des droits d’accès (mesures 9 et 26), annuel pour l’exercice de restauration (mesure 37) et l’audit (mesure 38). La mesure 35 ajoute le suivi des dates de fin de support, à tenir dans l’inventaire.

Des preuves datées, conservées et sauvegardées. Une preuve sans date ne prouve que le passé. Le dossier de preuves suit le même régime que les composants critiques : accès restreint, sauvegarde, restauration testée.

Une recotation à chaque changement de périmètre. Nouveau site, nouvelle interconnexion partenaire (mesure 25), nouvelle catégorie de terminaux : le périmètre ajouté repart de zéro, il n’hérite pas du niveau du reste. La mesure 38 suggère des indicateurs d’avancement dans un tableau de bord destiné à la direction ; le nombre de mesures au niveau standard, avec preuve, sur le périmètre complet, est le seul qui ne mente pas.

Le guide d’hygiène informatique est-il obligatoire ?

Section intitulée « Le guide d’hygiène informatique est-il obligatoire ? »

Par lui-même, non : c’est un guide de recommandations. Il devient exigible quand un référentiel de l’ANSSI le rend applicable, et le mode d’emploi précise qu’il s’agit alors, sauf mention explicite, des mesures de niveau « standard ». Savoir si une organisation donnée y est tenue se lit dans le référentiel ou le contrat qui la concerne, pas dans le guide.

Faut-il vraiment atteindre le niveau standard partout avant de viser le renforcé ?

Section intitulée « Faut-il vraiment atteindre le niveau standard partout avant de viser le renforcé ? »

C’est la consigne du mode d’emploi, et elle évite l’erreur classique : un chantier prestigieux sur une mesure pendant que dix autres restent à zéro. L’exception défendue ici porte sur les sauvegardes déconnectées, la centralisation des journaux et l’audit annuel, à anticiper dès que le niveau standard de la mesure correspondante tient.

Le guide convient-il à une structure sans équipe informatique ?

Section intitulée « Le guide convient-il à une structure sans équipe informatique ? »

Il ne lui est pas destiné : l’avant-propos vise les entités dotées d’une DSI ou de professionnels de la sécurité. Le mode d’emploi renvoie dans ce cas vers un spécialiste pour un diagnostic et vers le « Guide des bonnes pratiques de l’informatique » de mars 2015.

Sans ce socle, l’analyse de risque et la mise en conformité s’écrivent sur un système que personne ne sait décrire. Sans schéma du réseau ni inventaire des comptes privilégiés, impossible de dire quels serveurs un poste compromis peut joindre, ni quels comptes ouvrent quoi. Sans compte d’administration distinct utilisé sur un environnement dédié, les traces de connexion et les condensats de mots de passe des administrateurs restent sur des machines exposées à la navigation et au courrier. Sans cloisonnement, la compromission d’une machine met en jeu toutes les autres. Sans journaux conservés et horodatés sur une même source de temps, l’intrusion ne se date pas et son étendue ne se mesure pas. Sans restauration testée, la sauvegarde reste une hypothèse.

L’agence française chargée de la sécurité informatique de l’État a publié une liste de quarante-deux règles de base, rangées en dix thèmes : former les gens, savoir ce qu’on possède, contrôler qui se connecte, protéger les ordinateurs, découper le réseau, isoler les comptes des administrateurs, encadrer le travail en déplacement, installer les correctifs, garder des traces et des copies de secours. Chaque règle a un niveau de base et, souvent, un niveau plus exigeant. La méthode suit un ordre précis. D’abord, on passe les règles une par une et on note, preuve à l’appui, si le niveau de base est atteint. Ensuite, on corrige tout ce qui ne l’est pas. Seulement après, on vise le niveau exigeant. Tout dépend de la première étape : sans liste à jour des machines et des comptes puissants, impossible de répondre honnêtement aux autres questions. Quand une règle est déclarée respectée sans preuve, le défaut reste en place et plus personne ne le cherche. La liste a aussi des limites. Elle date de 2017 et ignore ce qui est apparu depuis. Elle est la même pour tout le monde, donc elle ne dit pas quels dangers pèsent sur une organisation précise : c’est le travail d’une étude des risques, qui vient après. Enfin, la suivre ne prouve pas qu’on respecte la loi.

À lire aussi

Pages voisines

: les deux pages se citent l’une l’autre.