Journal d’Audit Vertica
Vertica est fréquemment utilisé comme le cœur des plateformes analytiques où des dizaines d’applications, des tâches ETL et des outils BI génèrent d’énormes volumes de requêtes SQL. Lorsqu’un événement suspect survient — un lot échoué, une modification inattendue du schéma, ou un incident de sécurité potentiel — les équipes doivent pouvoir répondre à une question simple : qui a fait quoi, quand et comment ? Un journal d’audit Vertica bien implémenté offre cette visibilité en enregistrant les événements clés de la base de données ainsi que les requêtes SQL qui les ont déclenchés.
Cet article explique comment travailler avec les informations d’audit natives de Vertica directement depuis DBeaver, puis démontre comment DataSunrise transforme ces entrées bas niveau en une piste d’audit centralisée et consultable. Nous allons parcourir l’interrogation du schéma v_monitor, la configuration d’une règle d’audit Vertica dans DataSunrise, et la comparaison entre les journaux natifs et la vue enrichie dans Journaux d’Audit DataSunrise et Surveillance de l’Activité des Bases de Données. Pour référence sur toutes les tables système et paramètres disponibles, consultez la documentation officielle de Vertica.
Comprendre les Journaux d’Audit Vertica
Vertica n’expose pas une table monolithique unique nommée « audit_log ». À la place, il enregistre les informations pertinentes pour l’audit dans plusieurs vues système et fichiers journaux. Les deux éléments principaux sont :
- Fichiers journaux d’audit du moteur – fichiers journaux au niveau du système d’exploitation contenant les tentatives d’authentification, les changements de privilèges, et certains événements système.
- Vues
v_monitor– tables interrogeables en SQL affichant les requêtes exécutées, les sessions actives et historiques, ainsi que divers événements de surveillance.
Ensemble, ces sources permettent de répondre aux questions essentielles requises par les équipes de sécurité, conformité et opérations :
- Quel compte a tenté de se connecter au cluster et depuis où ?
- Quelle requête SQL a supprimé ou modifié une table sensible ?
- Quelles requêtes étaient en cours lors d’un incident ?
- À quelle fréquence surviennent les échecs ou erreurs d’authentification ?
Les sections suivantes utilisent DBeaver et DataSunrise pour rendre ces informations accessibles et exploitables.
Afficher les Informations d’Audit Vertica Natives dans DBeaver
Puisque le schéma v_monitor est exposé comme tout autre ensemble de tables, vous pouvez utiliser DBeaver pour explorer les vues liées à l’audit dans Vertica. L’une des plus utiles est v_monitor.query_requests, qui enregistre chaque instruction exécutée avec les informations utilisateur, temporelles et de succès.
Interrogation de v_monitor.query_requests depuis DBeaver. Chaque ligne représente une requête exécutée, incluant le nom d’utilisateur, le type de requête, le texte SQL complet, les horodatages de début et fin, ainsi que le statut de réussite.
Une requête typique pour construire un journal d’audit Vertica natif ressemble à ceci :
SELECT
user_name,
request_type,
request,
start_timestamp,
end_timestamp,
success,
error_count
FROM v_monitor.query_requests
ORDER BY start_timestamp DESC
LIMIT 50;
Cette sortie fonctionne déjà comme un journal d’audit : vous voyez quels utilisateurs ont exécuté quelles instructions et quand, ainsi que les éventuelles erreurs. Vous pouvez étendre la requête avec des colonnes supplémentaires provenant de v_monitor.sessions (pour l’adresse client et le nom de l’application) ou joindre des tables de catalogue pour ajouter des métadonnées d’objets.
Champs Clés dans un Journal d’Audit Vertica
Bien que les vues système de Vertica contiennent de nombreuses colonnes, un rapport d’audit pratique se concentre généralement sur un sous-ensemble essentiel. Le tableau ci-dessous décrit les champs les plus importants et leur utilité lors des investigations.
| Champ | Objet | Exemple |
|---|---|---|
user_name |
Identité de l’utilisateur de la base de données ayant exécuté l’instruction | dbadmin |
request_type |
Catégorie générale telle que QUERY, DDL, COPY ou LOAD | QUERY |
request |
Texte SQL complet de l’opération (ou extrait tronqué) | SELECT col.constraint_name AS pk_name FROM v_catalog... |
start_timestamp |
Moment où Vertica a commencé à exécuter la requête | 2025-12-01 15:03:57.385 |
end_timestamp |
Moment d’achèvement ; utilisé pour mesurer la durée d’exécution et le chevauchement avec les incidents | 2025-12-01 15:03:58.010 |
success |
Indicateur booléen indiquant si la requête s’est terminée avec succès | true |
error_count |
Nombre d’erreurs survenues lors du traitement de la requête | 0 |
Avec ces champs, DBeaver vous fournit déjà un journal d’audit Vertica opérationnel. Vous pouvez filtrer par utilisateur, rechercher des patterns SQL spécifiques, ou exporter les résultats en CSV pour analyse complémentaire. Cependant, cette approche présente encore certaines limites : l’historique est lié à un seul cluster, la rétention des journaux suit les réglages du moteur, et la corrélation des événements entre systèmes est manuelle.
Limites de l’Utilisation Exclusive des Journaux Natives
Les journaux d’audit natifs offrent une grande profondeur mais une portée limitée. Chaque cluster Vertica conserve son propre historique, et la rotation des journaux peut éliminer silencieusement les enregistrements plus anciens. Vous devrez aussi reconstituer des informations à partir de multiples vues et les joindre aux métadonnées du catalogue. Si vous exploitez plusieurs environnements — développement, pré-production, production — ou combinez Vertica avec d’autres bases de données, cela devient rapidement difficile à gérer.
De plus, les logs du moteur et les vues v_monitor ne catégorisent pas automatiquement les événements selon des règles métier. Par exemple, vous pourriez vouloir un journal dédié aux « toutes les modifications DDL dans le schéma finance » ou « tous les accès aux colonnes PII » avec des alertes en cas de violation. Mettre cela en place uniquement avec les journaux natifs implique d’écrire et maintenir vos propres scripts et requêtes planifiées.
Centraliser les Journaux d’Audit Vertica avec DataSunrise
DataSunrise répond à ces défis en agissant comme une couche d’audit devant Vertica. Il capture chaque requête SQL, l’associe à un utilisateur, une application et une base de données, l’évalue selon des règles configurables, et inscrit le résultat dans un dépôt d’audit central. Ce dépôt peut couvrir plusieurs clusters Vertica et autres plateformes de données, vous offrant une vue unifiée de l’activité des bases.
Pour activer l’audit, vous enregistrez Vertica comme source de données dans la console DataSunrise, puis créez une règle d’audit — par exemple « Journal d’Audit Vertica » — qui précise quelles requêtes et événements enregistrer. Une fois la règle activée, chaque opération correspondante apparaît dans l’interface Transactional Trails.
Transactional Trails de DataSunrise montrant les événements du journal d’audit Vertica. Chaque ligne représente une opération capturée, incluant le type de base de données, le nom de la règle d’audit, la connexion utilisateur, l’application cliente, la requête SQL, l’heure de début, et le nombre de lignes.
Contrairement aux journaux bruts du moteur, cette vue est conçue pour l’investigation et le reporting. Vous pouvez filtrer par règle (par exemple « Journal d’Audit Vertica »), zoomer sur des utilisateurs spécifiques, ou rechercher une table ou un pattern particulier. Les événements peuvent aussi être transmis vers des plateformes SIEM ou SOAR grâce aux intégrations natives Syslog ou webhook, évitant le parsing personnalisé des journaux.
Comment DataSunrise Enrichit les Journaux d’Audit Vertica
DataSunrise fait plus que simplement refléter les journaux natifs. Puisqu’il intercepte chaque requête SQL au niveau réseau, il peut :
- Capturer le texte complet des requêtes même lorsque Vertica tronque les journaux internes.
- Appliquer des règles d’audit par schéma, table, utilisateur ou type d’opération sans modifier le code des applications.
- Corréler les événements entre plateformes telles que Vertica, PostgreSQL, Oracle et entrepôts cloud dans une seule console.
- Alimenter des fonctionnalités avancées comme l’Analyse du Comportement Utilisateur et le Gestionnaire de Conformité, qui dépendent de données d’audit normalisées.
- Offrir une rétention flexible et des rapports via les rapports d’audit programmés et l’export vers un stockage externe.
Dans la pratique, les organisations utilisent souvent les journaux natifs Vertica pour un dépannage technique approfondi et s’appuient sur DataSunrise pour la surveillance quotidienne de sécurité et la preuve de conformité. Cette combinaison apporte à la fois la précision fine des journaux moteurs et la clarté élevée d’une plateforme d’audit spécialisée.
Pour Résumer
Mettre en place une stratégie complète de journal d’audit Vertica ne demande pas d’abandonner les outils natifs. Vous pouvez commencer par interroger v_monitor.query_requests et les vues associées depuis DBeaver pour comprendre comment Vertica enregistre l’activité. Ces vues révèlent qui a exécuté quelles requêtes SQL, quand, et avec succès ou non.
Ensuite, vous pouvez connecter Vertica à DataSunrise, créer des règles d’audit ciblées et utiliser Transactional Trails pour maintenir un journal d’audit centralisé et de longue durée couvrant tous vos environnements. En alignant l’historique natif Vertica avec la surveillance avancée, l’analyse comportementale et l’ensemble d’outils de conformité des données de DataSunrise, vous offrez aux équipes de sécurité et d’opérations une source unique de vérité pour enquêter sur les incidents, valider les contrôles et prouver que les données sensibles restent protégées.
Protégez vos données avec DataSunrise
Sécurisez vos données à chaque niveau avec DataSunrise. Détectez les menaces en temps réel grâce à la surveillance des activités, au masquage des données et au pare-feu de base de données. Appliquez la conformité des données, découvrez les données sensibles et protégez les charges de travail via plus de 50 intégrations supportées pour le cloud, sur site et les systèmes de données basés sur l'IA.
Commencez à protéger vos données critiques dès aujourd’hui
Demander une démo Télécharger maintenant