> Tech > 4. Audit interactif du niveau d’objet DB2

4. Audit interactif du niveau d’objet DB2

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

L'audit du niveau d'objet OS/400 permet aux administrateurs de savoir quels utilisateurs ont manipulé un ensemble d'objets. Les administrateurs peuvent à  posteriori examiner les données d'audit et procéder aux ajustements appropriés : autorités des profils utilisateur, applications ou autres. C'est un bon moyen pour renforcer la sécurité des données et

4. Audit interactif du niveau d’objet DB2

des applications
mais, malheureusement, après
que la sécurité ait été mise en péril.
La V5R3 a introduit le programme
de sortie Open Database File (QIBM_
QDB_OPEN), non seulement pour
fournir une liste d’audit d’accès à  la
base de données mais aussi pour permettre
de rejeter conditionnellement
l’accès à  la base de données. Le programme
de sortie Open Database File
est appelé chaque fois qu’un job ouvre
un fichier base de données (c’est-à dire,
une table) et ce que la requête
ouverte soit émise directement (par
un programme RPG ou Cobol) ou indirectement
(par une consultation ou
requête SQL, par exemple). Si le programme de sortie juge qu’il ne devrait pas accorder l’accès
au fichier, il peut créer un code de renvoi qui ordonne à 
DB2 de rejeter la requête ouverte. Cette possibilité de rejeter
conditionnellement une requête ouverte confère à  ce nouveau
programme de sortie un avantage par rapport à  l’audit
au niveau objet.
Le programme de sortie Open Database File se voit transmettre
la même information de job et profil utilisateur qui se
trouve dans le journal d’audit au niveau objet. En outre, le
programme de sortie se voit transmettre une liste de fichiers
(par exemple, une requête jointe ouvre de multiples fichiers)
référencée dans la requête ouverte et les options ouvertes
pour cette requête (lire des lignes, ajouter de nouvelles
lignes, par exemple). Un paramètre d’option de consultation
de base de données est également transmis au programme
de sortie. Si le fichier n’est ouvert que pour une opération de
lecture, le programme de sortie peut faire la distinction entre
une application HLL ouvrant le fichier pour lire les données
et une consultation ouvrant le fichier pour lire les données).
Dans un environnement client, un utilisateur final pourrait
parfaitement utiliser une application pour lire dans une
table contenant des données sensibles, parce que c’est l’application
qui contrôle et restreint l’accès aux dites données.
En revanche, si ce même utilisateur final utilise Query/400 ou
un rapport SQL pour accéder directement à  cette même
table, il y a danger parce qu’il pourrait alors accéder à  beaucoup
plus de données que l’application n’en autorisait.
Dans un tel cas, le programme de sortie peut utiliser le
paramètre Database Query pour permettre à  cet utilisateur
d’accéder à  une table sensible quand la requête ouverte
émane d’une application. En revanche, quand la requête ouverte
provient d’une consultation, le programme de sortie
peut rejeter la requête. Comme le profil utilisateur est transmis
comme un paramètre d’entrée, le programme
de sortie a aussi la liberté d’approuver
et de rejeter les requêtes pour tel ou tel
utilisateur ou pour tous.
Seules les opérations d’ouverture complètes
provoquent un appel vers le programme
de sortie. Par conséquent, celui-ci
n’est pas informé quand des applications effectuent
une ouverture partagée ou quand
une instruction SQL est exécutée avec une
pseudo-ouverture. En principe, dans un job,
seule la première ou la seconde exécution d’une instruction
SQL effectue une ouverture complète ; les exécutions suivantes
utilisent une pseudo-ouverture, ou ouverture réutilisable,
pour accélérer l’opération. Le programme de sortie
n’est pas non plus appelé quand des fichiers dans QTEMP ou
dans des bibliothèques système, comme QSYS2 ou SYSIBM,
sont ouverts.
Quand vous créez votre programme de sortie, vous
devez le faire avec *CALLER comme valeur de groupe d’activation.
Si vous le faites avec *NEW comme valeur de groupe
d’activation, le programme de sortie risque de provoquer la
fin des jobs chaque fois qu’une requête ouverte inclut des
fonctions définies par l’utilisateur.
Vous trouverez d’autres informations sur le programme
de sortie Open Database File dans l’iSeries InfoCenter (publib.
boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.h
tm?info/apis/xopendbf.htm). Bien que le programme de sortie
Open Database File permette de mieux sécuriser vos
données, il ne saurait remplacer un système de sécurité au
niveau objet. En fait, il vaut mieux utiliser ce nouveau programme
de sortie pour ajouter une couche de sécurité
autour des données et pour pouvoir rejeter conditionnellement
l’accès aux bases de données. Bien entendu, il faut
aussi évaluer soigneusement la quantité de traitement
qu’effectue le programme de sortie, pour minimiser une
éventuelle dégradation des performances système.

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010