Surveillance de l'activité de la base de données : quoi surveiller et comment le faire

Les bases de données contiennent les dossiers clients, paiements et santé qui intéressent le plus les régulateurs, attaquants et auditeurs. Les fonctions d’audit natives de SQL Server, Oracle, MySQL et PostgreSQL capturent les modifications d’objets et de permissions, mais offrent peu de visibilité sur qui a consulté les lignes sensibles.

Le Rapport sur la Sécurité des Données et de l'Identity Netwrix 2026 a révélé que 75 % des expositions de données sensibles commencent par des identités compromises ou des permissions mal configurées. L'audit natif offre la moindre visibilité là où ces identités ont le plus de pouvoir : les comptes privilégiés qui peuvent modifier eux-mêmes la piste d'audit.

La surveillance de l’activité des bases de données produit un enregistrement indépendant des accès, modifications et actions administratives, permettant aux équipes de sécurité d’enquêter sur les incidents, de prouver la conformité et de détecter les abus avant qu’un compte compromis ou un changement discret de configuration ne devienne une violation à signaler.

Qu'est-ce que la surveillance de l'activité des bases de données ?

La surveillance de l’activité des bases de données (DAM) est une discipline de sécurité qui capture, stocke et analyse l’activité des utilisateurs et des administrateurs à l’intérieur d’une base de données, indépendamment du moteur de base de données lui-même. Sur demande, elle répond à qui s’est connecté, ce qu’il a lu ou modifié, et si quelqu’un a modifié la configuration de l’audit.

DAM s’accompagne de la surveillance des performances mais sert un objectif différent. Les outils de performance suivent le CPU, les entrées/sorties et la latence des requêtes pour maintenir le moteur en bonne santé. DAM capture plutôt la requête SQL, l’identité de l’utilisateur, l’adresse IP du client et le timestamp, afin que vous puissiez relier l’activité à une personne ou un service nommé.

Un outil DAM collecte ces informations via un network tap, un agent hôte, ou la propre fonction d’audit de la base de données, puis les transmet à un dépôt en dehors de la base de données afin que l’enregistrement survive à un compte administrateur compromis.

Pourquoi la surveillance de l’activité des bases de données est importante

Pour un administrateur de base de données (DBA) ou un analyste en sécurité, la partie difficile de tout incident ou audit est de prouver qui a touché quoi. Sans une piste indépendante dans la base de données, les équipes reconstituent cette preuve manuellement à partir de journaux partiels, généralement dans un délai imparti.

Les données sensibles se concentrent dans la couche base de données

Les dossiers clients, les données des titulaires de carte et les protected health information (PHI) résident dans les tables de bases de données. Toute donnée réglementée transite à un moment donné par une base de données. Lorsque l'accès à la base de données n'est pas surveillé, les actifs les plus sensibles de l'environnement perdent leur couche la plus proche de responsabilité, et chaque contrôle en aval dépend d'une trace qui n'a jamais été capturée.

Les journaux natifs de la base de données ne peuvent pas soutenir une enquête

La trace par défaut de SQL Server capture les modifications d'objets et de permissions mais pas l'activité SELECT, et ne conserve que 100 Mo d'historique. Pire encore, Microsoft avertit que les sysadminsExpand peuvent altérer la piste d'audit elle-même, c'est pourquoi NIST SP 800-53 AU-9(2) exige de stocker les enregistrements d'audit sur un système distinct de celui audité.

Les cadres de conformité exigent une piste d’audit de base de données

Chaque cadre majeur considère l'activité de la base de données comme une preuve. PCI DSS v4.0.1 L'exigence 10 impose 12 mois d'accès journalisé aux données des titulaires de carte et l'intégrité des journaux d'audit. Le 45 CFR 164.312(b) de HIPAA exige des mécanismes qui enregistrent et examinent l'activité dans les systèmes ePHI.

Dans son rapport d’inspection 2023 sur Ernst & Young Incorporated (Publication PCAOB n° 104-2024-113), le PCAOB a reproché à la société de ne pas avoir évalué comment les propriétaires du contrôle client ont examiné les modifications directes à la base de données derrière son système comptable, lors d’un audit du contrôle interne sur le reporting financier selon SOX.

Le RGPD Article 5(2) oblige les responsables à démontrer la conformité aux principes du règlement, ce qui inclut de montrer qui a accédé aux données personnelles.

Les comptes compromis et les abus internes apparaissent d'abord dans la base de données

Une connexion valide semble légitime pour tous les systèmes sauf celui qui enregistre ce qui a été fait, c'est pourquoi le vol d'identifiants et l'utilisation abusive interne déclenchent rarement les contrôles périmétriques. Le 2026 Data Breach Investigations Report de Verizon a révélé que l'abus d'identifiants était présent dans 39 % des violations à un moment donné de la chaîne d'attaque, et la surveillance continue des bases de données est souvent le premier endroit pour détecter le mouvement latéral qui suit.

Activités de base de données à surveiller

Les catégories ci-dessous ont suffisamment de poids en matière de sécurité ou de conformité pour justifier leurs propres règles de détection. Ensemble, elles couvrent qui est entré, ce qu'ils ont lu ou modifié, et si quelqu'un a altéré l'enregistrement : les questions avec lesquelles toute enquête commence.

Événements d'authentification et de connexion

Les enregistrements de connexion sont le premier endroit où une identité volée devient visible. Les échecs de connexion révèlent des tentatives de deviner le mot de passe ou credential stuffing, tandis que les connexions réussies depuis des sources inhabituelles révèlent que les identifiants sont utilisés là où ils ne devraient pas.

Les connexions privilégiées et des comptes de service méritent une attention particulière, car un compte de service qui se connecte soudainement depuis un nouveau poste de travail au lieu de sa couche d’application habituelle mérite presque toujours une enquête. Oracle active une predefined failed-logon policy par défaut dans les nouvelles bases de données, bien que celles mises à niveau doivent souvent l’activer manuellement.

Lectures de données sensibles et exportations en masse

La visibilité directe sur qui a interrogé des tables réglementées permet de distinguer le fait de savoir qu’une exposition a eu lieu de la preuve de ce qui a été pris. L’accès pour la première fois à une table jamais consultée par un utilisateur, et l’extraction en masse via des outils tels que bcpExpand ou expdpExpand, sont les modèles de lecture les plus importants à surveiller, le même comportement que les contrôles de data loss prevention surveillent au niveau du point de terminaison.

Modifications du schéma et de la configuration

Les modifications de schéma et de configuration peuvent détruire des données ou aveugler la surveillance destinée à tout détecter. CREATE, ALTER, Expandet DROPExpand déclarations contre les tables et procédures stockées nécessitent leurs propres alertes, et les modifications de la configuration d’audit méritent la réponse la plus rapide. Microsoft fournit xp_cmdshellExpand désactivé par défaut dans SQL Server car l’activer donne à un attaquant un shell de commandes.

Nouveaux privilèges ou privilèges escaladés

Une seule attribution de privilège peut transformer un compte limité en un compte qui lit tout ou désactive entièrement la piste d'audit. Les changements d'appartenance aux rôles, les nouvelles connexions et toute addition au rôle sysadmin dans SQL Server, ou un rôle DBA équivalent dans Oracle, sont des alertes non négociables, le même privilege escalation modèle surveillé au niveau de l'identité. Le principe du moindre privilège est le contrôle de base. La politique ORA_ACCOUNT_MGMT d'Oracle le couvre, mais elle est désactivée par défaut.

Modifications des données dans les tables sensibles

Lorsqu'un salaire ou un solde de compte change sans autorisation, la première question est de savoir quelle était la valeur avant le changement. Les enregistrements d'audit natifs ne conservent que le texte de la requête, pas les valeurs des lignes, il faut donc un mécanisme séparé pour préserver le contenu avant et après, comme le Change Data Capture de SQL Server, la journalisation binaire des images de ligne de MySQL ou les PostgreSQL triggers. Les alertes sur les modifications massives ou hors horaires sur des tables réglementées correspondent à MITRE T1565, Data Manipulation.

Activité qui rompt le schéma normal

Les règles de base détectent une activité qui semble ordinaire isolément mais inhabituelle pour le compte qui l’exécute, comme un utilisateur interrogeant soudainement 10 tables en cinq minutes, ou un compte d’application connu se connectant depuis une nouvelle adresse IP.

C'est la seule catégorie qui dépend des analyses SIEM plutôt que de la configuration d'audit native, la même approche basée sur une ligne de base comportementale que identity threat detection utilise au niveau du compte.

Comment mettre en œuvre la surveillance des activités de la base de données

Suivez les cinq étapes dans l’ordre, car chacune dépend de la précédente. Ce que vous définissez à l’étape 1 détermine la méthode de collecte adaptée à l’étape 2, et ainsi de suite.

Ils supposent également une petite équipe qui ne peut pas examiner manuellement chaque événement, donc plusieurs étapes ci-dessous reposent sur des déploiements progressifs et des bases de référence automatisées plutôt que sur un tri manuel.

1. Définissez la portée de ce qui sera surveillé

Commencez par inventorier les bases de données contenant des données réglementées ou sensibles pour l'entreprise, telles que la paie, les titulaires de carte, la santé ou la propriété intellectuelle, et classez-les par moteur réglementaire. Cet inventaire n'a d'importance que lorsque vous savez quelles tables contiennent des champs sensibles, alors lancez d'abord data classification ; si vous le sautez, une spécification d'audit de paie n'aura rien à pointer.

Les enjeux sont réels : l’enquête à l’origine du Netwrix 2026 Data and Identity Security Report a révélé que 57 % des organisations ne maintiennent pas en continu un inventaire des données sensibles, donc la plupart des équipes commencent cette étape à l’aveugle.

Une fois que vous avez cartographié les bases de données sensibles, étendez le même inventaire aux comptes privileged, partagés et de service qui y ont accès, et engagez-vous à surveiller chaque session privileged dans son intégralité, même lorsque la journalisation des utilisateurs réguliers reste sélective.

CIS Safeguard 8.5 fixe le minimum pour cet engagement. Au minimum, capturez le nom d’utilisateur, l’horodatage, ainsi que les adresses source et destination pour chaque actif contenant des données sensibles.

2. Choisissez une méthode de collecte adaptée à votre environnement

La capture réseau passive via un port SPAN est le point de départ si vous avez besoin d’une charge nulle sur le serveur. Cependant, ce compromis de charge nulle vous fait perdre la visibilité sur Transport Layer Security (TLS) à secret avancé, les connexions locales et les bases de données gérées dans le cloud.

Lorsque bloquer une déclaration importe plus que de la voir, un proxy inline est plus adapté, car il termine TLS lui-même, bien que ce même contrôle ajoute de la latence et fasse du proxy une dépendance de disponibilité.

Si les connexions locales nécessitent encore une couverture après cela, et que l’équipe peut supporter le coût CPU ainsi que le travail de revalidation que chaque mise à jour du noyau ou de la base de données entraîne, un agent hôte comble cette lacune. Les équipes utilisant une base de données en tant que service (DBaaS) ou ayant besoin de visibilité sur les procédures stockées et le chiffrement y parviennent en associant l’audit natif à la collecte sans agent.

Oracle rapporte une surcharge CPU à un chiffre moyen unique pour l'audit natif jusqu'à 360 000 enregistrements d'audit par heure. La collecte sans agent ajoute une charge supplémentaire, il est donc conseillé de tester la combinaison avant de s'engager.

En pratique, la plupart des équipes combinent les méthodes de toute façon, car la documentation AVDF d’Oracle recommande d’associer la surveillance réseau à l’audit des bases de données afin que chacun couvre les angles morts de l’autre.

3. Définissez des politiques et des seuils d’alerte qu’une petite équipe peut gérer

Activez les règles par étapes, pas toutes en même temps, car tout activer dès le premier jour submergerait une petite équipe de faux positifs. Commencez ce déploiement progressif par la falsification des audits et les droits sysadmin, mappés à partir des six catégories d’activité ci-dessus, car ces deux cas tolèrent le moins les alertes manquées.

NIST SP 800-94 avertit qu’un système fraîchement déployé génère généralement trop de faux positifs avant que ses règles ne soient entièrement adaptées à l’environnement, ce qui explique l’importance de l’approche progressive.

Les règles de volume et de modèle d’accès nécessitent un traitement différent. Exécutez-les comme des anomalies, ajustées sur au moins une semaine de données de référence, du même ordre de grandeur que Microsoft Sentinel utilise pour sa propre règle d’anomalie des lignes affectées, qui s’entraîne sur 14 jours.

Attendez-vous à ce que ces seuils restent locaux à votre environnement plutôt que de suivre un chiffre universel, car l'anomalie pour une équipe est de 100 lignes, pour une autre de 500 000, et seule votre propre base de référence révèle laquelle est laquelle.

4. Centralisez les événements de la base de données et corrélez-les avec le contexte d’identité

Centralisez d'abord la collecte des journaux, comme l'exige CIS Safeguard 8.9, et utilisez un outil qui filtre de grands ensembles d'événements en un ensemble qu'un humain peut examiner, comme le recommande NIST SP 800-61 Rev. 3. Une fois ce pipeline en place, corrélez chaque événement avec le compte derrière, car un journal centralisé sans contexte d'identité vous laisse encore lire des instructions SQL brutes au lieu de noms.

Dans Microsoft Sentinel, cette corrélation s'effectue via des tables spécifiques. Acheminer les événements d'audit Azure SQL vers la table SQLSecurityAuditEventsExpand (ou AzureDiagnosticsExpand dans les anciennes configurations), les événements Windows de SQL Server vers SecurityEventExpand, et les alertes Defender vers SecurityAlert;Expand puis utiliser la table IdentityInfoExpand pour associer la personne derrière chaque compte.

Les utilisateurs de Splunk et IBM QRadar peuvent suivre le même schéma avec leurs propres recherches d’identité ; le résultat est de transformer « quelqu’un a exécuté un grand SELECT » en « un compte contractuel ajouté à sysadmin il y a deux heures a exécuté un grand SELECT ».

5. Tester, ajuster et maintenir le pipeline de surveillance

Testez la pipeline complète avec une activité représentative avant de lui faire confiance en production. Ajoutez une connexion test à un rôle serveur, modifiez une spécification d'audit et lancez une exportation de 600 lignes, puis confirmez que chaque alerte arrive avec la bonne identité attachée. Une pipeline qui enregistre l'événement mais perd le contexte d'identité est à moitié construite.

Reconstruisez les bases de référence chaque fois que les applications changent et revérifiez périodiquement les politiques d’audit, car Oracle's AVDF documentation avertit qu’un DBA peut les modifier ou les supprimer. Récupérez et examinez les paramètres selon un calendrier ; CIS Safeguard 8.1 recommande cette révision au moins une fois par an.

La rétention mérite la même rigueur. Réglez-la selon le mandat le plus strict applicable, avec le plancher de 12 mois de PCI DSS comme référence, et conservez également le paramètre de diagnostic qui alimente un pipeline Azure SQL dans votre liste surveillée, car le supprimer peut interrompre silencieusement la collecte.

Comment Netwrix vous aide à surveiller l'activité de la base de données

La plupart du travail ci-dessus, de la définition du périmètre à la corrélation du contexte d’identité, s’applique quel que soit l’outil utilisé. Netwrix Auditor couvre la collecte, les alertes et les détails avant et après pour SQL Server et Oracle, et Netwrix Access Analyzer ajoute la couche des permissions et des données sensibles.

Suivi des connexions et des accès privilégiés

Netwrix Auditor SQL Server monitoring enregistre les connexions réussies et échouées et suit l'activité des DBA, y compris les actions privilégiées et les modifications des rôles serveur. Son Oracle Database monitoring logiciel suit les connexions réussies et échouées et surveille les instructions SQL et les privilèges. Pour chaque source, vous pouvez configurer des alertes pour envoyer un email à un analyste ou exécuter un script que vous définissez comme une action de réponse.

Les rapports d’Auditor servent également de preuve de conformité. First National Bank and Trust of Beloit utilise Netwrix Auditor comme solution principale pour la conformité OCC et consacre maintenant une heure, au lieu d’une semaine, à la préparation des audits. Bank of the South l’utilise pour protéger les données critiques de l’entreprise et se conformer à PCI DSS et GLBA, économisant au moins 40 heures par an pour la préparation des audits.

Capture des valeurs avant et après les modifications des données

Netwrix Auditor for SQL Server fonctionne par défaut en mode sans déclencheur, lisant le journal de trace toutes les cinq minutes sans charge supplémentaire et rapportant qui a changé quoi et quand. Le mode basé sur les déclencheurs ajoute les valeurs avant et après pour INSERT, UPDATE et DELETE, que l’audit natif ne peut pas fournir, au prix d’une charge supplémentaire sur les serveurs à forte transaction.

Relier l'activité aux données sensibles

Netwrix Auditor applique un contexte de données sensibles au niveau des tables en mode sans déclencheur, en utilisant les tables et politiques que vous avez configurées, afin que les rapports puissent signaler les activités sur les tables réglementées. Pour une découverte et une analyse des permissions plus approfondies sur SQL Server et Oracle, Netwrix Access Analyzer cartographie les permissions effectives et met en lumière les données surexposées, au-delà de ce que couvre seul Auditor.

Déploiement avec un impact minimal en production

Netwrix Auditor collecte à distance, donc seul le mode déclenché touche directement les tables surveillées. La collecte Oracle s’effectue via Oracle Instant Client sur le serveur Auditor toutes les dix minutes, et la lecture des traces SQL Server toutes les cinq minutes. Les modules complémentaires transmettent les enregistrements d’activité à Splunk, IBM QRadar et ArcSight pour les équipes centralisant déjà sur un SIEM.

Mettez en pratique la surveillance de l'activité de la base de données

Commencez par l’instance contenant vos données les plus réglementées, établissez une base de référence, puis étendez-vous uniquement après que le premier ensemble d’alertes ait produit des résultats exploitables.

Pour les charges de travail gérées dans le cloud, la couverture dépend de la source de données et du modèle de déploiement. Netwrix Access Analyzer découvre les données sensibles et analyse les permissions sur SQL Server, Azure SQL, Amazon RDS pour SQL Server et Oracle.

Demandez une démo pour voir comment Netwrix peut vous aider à surveiller l'activité de la base de données, centraliser la piste d'audit et détecter les abus avant qu'ils ne deviennent une faille.