Active Directory, journaux, certificats, supervision et sauvegardes

Les thèmes systèmes de l'E7 SISR portent sur ce qui protège et surveille le cœur du système d'information : l'annuaire Active Directory et les comptes à privilèges, la centralisation des journaux avec Syslog et la lecture du journal de sécurité Windows, la supervision sécurisée en SNMPv3, la détection (EDR, SIEM), les certificats et la preuve électronique, et les sauvegardes qui permettent de survivre à un rançongiciel. Pour chacun, ce chapitre donne l'essentiel à savoir, la forme des questions et des réponses modèles.

Durcir Active Directory

Ce que tu dois savoir. L'annuaire est la cible prioritaire d'un attaquant : qui contrôle un compte administrateur du domaine contrôle tous les postes et serveurs. Les sujets donnent souvent un extrait de rapport d'audit (PingCastle, qui attribue un score de risque au domaine, ou un tableau de bord d'EDR) et demandent de relever les risques et de proposer des mesures.

Pour la politique de mot de passe, la CNIL recommande, quand le mot de passe est le seul facteur d'authentification, au moins 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux, ou au moins 14 caractères mêlant majuscules, minuscules et chiffres. Les recommandations de l'ANSSI raisonnent en force du secret et poussent l'authentification multifacteur pour les comptes à privilèges.

Le cours Windows Server montre la création des GPO et des comptes ; le cours Sécurité de l'Active Directory détaille les attaques et leurs parades et le durcissement du domaine.

Centraliser les journaux avec Syslog

Ce que tu dois savoir. Un journal (log) n'est utile que s'il existe encore après l'incident, s'il est horodaté de façon fiable et si quelqu'un le lit. Les recommandations de l'ANSSI sur la journalisation demandent de synchroniser l'heure de tous les équipements (NTP), de centraliser les journaux sur des serveurs dédiés, protégés et cloisonnés, de chiffrer et d'authentifier leur transport, et de choisir ce que l'on collecte.

Syslog est le protocole standard des équipements réseau et des systèmes Linux. Une architecture résiliente distingue trois rôles :

Transport : UDP 514 dans le mode historique (rapide, mais sans accusé de réception, sans chiffrement ni authentification : des messages peuvent être perdus, falsifiés ou rejoués) ; Syslog sur TLS, TCP 6514 (RFC 5425), qui apporte la fiabilité de TCP, la confidentialité, l'intégrité et l'authentification des deux extrémités par certificats.

La priorité d'un message. Chaque message porte une valeur PRI = facility × 8 + gravité.

Le sélecteur facility.gravité d'un fichier de configuration (rsyslog) retient la gravité indiquée et toutes les plus graves : auth.warning retient les messages d'authentification de gravité 0 à 4. Sur un équipement Cisco, logging trap warnings (ou logging trap 4) envoie de même les gravités 0 à 4 au serveur, c'est-à-dire « strictement inférieures à 5 ».

Trop ou trop peu. Tout transmettre sature le réseau et le stockage, et noie les événements importants ; ne transmettre que les erreurs fait perdre les traces d'une attaque discrète (connexions réussies inhabituelles, changements de configuration). La bonne réponse : choisir les événements de sécurité utiles, avec un niveau de gravité adapté à chaque source.

Sous Windows. Le transfert d'événements Windows (WEF) envoie les journaux des postes et serveurs vers un collecteur Windows (WEC), configuré par GPO, sans agent à installer. Il ne couvre pas les équipements réseau ni les serveurs Linux, d'où une collecte Syslog complémentaire, ou des agents qui envoient tout au SIEM.

Lire le journal de sécurité Windows

Ce que tu dois savoir. Sous Windows, les événements de sécurité (ouvertures de session, créations de comptes, changements de groupes) sont écrits dans le journal « Sécurité », que l'on consulte dans l'Observateur d'événements ou que l'on centralise. Chaque événement porte un identifiant (ID) stable : le reconnaître te permet de lire un extrait de journal sans hésiter. Les authentifications du domaine apparaissent sur les contrôleurs de domaine, les ouvertures de session sur la machine où elles ont lieu. Et ce journal ne se remplit que si la stratégie d'audit, définie par GPO, active les catégories utiles.

Deux champs complètent la lecture. Le type d'ouverture de session dit comment l'utilisateur s'est connecté : 2 au clavier du poste, 3 par le réseau (un partage de fichiers, par exemple), 10 à distance par le bureau à distance. Le code d'état d'un 4625 donne la cause de l'échec : 0xC000006A pour un mot de passe erroné sur un compte qui existe, 0xC0000064 pour un compte qui n'existe pas.

Comment ça tombe. Un extrait de journal à interpréter : une série d'échecs suivie d'une réussite, un compte ajouté à un groupe d'administration, un journal effacé. Le sujet 2024 portait aussi sur la centralisation des journaux des postes par le transfert d'événements Windows (WEF) : savoir quels événements collecter fait alors partie de la réponse. Un 1102 n'efface que la copie locale : si les événements partent au fil de l'eau vers un collecteur, la trace reste.

Superviser en SNMPv3

Ce que tu dois savoir. SNMP sert à interroger les équipements (requêtes du serveur vers l'agent, UDP 161) et à recevoir leurs alertes (traps de l'agent vers le serveur, UDP 162). Les versions 1 et 2c ne protègent les échanges que par une « communauté », un mot de passe qui circule en clair. SNMPv3 ajoute un modèle de sécurité par utilisateur avec trois niveaux : noAuthNoPriv, authNoPriv et authPriv.

Switch(config)# snmp-server group SUPERVISION v3 priv
Switch(config)# snmp-server user supervis SUPERVISION v3 auth sha <secret-auth> priv aes 128 <secret-chiffrement>
Switch(config)# snmp-server host 192.168.20.60 version 3 priv supervis
Switch(config)# snmp-server enable traps port-security

Pour être alerté d'un incident, le trap est préférable à l'interrogation périodique : l'alerte part au moment de l'événement. Le cours Supervision montre la mise en place côté serveur, avec SNMPv3 dans Zabbix.

Détecter : EDR, SIEM, SOC

• Un EDR (Endpoint Detection and Response) surveille le comportement des postes et serveurs, bloque ou isole une machine suspecte et remonte des informations détaillées.
• Un SIEM collecte les journaux et alertes de toutes les sources, les corrèle et déclenche des alertes.
• Un SOC est l'équipe qui surveille ces alertes et les qualifie.

Les sujets fournissent parfois un référentiel de tactiques d'attaque (la matrice MITRE ATT&CK simplifiée en 2026) : tu dois rattacher une alerte à une tactique (déplacement latéral, commande et contrôle…), juger si l'activité est légitime, et expliquer une gravité. Un flux sortant vers le site de mises à jour d'un éditeur connu peut être légitime ; une création de fichiers dans un dossier système d'un serveur, depuis un poste utilisateur, ne l'est presque jamais.

Lire un journal applicatif. En 2026, le sujet donnait le bulletin d'alerte du CERT-FR sur la vulnérabilité Log4Shell, qui indiquait les chaînes à rechercher dans les journaux (${jndi:), et un extrait de journal d'un serveur web : il fallait repérer les lignes qui contenaient cette chaîne, l'adresse qui les envoyait, et conclure sur une tentative d'exploitation. C'est une lecture de défenseur : chercher l'indicateur publié, dater, attribuer une source, puis vérifier si le serveur est concerné (version de la bibliothèque).

Certificats, empreintes et signatures : prouver et authentifier

Ce que tu dois savoir. Un certificat lie une clé publique à une identité, une empreinte prouve qu'un fichier n'a pas changé, une signature prouve en plus qui l'a produit. Ces outils reviennent dans toutes les questions d'identité numérique et de preuve électronique, et dans les justifications de TLS, de Syslog sur TLS ou d'une sauvegarde. Distingue-les par ce qu'ils garantissent.

TLS en pratique. Quand un client se connecte à un serveur en HTTPS (ou en Syslog sur TLS, ou à un serveur de sauvegarde), le serveur présente son certificat. Le client vérifie qu'il est signé par une autorité de confiance, qu'il n'a pas expiré, qu'il n'est pas révoqué et qu'il porte bien le nom du serveur ; le serveur prouve qu'il détient la clé privée correspondante. Les deux établissent ensuite une clé de session, et la suite des échanges est chiffrée en symétrique (AES). Retiens la répartition : l'asymétrique authentifie et sert à établir la clé, le symétrique chiffre les données.

L'empreinte d'un certificat. Quand le certificat d'un serveur interne n'est pas signé par une autorité reconnue (certificat autosigné), le client enregistre l'empreinte du certificat attendu. À chaque connexion, il compare l'empreinte du certificat présenté à celle qu'il connaît, et refuse la connexion si elles diffèrent. C'était le sens de la question du sujet 2026 : l'empreinte du certificat TLS du serveur de sauvegarde, renseignée sur les serveurs qui sauvegardent et sur le serveur distant, empêche un serveur usurpé de se faire passer pour lui (attaque de l'homme du milieu), donc de recevoir les sauvegardes ou d'en fournir de fausses.

Horodatage et preuve. Pour prouver qu'un fichier (un journal, la copie d'un disque) existait à une date donnée et n'a pas changé depuis, on calcule son empreinte et on la fait horodater par un service d'horodatage, qui signe l'empreinte avec la date. Avec des journaux centralisés, horodatés grâce à NTP et protégés contre la modification, ce sont les « moyens de preuve électronique » du référentiel.

Dans un domaine Windows. Une autorité de certification interne (le rôle AD CS) délivre les certificats des serveurs et des postes ; son certificat racine est déployé par GPO, et les postes font alors confiance à tout ce qu'elle signe. C'est le même mécanisme que l'inspection HTTPS du pare-feu, vue au chapitre précédent.

Usurper l'organisation par la messagerie : SPF, DKIM, DMARC. Un attaquant qui envoie des courriels au nom du domaine de l'organisation, pour un hameçonnage ciblé ou une fraude au président, atteint son identité numérique. Trois enregistrements DNS la protègent. SPF liste les serveurs autorisés à envoyer du courrier pour le domaine. DKIM ajoute à chaque message une signature que le destinataire vérifie avec une clé publique publiée dans le DNS. DMARC indique aux destinataires quoi faire d'un message qui échoue à ces contrôles (p=none pour observer, p=quarantine pour le classer en indésirable, p=reject pour le refuser) et leur demande des rapports. Depuis 2024, Gmail et Yahoo exigent les trois des expéditeurs qui envoient de gros volumes.

Sauvegarder contre le rançongiciel

Ce que tu dois savoir. Un rançongiciel moderne cherche et détruit les sauvegardes accessibles avant de chiffrer. Une sauvegarde n'est donc une protection que si l'attaquant ne peut pas l'atteindre et si sa restauration a été testée.

Les règles à connaître :

• 3-2-1 : trois copies des données (la production et deux sauvegardes), sur deux supports différents, dont une hors site ; l'ANSSI insiste sur une copie hors ligne. La variante 3-2-1-1-0 ajoute une copie hors ligne ou immuable et zéro erreur constatée lors des vérifications et des tests de restauration.
• Cloisonner les serveurs de sauvegarde dans une zone distincte de la production, faire circuler les flux de sauvegarde dans un VLAN dédié.
• Comptes dédiés pour administrer la sauvegarde, distincts des comptes du domaine : un attaquant administrateur du domaine ne doit pas pouvoir supprimer les sauvegardes.
• Chiffrer et authentifier les flux et les sauvegardes, et gérer les clés : une sauvegarde chiffrée dont la clé est perdue est perdue ; la clé se conserve aussi hors ligne.
• Tester les restaurations régulièrement et documenter le résultat.

La rétention. On te demande parfois de fixer des paramètres de rétention à partir de besoins métiers et d'obligations légales. Méthode : un paramètre par besoin. Exemple : restaurer une version quotidienne sur 30 jours (30 sauvegardes quotidiennes), garder une version par mois pour les clôtures de l'année (12 mensuelles), conserver une trace annuelle sur la durée légale (6 annuelles pour une obligation fiscale de 6 ans, 10 pour une obligation comptable de 10 ans). Le cours Sauvegarde, PCA et PRA détaille les types de sauvegarde et les tests de restauration.

Pour aller plus loin. Le cours Authentification détaille Active Directory et Kerberos et les comptes à privilèges ; le cours Réponse à incident, la centralisation des journaux et leur analyse ; le cours Cryptographie, les certificats et la PKI. Le cours Wazuh met en place un SIEM sur le labo, de la collecte des journaux à la détection des incidents courants, et le cours Stockage montre comment protéger un NAS contre les rançongiciels.

Exercices