Dérive de configuration : OSConfig, DSC et rapports

Appliquer un référentiel est un instantané. Ensuite, des programmes d'installation assouplissent les paramètres qui les gênent, des administrateurs font des modifications « temporaires » pendant un incident, des scripts d'un éditeur inversent une valeur de registre, et une GPO perd son lien lors d'une réorganisation. Six mois plus tard, la machine ne correspond plus au référentiel que vous avez montré à l'auditeur. Cet écart, c'est la dérive de configuration.

Le guide pilier sur les référentiels de sécurité a présenté OSConfig comme un moyen de maintenir un référentiel en place. Ce guide traite la dérive dans son ensemble : les moteurs de correction disponibles sous Windows (OSConfig, stratégie de groupe, PowerShell DSC, Intune), la détection des modifications au moment où elles surviennent, et le reporting de conformité à l'échelle d'un parc.

D'où vient la dérive et ce qui la corrige

Chaque classe d'appareils doit avoir exactement un moteur propriétaire de sa configuration de sécurité, plus un reporting indépendant pour repérer les cas où le moteur lui-même est défaillant ou contourné.

Étape 1 : faire réappliquer par la stratégie de groupe ce qu'elle possède

Si la stratégie de groupe est propriétaire de la configuration, comblez la lacune du retraitement. Sous Computer Configuration > Policies > Administrative Templates > System > Group Policy :

• Configure registry policy processing : Enabled, cochez Process even if the Group Policy objects have not changed.
• Configure security policy processing : Enabled, même option.

Ainsi, une modification locale d'un paramètre de modèle d'administration est écrasée au prochain rafraîchissement en arrière-plan (90 minutes plus un décalage aléatoire par défaut), au lieu de survivre jusqu'à ce que quelqu'un modifie la GPO. Le référentiel Microsoft active déjà le retraitement de la stratégie de registre ; vérifiez qu'il n'a pas été retiré.

Cela n'aide pas pour les paramètres qu'aucune GPO ne définit, pour les machines hors domaine, ni pour les GPO qui cessent de s'appliquer. C'est à cela que sert le reporting.

Étape 2 : OSConfig sur Windows Server 2025

OSConfig applique les référentiels de sécurité Microsoft pour Windows Server 2025 sous forme de scénarios nommés, puis les impose et en rend compte. Installez le module depuis PowerShell Gallery et appliquez le scénario correspondant au rôle du serveur :

Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

# Au choix : SecurityBaseline/WindowsServer/2025/MemberServer, /DomainController, /WorkgroupMember
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Default
Restart-Computer

Des scénarios complémentaires s'appliquent de la même façon : SecuredCore, Defender/Antivirus/WindowsServer/2025 et, uniquement sur les serveurs membres, LAPS/WindowsServer/2025/MemberServer. OSConfig dispose aussi d'un scénario pour App Control for Business. Appliquer ou retirer un référentiel nécessite un redémarrage. La version du référentiel est livrée dans le module : Update-Module Microsoft.OSConfig suivi d'une nouvelle application du scénario fait donc passer un serveur au nouveau référentiel.

Pour modifier un paramètre par rapport à la valeur par défaut, par exemple pour correspondre à une entrée de votre registre des écarts, définissez-le par son nom plutôt qu'en modifiant le registre, afin que le contrôle de la dérive impose votre valeur au lieu de la combattre :

Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  Where-Object Name -like '*Audit*' | Select-Object Name, Value

Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer `
  -Setting AuditDetailedFileShare -Value 3

Vérifiez une valeur personnalisée isolée avec Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Setting AuditDetailedFileShare.

Le contrôle de la dérive s'exécute sous forme de tâche de rafraîchissement planifiée qui compare chaque paramètre à la valeur souhaitée et le rétablit s'il a changé. La documentation Microsoft actuelle n'indique pas l'intervalle (les versions antérieures mentionnaient quatre heures) : mesurez-le lors de votre pilote plutôt que de le supposer. Retirer un scénario avec Remove-OSConfigDesiredConfiguration arrête l'application, et Microsoft précise ne pas pouvoir garantir que les paramètres reviennent à leurs valeurs antérieures au référentiel : prenez donc d'abord un instantané de la configuration d'origine sur les serveurs où vous pourriez devoir revenir en arrière.

Sur les serveurs joints au domaine, décidez qui possède le référentiel. Si vos GPO de domaine appliquent le même référentiel Microsoft, évitez de l'imposer deux fois : soit vous conservez les GPO et n'utilisez le reporting OSConfig que sur un échantillon, soit vous confiez le référentiel à OSConfig et retirez ces paramètres des GPO serveurs. Les contrôleurs de domaine méritent une attention particulière, car une attribution de droits utilisateur conflictuelle peut casser la réplication ou les ouvertures de session ; menez d'abord le pilote sur un seul DC.

Étape 3 : PowerShell DSC pour tout le reste

Pour les paramètres qu'aucun référentiel ne couvre, ou pour les serveurs plus anciens, la Desired State Configuration de Windows PowerShell 5.1 peut imposer et rendre compte. Configurez le Local Configuration Manager (LCM) en autocorrection :

[DSCLocalConfigurationManager()]
configuration LcmAutoCorrect {
  Node localhost {
    Settings {
      RefreshMode                    = 'Push'
      ConfigurationMode              = 'ApplyAndAutoCorrect'
      ConfigurationModeFrequencyMins = 30
    }
  }
}
LcmAutoCorrect -OutputPath C:\DSC\Lcm
Set-DscLocalConfigurationManager -Path C:\DSC\Lcm -Verbose

Puis une configuration contenant les paramètres dont vous êtes propriétaire. La ressource intégrée Registry suffit pour de nombreuses valeurs de durcissement :

configuration HardeningExtras {
  Import-DscResource -ModuleName PSDesiredStateConfiguration
  Node localhost {
    Registry DisableLLMNR {
      Key       = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient'
      ValueName = 'EnableMulticast'
      ValueData = '0'
      ValueType = 'Dword'
      Ensure    = 'Present'
    }
  }
}
HardeningExtras -OutputPath C:\DSC\Hardening
Start-DscConfiguration -Path C:\DSC\Hardening -Wait -Verbose

Des modules communautaires comme SecurityPolicyDsc et AuditPolicyDsc couvrent les droits utilisateur, les options de sécurité et les sous-catégories d'audit, et le module BaselineManagement peut convertir une sauvegarde de GPO en configuration DSC. Le nouveau Microsoft DSC (version 3) est un outil distinct, multiplateforme, avec un modèle différent ; évaluez-le séparément plutôt que de le mélanger avec le LCM.

Les fichiers de configuration DSC (.mof) peuvent contenir des données sensibles et le LCM s'exécute en SYSTEM : stockez-les donc dans un emplacement protégé et restreignez qui peut pousser des configurations, exactement comme vous restreindriez la modification des GPO (voir tiering d'administration).

Étape 4 : détecter les modifications au moment où elles surviennent

Les moteurs de correction masquent la dérive en la corrigeant. Vous voulez aussi savoir qu'elle a eu lieu, car un paramètre qui ne cesse de basculer signifie généralement que quelqu'un ou quelque chose travaille contre vous. Activez les sous-catégories d'audit concernées (voir stratégie d'audit et Sysmon) et transférez ces événements :

Pour quelques clés de registre à forte valeur (par exemple les paramètres LSA sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa), ajoutez une SACL d'audit afin que le 4657 se déclenche en cas de modification. L'événement Sysmon 13 (valeur de registre définie), avec une configuration ciblée, est une alternative. Transférez le tout avec Windows Event Forwarding vers votre SIEM, et alertez sur les modifications survenant en dehors des fenêtres de changement.

Étape 5 : rendre compte de la conformité à l'échelle du parc

L'application dit à chaque machine quoi faire ; le reporting vous dit si cela a fonctionné. Pour Windows Server 2025 avec OSConfig, collectez la conformité par paramètre à distance :

$servers = Get-Content C:\Reports\ws2025-servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
  Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
    Select-Object Name,
      @{n='Status';e={$_.Compliance.Status}},
      @{n='Reason';e={$_.Compliance.Reason}}
} | Select-Object PSComputerName, Name, Status, Reason |
  Export-Csv "C:\Reports\osconfig-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Pour les nœuds gérés par DSC, Test-DscConfiguration -Detailed renvoie les ressources conformes et non conformes à l'état souhaité, et Get-DscConfigurationStatus affiche la dernière exécution. Des outils d'audit locaux comme secedit /analyze /db C:\Temp\bl.sdb /cfg C:\Baseline\GptTmpl.inf /log C:\Temp\analyze.log comparent les paramètres de sécurité à un modèle. La comparaison avec l'état effectif de Policy Analyzer (voir Policy Analyzer et LGPO) couvre des échantillons de postes clients. À grande échelle, les rapports par paramètre d'Intune, Azure machine configuration pour les serveurs connectés à Arc et l'évaluation des référentiels de sécurité de Defender Vulnerability Management (selon les licences) offrent une vue centralisée.

Suivez trois indicateurs par classe d'appareils : le pourcentage de paramètres conformes, le nombre d'appareils présentant au moins un paramètre à haut risque non conforme, et les paramètres qui dérivent de façon répétée.

Vérifier

Prouvez que la boucle de correction fonctionne sur un serveur pilote : modifiez à la main un paramètre imposé, attendez le prochain rafraîchissement, et confirmez qu'il a été rétabli.

Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  Where-Object { $_.Compliance.Status -ne 'Compliant' } |
  Format-Table Name, @{n='Reason';e={$_.Compliance.Reason}} -Wrap

Test-DscConfiguration -Detailed | Select-Object -ExpandProperty ResourcesNotInDesiredState
Get-WinEvent -LogName 'Microsoft-Windows-DSC/Operational' -MaxEvents 20

Confirmez aussi que l'événement de modification est bien arrivé dans votre SIEM. Une correction de dérive que personne n'a vue reste un signal manqué.

Ce qui casse

• Deux moteurs, un paramètre. GPO et OSConfig, ou Intune et DSC, qui imposent des valeurs différentes produisent des paramètres qui oscillent et des rapports déroutants.
• Des modifications légitimes annulées. Un correctif d'urgence appliqué à la main est défait au rafraîchissement suivant. Passez par le moteur, pas à côté.
• Des exceptions au référentiel perdues. Les personnalisations appliquées en dehors du moteur disparaissent. Consignez-les dans la configuration du moteur et dans le registre des écarts.
• Des rapports périmés. Un appareil qui a cessé de remonter ses informations paraît conforme dans certains tableaux de bord. Alertez sur les rapports manquants, pas seulement sur les échecs.

Liste de contrôle

• Un seul moteur d'application choisi par classe d'appareils
• Traitement des stratégies de registre et de sécurité configuré pour réappliquer les GPO inchangées
• Scénario de référentiel OSConfig appliqué sur Windows Server 2025 selon le rôle
• Écarts appliqués via OSConfig ou DSC, pas à la main
• LCM DSC en ApplyAndAutoCorrect pour les paramètres hors référentiel
• Événements de modification (4719, 4739, 5136, 4657) transférés et soumis à alerte
• Rapport de conformité du parc produit et revu chaque mois
• Boucle de correction testée en modifiant délibérément un paramètre

La gestion de la dérive est ce qui garde un référentiel fidèle une fois le projet terminé. Consultez l'ensemble du domaine référentiels de sécurité pour choisir, tester et déployer des référentiels en premier lieu.