Qu’est-ce que la piste d’audit Vertica
Une piste d’audit Vertica est l’enregistrement complet et chronologique des activités liées à la sécurité à l’intérieur de la base de données. Elle relie les entrées individuelles du journal d’audit en une histoire : qui s’est connecté, quelles instructions SQL ont été exécutées, quels objets ont été manipulés, si ces actions ont réussi, et quand tout cela s’est produit. Cette piste est essentielle lorsque vous devez enquêter sur un incident, prouver que les contrôles d’accès fonctionnent comme prévu, ou satisfaire aux exigences réglementaires telles que le RGPD, HIPAA ou PCI DSS.
Vertica fournit les éléments bruts pour une piste d’audit via des vues système et des fichiers journaux du moteur. DataSunrise transforme ces éléments en une piste d’audit de base de données consolidée qui couvre plusieurs clusters et plateformes de données. Cet article explique à quoi ressemble l’historique natif Vertica dans des outils comme DBeaver et comment DataSunrise s’appuie dessus pour créer une piste d’audit Vertica complète.
Les éléments constitutifs natifs de la piste d’audit Vertica
Au niveau natif, Vertica expose l’historique d’activité via le schéma v_monitor et les fichiers journaux du moteur. La vue la plus pertinente pour l’audit est v_monitor.query_requests, qui suit chaque requête exécutée par Vertica. Vous pouvez interroger cette vue directement depuis DBeaver pour voir qui a exécuté quoi, quand, et comment cela s’est comporté.
v_monitor.query_requests dans DBeaver. Chaque ligne montre le nom du nœud, l’utilisateur Vertica, l’ID de session, le type de requête et le texte SQL, formant la base native d’une piste d’audit Vertica.
D’autres vues v_monitor ajoutent un contexte supplémentaire, comme la durée de session, l’hôte client ou la consommation des ressources. Cependant, Vertica stocke ces informations pour chaque cluster séparément, et la rétention dépend des paramètres locaux de rotation des journaux. Transformer cela en une piste d’audit à long terme qui supporte la recherche judiciaire et la conformité nécessite généralement une couche d’audit externe.
Architecture de la piste d’audit Vertica avec DataSunrise
DataSunrise capture le trafic SQL tel qu’il circule entre les applications clientes et Vertica. Il peut fonctionner comme un proxy transparent ou en mode sniffer, reconstruisant le SQL à partir des paquets réseau. Chaque requête passe par le moteur d’audit DataSunrise, qui applique des règles, enrichit les événements avec des métadonnées, et les enregistre dans un référentiel centralisé. Le schéma ci-dessous illustre ce flux.
Architecture de la piste d’audit Vertica : l’activité client génère du trafic SQL, Vertica l’enregistre dans les vues v_monitor et les fichiers journaux, et DataSunrise Audit ingère le SQL et les métadonnées pour construire une piste d’audit centralisée.
Parce que DataSunrise se place à la frontière du réseau, il voit chaque requête et réponse, y compris les instructions qui peuvent ne pas figurer dans un fichier journal spécifique à Vertica. Il normalise également les événements entre plateformes, de sorte que Vertica, PostgreSQL et les entrepôts de données cloud puissent partager le même format d’audit. Cela facilite grandement l’investigation des incidents inter-systèmes et la génération de rapports cohérents.
Comparaison entre les journaux natifs et une piste d’audit Vertica
Le tableau suivant met en lumière la différence entre la journalisation native brute et une piste d’audit Vertica complète telle qu’implémentée avec DataSunrise.
| Aspect | Journaux natifs Vertica | Piste d’audit Vertica avec DataSunrise |
|---|---|---|
| Portée | Cluster unique, vues locales et fichiers journaux du moteur | Plusieurs clusters Vertica et autres bases de données dans un même référentiel |
| Détail de l’événement | Texte SQL, horodatages et métadonnées moteur dans des vues séparées | Événements unifiés contenant utilisateur, application, SQL, objet, règle et contexte de risque |
| Rétention | Contrôlée par la rotation et l’entretien des journaux Vertica | Rétention à long terme configurable pour les audits et les enquêtes |
| Consommation | Requêtes manuelles via DBeaver ou scripts personnalisés | Interface Web (Trails transactionnels), APIs et intégrations SIEM/SOAR |
Les journaux natifs sont cruciaux comme source de vérité interne à Vertica. La piste d’audit ajoute structure, contexte et portée, transformant ces journaux en un outil que les équipes sécurité, risques et conformité peuvent utiliser quotidiennement.
Visualiser la piste d’audit Vertica dans DataSunrise
Une fois les règles d’audit DataSunrise activées pour Vertica, chaque opération correspondant à une règle apparaît dans la vue Audit → Trails transactionnels. Ici, vous pouvez filtrer par type de base de données, nom de règle, utilisateur, application, plage horaire, état d’erreur ou texte de requête. La capture d’écran ci-dessous montre une règle d’audit Vertica simple qui enregistre les commandes d’ouverture/fermeture de session, les instructions DDL et les modifications de configuration issues d’un pilote JDBC.
Trails transactionnels DataSunrise affichant les événements d’audit Vertica. La règle VERTICA_audit enregistre les commandes de session et les opérations DDL émises par le pilote JDBC, incluant les horodatages et le texte SQL.
Contrairement aux requêtes ad-hoc sur v_monitor, cette vue offre une piste d’audit Vertica prête à l’emploi : les lignes peuvent être exportées, transmises à un SIEM, ou utilisées pour des rapports automatisés. Vous pouvez aussi passer à la vue Trails de session pour voir le déroulement chronologique d’une session utilisateur, ou utiliser les analyses de surveillance de l’activité des bases de données pour identifier les comportements inhabituels.
Quand avez-vous besoin d’une piste d’audit Vertica ?
Une piste d’audit formelle devient indispensable dans plusieurs situations :
- Incidents de sécurité – retracer quels comptes ont accédé ou modifié des tables sensibles durant une période de compromission.
- Gestion des changements – vérifier que toutes les modifications de schéma et de rôles ont suivi les workflows approuvés.
- Preuve de conformité – démontrer aux auditeurs que l’accès aux données réglementées est journalisé et consultable.
- Environnements partagés – séparer les responsabilités lorsque plusieurs équipes ou locataires utilisent le même cluster Vertica.
Dans chaque cas, une piste d’audit Vertica claire vous permet de reconstruire les événements en toute confiance plutôt que de vous fier à des fragments de journaux incomplets.
Conclusion
Dans Vertica, une véritable piste d’audit est plus qu’un ensemble de fichiers journaux : c’est la chaîne complète de preuves qui relie l’activité utilisateur, les instructions SQL, les objets de la base de données et les horodatages de façon à soutenir l’investigation et la conformité. Les vues natives v_monitor fournissent les données brutes, mais des plateformes comme DataSunrise transforment ces données en une piste d’audit centralisée, lisible, avec une rétention et des rapports flexibles.
En combinant la journalisation native Vertica avec les capacités d’audit DataSunrise, les organisations obtiennent un enregistrement durable de l’activité des bases de données conforme aux réglementations sur la conformité des données et aux politiques de sécurité internes. Cela facilite à son tour la détection précoce des problèmes, la réponse confiante aux incidents, et la preuve que les informations sensibles stockées dans Vertica restent sous contrôle.
