Mises en garde

L’utilisateur final lambda ne peut pas changer les paramètres, mais le fait de lister quels principaux de sécurité ne sont pas suivis pour quelles catégories d’audit, pourrait bien aider un intrus déjà connecté dans sa tentative d’exploration.

Par ailleurs, n’attendez pas de l’audit par utilisateur qu’il inclue ou exclue tous les messages d’événement concernant un utilisateur. Ce genre d’audit filtre uniquement les messages qui ont le nom du principal de sécurité prédéfini dans le champ User du message. Beaucoup de messages d’événements spécifient un autre User mais mentionnent le principal de sécurité prédéfini dans la Description du message. Ainsi, l’event ID 682 enregistre la connexion réussie d’un utilisateur à une session Winstation. Le User sur l’événement est généralement le compte System et le nom de l’utilisateur évincé par filtrage est dans la Description du message journal d’événements. En outre, bien que l’audit par utilisateur accentue la granularité d’un système déjà bien granulaire, vous ne pouvez pas l’utiliser pour arrêter un seul type de message journal d’événements pour un principal de sécurité : c’est encore tout ou rien pour une catégorie d’audit.

Enfin, l’audit par utilisateur semble causer quelques interactions intéressantes (bogues ?) entre les différentes catégories d’audit. Par exemple, quand j’ai désactivé globalement la catégorie Logon/Logoff mais utilisé l’audit par utilisateur pour valider un utilisateur administratif, certaines des actions Privilege Use de cet utilisateur ont aussi été journalisées. Quand j’ai désactivé Logon/Logoff pour l’utilisateur administratif, le journal d’événements n’a pas non plus saisi les messages d’audit Privilege Use. Je suppose que cela a à voir avec la manière dont les différentes catégories d’audit suivent l’usage. La leçon à retenir ici est que vous devriez tester l’audit par utilisateur en profondeur avant de vous en remettre à lui.

L’audit par utilisateur est une fonction intéressante avec des applications spécifiques, mais il faut toujours être prudent quand on modifie la journalisation ou la liste de contrôle d’audit légitime. Ainsi, vous pourriez vouloir empêcher un compte de service de sauvegarde sur bande d’apparaître dans les journaux d’audit quand il effectue ses tâches nocturnes. Un filtre d’audit par utilisateur pourrait supprimer la présence des sauvegardes sur bande des journaux d’événements et réduire les parasites, mais il pourrait aussi cacher les actions d’un pirate malveillant qui utilise le compte de service pour accomplir ses méfaits. De plus, si vous ne protégez pas et ne gérez pas de manière appropriée l’audit par utilisateur, des intrus malveillants pourraient l’utiliser de bien d’autres manières pour empêcher que leurs actions ne soient surveillées. En réglant finement votre stratégie d’audit, vous pouvez trouver le bon équilibre entre capturer ce qui est important et subir les parasites de trop d’événements. Les événements non audités peuvent être utilisés contre votre environnement.

Certains administrateurs préfèreront capturer tous les événements d’audit et filtrer les parasites hors du journal, a posteriori. Cette méthode assure un chemin d’audit fiable que l’on peut reconstruire en cas de besoin. Vous pouvez utiliser le filtrage fourni par l’application Event Viewer, n’importe lequel des outils de supervision de journaux d’événements de Microsoft (comme Microsoft Systems Management Server – SMS, Microsoft Operations Manager – MOM, EventCombMT, Microsoft Audit Collection System – MACS), ou l’un parmi les dizaines de moniteurs de journaux tierce partie.

L’audit par utilisateur procure un outil de plus dans l’arsenal de logging Windows déjà très puissant. Si vous l’utilisez à bon escient, les journaux d’événements auront moins de parasites et contiendront par conséquent des événements plus pertinents.