Comment auditer Teradata

Cet article présente une approche structurée de l’audit dans Teradata. Il explique comment activer et ajuster les fonctionnalités natives — Journalisation d’Accès et Journalisation des Requêtes en Base de Données (DBQL) — et comment les exploiter efficacement avec une portée appropriée, un contrôle de la charge et une conservation adaptée.

Il décrit également comment étendre l’audit natif avec DataSunrise afin de centraliser la visibilité à travers les environnements, corréler les événements pour les investigations, fournir des alertes rapides aux équipes opérationnelles et de sécurité, et produire des rapports répétables prêts pour l’audit à grande échelle.

Qu’est-ce que l’audit ?

Un audit est la capture structurée de qui a fait quoi, quand, d’où, et avec quel résultat — stockée comme preuve fiable. Dans les bases de données, il relie les identités et rôles aux opérations sur les données, enregistre le contexte de chaque action (heure, client, IP, session, outil), et conserve le résultat (autorisé ou refusé, lignes lues ou modifiées, erreurs). Un bon audit ne se limite pas à l’enregistrement des activités ; c’est une gestion des preuves dirigée par des politiques qui permet la responsabilité, l’investigation et la conformité réglementaire.

Les audits efficaces partagent des caractéristiques clés : exhaustivité (aucun vide pour les objets sensibles), fidélité (texte SQL original et références aux objets), provenance (tables et vues source de vérité claires), intégrité (stockage inviolable avec sommes de contrôle), et conservation adaptée à la politique. Dans Teradata, ces preuves proviennent de deux piliers natifs : la Journalisation des Requêtes en Base de Données (DBQL) pour le contexte des requêtes et la performance, et la Journalisation d’Accès pour les résultats des vérifications de privilèges. Utilisés ensemble, ils créent une piste d’audit défendable à laquelle les équipes de sécurité, d’exploitation et de conformité peuvent faire confiance.

Pour aligner la conception de l’audit avec les exigences de gouvernance, examinez vos contrôles en les comparant à la Conformité des Données et aux directives plus larges de la Conformité Réglementaire. Pour des concepts et exemples spécifiques à Teradata, consultez Qu’est-ce que la piste d’audit Teradata et Historique d’activité de la base de données Teradata. Pour centraliser la surveillance sur plusieurs plateformes, explorez La Surveillance des Activités des Bases de Données.

• Portée. Priorisez les schémas régulés et les identités privilégiées ; capturez à la fois les accès réussis et les refus pour une responsabilité complète.
• Preuves. Corrélez le contexte DBQL avec les résultats de la Journalisation d’Accès ; conservez les références SQL/objets originales pour préserver la fidélité.
• Intégrité et conservation. Déchargez régulièrement et stockez les preuves de manière immuable avec des sommes de contrôle ; documentez les versions de règles et les cadences de révision.

Des recherches indépendantes soulignent l’enjeu : l’usage abusif des bases de données et les accès non autorisés restent des vecteurs majeurs de violation ; consultez la dernière analyse IBM Security dans le Rapport sur le Coût d’une Violation de Données pour un benchmarking externe.

Outils natifs pour auditer Teradata

Journalisation des Requêtes en Base de Données (DBQL)

DBQL enregistre qui a exécuté une requête, quand elle a été exécutée, les métriques de performance (CPU/I/O), et — si activé — le texte SQL et les objets référencés. Les administrateurs contrôlent la portée et le détail avec les commandes BEGIN/REPLACE/END QUERY LOGGING et les options WITH/LIMIT. Les données journalisées sont accessibles via des objets dictionnaire comme DBC.DBQLogTbl et les vues associées.

Activation et réglage

-- Conserver le texte SQL et les références d’objets pour un utilisateur sensible
BEGIN QUERY LOGGING WITH SQL, OBJECTS ON USER secure_user;

-- Contrôler le volume sur les systèmes chargés (journaliser uniquement les requêtes coûteuses)
BEGIN QUERY LOGGING LIMIT THRESHOLD = 100 CPUTIME ON ALL;

-- Afficher ou terminer les règles
SHOW QUERY LOGGING ON ALL;
END QUERY LOGGING ON USER secure_user;

DBQL peut aussi enregistrer les plans d’optimiseur dans DBC.DBQLXMLTbl lorsque des analyses approfondies sont nécessaires.

Journalisation d’Accès

La Journalisation d’Accès enregistre le résultat de chaque vérification de privilège sur un objet protégé ou une opération (par exemple, accès à une table ou GRANT). Les événements sont exposés via AccessLogV/AccLogTbl et peuvent inclure le texte de la requête si activée avec WITH TEXT.

Activation et revue

-- Journaliser l’activité GRANT et conserver le texte des requêtes
BEGIN LOGGING WITH TEXT ON EACH USER, DATABASE, GRANT;

-- Portée par base de données (tous les objets sous finance_db)
BEGIN LOGGING WITH TEXT ON EACH DATABASE finance_db;

-- Inspecter les résultats
SELECT TOP 100 *
FROM DBC.AccessLogV
ORDER BY LogDate DESC, LogTime DESC;

La syntaxe exacte peut varier selon la version et la portée (BY USER/ALL, TABLE vs DATABASE). Utilisez les modèles officiels BEGIN LOGGING adaptés à votre version.

Revue et gestion des logs

• Utilisez QryLogV/DBQLogTbl pour le contexte des requêtes et la performance, et AccessLogV pour les résultats autorisés/refusés.
• Déchargez et résumez régulièrement avec PDCR (Collecte et Reporting des Données de Performance) pour éviter la surcharge du dictionnaire et conserver l’historique pour analyse.

Améliorer les audits avec DataSunrise

Surveillance centralisée des activités

DataSunrise consolide les événements Teradata dans une timeline unique et normalisée et les corrèle avec le contexte tel que utilisateur/rôle, application cliente, IP source, session, hash de requête, et objets référencés. Les analystes peuvent pivoter selon l’acteur, l’objet ou la période, explorer le SQL original (lorsqu’il est capturé), et comparer des requêtes similaires entre environnements. Les flux d’événements peuvent être transférés vers des plateformes SIEM tandis qu’un historique complet et interrogeable reste disponible pour les enquêtes. Les politiques d’ingestion et filtres maintiennent une faible charge sans sacrifier la qualité des preuves.

Règles d’audit granulaires

Les règles définissent quoi capturer, quand le capturer, et à quel niveau de détail. Composez des conditions par utilisateur ou rôle, chemin d’objet (base.table), type d’opération (SELECT/INSERT/UPDATE/DELETE/DDL), zone réseau, outil client, et horaire. Utilisez des exceptions pour les comptes de service de confiance et définissez des seuils pour les requêtes « longues » ou « coûteuses » afin de réduire le bruit. Versionnez les règles, testez-les en brouillon ou en mode simulation, et validez-les par approbation pour garantir l’auditabilité des changements. Alignez les ensembles de règles à des contrôles spécifiques (par exemple, « capturer tout DDL sur les schémas régulés après les heures ouvrées ») afin de maintenir une cartographie claire politique/preuve.

Analytique comportementale et alertes

DataSunrise profile le comportement typique par utilisateur, application et objet, puis met en évidence les écarts : accès inhabituels hors horaires, pics soudains de lectures de lignes, outils clients atypiques ou localisations source inattendues. Les alertes contiennent le contexte nécessaire au triage — qui, quoi, où, quand, et la capture de preuves pertinente — pour que les intervenants puissent agir sans corrélation manuelle. Les politiques de gravité, routage et déduplication préviennent la fatigue des alertes et assurent que les signaux à haute valeur atteignent les canaux SOC, outils de suivi ou systèmes de chat avec des métadonnées cohérentes.

• Les lignes de base s’adaptent à la saisonnalité et aux charges de travail ; chaque alerte porte un score de risque et des liens vers les preuves correspondantes.
• Les cibles de livraison incluent SIEM/SOAR, Slack/Teams, email et webhooks avec JSON structuré ; le throttling et la déduplication évitent les tempêtes d’alertes.
• Le triage automatisé joint les dernières N requêtes, différences d’objets et enrichissements géo/IP ; les playbooks ouvrent des tickets, alertent les responsables et capturent les retours pour améliorer les détections futures.

Pilote automatique de conformité et rapports

Des packs de rapports préconstruits associent les preuves d’audit aux cadres communs (RGPD, HIPAA, PCI DSS, SOX). Des plannings génèrent périodiquement des preuves avec des checklists de contrôle, identifiants de politiques et signatures des réviseurs. Les rapports réfèrent aux emplacements de stockage immuables et incluent des sommes de contrôle pour vérifier l’intégrité. L’historique des modifications — qui a modifié une règle, quand, et pourquoi — figure aux côtés des résumés d’activité pour faciliter les revues d’audit. Le résultat est une documentation répétable et défendable sans exports ad hoc ni scripts ponctuels.

• La cartographie des contrôles inclut des résumés pass/échec, des notes de portée et des liens directs vers les événements et politiques support.
• La planification produit des ensembles de preuves mensuels/trimestriels vers WORM/S3 Object Lock avec des sommes SHA-256 et une rétention définie.
• Le flux de travail d’audit supporte les approbations, attestations, masquage des champs non essentiels, et export en PDF/CSV/JSON ou intégration API avec des outils GRC.

Tableau comparatif

Conclusion

Commencez avec DBQL pour le contexte et la Journalisation d’Accès pour les résultats d’autorisation. Corrélez-les dans une vue unique et prévisible, et déchargez régulièrement avec PDCR. Ajoutez DataSunrise lorsque vous avez besoin d’une visibilité centrale, d’une capture précise, d’une détection en temps réel, et de rapports auditables et répétables à grande échelle.

Pour l’alignement des politiques et la conservation des preuves, consultez les ressources suivantes : Conformité des Données et Conformité Réglementaire.

Lectures complémentaires pour approfondir votre stratégie d’audit Teradata :

• Qu’est-ce que la piste d’audit Teradata — concepts, portée, et modèles communs de preuves.
• Historique d’activité de la base de données Teradata — modèles pour la surveillance à haut volume et le triage.
• Surveillance des activités des bases de données — visibilité centralisée et corrélation multi-plateformes.