Comment auditer l'activité de la base de données sans problèmes de performances et d'évolutivité?

Question

J'ai besoin de vérifier toutes les activités de base de données, qu'elles proviennent d'une application ou d'une personne qui a publié un fichier SQL par d'autres moyens. L'audit doit donc être effectué au niveau de la base de données. La base de données en question est Oracle. J'ai envisagé de le faire via des déclencheurs et également via quelque chose appelé Audit fin grainé fourni par Oracle. Dans les deux cas, nous avons activé l'audit sur des tables et des colonnes spécifiques. Cependant, nous avons constaté que les performances sont vraiment nul lorsque nous utilisons ces méthodes.

L'audit étant une nécessité absolue en raison de la réglementation en matière de confidentialité des données, je me demande quel est le meilleur moyen de le faire sans dégrader de manière significative les performances. Si quelqu'un a une expérience spécifique d'Oracle dans ce domaine, cela sera utile, mais sinon, les pratiques générales relatives à l'audit de l'activité de base de données seront également acceptables.

Answer 1

Je ne suis pas sûr que ce soit une approche suffisamment mature pour une production système, mais j'ai eu beaucoup de succès avec la base de données de surveillance le trafic à l'aide d'un renifleur de trafic réseau.

Envoyer les données brutes entre l'application et la base de données à un autre machine et décoder et analyser là-bas.

J’ai utilisé PostgreSQL, puis décodé et transformé le trafic en un flux d'opérations de base de données pouvant être consignées était relativement simple. J'imagine que cela fonctionnerait sur n'importe quelle base de données où le paquet le format est documenté cependant.

Le point principal était qu’il n’imposait aucune charge supplémentaire à la base de données elle-même.

De plus, c’était une surveillance passive, elle enregistrait toute l’activité, mais ne pouviez pas bloquer les opérations, alors peut-être pas tout à fait ce que vous cherchez.

Answer 2

Il n’est pas nécessaire de "créer votre propre". Activez simplement l'audit:

1. Définissez le paramètre de base de données AUDIT_TRAIL = DB.
2. Démarrer l'instance.
3. Connectez-vous avec SQLPlus.
4. Entrez l'instruction

   audit all;

   Ceci active l'audit pour de nombreuses opérations DDL critiques, mais DML et certaines autres instructions DDL ne sont toujours pas auditées.
5. Pour activer l'audit sur ces autres activités, essayez des instructions telles que:

   audit alter table; -- DDL audit
   audit select table, update table, insert table, delete table; -- DML audit

Remarque: tous "as sysdba" l'activité est TOUJOURS auditée auprès du système d'exploitation. Sous Windows, cela signifie le journal des événements Windows. Sous UNIX, il s’agit généralement de $ ORACLE_HOME / rdbms / audit.

Découvrez le Audit Oracle 10g R2 Chapitre de la référence de base de données SQL.

Le journal d'audit de la base de données peut être affiché dans la vue SYS.DBA_AUDIT_TRAIL.

Il convient de noter que l’audit interne Oracle sera performant par définition. Il est conçu pour être exactement cela, et il est très difficile d’imaginer quoi que ce soit qui puisse rivaliser avec lui pour la performance. En outre, il existe un degré élevé de "grain fin" contrôle de l'audit Oracle. Vous pouvez l'obtenir aussi précisément que vous le souhaitez. Enfin, la table SYS.AUD $ et ses index peuvent être déplacés vers un espace de table séparé pour éviter de remplir l'espace de table SYSTEM.

Cordialement, Opus

Answer 3

Si vous souhaitez enregistrer des copies des enregistrements modifiés sur un système cible, vous pouvez le faire avec Golden Gate Software et éviter ainsi beaucoup de pertes de ressources côté source. De plus, vous n'avez aucune modification à apporter à la base de données source pour implémenter cette solution.

Golden Gate élimine les journaux de restauration pour les transactions faisant référence à une liste de tables qui vous intéressent. Ces modifications sont écrites dans un "fichier de chemin" et peuvent être appliquées à un autre schéma de la même base de données ou expédiées à une cible. système et appliqué à cet emplacement (idéal pour réduire la charge de votre système source).

Une fois que le fichier journal est envoyé au système cible, des modifications de configuration vous permettent de définir une option d'audit et, si nécessaire, d'appeler 2 fonctions Golden Gate pour obtenir des informations sur la transaction:

1) Définissez le paramètre INSERTALLRECORDS Replication pour insérer un nouvel enregistrement dans la table cible pour chaque opération de modification apportée à la table source. Attention, cela peut prendre beaucoup de place, mais si vous avez besoin d'un audit complet, c'est probablement ce que vous attendez.

2) Si vous ne possédez pas déjà CHANGED_BY_USERID ni CHANGED_DATE attachés à vos enregistrements, vous pouvez utiliser les fonctions Golden Gate du côté cible pour obtenir ces informations pour la transaction en cours. Découvrez les fonctions suivantes dans le Guide de référence GG: GGHEADER ("USERID") GGHEADER ("TIMESTAMP")

Donc, non, ce n’est pas gratuit (nécessite une licence par Oracle), et nécessitera quelques efforts de spin-up, mais probablement moins d’effort / de coût que la mise en place et la maintenance d’une solution personnalisée évoluant à votre guise, et vous aurez l’avantage supplémentaire de l'envoi des données vers un système distant afin que vous puissiez garantir un impact minimal sur votre base de données source.

Answer 4

si vous utilisez oracle, il existe une fonctionnalité appelée CDC (Capture Data Change) qui constitue une solution plus performante en termes de performances pour les types d'audit requis.