Fonctionnement de SQL Server Audit
L'audit d'une instance de SQL Server ou d'une base de données SQL Server implique le suivi et l'enregistrement des événements qui se produisent sur le système. Vous pouvez utiliser plusieurs méthodes d'audit pour SQL Server, comme décrit dans Audit (moteur de base de données). À compter de SQL Server 2008 Enterprise, vous pouvez également configurer l'audit automatique à l'aide de SQL Server Audit.
Il existe plusieurs niveaux d'audit pour SQL Server, selon les spécifications de normes pour votre installation. SQL Server Audit fournit les outils et processus nécessaires pour activer, stocker et afficher les audits sur différents objets de serveur et de base de données.
Vous pouvez enregistrer des groupes d'actions d'audit du serveur par instance, et des groupes d'actions d'audit de base de données ou des actions d'audit de base de données par base de données. L'événement d'audit se produit chaque fois que l'action pouvant être auditée est rencontrée.
Composants de SQL Server Audit
Un audit est la combinaison de plusieurs éléments dans un package unique pour un groupe spécifique d'actions de serveur ou d'actions de base de données. Les composants de SQL Server Audit se combinent de façon à produire une sortie appelé audit, tout comme une définition de rapport combinée à des graphiques et des éléments de données produit un rapport.
SQL Server Audit utilise des événements étendus pour aider à créer un audit. Pour plus d'informations sur les événements étendus, consultez Présentation des événements étendus SQL Server.
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é.
Spécification de l'audit du serveur
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.
Spécification de l'audit de la base de données
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. N'incluez pas d'objets dans l'étendue du serveur, tels que les vues système, dans une spécification d'audit de base de données utilisateur.
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.
Cible
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.
Important
Tout utilisateur authentifié peut lire et écrire dans le journal des événements d'applications de Windows. Celui-ci requiert des autorisations inférieures au journal des événements de sécurité de Windows et il est moins sécurisé.
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.
Vue d'ensemble de l'utilisation de SQL Server Audit
Vous pouvez utiliser SQL Server Management Studio ou Transact-SQL pour définir un audit. Une fois l'audit créé et activé, la cible reçoit des entrées.
Vous pouvez lire les journaux des événements de Windows à l'aide de l'utilitaire Observateur d'événements de Windows. Si la cible est un fichier, vous pouvez utiliser la Visionneuse du fichier journal dans SQL Server Management Studio ou la fonction fn_get_audit_file pour lire le fichier journal.
Voici le processus général employé pour créer et utiliser un audit.
Créez un audit et définissez la cible.
Créez une spécification de l'audit du serveur ou une spécification de l'audit de la base de données mappée à l'audit. Activez la spécification d'audit.
Activez l'audit.
Lisez les événements d'audit à l'aide de l'Observateur d'événements Windows, de la Visionneuse du fichier journal ou de la fonction fn_get_audit_file.
La rubrique Rubriques consacrées aux procédures de SQL Server Audit fournit des exemples SQL Server Management Studio et Transact-SQL d'utilisation de la fonctionnalité d'audit.
Éléments à prendre en considération
En cas d'échec pendant le lancement de l'audit, le serveur ne démarre pas. Dans ce cas, le serveur peut être démarré à l'aide de l'option .f à la ligne de commande.
Lorsqu'un échec de l'audit provoque l'arrêt ou empêche le démarrage du serveur car l'instruction ON_FAILURE=SHUTDOWN est spécifiée pour l'audit, l'événement MSG_AUDIT_FORCED_SHUTDOWN est écrit dans le journal. Étant donné que l'arrêt se produit lors de la première rencontre de ce paramètre, l'événement est écrit une seule fois. Cet événement est écrit après le message d'échec d'audit qui provoque l'arrêt. Un administrateur peut contourner les arrêts provoqués par l'audit en démarrant SQL Server en mode mono-utilisateur à l'aide de l'indicateur -m. Un démarrage en mode mono-utilisateur rétrograde les audits pour lesquels ON_FAILURE=SHUTDOWN est spécifié pour s'exécuter dans cette session comme ON_FAILURE=CONTINUE. Lorsque SQL Server est démarré à l'aide de l'indicateur –m, le message MSG_AUDIT_SHUTDOWN_BYPASSED est écrit dans le journal des erreurs.
Pour plus d'informations sur les options de démarrage de service, consultez Utilisation des options de démarrage du service SQL Server.
Attachement d'une base de données avec un audit défini
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.
Mise en miroir de bases de données et SQL Server Audit
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.
Voir aussi