Comparer les points de sortie avec des déclencheurs de base de données

lue ou qu’un changement se produit dans la table, indépendamment de l’interface à l’origine du changement. Le principal objectif des déclencheurs de base de données est de superviser les changements de base de données au niveau des lignes et de mener à bien les tâches associées à ces changements. Si vous devez choisir entre le point de sortie ou les déclencheurs pour assurer votre sécurité, considérez les points suivants :

Administration. Le point de sortie est un paramètre global, à l’échelle du système. Vous devez l’établir dans un seul endroit et écrire le programme de sortie. Bien entendu, ce dernier doit être capable de traiter des tables multiples. Selon le nombre de tables que vous voulez soumettre au déclencheur, les déclencheurs de base de données peuvent demander plus d’intervention. En effet, il faut ajouter des déclencheurs pour chaque table que vous voulez auditer. En outre, si vous utilisez la commande CL AddPfTrg, il faut exécuter une commande séparée pour chaque type d’accès que vous voulez contrôler ou auditer : READ, UPDATE, INSERT et DELETE. (Cependant, le même programme peut être appelé pour chacun d’eux.) Pour effectuer des tâches d’audit, les deux méthodes vous demandent d’écrire des programmes et de créer les objets à l’appui.

Autorité au niveau objet. De la même manière que le point de sortie, les déclencheurs de base de données ne sont pas appelés si l’autorité au niveau objet empêche l’utilisateur d’accéder à la table.

Performance. Comme les déclencheurs sont généralement appelés pour chaque ligne traitée, ils peuvent dégrader davantage la performance. C’est particulièrement vrai si la requête traite de nombreuses lignes. En outre, les déclencheurs READ peuvent être très coûteux et doivent être utilisés avec prudence. Dans certains cas d’utilisation des déclencheurs READ, comme quand la requête contient des champs de groupage, il faut créer une copie temporaire de la table avant de traiter l’instruction. On l’a vu, le programme point de sortie n’est invoqué que quand un full open est demandé. Par rapport aux déclencheurs, le point de sortie a généralement moins d’invocations de programmes et moins de traitement.

Information fournie. Les déclencheurs ont l’avantage d’accéder aux données réelles dans l’événement soumis à l’audit. Dans le cas d’une mise à jour, l’image avant et après de la ligne est fournie au programme déclencheur. De son côté, le programme point de sortie est invoqué pendant un full open et ne fournit aucune information à propos de la ou des lignes faisant l’objet de l’accès.

Possibilité d’agir. Tout comme le point de sortie, les déclencheurs de base de données peuvent bloquer des tentatives d’accéder à la base de données et/ou effectuer d’autres tâches de workflow, tant que l’autorité au niveau objet n’empêche pas l’utilisateur d’accéder à la table. Pour bloquer l’accès, le programme déclencheur signale simplement une erreur pour empêcher que l’opération demandée ne se termine avec succès.

Le choix de la méthode dépendra beaucoup de vos besoins en matière d’audit. Certaines règles d’audit (telles que HIPAA) stipulent que les applications doivent journaliser chaque tentative d’accès à des bases de données sensibles, ainsi que le contenu des lignes faisant l’objet de l’accès. Dans un tel cas, seuls les déclencheurs satisferont à vos besoins d’audit. (Pour plus d’informations sur les déclencheurs de base de données, reportez-vous à l’IBM redbook Stored Procedures, Triggers and User Defined Functions on DB2 Universal Database for iSeries.) La figure 2 montre une comparaison résumée des méthodes d’audit.