Forum Aux Questions sur les stratégies d’audit de sécurité avancée

Article
04/01/2016

Cette rubrique destinée aux professionnels de l’informatique répertorie des questions et leurs réponses sur le fonctionnement, le déploiement et la gestion des stratégies d’audit de sécurité.

Qu’est-ce que l’audit de sécurité Windows et pourquoi devrais-je l’utiliser ?
Quelle est la différence entre les stratégies d’audit figurant dans Stratégies locales\Stratégie d’audit et celles situées dans la configuration avancée de la stratégie d’audit ?
Quelle est l’interaction entre les paramètres de stratégie d’audit de base et les paramètres de stratégie d’audit avancée ?
Comment les paramètres d’audit sont-ils fusionnés par une stratégie de groupe ?
Quelle est la différence entre une liste DACL d’objets et une liste SACL d’objets ?
Pourquoi les stratégies d’audit sont-elles appliquées par ordinateur plutôt que par utilisateur ?
Quelles sont les différences de fonctionnalités d’audit entre les versions de Windows ?
Puis-je utiliser la stratégie d’audit avancée d’un contrôleur de domaine exécutant Windows Server 2003 ou Windows 2000 Server ?
Quelle est la différence entre les événements de réussite et d’échec ? L’obtention d’un audit des échecs signale-t-elle l’existence d’un problème ?
Comment définir une stratégie d’audit qui affecte tous les objets d’un ordinateur ?
Comment découvrir pourquoi un utilisateur a été en mesure d’accéder à une ressource ?
Comment savoir quand des modifications ont été apportées aux paramètres de contrôle d’accès, par qui et en quoi elles consistaient ?
Comment restaurer une stratégie d’audit de sécurité de base à partir d’une stratégie d’audit de sécurité avancée ?
Comment contrôler si des modifications ont été apportées aux paramètres de stratégie d’audit ?
Comment restreindre le nombre d’événements générés ?
Quels sont les meilleurs outils pour modéliser et gérer la stratégie d’audit ?
Où trouver des informations sur tous les événements pouvant être reçus ?
Où trouver des informations plus détaillées ?

Qu’est-ce que l’audit de sécurité Windows et pourquoi devrais-je l’utiliser ?

L’audit de sécurité consiste en un examen et une révision méthodiques des activités susceptibles d’affecter la sécurité d’un système. Dans les systèmes d’exploitation Windows, l’audit de sécurité désigne plus simplement les fonctionnalités et services qui permettent à un administrateur d’enregistrer et d’examiner des événements concernant des activités spécifiques relatives à la sécurité.

Lorsque le système d’exploitation Windows et les applications qui s’y exécutent effectuent leurs tâches, des centaines d’événements se produisent. Ces événements peuvent fournir de précieuses informations pour aider les administrateurs à résoudre les problèmes liés aux activités relatives à la sécurité et à enquêter sur celles-ci.

Quelle est la différence entre les stratégies d’audit figurant dans Stratégies locales\Stratégie d’audit et celles situées dans la configuration avancée de la stratégie d’audit ?

Les paramètres de stratégie d’audit de sécurité de base dans Paramètres de sécurité\Stratégies locales\Stratégie d’audit et les paramètres de stratégie d’audit de sécurité avancée dans Paramètres de sécurité\Configuration avancée de la stratégie d’audit\Stratégies d’audit du système semblent se chevaucher, mais ils sont enregistrés et appliqués différemment. Lorsque vous appliquez des paramètres de stratégie d’audit de base à l’ordinateur local à l’aide du composant logiciel enfichable de stratégie de sécurité locale (secpol.msc), vous modifiez la stratégie d’audit en vigueur, de sorte que les modifications apportées aux paramètres de stratégie d’audit de base apparaîtront exactement comme configurées dans Auditpol.exe.

Il existe plusieurs autres différences entre les paramètres de stratégie d’audit de sécurité de ces deux emplacements.

Vous disposez de neuf paramètres de stratégie d’audit de base sous Paramètres de sécurité\Stratégies locales\Stratégie d’audit et de divers paramètres sous Configuration avancée de la stratégie d’audit. Les paramètres disponibles dans Paramètres de sécurité\Configuration avancée de la stratégie d’audit traitent les mêmes aspects que les neuf paramètres de base dans Stratégies locales\Stratégie d’audit, mais permettent aux administrateurs d’être plus sélectifs concernant le nombre et les types d’événements à auditer. Par exemple, là où la stratégie d’audit de base ne fournit qu’un seul paramètre pour la connexion de compte, la stratégie d’audit avancée en offre quatre. L’activation du paramètre unique de connexion de compte de base revient à définir l’ensemble des quatre paramètres de connexion de compte avancés. En comparaison, la définition d’un seul paramètre de stratégie d’audit avancée ne génère pas d’événements d’audit pour les activités qui ne vous intéressent pas.

En outre, si vous activez l’audit des réussites pour le paramètre de base Auditer les événements de connexion aux comptes, seuls les événements de réussite seront enregistrés pour tous les comportements liés à la connexion de compte. En comparaison, vous pouvez configurer l’audit des réussites pour un paramètre de connexion de compte avancé, l’audit des échecs pour un deuxième paramètre de connexion de compte avancé, l’audit des réussites et des échecs pour un troisième paramètre de connexion de compte avancé, ou aucun audit, selon les besoins de votre organisation.

Les neuf paramètres de base figurant sous Paramètres de sécurité\Stratégies locales\Stratégie d’audit ont été introduits dans Windows 2000, et sont par conséquent disponibles dans toutes les versions de Windows commercialisées depuis lors. Les paramètres de stratégie d’audit avancée ont été introduits dans Windows Vista et Windows Server 2008. Les paramètres avancés ne sont utilisables que sur les ordinateurs exécutant Windows 7, Windows Server 2008 et les versions ultérieures.

Quelle est l’interaction entre les paramètres de stratégie d’audit de base et les paramètres de stratégie d’audit avancée ?

Les paramètres de stratégie d’audit de base ne sont pas compatibles avec les paramètres de stratégie d’audit avancée appliqués à l’aide de la stratégie de groupe. En effet, dès que les paramètres de stratégie d’audit avancée sont appliqués à l’aide de la stratégie de groupe, les paramètres de stratégie d’audit de l’ordinateur en vigueur sont effacés avant l’application des paramètres de stratégie d’audit avancée résultants. Après avoir appliqué des paramètres de stratégie d’audit avancée au moyen de la stratégie de groupe, vous pouvez uniquement définir de manière fiable la stratégie d’audit système pour l’ordinateur à l’aide des paramètres de stratégie d’audit avancée.

Étant donné que la modification et l’application des paramètres de stratégie d’audit avancée dans Stratégie de sécurité locale modifient l’objet de stratégie de groupe local, les modifications effectuées à cet emplacement peuvent ne pas être reflétées exactement dans Auditpol.exe s’il existe des stratégies provenant d’autres objets de stratégie de groupe de domaine ou scripts d’ouverture de session. Les deux types de stratégies peuvent être modifiés et appliqués à l’aide des objets de stratégie de groupe de domaine, et ces paramètres remplaceront tous les paramètres de stratégie d’audit locale incompatibles. Toutefois, étant donné que la stratégie d’audit de base est enregistrée dans la stratégie d’audit en vigueur, la stratégie d’audit doit être supprimée explicitement lorsqu’une modification est souhaitée, ou elle restera dans la stratégie d’audit en vigueur. Les modifications de stratégie appliquées à l’aide de paramètres de stratégie de groupe de domaine ou locale sont reflétées dès que la nouvelle stratégie est appliquée.

Important

Que vous appliquiez des stratégies d’audit avancées à l’aide d’une stratégie de groupe ou de scripts d’ouverture de session, n’utilisez pas à la fois les paramètres de stratégie d’audit de base figurant sous Stratégies locales\Stratégie d’audit et les paramètres avancés disponibles sous Paramètres de sécurité\Configuration avancée de la stratégie d’audit. L’utilisation combinée de paramètres de stratégie d’audit avancée et de base risque d’engendrer des résultats inattendus.

Si vous utilisez les paramètres de configuration avancée de la stratégie d’audit ou des scripts d’ouverture de session pour appliquer des stratégies d’audit avancées, veillez à activer le paramètre de stratégie Audit : force les paramètres de sous-catégorie de stratégie d’audit (Windows Vista ou version ultérieure) à se substituer aux paramètres de catégorie de stratégie d’audit sous Stratégies locales\Options de sécurité. Cette opération permettra d’éviter les conflits entre des paramètres similaires en ignorant systématiquement l’audit de sécurité de base.

Comment les paramètres d’audit sont-ils fusionnés par une stratégie de groupe ?

Par défaut, les options de stratégie définies dans les objets de stratégie de groupe et liées à des niveaux supérieurs des sites, domaines et unités d’organisation Active Directory sont héritées par toutes les unités d’organisation des niveaux inférieurs. Toutefois, une stratégie héritée peut être remplacée par un objet de stratégie de groupe lié à un niveau inférieur.

Supposons que vous utilisiez un objet de stratégie de groupe de domaine pour attribuer un groupe de paramètres d’audit au niveau de l’organisation, mais que vous souhaitiez qu’une unité d’organisation spécifique obtienne un groupe défini de paramètres supplémentaires. Pour ce faire, vous pouvez lier un second objet de stratégie de groupe à cette unité d’organisation de niveau inférieur spécifique. Par conséquent, un paramètre d’audit de connexion appliqué au niveau de l’unité d’organisation remplacera un paramètre d’audit de connexion incompatible appliqué au niveau du domaine (sauf si vous avez suivi une procédure spéciale pour appliquer le traitement en boucle de la stratégie de groupe).

Les règles qui régissent le mode d’application des paramètres de stratégie de groupe sont propagées au niveau de la sous-catégorie des paramètres de stratégie d’audit. Cela signifie que les paramètres de stratégie d’audit configurés dans différents objets de stratégie de groupe seront fusionnés, tant qu’il n’existe aucun paramètre de stratégie configuré à un niveau inférieur. Le tableau ci-après illustre ce comportement.

Sous-catégorie d’audit	Paramètre configuré dans un objet de stratégie de groupe d’unité d’organisation (priorité plus élevée)	Paramètre configuré dans un objet de stratégie de groupe de domaine (priorité plus faible)	Stratégie résultante pour l’ordinateur cible
Audit de partage de fichiers détaillé	Réussite	Échec	Réussite
Audit de création de processus	Désactivé	Réussite	Désactivé
Audit de connexion	Réussite	Échec	Échec

Quelle est la différence entre une liste DACL d’objets et une liste SACL d’objets ?

Tous les objets des services de domaine Active Directory (AD DS), ainsi que tous les objets sécurisables sur un ordinateur local ou sur le réseau, disposent de descripteurs de sécurité permettant de mieux contrôler l’accès aux objets. Les descripteurs de sécurité fournissent des informations sur le propriétaire d’un objet, sur les utilisateurs autorisés à y accéder et leur façon de procéder, ainsi que sur les types d’accès sur lesquels porte l’audit. Les descripteurs de sécurité contiennent la liste de contrôle d’accès (ACL) d’un objet, qui inclut toutes les autorisations de sécurité qui s’appliquent à cet objet. Le descripteur de sécurité d’un objet peut contenir deux types de listes ACL :

une liste de contrôle d’accès discrétionnaire (DACL) qui identifie les utilisateurs et groupes auxquels l’accès est accordé ou refusé ;
une liste de contrôle d’accès système (SACL) qui contrôle la façon dont l’accès est audité.

Le modèle de contrôle d’accès utilisé dans Windows est administré au niveau de l’objet par la définition de différents niveaux d’accès, ou autorisations, aux objets. Si des autorisations sont configurées pour un objet, le descripteur de sécurité de l’objet contient une liste DACL avec des identificateurs de sécurité (SID) pour les utilisateurs et groupes auxquels l’accès est autorisé ou refusé.

Si l’audit est configuré pour l’objet, le descripteur de sécurité de l’objet contient également une liste SACL qui contrôle la façon dont le sous-système de sécurité audite les tentatives d’accès à l’objet. Toutefois, le paramétrage de l’audit n’est pas achevé tant qu’une liste SACL n’a pas été configurée pour un objet et qu’un paramètre de stratégie d’audit Accès aux objets correspondant n’a pas été configuré et appliqué.

Pourquoi les stratégies d’audit sont-elles appliquées par ordinateur plutôt que par utilisateur ?

Dans l’audit de sécurité Windows, l’ordinateur, les objets sur l’ordinateur et les ressources connexes sont les principaux destinataires des actions exécutées par les clients, comprenant les applications, les autres ordinateurs et les utilisateurs. Lors d’une violation de la sécurité, des utilisateurs malveillants peuvent utiliser d’autres informations d’identification pour masquer leur identité, et les applications malveillantes peuvent emprunter l’identité d’utilisateurs légitimes pour effectuer des tâches indésirables. Par conséquent, la méthode la plus cohérente pour appliquer la stratégie d’audit consiste à se concentrer sur l’ordinateur et sur les objets et ressources figurant sur ce dernier.

En outre, étant donné que les fonctionnalités de stratégie d’audit peuvent varier entre des ordinateurs qui exécutent différentes versions de Windows, la meilleure façon de s’assurer que la stratégie d’audit est correctement appliquée est de baser ces paramètres sur l’ordinateur plutôt que sur l’utilisateur.

Toutefois, si vous souhaitez que les paramètres d’audit s’appliquent uniquement à des groupes d’utilisateurs spécifiques, vous pouvez effectuer cette opération en configurant des listes SACL sur les objets appropriés afin d’activer l’audit pour un groupe de sécurité contenant uniquement les utilisateurs que vous spécifiez. Par exemple, vous pouvez configurer une liste SACL pour un dossier appelé Données de paie sur le serveur de comptabilité 1. Cette opération permet d’activer l’audit sur les tentatives de suppression d’objets de ce dossier effectuées par les membres de l’unité d’organisation Processus de paie. Le paramètre de stratégie d’audit Accès aux objets\Auditer le système de fichiers s’applique au serveur de comptabilité 1, mais étant donné qu’il requiert une liste SACL correspondante pour les ressources, seules les actions exécutées par des membres de l’unité d’organisation Processus de paie sur le dossier Données de paie génèrent des événements d’audit.

Quelles sont les différences de fonctionnalités d’audit entre les versions de Windows ?

Les paramètres de stratégie d’audit de base sont disponibles dans toutes les versions de Windows depuis Windows 2000 et sont applicables localement ou par le biais d’une stratégie de groupe. Les paramètres de stratégie d’audit avancée ont été introduits dans Windows Vista et dans Windows Server 2008, mais ils sont uniquement applicables à l’aide de scripts d’ouverture de session dans ces versions. Les paramètres de stratégie d’audit avancée introduits dans Windows 7 et dans Windows Server 2008 R2 peuvent être configurés et appliqués à l’aide de paramètres de stratégie de groupe de domaine et locale.

Puis-je utiliser la stratégie d’audit avancée d’un contrôleur de domaine exécutant Windows Server 2003 ou Windows 2000 Server ?

Pour utiliser des paramètres de stratégie d’audit avancée, votre contrôleur de domaine doit être installé sur un ordinateur qui exécute Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 ou Windows Server 2003 avec Service Pack 2 (SP2). Windows 2000 Server n’est pas pris en charge.

Quelle est la différence entre les événements de réussite et d’échec ? L’obtention d’un audit des échecs signale-t-elle l’existence d’un problème ?

Un événement d’audit de réussite est déclenché lorsqu’une action définie, telle que l’accès à un partage de fichiers, est exécutée avec succès.

Un événement d’audit d’échec est déclenché lorsqu’une action définie, telle qu’une connexion utilisateur, n’aboutit pas.

L’apparition d’événements d’audit d’échec dans le journal des événements ne signale pas nécessairement l’existence d’un problème au niveau de votre système. Par exemple, si vous configurez des événements d’audit de connexion, un événement d’échec peut simplement signifier qu’un utilisateur a mal tapé son mot de passe.

Comment définir une stratégie d’audit qui affecte tous les objets d’un ordinateur ?

Les administrateurs système et auditeurs souhaitent de plus en plus souvent vérifier qu’une stratégie d’audit est appliquée à tous les objets d’un système. Cette opération était autrefois difficile à effectuer, car les listes de contrôle d’accès système (SACL) régissant l’audit sont appliquées par objet. Ainsi, pour vous assurer qu’une stratégie d’audit était appliquée à tous les objets, vous deviez contrôler chaque objet pour vérifier qu’aucune modification n’avait été apportée, même temporairement à une seule liste SACL.

Dans Windows Server 2008 R2 et Windows 7, l’audit de sécurité permet aux administrateurs de définir des stratégies d’audit d’accès global aux objets pour l’intégralité du système de fichiers ou pour le Registre d’un ordinateur. La liste SACL spécifiée est ensuite appliquée automatiquement à chaque objet de ce type. Cette amélioration peut se révéler utile pour vérifier que tous les fichiers, dossiers et paramètres du Registre essentiels sont protégés, ainsi que pour identifier le moment où un problème survient avec une ressource système. Si une liste SACL de fichier ou de dossier et une stratégie d’audit d’accès global aux objets (ou une simple liste SACL de paramètre de Registre et une stratégie d’audit d’accès global aux objets) sont configurées en même temps sur un ordinateur, la liste SACL effective découle de la combinaison de la liste SACL de fichier ou de dossier et de la stratégie d’audit d’accès global aux objets. Cela signifie qu’un événement d’audit est créé si une activité correspond soit à la liste SACL de fichier ou de dossier, soit à la stratégie d’audit d’accès global aux objets.

Comment découvrir pourquoi un utilisateur a été en mesure d’accéder à une ressource ?

Le fait de savoir qu’un utilisateur a accédé à un objet, tel qu’un fichier ou un dossier, n’est généralement pas suffisant. Vous pouvez également avoir besoin de connaître la raison pour laquelle l’utilisateur a été en mesure d’accéder à cette ressource. Vous pouvez obtenir ces données d’investigation en configurant le paramètre Auditer la manipulation de handle avec le paramètre d’audit Auditer le système de fichiers ou Auditer le Registre.

Comment savoir quand des modifications ont été apportées aux paramètres de contrôle d’accès, par qui et en quoi elles consistaient ?

Pour effectuer le suivi des modifications de contrôle d’accès sur des ordinateurs exécutant Windows Server 2016 Technical Preview, Windows Server 2012 R2, Windows Server 2012, Windows 7, Windows Server 2008 R2, Windows Vista ou Windows Server 2008, vous devez activer les paramètres ci-après pour assurer le suivi des modifications apportées aux listes DACL :

sous-catégorie Auditer le système de fichiers activée pour la réussite, l’échec ou la réussite et l’échec ;
paramètre Auditer la modification de la stratégie d’autorisation activé pour la réussite, l’échec ou la réussite et l’échec ;
liste SACL avec autorisations Écriture et Appropriation appliquée à l’objet que vous souhaitez surveiller.

Dans Windows XP et Windows Server 2003, vous devez utiliser la sous-catégorie Auditer les modifications de stratégie.

Comment restaurer une stratégie d’audit de sécurité de base à partir d’une stratégie d’audit de sécurité avancée ?

L’application des paramètres de stratégie d’audit avancée a pour effet de remplacer tous les paramètres de stratégie d’audit de sécurité de base comparables. Si, par la suite, vous avez besoin de redéfinir le paramètre de stratégie d’audit avancée sur la valeur Non configurée, vous devrez exécuter la procédure ci-après pour restaurer les paramètres de stratégie d’audit de sécurité de base d’origine :

Affectez à toutes les sous-catégories de stratégie d’audit avancée la valeur Non configurée.
Supprimez tous les fichiers audit.csv du dossier %SYSVOL% sur le contrôleur de domaine.
Reconfigurez et appliquez les paramètres de stratégie d’audit de base.

Si vous n’exécutez pas l’ensemble de ces étapes, les paramètres de stratégie d’audit de base ne seront pas restaurés.

Comment contrôler si des modifications ont été apportées aux paramètres de stratégie d’audit ?

Les modifications apportées aux stratégies d’audit de sécurité sont des événements de sécurité cruciaux. Vous pouvez utiliser le paramètre Auditer les modifications de stratégie pour déterminer si le système d’exploitation génère des événements d’audit lorsque les types d’activités ci-après se produisent :

Les autorisations et paramètres d’audit sur l’objet de stratégie d’audit sont modifiés.
La stratégie d’audit système est modifiée.
Les sources d’événements de sécurité sont inscrites ou désinscrites.
Les paramètres d’audit par utilisateur sont modifiés.
La valeur de CrashOnAuditFail est modifiée.
Les paramètres d’audit sur un fichier ou une clé de Registre sont modifiés.
Une liste de groupes spéciaux est modifiée.

Comment restreindre le nombre d’événements générés ?

Il peut être difficile de trouver le bon équilibre entre l’audit d’un nombre d’activités de réseau et d’ordinateur suffisant et l’audit d’un nombre d’activités de réseau et d’ordinateur insuffisant. Vous pouvez atteindre cet équilibre en identifiant les ressources, activités essentielles et utilisateurs ou groupes d’utilisateurs les plus importants, puis en concevant une stratégie d’audit de sécurité qui cible ces ressources, activités et utilisateurs. Vous trouverez des recommandations et des instructions utiles pour le développement d’une stratégie d’audit de sécurité efficace dans l’article Planification et déploiement de stratégies d’audit de sécurité avancée.

Quels sont les meilleurs outils pour modéliser et gérer la stratégie d’audit ?

L’intégration de paramètres de stratégie d’audit avancée à une stratégie de groupe de domaine dans Windows 7 et Windows Server 2008 R2 est destinée à simplifier la gestion et l’implémentation de stratégies d’audit de sécurité sur le réseau d’une organisation. De ce fait, les outils employés pour planifier et déployer des objets de stratégie de groupe pour un domaine sont également utilisables pour planifier et déployer des stratégies d’audit de sécurité.

Sur un ordinateur individuel, l’outil en ligne de commande Auditpol offre la possibilité d’exécuter plusieurs tâches de gestion importantes associées à la stratégie d’audit.

En outre, il existe plusieurs produits de gestion d’ordinateur, tels que les services ACS dans les produits Microsoft System Center Operations Manager, qui permettent de collecter et de filtrer des données d’événement.

Où trouver des informations sur tous les événements pouvant être reçus ?

Les utilisateurs qui examinent le journal des événements de sécurité pour la première fois peuvent être quelque peu submergés par le nombre d’événements d’audit qui y sont stockés (nombre qui peut rapidement atteindre les milliers) et par les informations structurées incluses pour chaque événement d’audit. Des informations supplémentaires concernant ces événements, ainsi que les paramètres utilisés pour les générer, sont accessibles à partir des ressources suivantes :

Où trouver des informations plus détaillées ?

Pour plus d’informations sur les stratégies d’audit de sécurité, voir les ressources suivantes :

Partager via