Comment activer l'audit de SQL Server et examiner le journal d'audit

L'audit de Microsoft SQL Server est essentiel pour identifier les problèmes de sécurité et les violations. De plus, l'audit de SQL Server est une exigence pour la conformité avec des réglementations telles que PCI DSS et HIPAA.

La première étape consiste à définir ce qu'il faut auditer. Par exemple, vous pourriez auditer les connexions des utilisateurs, la configuration du serveur, les modifications de schéma et les modifications des données d'audit. Ensuite, vous devez choisir les fonctionnalités d'audit de sécurité à utiliser. Les fonctionnalités utiles comprennent les suivantes :

• Audit C2
• Critères de conformité communs
• Audit de connexion
• Audit de SQL Servering
• Trace SQL
• Événements étendus
• Capture des modifications de données
• Déclencheurs DML, DDL et de connexion

Cet article s'adresse aux administrateurs de bases de données (DBA) qui envisagent d'utiliser l'audit C2, les Critères de Conformité Communs et l'audit SQL Server. Nous n'examinerons pas les outils d'audit tiers, bien qu'ils puissent être d'une grande aide, en particulier pour les environnements plus importants et dans les industries réglementées.

Activation de l'audit C2 et de la conformité aux critères communs

Si vous n'effectuez pas actuellement d'audit sur votre SQL Server, le moyen le plus simple de commencer est d'activer l'audit C2. L'audit C2 est une norme internationalement reconnue qui peut être activée dans SQL Server. Il enregistre des événements tels que les connexions des utilisateurs, les procédures stockées et la création et la suppression d'objets. Mais c'est tout ou rien — vous ne pouvez pas choisir ce qu'il audite, et cela peut générer beaucoup de données. De plus, l'audit C2 est en mode maintenance, il sera donc probablement supprimé dans une future version de SQL Server.

La conformité aux Critères Communs est une norme plus récente qui remplace l'audit C2. Elle a été développée par l'Union européenne et peut être activée dans les éditions Enterprise et Datacenter de SQL Server 2008 R2 et ultérieures. Cependant, elle peut causer des problèmes de performance si votre serveur n'est pas suffisamment équipé pour gérer la surcharge supplémentaire.

Voici comment activer l'audit C2 dans SQL Server 2017 :

1. Ouvrez SQL Server Management Studio.

2. Connectez-vous au moteur de base de données pour lequel vous souhaitez activer l'audit C2. Dans la boîte de dialogue Se connecter au serveur, assurez-vous que le Server type est défini sur Database Engine puis cliquez sur Connect.

3. Dans le panneau Explorateur d'objets sur la gauche, faites un clic droit sur votre instance SQL Server en haut et sélectionnez Properties dans le menu.

4. Dans la fenêtre des propriétés du serveur, cliquez sur Security sous Select a page.

5. Sur la page Sécurité, vous pouvez configurer la surveillance des connexions. Par défaut, seules les tentatives de connexion échouées sont enregistrées. Alternativement, vous pouvez auditer uniquement les connexions réussies, ou bien les tentatives échouées et réussies.

Figure 1. Configuration de l'audit d'accès

6. Cochez Activer le traçage d'audit C2 sous Options.

7. Si vous souhaitez activer l'audit de conformité aux critères communs C2, cochez Enable Common Criteria compliance.

La conformité aux Critères Communs (CC) est une norme flexible qui peut être mise en œuvre avec différents niveaux d'assurance d'évaluation (EAL), de 1 à 7. Les EAL plus élevés nécessitent un processus de vérification plus exigeant. Lorsque vous activez Enable Common Criteria compliance dans SQL Server, vous activez la conformité CC EAL1. Il est possible de configurer manuellement SQL Server pour EAL4+.

L'activation de la conformité CC modifie le comportement de SQL Server. Par exemple, les permissions DENY au niveau des tables auront la priorité sur les GRANTs au niveau des colonnes, et les connexions réussies comme échouées seront auditées. De plus, la Protection des Informations Résiduelles (RIP) est activée, ce qui réécrit les allocations de mémoire avec un motif de bits avant qu'elles ne soient utilisées par une nouvelle ressource.

8. Cliquez sur OK.

9. Selon les options sélectionnées, il se peut qu'on vous demande de redémarrer SQL Server. Si vous recevez ce message, cliquez sur OK dans la boîte de dialogue d'avertissement. Si vous avez activé la conformité aux critères communs C2, redémarrez le serveur. Sinon, faites un clic droit sur votre instance SQL Server dans l'Explorateur d'objets et sélectionnez Redémarrer dans le menu. Dans la boîte de dialogue d'avertissement, cliquez sur Oui pour confirmer que vous souhaitez redémarrer SQL Server.

Activation de l'audit SQL Server

L'audit de SQL Server peut être activé à la place de l'audit C2 ; vous pouvez également choisir d'activer les deux. Les objets d'audit SQL Server peuvent être configurés pour collecter des événements au niveau du serveur ou au niveau de la base de données SQL Server.

Créer un objet d'audit de serveur

Créons un objet d'audit SQL Server au niveau du serveur :

1. Dans le panneau Explorateur d'objets sur la gauche, déployez Security.

2. Faites un clic droit sur Audits et sélectionnez Nouvel Audit… dans le menu. Cela créera un nouvel objet Audit SQL Server pour l'audit au niveau du serveur.

3. Dans la fenêtre Créer un audit, donnez un nom aux paramètres d'audit dans le champ Audit name

4. Spécifiez ce qui doit se passer si l'audit de SQL Server échoue en utilisant l'option On Audit Log Failure. Vous pouvez choisir Continue ou décider d'arrêter le serveur ou d'interrompre les opérations de base de données qui sont auditées. Si vous sélectionnez Fail operation, les opérations de base de données qui ne sont pas auditées continueront de fonctionner.

Figure 2. Création d'un objet d'audit SQL Server au niveau du serveur

5. Dans le menu déroulant Audit destination, vous pouvez choisir d'écrire la piste d'audit SQL dans un fichier ou d'auditer les événements dans le journal de sécurité Windows ou le journal des événements d'application. Si vous choisissez un fichier, vous devez spécifier un chemin pour le fichier.

Notez que si vous souhaitez écrire dans le journal des événements de sécurité Windows, SQL Server devra se voir accorder la permission. Pour des raisons de simplicité, sélectionnez le journal des événements Application. De plus, vous pouvez inclure un filtre dans le cadre de l'objet d'audit pour fournir un ensemble de résultats plus restreint ; les filtres doivent être rédigés en Transact-SQL (T-SQL).

6. Cliquez sur OK.

7. Vous trouverez maintenant la nouvelle configuration d'audit dans l'Explorateur d'objets sous Audits. Cliquez avec le bouton droit sur la nouvelle configuration d'audit et sélectionnez Enable Audit dans le menu.

8. Cliquez sur Close dans la boîte de dialogue Activer l'Audit.

Créer un objet d'audit de base de données

Pour créer un objet d'audit SQL Server pour l'audit au niveau de la base de données, le processus est un peu différent et vous devez d'abord créer au moins un objet d'audit au niveau du serveur.

1. Développez Databases dans l'Explorateur d'objets et déployez la base de données sur laquelle vous souhaitez configurer l'audit.

2. Développez le dossier Security, cliquez droit sur Database Audit Specifications et sélectionnez New Database Audit Specification… dans le menu.

Figure 3. Création d'une spécification d'audit de serveur pour l'audit au niveau de la base de données

3. Dans la fenêtre Propriétés sous Actions, utilisez les menus déroulants pour configurer un ou plusieurs types d'actions d'audit, en sélectionnant les déclarations que vous souhaitez auditer (telles que DELETE ou INSERT), la classe d'objet sur laquelle l'action est effectuée, et ainsi de suite.

4. Lorsque vous avez terminé, cliquez sur OK puis activez l'objet d'audit en faisant un clic droit dessus et en sélectionnant Enable Database Audit Specification.

Visualisation des journaux d'audit de SQL Server

Les journaux d'audit C2 Audit SQL Server sont stockés dans le répertoire de données par défaut de l'instance SQL Server. Chaque fichier journal peut atteindre un maximum de 200 mégaoctets. Un nouveau fichier est automatiquement créé lorsque la limite est atteinte.

Une solution native recommandée pour consulter les journaux d'audit de SQL Server s'appelle Log File Viewer. Pour l'utiliser, suivez les étapes suivantes :

1. Dans SQL Server Management Studio, dans le panneau Explorateur d'objets, déployez Security et

2. Faites un clic droit sur l'objet d'audit que vous souhaitez consulter et sélectionnez View Audit Logs dans le menu.

3. Dans le Log File Viewer, les journaux seront affichés sur le côté droit. Que les journaux soient écrits dans un fichier ou dans le Journal des événements Windows, le Log File Viewer affichera les journaux.

4. En haut du Log File Viewer, vous pouvez cliquer sur Filter pour personnaliser les entrées de journal affichées. Les fichiers journaux de SQL Server sont enregistrés au format .sqlaudit et ne sont pas lisibles, donc Log File Explorer vous permet de cliquer sur Export pour enregistrer les journaux dans un format de fichier délimité par des virgules .log.

Figure 4. Examiner l'audit de SQL Server dans le Log File Viewer

FAQ

Comment vérifier si l'audit de SQL Server est activé ?

Pour vérifier si l'audit de SQL Server est activé, interrogez la vue de gestion dynamique sys.dm_server_audit_status ou vérifiez le dossier Sécurité dans SQL Server Management Studio (SSMS). Dans SSMS, déployez Sécurité > Audits pour voir tous les audits configurés et leur statut actuel – les audits activés afficheront une icône verte, tandis que ceux désactivés apparaîtront avec une icône rouge. Vous pouvez également exécuter cette requête pour vérifier le statut de l'audit de manière programmatique :

      SELECT name, is_state_enabled FROM sys.server_audits
      

N'oubliez pas que l'audit du serveur et la spécification d'audit de la base de données doivent être activés pour une couverture d'audit complète. Data Security qui commence par l'identité nécessite une visibilité complète sur qui accède à quelles données, et l'audit SQL Server fournit cette base lorsqu'il est correctement configuré et vérifié.

Pourquoi mon fichier d'audit SQL Server grossit-il autant ?

Une croissance excessive du fichier d'audit se produit généralement lorsque vous auditez trop d'événements ou que vous n'avez pas configuré les paramètres de gestion de fichiers de manière appropriée. Les coupables les plus courants sont l'activation de TOUS les groupes d'actions d'audit, l'audit des instructions SELECT sur des tables à fort trafic, ou la définition d'une croissance illimitée du fichier sans rotation. Pour contrôler la croissance, concentrez-vous sur l'audit uniquement des événements dont vous avez réellement besoin pour la conformité – généralement LOGIN_CHANGE_PASSWORD_GROUP, DATABASE_PERMISSION_CHANGE_GROUP, et des opérations DML spécifiques sur des tables sensibles. Configurez des limites de taille maximale de fichier et activez la rotation des fichiers avec les options MAXSIZE et MAX_ROLLOVER_FILES. Pour les environnements à fort volume, envisagez d'utiliser la cible APPLICATION_LOG au lieu de la cible FILE, ou mettez en œuvre un filtrage d'audit avec des clauses WHERE pour réduire la capture d'événements inutiles. Un audit intelligent signifie suivre ce qui compte sans se noyer dans le bruit des données.

Comment résoudre les problèmes lorsque l'audit de SQL Server ne démarre pas ?

Lorsque l'audit de SQL Server échoue à démarrer, le problème est généralement lié aux permissions de fichiers, à l'accessibilité du chemin ou à des conflits de configuration. Tout d'abord, vérifiez que le compte de service SQL Server dispose des permissions d'écriture pour le répertoire du fichier d'audit – c'est la cause la plus fréquente des échecs de démarrage. Consultez le journal d'erreurs de SQL Server pour des messages d'erreur spécifiques, qui fournissent généralement des indications claires sur le problème. Assurez-vous que le répertoire cible existe et est accessible depuis l'instance SQL Server, en particulier dans des environnements clusterisés où les chemins de stockage partagés doivent être valides sur tous les nœuds. Si vous utilisez le journal d'applications Windows comme cible, vérifiez que le compte de service dispose des permissions d'écriture appropriées pour le journal des événements. Des erreurs de configuration telles que des noms d'audit dupliqués ou des chemins de fichiers invalides empêcheront également le démarrage. La clé est un dépannage méthodique : vérifiez d'abord les permissions, puis les chemins, puis la syntaxe de configuration. Netwrix simplifie cette complexité en fournissant une gestion centralisée des audits qui élimine ces pièges courants.

Quel est l'impact sur les performances de l'audit de SQL Server ?

L'audit de SQL Server a un impact minimal sur les performances lorsqu'il est correctement configuré, ajoutant généralement une surcharge de 2 à 5 % dans la plupart des environnements. L'impact réel dépend de trois facteurs clés : les événements que vous auditez, leur fréquence d'occurrence et la performance de votre sous-système de stockage. Auditer des opérations à haute fréquence telles que les instructions SELECT sur des systèmes OLTP très sollicités créera plus de surcharge que de se concentrer sur des événements pertinents pour la sécurité tels que les connexions, les changements de permissions et les opérations DML sur des tables sensibles. Les cibles d'audit asynchrones (l'option par défaut) offrent de meilleures performances que les options synchrones, mais avec un enregistrement des événements légèrement retardé. Pour minimiser l'impact, utilisez le filtrage d'audit avec des clauses WHERE, évitez d'auditer des opérations système inutiles et assurez-vous que votre stockage de fichiers d'audit dispose d'une capacité d'E/S adéquate. Les Événements Étendus ont généralement moins d'impact que SQL Server Audit pour les scénarios à haut volume, mais SQL Server Audit offre des fonctionnalités de conformité supérieures et une gestion plus facile. Une conception d'audit intelligente se concentre sur la valeur de sécurité plutôt que sur une journalisation exhaustive – vous voulez une visibilité qui protège sans paralyser les performances.

Audit de SQL Server contre SQL Trace : lequel devrais-je utiliser ?

SQL Server Audit est le choix moderne pour les nouvelles mises en œuvre, tandis que SQL Trace est obsolète et doit être évité pour les nouveaux projets. SQL Server Audit offre une meilleure sécurité, performance et capacités de gestion par rapport à la fonctionnalité SQL Trace héritée. Contrairement à SQL Trace, les événements de SQL Server Audit ne peuvent pas être modifiés ou supprimés par les utilisateurs (y compris les administrateurs système), garantissant ainsi l'intégrité de l'audit pour les exigences de conformité. Le cadre d'audit propose un traitement asynchrone pour de meilleures performances, des capacités de filtrage intégrées et une intégration avec le journal des événements de sécurité Windows. SQL Trace nécessite une programmation manuelle avec des procédures stockées et a été marqué pour suppression dans les futures versions de SQL Server. Extended Events est le remplacement recommandé pour les capacités de diagnostic de SQL Trace, tandis que SQL Server Audit gère la surveillance de la sécurité et de la conformité. Si vous utilisez actuellement SQL Trace pour l'audit de sécurité, migrez immédiatement vers SQL Server Audit – il fournit la piste d'audit inviolable que la véritable sécurité des données exige. Les solutions Netwrix s'appuient sur ces capacités d'audit natives pour fournir une visibilité centralisée sur l'ensemble de votre environnement de données.