Les journaux d’événements Windows contiennent des informations détaillées sur le comportement de vos terminaux : des incidents de sécurité aux échecs de mise à jour, les administrateurs informatiques et les MSP doivent disposer d’une visibilité complète sur leur contenu.
La surveillance des journaux d’événements Windows est indispensable pour superviser et sécuriser les réseaux, aussi bien dans les petites entreprises que dans les grandes entreprises. Les vérifications manuelles posent toutefois un problème de passage à l’échelle, car le volume d’événements enregistrés est important et souvent sans conséquence. Ce guide explique comment automatiser la surveillance des journaux d’événements Windows sur plusieurs clients, afin que les incidents notables soient signalés et que tous les journaux de plusieurs appareils soient regroupés en un point central.
Conditions préalables à la surveillance et au transfert des journaux d’événements Windows
L’objectif principal de votre solution de surveillance des journaux d’événements Windows doit être de garantir qu’aucun signal de sécurité ne passe entre les mailles du filet. D’autres objectifs sont également à viser : la détection et la notification des événements importants ou des comportements suspects, la centralisation du stockage des journaux critiques et la possibilité de corriger les problèmes connus par script.
Pour surveiller et transférer les journaux d’événements Windows sous Windows 10, Windows 11 et Windows Server 2016+, vous aurez besoin des éléments suivants :
- un accès administrateur sur toutes les machines
- un accès à PowerShell
- un domaine Active Directory si vous déployez des objets de stratégie de groupe
Notez que certains des exemples ci-dessous utilisent un script pour envoyer des e-mails de notification, mais il peut être préférable de recourir à une solution tierce pour envoyer les notifications ou transférer les entrées de journal pertinentes vers une plateforme centralisée (par exemple à l’aide d’une application cliente ou via une API REST). Comme pour toutes les fonctions informatiques et MSP critiques, vous devez vérifier que les solutions mises en place répondent à vos besoins et fonctionnent dans votre environnement spécifique.
Méthode 1 : automatisation via l’interface graphique avec l’observateur d’événements et le Planificateur de tâches
L’observateur d’événements de Windows permet d’automatiser le transfert des entrées de journal d’événements grâce au Planificateur de tâches Windows. Voici comment procéder :
- Ouvrez l’observateur d’événements depuis le menu Démarrer ou en exécutant eventvwr.msc dans la boîte de dialogue Exécuter
- Repérez l’événement concerné dans le journal (par exemple Windows > System > Event ID 1001 pour les rapports de plantage)
- Faites un clic droit sur l’événement, choisissez Joindre une tâche à cet événement… puis donnez un nom à la tâche
- Lorsque l’assistant vous demande l’action à effectuer, sélectionnez Démarrer un programme (vous pouvez aussi envoyer un e-mail ou afficher un message, mais ces actions sont obsolètes)
- Indiquez le chemin d’accès au programme ou au script, ainsi que les éventuels arguments
- Vérifiez les informations et cliquez sur Terminer
Cette tâche s’exécutera ensuite chaque fois que l’événement se produira, avec les détails de celui-ci. Le programme ou le script utilisé comme action peut être un client tiers d’envoi de notifications, ou encore un script qui lance des diagnostics, redémarre des services, puis envoie une notification ou transfère les données de diagnostic vers un autre service.
Méthode 2 : surveillance et réponse centralisées avec PowerShell
Vous pouvez également utiliser un script PowerShell pour interroger des événements spécifiques et envoyer des alertes, comme dans l’exemple ci-dessous :
$Events = Get-WinEvent -FilterHashtable @{LogName=’Security’; ID=4625; StartTime=(Get-Date).AddMinutes(-5)}
foreach ($e in $Events) {
$message = $e.Message
# Custom action : send email, trigger flow, or write to external log
Send-MailMessage -To ‘[email protected]’ -From ‘[email protected]’ -Subject ‘Failed Login Attempt’ -Body $message -SmtpServer ‘smtp.example.com’
}
Ce script s’appuie sur la cmdlet Get-WinEvent pour rechercher les événements portant l’ID indiqué (ici 4625, qui correspond à un échec de connexion) sur les 5 dernières minutes. Rappelons que Send-MailMessage est obsolète : en production, privilégiez les alertes de votre RMM ou les API de Slack et d’autres services de notification.
Pour automatiser l’exécution de ce script, vous pouvez utiliser le Planificateur de tâches ou la cmdlet Register-ScheduledTask (en définissant le même intervalle que celui indiqué dans le script). Vous pouvez aussi déployer le script avec une solution RMM telle que NinjaOne, ou via une stratégie de groupe.
Méthode 3 : interrogation manuelle ou déclenchement de scripts depuis l’invite de commandes
Vous pouvez également détecter la création de nouvelles entrées de journal avec wevtutil dans l’invite de commandes Windows ou dans un fichier batch.
La commande ci-dessous utilise wevtutil pour rechercher les événements portant l’ID 4625 et renvoie la dernière entrée correspondante :
wevtutil qe Security "/q:*[System[(EventID=4625)]]" /c:1 /f:text
Cette commande peut être déclenchée depuis le Planificateur de tâches, ou depuis un script batch ou PowerShell. Vous pouvez ainsi tester différentes conditions sur la dernière entrée de journal correspondant à un ID d’événement et déclencher une action supplémentaire si nécessaire.
Méthode 4 : transfert et audit des journaux pilotés par stratégie de groupe
Les stratégies de groupe dans Active Directory permettent d’activer et de configurer le transfert des journaux d’événements sur toutes les machines jointes à un domaine Windows. Voici comment procéder :
- Ouvrez la console de gestion des stratégies de groupe
- Accédez à Configuration ordinateur > Modèles d’administration > Composants Windows > Transfert d’événements
- Configurez les paramètres Configurer le gestionnaire d’abonnement cible (définir l’URI du collecteur), Activer le transfert d’événements et Utiliser WinRM pour une communication sécurisée
L’application des stratégies d’audit se configure en accédant à Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d’audit > Stratégies d’audit système, puis en activant les stratégies d’audit pour des événements tels que les connexions ou les accès aux objets. La taille des journaux, leur durée de conservation et les règles d’écrasement peuvent également être configurées via une stratégie de groupe.
Définir la taille, la conservation et le comportement des journaux d’événements via le registre Windows
Vous pouvez contrôler la taille et la conservation des journaux avec l’Éditeur du registre Windows, en modifiant les valeurs de la clé EventLog située dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<LogName>
- MaxSize (DWORD) : taille maximale du journal en octets
- Retention (DWORD) : 1 = écraser si nécessaire, 0 = ne pas écraser
- AutoBackupLogFiles (DWORD) : 1 = activé, 0 = désactivé
Vous pouvez utiliser PowerShell pour définir ces valeurs de registre et déployer votre script via une stratégie de groupe ou votre plateforme de gestion des terminaux :
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Eventlog\Security" -Name MaxSize -Value 104857600
Points complémentaires et résolution des problèmes
Lors de la mise en place de votre solution de transfert ou de surveillance des journaux d’événements Windows, vous pouvez également tenir compte des facteurs suivants, selon votre contexte et vos besoins :
- Limites du transfert de journaux : le transfert natif fonctionne par extraction (pull) et non en temps réel. Si vous avez besoin d’alertes en direct, mieux vaut passer par des scripts ou un SIEM
- Taille des journaux : surveillez la taille et la durée de conservation des journaux pour éviter l’écrasement de données utiles
- Journaux de sécurité : ces journaux importants doivent être sauvegardés et/ou ingérés dans un SIEM pour analyse
- Fréquence de l’automatisation : adoptez une planification équilibrée (par exemple des intervalles d’interrogation de 5 minutes) pour limiter l’impact sur les performances
Si votre solution de surveillance des événements ne se comporte pas comme prévu, vérifiez les points suivants :
- Le transfert d’événements ne fonctionne pas : vérifiez l’état de WinRM et les règles de pare-feu
- Les scripts ne se déclenchent pas : vérifiez la correspondance de l’ID d’événement et que le compte utilisateur dispose des autorisations adéquates
- Journaux manquants ou incomplets : vérifiez les règles de conservation et assurez-vous que les journaux ne sont pas en cours de rotation
- Autorisations des scripts : assurez-vous que la politique d’exécution PowerShell autorise l’exécution de scripts non signés
Surveiller les journaux d’événements Windows de façon centralisée, sans scripts complexes
Il est essentiel, pour les départements informatiques internes comme pour les MSP, de surveiller les journaux d’événements Windows sur l’ensemble des terminaux afin de garantir la visibilité opérationnelle, la sécurité et la conformité. La gestion des terminaux par NinjaOne simplifie cette tâche grâce à la surveillance et aux alertes en temps réel (par SMS, e-mail et notifications push), de sorte qu’en cas de problème, les techniciens peuvent immédiatement engager les actions de résolution.
De plus, vous pouvez adapter votre propre surveillance des journaux d’événements avec le déploiement de scripts, des alertes configurables selon les ID d’événements et des scripts de correction automatique déclenchés par des événements spécifiques. Tout est parfaitement visible dans un tableau de bord web unifié, ce qui simplifie les diagnostics et rend votre dispositif informatique proactif dans l’identification et la résolution des menaces de cybersécurité, des problèmes rencontrés par les utilisateurs finaux et des dysfonctionnements.
