Comment Auditer Vertica

Auditer Vertica est plus qu’un simple basculement d’un interrupteur de journalisation. Pour comprendre qui a accédé à la base de données, quelles instructions SQL ont été exécutées, et comment ces actions ont affecté les données, vous avez besoin à la fois des vues de surveillance natives de Vertica et d’un emplacement centralisé pour stocker et analyser ces événements. Ce guide présente un flux de travail pratique : d’abord utiliser v_monitor pour collecter les preuves natives, puis utiliser DataSunrise Data Audit pour construire une piste d’audit complète de Vertica.

Nous ferons référence à des sujets connexes tels que Journaux d’Audit, Surveillance d’Activité des Bases de Données et Gestionnaire de Conformité. Pour la configuration au niveau du moteur et les détails du catalogue, la documentation officielle de Vertica reste la source d’autorité.

Étape 1 – Inspecter les Sources d’Audit Natives de Vertica

Vertica stocke l’historique des activités dans son schéma v_monitor ainsi que dans les fichiers journaux du moteur. Ces vues ne sont pas étiquetées « audit », mais elles contiennent la plupart des informations nécessaires pour reconstruire ce qui s’est passé :

• v_monitor.query_requests – une ligne par requête, incluant le nom d’utilisateur, le type de requête, le texte SQL, les dates et heures, et un indicateur de succès.
• v_monitor.sessions – métadonnées des sessions telles que ID de session, hôte client et heure de connexion.
• Fichiers journaux du moteur – tentatives d’authentification, erreurs et avertissements du moteur écrits dans le répertoire des logs de Vertica.

Vous pouvez inspecter directement ces données dans DBeaver en exécutant une requête basique :

SELECT *
FROM v_monitor.query_requests
ORDER BY start_timestamp DESC
LIMIT 100;

Historique natif de Vertica à partir de v_monitor.query_requests dans DBeaver. Chaque ligne identifie le nœud, l’utilisateur, la session, le type de requête et le texte SQL, vous donnant une vue d’audit de base.

Cette approche répond déjà à de nombreuses questions d’audit : quels utilisateurs ont exécuté quelles instructions et quand. Cependant, si vous gérez plusieurs clusters, ou si vous devez conserver des données d’audit pendant des mois ou des années, interroger manuellement v_monitor et extraire les résultats de DBeaver devient difficile à maintenir. Les étapes suivantes montrent comment passer des logs bruts à un flux de travail d’audit structuré pour Vertica.

Étape 2 – Identifier les Lacunes de l’Audit Natif de Vertica

Avant d’ajouter plus d’outils, il est utile de clarifier où l’audit natif montre ses limites :

• Vue locale au cluster. Les requêtes sur v_monitor montrent uniquement ce qui s’est passé sur un seul cluster. Vous devez vous connecter à chaque environnement séparément.
• Rétention limitée. L’historique est limité par la capacité disque et la configuration. Les anciens enregistrements disparaissent au fur et à mesure que les tables sont nettoyées et que les fichiers journaux sont archivés.
• Pas d’abstraction des politiques. Vertica enregistre fidèlement ce qui s’est produit, mais ne propose pas de politiques d’audit basées sur des règles, telles que « journaliser tous les DDL dans le schéma finance ».
• Exportation et corrélation manuelles. Pour alimenter des systèmes SIEM ou de reporting, vous devez créer vos propres exports, fusionner les logs de plusieurs nœuds, et normaliser les formats.

Pour passer d’une inspection ponctuelle à un audit répétable, la plupart des équipes ajoutent une couche dédiée capable de capturer le SQL en temps réel, d’appliquer des règles d’audit, et de stocker les événements dans un référentiel central.

Étape 3 – Introduire DataSunrise comme Couche d’Audit pour Vertica

DataSunrise Activity Monitoring complète Vertica en capturant le trafic SQL en transit vers la base. Déployé en mode proxy, les applications se connectent via DataSunrise ; en mode sniffer, DataSunrise écoute le trafic en miroir. Dans les deux cas, il peut voir les instructions reçues par Vertica et les évaluer selon des règles d’audit.

1. Les applications envoient le trafic SQL vers Vertica.
2. DataSunrise observe chaque requête passant par ou à travers l’interface surveillée.
3. Les événements correspondants sont écrits dans un référentiel d’audit interne et, optionnellement, envoyés vers des outils Syslog ou SIEM.
4. Le résultat est une piste d’audit Vertica centralisée exposée dans l’interface web et les API de DataSunrise.

Les étapes suivantes expliquent comment configurer ce chemin d’audit.

Étape 4 – Enregistrer Vertica dans DataSunrise

Commencez par enregistrer Vertica comme base de données surveillée dans la console DataSunrise afin que la plateforme comprenne comment interpréter le SQL capturé :

1. Ouvrez Configuration → Bases de données.
2. Cliquez sur Ajouter et choisissez Vertica comme type de base de données.
3. Fournissez le nom d’hôte, le port, la base de données, et un compte de service disposant des privilèges suffisants pour voir les objets nécessaires.
4. Sélectionnez si cette instance sera auditée en mode proxy ou en mode sniffer.
5. Cliquez sur Tester pour confirmer que DataSunrise peut atteindre l’instance Vertica.

Enregistrement d’une instance Vertica dans DataSunrise. Une fois la connexion validée, le trafic Vertica transitant par le chemin surveillé peut être audité.

Après cette étape, DataSunrise peut associer le SQL capturé à une base Vertica spécifique et l’afficher correctement dans l’interface d’audit.

Étape 5 – Créer une Règle d’Audit pour Vertica

Ensuite, vous définissez quelles opérations Vertica doivent être considérées comme des événements d’audit. DataSunrise utilise des règles d’audit pour contrôler ce qui est journalisé et où les logs sont envoyés :

1. Ouvrez Audit → Règles.
2. Créez une nouvelle règle, par exemple VERTICA_audit.
3. Sélectionnez l’instance Vertica dans la liste des bases.
4. Dans l’onglet types de requêtes, sélectionnez les opérations à enregistrer (par exemple, SELECT, INSERT, UPDATE, DELETE et DDL).
5. Optionnellement, limitez la règle à certains schémas ou tables, comme ceux contenant des données réglementées.
6. Configurez les paramètres de journalisation : enregistrement dans le stockage d’audit interne, Syslog, ou les deux.
7. Activez la règle et enregistrez la configuration.

À partir de ce moment, toute requête Vertica correspondant aux conditions de la règle est écrite dans le référentiel d’audit DataSunrise.

Étape 6 – Valider la Piste d’Audit Vertica dans les Trajets Transactionnels

Pour vérifier que l’audit fonctionne comme prévu, générez une activité test via le chemin surveillé (par exemple, ouvrez et fermez une session, changez un paramètre, et exécutez une instruction DDL), puis examinez les résultats :

1. Allez dans Audit → Trajets Transactionnels.
2. Filtrez par Type de base = Vertica et par votre règle d’audit (par exemple, VERTICA_audit).
3. Inspectez les requêtes capturées, les horodatages et le nombre de lignes affectées.

Résultats d’audit Vertica dans les Trajets Transactionnels de DataSunrise. La règle VERTICA_audit journalise les DDL et les instructions liées aux sessions exécutées par le driver JDBC, avec horodatages et compte des lignes.

Vous devriez maintenant voir des entrées d’audit correspondant à l’activité test que vous avez exécutée. Si les événements apparaissent correctement, l’audit Vertica via DataSunrise fonctionne.

Étape 7 – Cartographier les Tâches d’Audit entre Vertica Natif et DataSunrise

Le tableau ci-dessous montre comment les tâches courantes d’audit diffèrent selon qu’on s’appuie uniquement sur les vues natives de Vertica ou sur une piste d’audit Vertica supportée par DataSunrise.

Étape 8 – Bonnes Pratiques pour Auditer Vertica

Une fois les bases en place, quelques pratiques aident à maintenir votre audit Vertica efficace et facile à gérer :

• Définissez des règles d’audit pour les schémas stockant des données réglementées, financières ou autrement sensibles.
• Combinez les Trajets Transactionnels avec les Trajets de Session pour reconstruire les parcours complets des utilisateurs.
• Choisissez des périodes de rétention en accord avec les exigences réglementaires et la capacité de stockage.
• Passez en revue régulièrement les rapports d’audit avec les parties prenantes de la sécurité et de la conformité.
• Utilisez l’analyse du comportement utilisateur pour mettre en évidence les comportements inhabituels au lieu de scanner manuellement chaque instruction.

Conclusion

Auditer Vertica commence par comprendre ce que la base de données enregistre déjà dans v_monitor et les logs du moteur. Ces sources natives fournissent les faits bruts : qui a exécuté quelles instructions et quand. Pour bâtir une pratique d’audit durable, vous ajoutez DataSunrise comme couche d’audit dédiée capable de capturer le trafic SQL, appliquer des règles cohérentes, centraliser l’historique, et présenter les données d’audit sous une forme fiable pour les équipes sécurité, risque, et conformité.

En enregistrant Vertica dans DataSunrise, créant des règles d’audit ciblées, et validant les résultats dans les Trajets Transactionnels, vous passez du simple scraping occasionnel des logs à un flux de travail d’audit structuré et répétable. Le résultat est une piste d’audit Vertica conforme aux réglementations de conformité des données, supportant la réponse aux incidents et offrant une visibilité durable sur la manière dont vos données analytiques sont consultées et modifiées.