QAUDJRN, reporting sur les événements sécurité

Une fois que vous avez démarré l'audit avec QAUDLVL *SECURITY, vous pouvez commencer à présenter les événements au fur et à mesure qu'ils se produisent.

Vous pouvez écrire un programme qui reçoit les entrées de journal QAUDJRN au moment où elles y sont écrites, ou, cas le plus fréquent, vous pouvez écrire un programme qui imprimera le rapport d’activité a posteriori.

QAUDJRN, reporting sur les événements sécurité

Pour extraire les entrées de journal en temps réel, vous disposez de la commande CL Receive Journal Entry (RCVJRNE). Dans ce cas, un programme de sortie écrit par vous reçoit les données d’entrée de journal et les interprète pour déterminer une action éventuelle. Pour plus d’informations sur la commande RCVJRNE, visitez le IBM information Center.

L’un des types d’événements que vous pouvez présenter dans la catégorie *SECURITY est celui où un attribut de service ou une valeur système a été changé(e). Comme le montre le tableau ci-dessous, ces événements sont enregistrés avec le type d’entrée de journal SV. SV est aussi utilisé pour montrer les changements apportés à l’horloge système.

**Evénements sélectionnés audités quand *SECURITY est spécifié dans la valeur système QAUDLVL**

Type d’entrée	Événements associés
AD	L’audit d’un DLO a été changé avec la commande CHGDLOAUD L’audit d’un objet a été changé avec les commandes CHGOBJAUD et CHGAUD Un changement d’attribut scan avec la commande CHGATR ou l’API Qp01Set Attr L’audit pour un utilisateur a été changé avec la commande CHGUSRAUD
CA	Changements à la liste d’autorisations ou à l’autorité sur les objets
CP	Créer, changer ou restaurer le fonctionnement du profil utilisateur quand l’API QSYRESPA est utilisée
CV	Connexion établie Connexion terminée normalement Connexion rejetée
DO	L’objet a été supprimé, mais pas sous contrôle d’engagement Une suppression d’objet en suspens a été engagée Une création d’objet en suspens a fait l’objet d’un retour arrière (rollback) La suppression d’objet est en suspens (la suppression a eu lieu sous contrôle d’engagement) Une suppression d’objet en suspens a fait l’objet d’un retour arrière (rollback)
DS	Une requête pour redéfinir le mot de passe DST QSECOFR à la valeur par défaut fournie par le système Un changement de profil Dedicated Service Tools (DST)
GR (Related to WRKREGINF)	Un programme de sortie a été ajouté Un programme de sortie a été enlevé Opération d’enregistrement de fonction Un programme de sortie a été remplacé
JD	Le paramètre USER d’une description de job a été changé
NA	Un attribut de réseau a été changé
OW	La propriété (ownership) d’un objet a été changée
PA	Un programme a été changé pour adopter l’autorité du propriétaire
PG	Le groupe primaire pour un objet a été changé
PS	Un handle de profil a été généré au moyen de l’API QSYGETPH (Swap Profile)
SE	Une entrée de routage de sous-système a été changée
SV	Une valeur système a été changée Un attribut de service a été changé Un changement a été apporté à l’horloge système

Quand vous voulez produire un rapport journalier ou hebdomadaire des changements apportés à certains de ces éléments, vous devez d’abord extraire les entrées de journal SV dans un format adapté à votre processus de requête ou de reporting.

Pour chaque type de journal, IBM a fourni un modèle de fichier base de données qui vous permet de formater facilement les données en utilisation conjointe avec la commande Display Journal (DSPJRN) fournie par IBM.

Comme on l’a vu dans les articles précédents de cette série, vous créez d’abord un double du fichier modèle fourni par IBM. Ici, choisissez le fichier modèle pour le type d’entrée de journal SV, par cette commande :

CRTDUPOBJ OBJ(QASYSVJ5) FROMLIB(QSYS) OBJTYPE(*FILE) TOLIB(MYLIB) NEWOBJ(SV_MODEL)

Le fichier modèle est nommé QASYSVJ5, où SV est le type d’entrée de journal.
Ensuite, exécutez la commande DSPJRN, en spécifiant que vous voulez extraire toutes les entrées SV et que vous voulez placer la sortie dans votre copie du fichier de sortie modèle SV :

DSPJRN JRN(QAUDJRN) RCVRNG(*CURRENT) JRNCDE((T)) ENTTYP(SV) OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5) OUTFILE(MYLIB/SV_MODEL) OUTMBR(*FIRST *REPLACE)

La figure 2 (voir l’article dans le Club Abonnés) montre la disposition du fichier de sortie modèle pour les entrées SV, qui identifient les changements suivants : attributs de service, valeurs système et horloge système. Au terme de la commande DSPJRN, votre fichier de sortie contiendra les données formatées provenant de chaque entrée de journal SV. Le champ nommé SVSYSV contient le nom de l’attribut de service ou de la valeur système qui a été changé(e). Les champs SVNVAL et SVOVAL contiennent la nouvelle et l’ancienne valeur, respectivement. Si l’une d’elles dépasse 250 caractères, elle déborde dans les champs SVNCVL et SVOCVL. Le champ SVUSPF contient le nom de l’utilisateur courant du job, auteur du changement.

Plusieurs autres champs sont intéressants pour votre reporting. Par exemple, timestamp, job user, job name, et job number (tampon horodateur, utilisateur, nom et numéro du job). Si le changement a été effectué à partir d’une session de station de travail interactive, le nom du job est celui de la station de travail.

Vous pouvez aussi présenter le nom du programme qui a servi à effectuer le changement. Si ce dernier a été effectué à partir d’une ligne de commande, le nom du programme sera QCMD ou un autre des programmes ligne de commande. Si le changement a été effectué à l’aide de vos propres programmes RPG ou CL, ce nom de programme apparaîtra dans le fichier de sortie. Vous pouvez aussi présenter l’adresse IP à partir de laquelle le changement a été effectué. La figure 2 contient chaque élément disponible de l’information enregistrée.

Une fois les données de journal dans le bon format, c’est-à-dire dans le fichier de sortie, vous pouvez écrire votre propre programme de reporting ou utiliser Query ou SQL pour présenter le contenu. Vous pouvez aussi tout simplement transférer le fichier dans Microsoft Excel pour le triturer à votre gré.

À la prochaine fois

J’espère que cet article vous a appris comment maîtriser les activités liées à la sécurité qui affectent votre système. Dans le prochain et dernier article de cette série sur l’analyse approfondie, j’examinerai comment auditer et présenter les changements apportés aux bases de données. Cependant, je n’utiliserai pas le journal QAUDJRN. Je traiterai le sujet de la journalisation de la base de données DB2 for i sur l’IBM i, et expliquerai comment extraire des données intéressantes d’un journal de base de données pour savoir « qui donc a modifié cet enregistrement de la base de données ? «