Fonctionnement de SQL Server Audit

L'objet SQL Server Audit recueille une seule instance des actions et des groupes d'actions au niveau du serveur ou de la base de données à contrôler. L'audit s'effectue au niveau de l'instance SQL Server. Vous pouvez exécuter plusieurs audits par instance SQL Server.

Lorsque vous définissez un audit, vous spécifiez l'emplacement de sortie des résultats. Il s'agit de la destination de l'audit. L'audit est créé dans un état désactivé et ne s'exécute pas automatiquement pour contrôler les actions. Les données d'audit sont transmises vers la destination de l'audit lorsque ce dernier est activé.

L'objet Spécification de l'audit du serveur appartient à un audit. Vous pouvez créer une spécification de l'audit du serveur par audit, car tous deux sont créés au niveau de la portée de l'instance SQL Server.

La spécification de l'audit du serveur recueille de nombreux groupes d'actions au niveau du serveur déclenchées par la fonctionnalité Événements étendus. Vous pouvez inclure des groupes d'actions d'audit dans une spécification de l'audit du serveur. Les groupes d'actions d'audit constituent des groupes d'actions prédéfinis, qui sont les événements atomiques qui se produisent dans le moteur de base de données. Ces actions sont envoyées à l'audit, qui les enregistre dans la cible.

Les groupes d'actions d'audit de niveau serveur sont décrits dans la rubrique Actions et groupes d'actions SQL Server Audit.

L'objet Spécification de l'audit de la base de données appartient également à un audit SQL Server. Vous pouvez créer une spécification de l'audit de la base de données par base de données SQL Server par audit.

La spécification de l'audit de la base de données recueille des actions d'audit au niveau de la base de données déclenchées par la fonctionnalité Événements étendus. Vous pouvez ajouter des groupes d'actions d'audit ou des événements d'audit à une spécification de l'audit de la base de données. Les événements d'audit sont les opérations atomiques qui peuvent être auditées par le moteur SQL Server. Les groupes d'actions d'audit sont des groupes d'actions prédéfinis. Tous deux sont à la portée de la base de données SQL Server. Ces actions sont envoyées à l'audit, qui les enregistre dans la cible.

Les groupes d'actions d'audit et les actions d'audit au niveau de la base de données sont décrits dans la rubrique Actions et groupes d'actions SQL Server Audit.

Les résultats d'un audit sont envoyés à une cible, qui peut être un fichier, le journal des événements de sécurité de Windows ou le journal des événements d'applications de Windows. (L'écriture dans le journal de sécurité n'est pas disponible sur Windows XP.) Les journaux doivent être examinés et archivés périodiquement afin de s'assurer que la cible dispose d'un espace suffisant pour écrire des enregistrements supplémentaires.

L'écriture dans le journal de sécurité de Windows requiert l'ajout du compte de service SQL Server à la stratégie Générer des audits de sécurité. Par défaut, les comptes Système Local, Service local et Service réseau font partie de cette stratégie. Ce paramètre peut être configuré à l'aide du composant logiciel enfichable de stratégie de sécurité (secpol.msc). En outre, la stratégie de sécurité Auditer l'accès aux objets doit être activée pour Succès et Échec. Ce paramètre peut être configuré à l'aide du composant logiciel enfichable de stratégie de sécurité (secpol.msc). Dans Windows Vista ou Windows Server 2008, vous pouvez définir une stratégie générée par une application plus précise à partir de la ligne de commande à l'aide du programme de stratégie d'audit (AuditPol.exe). Pour plus d'informations sur les étapes permettant d'activer l'écriture dans le journal de sécurité de Windows, consultez Procédure : écrire des événements d'audit du serveur dans le journal de sécurité. Pour plus d'informations sur le programme Auditpol.exe, consultez l'article 921469 de la Base de connaissances : Comment faire pour utiliser la stratégie de groupe pour configurer des paramètres d'audit de sécurité détaillés. Les journaux des événements de Windows sont communs à l'ensemble du système d'exploitation Windows. Pour plus d'informations sur les journaux des événements de Windows, consultez Vue d'ensemble de l'observateur d'événements. Si vous avez besoin d'autorisations plus précises sur l'audit, utilisez la cible de fichier binaire.

Lorsque vous enregistrez des informations d'audit dans un fichier, pour éviter toute falsification, vous pouvez limiter l'accès à l'emplacement du fichier des façons suivantes :

• Le compte de service SQL Server doit posséder des autorisations d'accès en lecture et en écriture.

• Les administrateurs d'audit ont généralement besoin des autorisations d'accès en lecture et en écriture. Cela suppose que ces administrateurs sont des comptes Windows pour l'administration des fichiers d'audit, par exemple leur copie sur des partages différents, leur sauvegarde, entre autres.

• Les lecteurs d'audit qui sont autorisés à lire les fichiers d'audit doivent disposer de l'autorisation d'accès en lecture.

Même lorsque le moteur de base de données écrit dans un fichier, d'autres utilisateurs Windows peuvent lire le fichier d'audit s'ils en ont l'autorisation. Le moteur de base de données n'applique pas de verrou exclusif qui empêche les opérations de lecture.

Dans la mesure où le moteur de base de données peut accéder au fichier, les connexions SQL Server qui possèdent l'autorisation CONTROL SERVER peuvent utiliser le moteur de base de données pour accéder aux fichiers d'audit. Pour enregistrer tout utilisateur qui lit le fichier d'audit, définissez un audit sur master.sys.fn_get_audit_file. Vous enregistrez ainsi les connexions avec l'autorisation CONTROL SERVER qui ont accédé au fichier d'audit par le biais de SQL Server.

Si un administrateur d'audit copie le fichier à un autre emplacement (entre autres, à des fins d'archivage), les listes de contrôle d'accès du nouvel emplacement doivent disposer uniquement des autorisations suivantes :

• Administrateur d'audit – Lecture/Écriture

• Lecteur d'audit – Lecture

Nous conseillons de générer des rapports d'audit à partir d'une instance distincte de SQL Server, telle une instance de SQL Server Express, accessible uniquement aux administrateurs ou lecteurs d'audit. En utilisant une instance distincte du moteur de base de données pour la création de rapports, vous pouvez mieux empêcher les utilisateurs non autorisés d'obtenir un accès à l'enregistrement d'audit.

Vous pouvez offrir une protection supplémentaire contre tout accès non autorisé en chiffrant le dossier dans lequel le fichier d'audit est stocké à l'aide du chiffrement de lecteur BitLocker Windows ou du système de fichiers EFS Windows.

Pour plus d'informations sur les enregistrements d'audit qui sont écrits dans la cible, consultez Enregistrements SQL Server Audit.

L'attachement d'une base de données qui a une spécification d'audit et spécifie un GUID qui n'existe pas sur le serveur génère une spécification d'audit orpheline. Étant donné qu'il n'existe pas d'audit avec un GUID correspondant sur l'instance de serveur, aucun événement d'audit n'est enregistré. Pour remédier à cette situation, utilisez la commande ALTER DATABASE AUDIT SPECIFICATION pour connecter la spécification d'audit orpheline à un audit du serveur existant. Ou utilisez la commande CREATE SERVER AUDIT pour créer un nouvel audit de serveur avec le GUID spécifié.

Vous pouvez attacher une base de données pour laquelle une spécification d'audit est définie à une autre édition de SQL Server qui ne prend pas en charge SQL Server Audit, telle que SQL Server Express, mais les événements d'audit ne seront pas enregistrés.

Une base de données qui possède une spécification d'audit définie et qui utilise la mise en miroir de bases de données inclut la spécification de l'audit de la base de données. Pour fonctionner correctement sur l'instance SQL en miroir, les éléments suivants doivent être configurés :

• Le serveur miroir doit avoir un audit avec le même GUID afin de permettre à la spécification de l'audit de la base de données d'écrire des enregistrements d'audit. La commande CREATE AUDIT WITH GUID=<GUID from source Server Audit> permet d'obtenir cette configuration.

• Si la cible est un fichier binaire, le compte de service de serveur miroir doit avoir des autorisations appropriées pour l'emplacement où le journal d'audit est écrit.

• Si la cible est le journal des événements Windows, la stratégie de sécurité sur l'ordinateur où le serveur miroir se trouve doit autoriser l'accès du compte de service au journal des événements de sécurité ou d'applications.