Cours Active Directory & Windows Server - Partie 7-bis¶

Gouverner et intégrer les outils de sécurité DANS Active Directory¶

Windows Server 2022 - le liant opérationnel¶

Prérequis : Parties 1 à 7. Cette partie est le liant de tout le cours. Jusqu'ici on a vu chaque outil isolément - Sysmon (P7), WEF (P4/P7), SIEM, agents, SOAR, JEA (P4), PKI (P2), LAPS (P4). Ici on répond à la question d'exploitation : comment déployer, administrer, sécuriser et gouverner tout ce tooling à l'échelle du parc, en utilisant les mécanismes natifs d'AD - OU, GPO, gMSA, délégation, tiering.

La bascule d'ingénieur : un outil de sécurité mal gouverné est pire qu'un outil absent. Un SIEM avec un compte de service Domain Admin, un collecteur non durci, des agents déployés à la main machine par machine, des analystes SOC membres de « Domain Admins » - c'est exactement ce qu'un attaquant rêve de trouver. Ton tooling de sécurité est une surface d'attaque de premier plan, et souvent un actif Tier 0. Cette partie le gouverne comme tel.

Fil rouge : moindre privilège pour le tooling, déploiement déclaratif à l'échelle, et protection Tier 0 de ce qui voit/contrôle tout. On réinvestit tout : OU/GPO/AGDLP (P1), gMSA/PKI (P2), tiering/JEA/LAPS (P4), detection-as-code (P7).

Structure (6 modules, 75 → 80)¶

75 - Principe : le tooling de sécurité comme infra gouvernée (et Tier 0)
76 - Structure d'OU & tiering appliqués au tooling
77 - Déploiement à l'échelle par GPO (Sysmon, agents, WEF, audit, logging)
78 - Identités & comptes de service (gMSA, délégation SOC via JEA)
79 - Sécuriser le tooling lui-même (logs inviolables, anti-sabotage, break-glass)
80 - Gouvernance as code & cycle de vie + projet final

Module 75 - Le tooling de sécurité comme infrastructure gouvernée¶

75.1 L'erreur fondatrice à ne jamais commettre¶

La plupart des organisations déploient leurs outils de sécurité en dehors de toute gouvernance : agents installés à la main, comptes de service sur-privilégiés, consoles admin accessibles depuis n'importe quel poste. Résultat : l'outil censé les protéger devient le maillon faible. Un ingénieur pense l'inverse : chaque outil de sécurité est un objet AD à classer, déployer, restreindre et surveiller comme le plus sensible des serveurs.

75.2 Classer le tooling par niveau (le tiering, rappel P4 M12/M33)¶

Rappel du modèle de niveaux, appliqué au tooling :

Tier	Outils concernés	Pourquoi
Tier 0	SIEM, WEC (collecteur), console EDR, PKI (CA), SOAR, C2 de lab, contrôleurs de domaine	Ils voient et/ou contrôlent tout. Compromettre le SIEM = voir toutes les détections et t'aveugler. Compromettre le SOAR = désactiver des comptes en masse. Compromettre la CA = forger des identités (P2).
Tier 1	Serveurs de gestion (WSUS, GPO mgmt), serveurs d'agents	Contrôle large mais pas total
Tier 2	Postes, agents endpoint	Périmètre local

L'insight qui vaut la partie entière : ton SIEM est un actif Tier 0. Il agrège tous les logs = il contient la carte complète de ton réseau et de tes détections. Un attaquant qui le compromet sait exactement ce que tu détectes, peut supprimer ses traces, et t'aveugle. On l'administre donc uniquement depuis un PAW, avec des comptes Tier 0 dédiés, jamais depuis un poste bureautique. Idem pour le collecteur WEC (il reçoit tout) et le SOAR (il peut agir sur l'AD).

75.3 Les trois piliers de la gouvernance du tooling¶

Déployer de façon déclarative et à l'échelle (GPO/DSC), jamais à la main - un agent manquant = un angle mort (module 77).
Restreindre les identités du tooling au strict nécessaire (gMSA, délégation, jamais Domain Admin - module 78).
Protéger le tooling lui-même : logs inviolables, anti-sabotage des capteurs, accès Tier 0, break-glass (module 79).

75.4 Exercice n°63¶

Dresse l'inventaire des outils de ton lab (Sysmon, WEC, SIEM, SOAR, PKI, LAPS…) et classe chacun par tier. Justifie chaque Tier 0.
Pour ton SIEM, écris en 5 lignes le scénario d'attaque « l'attaquant possède le SIEM » et ses conséquences. Conclus sur les mesures.
Identifie, dans ton lab actuel, un outil administré depuis un poste non-PAW → note-le comme dette à corriger.

Module 76 - Structure d'OU & tiering appliqués au tooling¶

76.1 Une place dédiée pour la sécurité dans l'annuaire¶

Rappel P1 : la structure d'OU sert l'administration et les GPO, pas l'organigramme. Le tooling de sécurité mérite ses propres OU, pour lui appliquer des GPO spécifiques (durcissement fort, restrictions de logon) et une délégation isolée. Extension de la structure des Parties 1/4 :

corp.lab.local
├── OU=Admin                          (comptes/groupes d'admin - P4)
│   ├── OU=Tier0                       (comptes T0 : adm-t0-*, break-glass)
│   ├── OU=Tier1
│   └── OU=SOC                         (comptes et groupes du SOC)
├── OU=Tier0-Infrastructure           (les ACTIFS T0)
│   ├── OU=DomainControllers          (les DC - déjà là)
│   ├── OU=PKI                         (ROOTCA offline / SUBCA - P2)
│   └── OU=Security-Tooling            (★ le cœur de cette partie)
│       ├── OU=SIEM                    (SIEM, WEC/collecteurs)
│       ├── OU=SOAR
│       └── OU=EDR-Management
├── OU=Tier1-Servers
│   └── OU=Security-Agents-Mgmt        (WSUS, serveurs de déploiement d'agents)
├── OU=Serveurs                        (P1)
└── OU=Postes                          (P1 - cibles des agents/Sysmon)

# Créer l'ossature dédiée au tooling
$base = "DC=corp,DC=lab,DC=local"
New-ADOrganizationalUnit -Name "Tier0-Infrastructure" -Path $base
$t0 = "OU=Tier0-Infrastructure,$base"
New-ADOrganizationalUnit -Name "Security-Tooling" -Path $t0
$sec = "OU=Security-Tooling,$t0"
"SIEM","SOAR","EDR-Management" | ForEach-Object {
    New-ADOrganizationalUnit -Name $_ -Path $sec
}
New-ADOrganizationalUnit -Name "SOC" -Path "OU=Admin,$base"

76.2 Groupes SOC en AGDLP (rappel P1)¶

On ne rend jamais un analyste « Domain Admin ». On modélise ses rôles proprement :

$socOU = "OU=SOC,OU=Admin,DC=corp,DC=lab,DC=local"
# Groupes GLOBAUX = les rôles (les personnes)
New-ADGroup -Name "G_SOC_Tier1" -GroupScope Global -GroupCategory Security -Path $socOU
New-ADGroup -Name "G_SOC_Tier2" -GroupScope Global -GroupCategory Security -Path $socOU
New-ADGroup -Name "G_SOC_Response" -GroupScope Global -GroupCategory Security -Path $socOU
# Groupes DOMAIN LOCAL = les capacités (les droits sur des ressources)
New-ADGroup -Name "DL_Read_SecurityLogs" -GroupScope DomainLocal -GroupCategory Security -Path $socOU
New-ADGroup -Name "DL_Containment_AD"    -GroupScope DomainLocal -GroupCategory Security -Path $socOU
# Chaînage AGDLP
Add-ADGroupMember "DL_Read_SecurityLogs" "G_SOC_Tier1","G_SOC_Tier2"
Add-ADGroupMember "DL_Containment_AD"    "G_SOC_Response"

G_SOC_Response recevra la capacité de confinement (désactiver un compte) via JEA au module 78 - pas des droits admin.

76.3 Séparer les GPO : durcir fort le tooling¶

Chaque OU de tooling reçoit des GPO plus strictes que la prod : refus de logon interactif pour les comptes non-T0, restriction des flux, pas de navigation, baseline renforcée (P4 M33). Le tooling Tier 0 n'est administrable que depuis un PAW.

76.4 Exercice n°64¶

Crée l'OU Security-Tooling et ses sous-OU ; déplaces-y tes VM SIEM/WEC/SOAR de lab.
Modélise les groupes SOC en AGDLP (76.2).
Crée une GPO GPO-C-Tier0-Tooling liée à l'OU tooling qui interdit le logon interactif aux comptes non-Tier 0 (User Rights Assignment : « Deny log on locally / through RDP »).

Module 77 - Déploiement à l'échelle par GPO¶

77.1 Le principe : jamais à la main, toujours déclaratif¶

Un capteur installé manuellement sur 200 machines, c'est 200 occasions d'en oublier une - et une machine sans Sysmon est un angle mort pour l'attaquant. La règle d'ingénieur : le tooling se déploie par mécanisme centralisé (GPO), s'applique automatiquement aux nouvelles machines (via l'OU), et se vérifie. AD est la meilleure plateforme de déploiement de ton stack défensif.

77.2 Déployer Sysmon par GPO¶

Sysmon s'installe/se met à jour en ligne de commande (P7), donc on l'orchestre par une tâche planifiée poussée en GPO, alimentée depuis un partage de référence (SYSVOL ou un partage dédié en lecture pour Domain Computers).

# 1. Déposer les binaires + la config sur un partage lisible par les machines
#    \\corp.lab.local\Deploy\Sysmon\Sysmon64.exe
#    \\corp.lab.local\Deploy\Sysmon\sysmonconfig.xml   (sysmon-modular, versionné en Git)

# 2. GPO "GPO-C-Deploy-Sysmon" liée à OU=Ordinateurs (et OU=Serveurs) :
#    Computer > Preferences > Control Panel Settings > Scheduled Tasks
#    Tâche "Deploy-Sysmon", exécutée en SYSTEM au démarrage + quotidienne, action :

# Logique exécutée par la tâche (script de déploiement idempotent)
$svc = Get-Service Sysmon64 -ErrorAction SilentlyContinue
if (-not $svc) {
    & \\corp.lab.local\Deploy\Sysmon\Sysmon64.exe -accepteula -i \\corp.lab.local\Deploy\Sysmon\sysmonconfig.xml
} else {
    # Déjà installé : (re)pousser la config si elle a changé (idempotence)
    & \\corp.lab.local\Deploy\Sysmon\Sysmon64.exe -c \\corp.lab.local\Deploy\Sysmon\sysmonconfig.xml
}

Idempotence : le script vérifie l'état avant d'agir → il peut tourner tous les jours sans casser. C'est la mentalité config management (DSC/Ansible), appliquée via GPO. Mettre à jour la config sur tout le parc = remplacer un fichier sur le partage.

77.3 Déployer les agents (Winlogbeat / Wazuh / EDR)¶

Deux voies AD-natives :

GPO Software Installation (pour les MSI) : Computer > Policies > Software Settings > Software Installation → assigner le MSI de l'agent. Installé au démarrage, désinstallable proprement. Idéal pour un agent packagé en MSI.

Tâche planifiée GPO (comme Sysmon) pour les installeurs non-MSI ou avec paramètres (clé d'inscription Wazuh, adresse du manager) :

# Wazuh agent : install silencieux + inscription au manager
msiexec /i \\corp.lab.local\Deploy\Wazuh\wazuh-agent.msi /q `
  WAZUH_MANAGER="siem.corp.lab.local" WAZUH_REGISTRATION_SERVER="siem.corp.lab.local"

77.4 Déployer la configuration de collecte par GPO (WEF, audit, logging)¶

Le vrai déploiement à l'échelle, ce n'est pas que les binaires - c'est la config de télémétrie poussée uniformément. Une GPO « socle de détection » (liée haut dans l'arbre) qui active partout :

GPO-C-Detection-Baseline (liée au domaine ou aux OU serveurs/postes) :

Event Forwarding : "Configure target Subscription Manager"
Server=http://WEC01.corp.lab.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
WinRM : activer le service (pour WEF)
Groupe "Event Log Readers" : ajouter NETWORK SERVICE (Restricted Groups)
Advanced Audit Policy Configuration (P1/P4) : Account Logon, Logon/Logoff, DS Access, Detailed Tracking (process creation), Sensitive Privilege Use, Object Access (selon SACL)
"Include command line in process creation events" = Enabled (4688 enrichi)
PowerShell : Script Block Logging + Module Logging + Transcription (P4)
(rappel P4) ASR rules, Credential Guard, LAPS

Point clé : la Detection Baseline est une GPO unique et versionnée qui garantit que chaque machine du parc émet la bonne télémétrie. Un nouveau serveur placé dans l'OU hérite automatiquement de tout le stack de détection. C'est ça, gouverner par AD.

77.5 Vérifier le déploiement (le contrôle de couverture)¶

Déployer sans vérifier = espérer. On mesure la couverture :

# Quelles machines n'ont PAS le service Sysmon ? (angle mort de détection)
$computers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"}
foreach ($c in $computers) {
    $s = Get-Service -ComputerName $c.DNSHostName -Name Sysmon64 -ErrorAction SilentlyContinue
    [pscustomobject]@{ Machine = $c.Name; Sysmon = if($s){$s.Status}else{"ABSENT"} }
} | Where-Object Sysmon -eq "ABSENT"

# Quelles machines ne remontent plus de logs depuis 24h ? (à corréler côté SIEM)

La couverture télémétrie (% d'actifs qui émettent) est une métrique SOC (P7 M73). Vise 100 %, alerte sur les manquants.

77.6 Exercice n°65¶

Déploie Sysmon par tâche planifiée GPO depuis un partage \\corp.lab.local\Deploy, en mode idempotent. Ajoute une machine à l'OU et vérifie l'auto-déploiement.
Crée la GPO GPO-C-Detection-Baseline (WEF + audit avancé + command line + PowerShell logging) liée aux OU serveurs/postes.
Écris le script de contrôle de couverture Sysmon et identifie les angles morts.
Change la config Sysmon une seule fois sur le partage et prouve la propagation au parc.

Module 78 - Identités & comptes de service du tooling¶

78.1 Le péché mortel : le compte de service Domain Admin¶

L'anti-pattern le plus courant et le plus grave : installer un SIEM, un agent, un SOAR, une sauvegarde… avec un compte de service membre de Domain Admins « parce que c'est plus simple ». Résultat : le hash de ce compte traîne sur le serveur du tooling (P5 M38), et sa compromission = domaine entier. Chaque outil tourne avec le privilège minimal, via un compte géré.

78.2 gMSA pour les comptes de service (rappel P1 M11.4 / P2)¶

Les Group Managed Service Accounts ont un mot de passe de 240 octets, pivoté automatiquement par AD, jamais connu d'un humain - donc ni volable ni rejouable utilement. C'est le standard pour tout service/agent/tâche du tooling.

# gMSA pour l'agent de collecte / forwarder tournant en compte de service
New-ADServiceAccount -Name "gmsa-siemfwd" `
    -DNSHostName "gmsa-siemfwd.corp.lab.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "G_SIEM_Servers"
# Sur chaque serveur SIEM : installer et tester
Install-ADServiceAccount gmsa-siemfwd
Test-ADServiceAccount gmsa-siemfwd     # True attendu
# Le service tourne sous CORP\gmsa-siemfwd$ (mot de passe vide, géré par AD)

Note : Sysmon tourne en SYSTEM (pas de compte à gérer). Le collecteur WEC utilise Network Service. Les agents SIEM/EDR et surtout le SOAR (qui agit sur AD) doivent utiliser des gMSA à privilèges délégués et précis.

78.3 Délégation : donner à chaque outil juste ce qu'il lui faut¶

Principe de moindre privilège appliqué finement (rappel délégation P1 M6.6) :

SIEM / agents : besoin de lire des logs et éventuellement l'annuaire. → DL_Read_SecurityLogs, appartenance à Event Log Readers, lecture seule LDAP. Jamais d'écriture.

SOAR : besoin d'agir pour le confinement (désactiver un compte, le sortir de groupes). → délégation ciblée sur les OU concernées, pas Domain Admin :

# Déléguer au gMSA du SOAR le droit de DÉSACTIVER des comptes utilisateurs
#   (write sur userAccountControl) sur l'OU Utilisateurs uniquement - via dsacls
dsacls "OU=Utilisateurs,OU=CORP,DC=corp,DC=lab,DC=local" `
  /I:S /G "CORP\gmsa-soar$:WP;userAccountControl;user"
# Rien de plus. Pas de reset de mdp sur les OU d'admin, pas de droits sur les DC.

78.4 Le confinement SOC sans privilège : JEA (rappel P4 M31)¶

Comment un analyste G_SOC_Response désactive un compte compromis sans être admin ? Un endpoint JEA dédié - moindre privilège au niveau commande, tout transcrit.

# Role capability : SEULEMENT les commandes de confinement
New-PSRoleCapabilityFile -Path "C:\JEA\Roles\SOC-Response.psrc"

@{
  VisibleCmdlets = @(
    'Disable-ADAccount',
    'Unlock-ADAccount',
    @{ Name='Get-ADUser'; Parameters=@{ Name='Identity' } },
    @{ Name='Set-ADAccountPassword'; Parameters=@{ Name='Identity' } },
    'Get-ADPrincipalGroupMembership'
  )
}

# Session config : s'exécute sous un gMSA délégué, runspace verrouillé, TOUT journalisé
New-PSSessionConfigurationFile -Path "C:\JEA\SOC-Response.pssc" # ...
@{
  SessionType         = 'RestrictedRemoteServer'
  GroupManagedServiceAccount = 'CORP\gmsa-socresponse$'   # identité privilégiée déléguée
  TranscriptDirectory = 'C:\JEA\Transcripts'
  RoleDefinitions     = @{ 'CORP\G_SOC_Response' = @{ RoleCapabilities = 'SOC-Response' } }
}
Register-PSSessionConfiguration -Name "JEA-SOC-Response" -Path "C:\JEA\SOC-Response.pssc"

L'analyste se connecte à l'endpoint et ne peut rien faire d'autre que confiner :

Enter-PSSession -ComputerName ADMGMT01 -ConfigurationName "JEA-SOC-Response" -Credential CORP\soc1
# Disable-ADAccount jdupont  → OK et transcrit
# Get-Process / Stop-Computer → REFUSÉ

C'est l'aboutissement : le SOAR (78.3) et les analystes (JEA) peuvent confiner, sans jamais détenir de droits admin permanents, et chaque action est tracée pour le postmortem (P4/P7).

78.5 Exercice n°66¶

Crée un gMSA pour ton agent SIEM (lecture seule) et un autre pour le SOAR (délégation ciblée de désactivation de compte via dsacls).
Vérifie que le gMSA SOAR ne peut PAS toucher les OU d'admin ni les DC.
Crée l'endpoint JEA-SOC-Response et prouve qu'un analyste peut désactiver un compte mais pas lancer un shell.
Retrouve la trace de l'action dans le transcript JEA.

Module 79 - Sécuriser le tooling lui-même¶

79.1 Le paradoxe du gardien¶

Ton tooling de sécurité voit et contrôle tout - donc c'est la première cible d'un attaquant compétent. Avant de neutraliser sa victime, un adversaire cherche à aveugler le SOC : arrêter Sysmon, vider les journaux, couper le forwarding, compromettre le SIEM. Ce module protège le gardien.

79.2 Rendre les logs inviolables¶

Un attaquant admin local peut effacer les journaux (wevtutil cl Security, event 1102). La parade n'est pas d'empêcher l'effacement (impossible pour un admin local), c'est de sortir les logs de la machine plus vite qu'il ne peut les effacer :

WEF vers le WEC en quasi temps réel (Refresh court) : même si l'attaquant vide le journal local, la copie est déjà partie. Les logs vivent hors de portée de l'hôte compromis.
Immutabilité côté SIEM (rappel P4 3-2-1-1-0) : stockage WORM / rétention verrouillée → l'attaquant qui atteint le SIEM ne peut pas réécrire l'historique.
Compte de sauvegarde/collecte hors domaine de prod (P4) : si le domaine tombe, le référentiel de logs n'est pas atteignable avec des identifiants AD.
Alerter sur 1102 (log cleared) et 4719 (audit policy changed) : l'effacement lui-même est une détection à haute valeur.

79.3 Anti-sabotage des capteurs¶

L'attaquant tentera de désactiver Sysmon (sysmon -u, arrêt de service, altération de config) ou d'aveugler ETW/AMSI (P6-bis M65). On surveille l'absence :

Arrêt de service Sysmon → event système 7036/7040 sur le service Sysmon64 ; Sysmon Event 255 (erreur) ; désinstallation du driver.
Changement de config Sysmon → Sysmon Event 16 (le capteur logue lui-même sa reconfiguration) : toute config non poussée par ta GPO = suspecte.
Chute de volume de télémétrie (Sysmon/Security/PowerShell) → détection d'aveuglement (P6-bis M65) : une source qui se tait est une alerte.
Protéger le service : ACL restrictives, et sur Windows récent, envisager la protection du service ; sauvegarder la config en lecture seule sur le partage (module 77).

Règle SIEM "capteur muet" : pour chaque hôte, si volume(Sysmon events, 1h) == 0
   alors que baseline > 0  → ALERTE (aveuglement probable)

79.4 Accès Tier 0 strict au tooling¶

Rappel P4, appliqué au tooling (module 75) :

SIEM / WEC / console EDR / SOAR / PKI administrés uniquement depuis un PAW, avec des comptes Tier 0 dédiés (adm-t0-*), jamais des comptes bureautiques.
Comptes T0 dans Protected Users (P4) : pas de cache, NTLM bloqué, délégation interdite.
Authentication Policies / Silos : verrouiller où les comptes T0 peuvent s'authentifier (uniquement sur les actifs T0).
Segmentation réseau : le management du tooling sur un VLAN isolé ; l'ingestion SIEM et l'egress des collecteurs filtrés (rappel egress filtering, P6-bis M64).

79.5 Break-glass : le compte de secours maîtrisé¶

Que se passe-t-il si l'AD est compromis/inaccessible en plein incident et que tes JEA/délégations tombent ? Il faut des comptes break-glass :

1 ou 2 comptes d'urgence à privilèges élevés, hors des dépendances normales (pas soumis à une éventuelle politique d'accès conditionnel qui pourrait les bloquer).
Identifiants longs, aléatoires, scindés (deux moitiés détenues par deux personnes) et stockés physiquement hors ligne (coffre).
Aucune utilisation en temps normal → toute authentification de ces comptes déclenche une alerte immédiate de sévérité maximale (c'est un honeytoken privilégié).
Testés périodiquement (le mot de passe fonctionne-t-il encore ?), rotation après usage.

79.6 Exercice n°67¶

Règle ton WEF pour un forwarding quasi temps réel et prouve qu'un wevtutil cl Security sur une source n'efface pas la copie déjà collectée sur le WEC.
Écris les détections « 1102 (log cleared) », « arrêt du service Sysmon » et « capteur muet » (chute de volume).
Mets les comptes T0 du tooling dans Protected Users et vérifie le comportement.
Crée un compte break-glass documenté (scindé, hors ligne) et la règle d'alerte « toute authentification = incident P1 ».

Module 80 - Gouvernance as code & cycle de vie¶

80.1 L'aboutissement : gouverner le tooling comme du code¶

Tout ce qui précède (OU, GPO, gMSA, délégations, configs Sysmon, règles) doit être versionné, revu et reproductible - sinon la dérive s'installe. C'est le pont vers la Trajectoire 3, appliqué à la gouvernance du tooling.

80.2 Ce qui va dans Git¶

Configs de capteurs : sysmonconfig.xml versionné (un diff = une revue de PR).

GPO : export/backup versionné (rappel P1 Backup-GPO), et idéalement gestion déclarative :

# Sauvegarde versionnable de toutes les GPO (à committer)
Backup-GPO -All -Path "C:\Git\ad-governance\gpo"
# Restauration contrôlée (rejeu depuis Git)
Import-GPO -BackupGpoName "GPO-C-Detection-Baseline" -TargetName "GPO-C-Detection-Baseline" `
    -Path "C:\Git\ad-governance\gpo" -CreateIfNeeded

Règles de détection : Sigma dans Git, testées en CI (P7 M71).
Délégations : scripts dsacls / gMSA idempotents (rejouables).
Structure d'OU & groupes : provisionnés en PowerShell/DSC/Ansible (rejouables).

80.3 Détecter la dérive (drift)¶

Un état déclaré doit être vérifié en continu - la config a-t-elle dérivé de la référence Git ?

# Exemple : comparer la config Sysmon en place à la référence versionnée
$ref = Get-FileHash "\\corp.lab.local\Deploy\Sysmon\sysmonconfig.xml"
Invoke-Command -ComputerName (Get-ADComputer -Filter *).DNSHostName -ScriptBlock {
    (& C:\Windows\Sysmon64.exe -c) # comparer au hash de référence hors bande
}
# En pratique : PowerShell DSC (Test-DscConfiguration) ou Ansible (--check) pour le drift.

La détection de dérive est elle-même une alerte de sécurité : une config Sysmon modifiée hors GPO = sabotage potentiel (module 79).

80.4 Cycle de vie du tooling¶

Onboarding d'une machine : entrée dans la bonne OU → hérite automatiquement de Sysmon + Detection Baseline + agents → apparaît dans le contrôle de couverture (M77).
Rotation : gMSA (auto), certificats du tooling (auto-enrollment P2), secrets.
Offboarding : désinstallation propre (GPO software → removal), révocation des délégations, nettoyage.
Revue périodique : qui est dans G_SOC_* et Tier 0 ? Les délégations sont-elles toujours minimales ? Les règles obsolètes retirées (P7 M71) ?

80.5 Projet fil rouge : « Gouvernance CORP »¶

Objectif : gouverner l'intégralité du stack de sécurité de corp.lab.local par AD, de façon versionnée et vérifiable.

Checklist :

[ ] OU dédiées Security-Tooling (Tier 0) + groupes SOC en AGDLP.
[ ] Sysmon + Detection Baseline déployés par GPO à l'échelle, config versionnée en Git, couverture vérifiée (100 %).
[ ] Tout le tooling en gMSA ; aucun compte de service Domain Admin (audité et prouvé).
[ ] Confinement SOC via JEA + délégation SOAR ciblée (dsacls), zéro droit admin permanent.
[ ] Tooling Tier 0 : PAW-only, Protected Users, segmenté ; logs inviolables (WEF temps réel + immuable).
[ ] Détections d'auto-défense : 1102, arrêt Sysmon, capteur muet, dérive de config.
[ ] Break-glass documenté + alerte maximale sur usage.
[ ] OU/GPO/gMSA/délégations/règles dans Git, drift détecté (DSC/Ansible).

80.6 Questions type entretien¶

Pourquoi le SIEM est-il un actif Tier 0, et qu'implique cette classification ?
Comment déploies-tu Sysmon à l'échelle de façon idempotente, et comment vérifies-tu la couverture ?
Un SOAR doit désactiver des comptes : comment lui donner ce pouvoir sans Domain Admin ?
Comment un analyste SOC confine-t-il un compte sans être administrateur ? (JEA)
Un attaquant vide le journal Security d'un hôte : comment tes logs survivent-ils ?
Comment détectes-tu qu'un capteur (Sysmon) a été saboté ou aveuglé ?
Qu'est-ce qu'un compte break-glass, et pourquoi son usage doit-il alerter ?
Pourquoi versionner GPO et configs de capteurs dans Git, et comment détecter la dérive ?
Quelle OU/tiering pour ton tooling, et pourquoi le séparer de la prod ?
Cite 3 anti-patterns de gouvernance de tooling et leur correction.

80.7 Conclusion - le liant est posé¶

Cette Partie 7-bis relie tout le cours : les outils des Parties 2-7 ne sont plus des îlots, ils sont déployés, identifiés, restreints, protégés et versionnés par les mécanismes natifs d'AD que tu maîtrises depuis la Partie 1. Tu ne « connais » plus des outils - tu gouvernes une plateforme de sécurité.

Le principe qui traverse la partie, avec ta casquette : le tooling de sécurité obéit aux mêmes lois que le reste de l'infra, en plus strict. Moindre privilège (gMSA/JEA, jamais Domain Admin), déploiement déclaratif (GPO/DSC, jamais à la main), protection Tier 0 (PAW, logs inviolables), et gouvernance as code (Git, drift). Un gardien mal gardé est une porte d'entrée ; bien gouverné, c'est le socle de toute la détection.

Et la suite, définitivement hors on-prem : la Trajectoire 2 (porter cette gouvernance vers Entra ID - RBAC, PIM, Conditional Access, gouvernance des identités du tooling cloud) et la Trajectoire 3 (cette gouvernance entièrement en GitOps/IaC - le SIEM, les GPO, les délégations et les détections gérés comme du code, à l'échelle). C'est, avec ta casquette Google, l'horizon naturel.

Annexe - Aide-mémoire Partie 7-bis¶

# Structure & délégation
New-ADOrganizationalUnit  ...Security-Tooling      OU dédiée Tier 0
# AGDLP : G_SOC_* (rôles) → DL_* (capacités) → droits
dsacls "OU=..." /G "CORP\gmsa-soar$:WP;userAccountControl;user"   Délégation ciblée

# Déploiement par GPO
# Tâche planifiée GPO idempotente : sysmon -i / -c depuis \\...\Deploy
# GPO Software Installation (MSI) pour les agents
# GPO Detection Baseline : WEF + audit avancé + 4688 cmdline + PS logging

# Identités
New-ADServiceAccount / Install-ADServiceAccount    gMSA (jamais Domain Admin)
# JEA : New-PSRoleCapabilityFile + New-PSSessionConfigurationFile
Register-PSSessionConfiguration -Name JEA-SOC-Response

# Auto-défense du tooling
# Alerter : 1102 (log cleared), 4719 (audit changed), arrêt Sysmon, Sysmon Event 16, capteur muet
# WEF temps réel + stockage immuable ; Protected Users ; PAW-only ; break-glass

# Gouvernance as code
Backup-GPO -All -Path C:\Git\...        GPO versionnées
Import-GPO ...                          Rejeu depuis Git
# Sysmon config, Sigma, dsacls, OU : dans Git ; drift via DSC/Ansible

Fin de la Partie 7-bis. La ligne qui la résume : le tooling qui te protège doit être mieux gouverné que ce qu'il protège - moindre privilège, déployé par AD, protégé en Tier 0, versionné comme du code. Un gardien qu'on ne garde pas devient la première porte de l'attaquant.