La commande ANZAUDJRN

Le moment est venu de nous intéresser à l’interface de commande. En utilisant les paramètres de la commande DSPJRN comme point de départ, ajoutez des critères de sélection pour le type d’événement d’entrée, le nom de l’objet, le type et la bibliothèque ainsi que le nom de chemin d’accès IFS. Cela couvre la plupart des exigences prévues à l’origine, et l’ensemble des options du filtre d’entrée du journal d’audit facilitera considérablement le ciblage des entrées du journal présentant un intérêt particulier dans toute situation.

Pour fournir aussi un niveau spécifique de recherche générique, j’ai complété l’interface de commande par un paramètre final qui vous permet de spécifier une chaîne de caractères de longueur variable pour effectuer une comparaison par rapport à la partie Entry Specific Data (ESD) de l’entrée du journal d’audit. Vous pouvez soit spécifier un emplacement spécifique dans l’ESD sous la forme d’une valeur offset ou demander à la commande de scruter tout l’ESD pour l’argument de recherche donné. Vous pouvez voir l’interface de la commande Analyze Audit Journal (ANZAUDJRN) résultante dans la figure 5.

Alors que la plupart des paramètres de la commande ANZAUDJRN ont une relation de un à un avec les critères de sélection d’entrée offerts par l’API QjoRetrieveJournalEntries et par conséquent demandent un peu de réflexion, il y a d’autres préoccupations, y compris la plage disponible et valide des valeurs d’entrées de paramètres. Le paramètre Entry type de la commande appelle une source qui fournit la liste des codes de types d’entrée et leur description pour la release actuelle du système d’exploitation. Une telle liste offrirait une double base : pour vérifier l’entrée du paramètre du type d’entrée, mais aussi pour permettre de créer dynamiquement le texte choisi pour le paramètre et la fonction de liste F4, pour l’invite de commande. Ainsi, les utilisateurs de la commande pourraient plus facilement décider quelles sont leurs options et les valeurs correctes à entrer.

Les autres paramètres de commande, comme ceux qui concernent l’objet et le chemin, doivent être validés quant à leur présence dans l’ESD d’entrée du journal pour déterminer s’ils doivent être inclus dans l’invite de commande, selon le Type d’entrée entré réellement. Pour récapituler les exigences établies jusqu’ici, je dois déterminer ce qui suit :

• Quels types d’entrée du journal d’audit sont supportés pour la release en cours
• La description textuelle de chaque type d’entrée du journal d’audit
• La présence et l’emplacement dans l’ESD du type d’objet, du nom et de la bibliothèque
• La présence et l’emplacement dans l’ESD d’un nom de chemin d’accès d’objet IFS

Surmonter les obstacles

En ce qui concerne la première difficulté, il est indiqué dans l’annexe F du manuel « System i Security Reference » que, pour chaque type d’entrée du journal d’audit, il y a un fichier de modèles système correspondant, suivant la convention de nommage QASYxxJ5 pour les fichiers de sortie du format *TYPE5, où xx est remplacé par le type d’entrée. D’après cette information, il est possible d’utiliser l’API Open List of Objects (QGYOLOBJ) pour lister tous les fichiers QASYxxJ5 et extraire chaque type d’entrée pris en charge.

La description textuelle du type d’entrée nécessite aussi une sorte d’approche par « fonction non documentée ». Il se trouve que, par le passé, j’ai eu affaire à des descriptions de messages dans le fichier de messages QCPFMSG

Le système employé pour stocker à la fois les codes de journaux et les types d’entrées de journaux, ainsi que leurs descriptions textuelles respectives. Fort de cette connaissance, je peux utiliser l’API Retrieve Message Description (QMHRTVM) pour extraire la description du type d’entrée.

En vous fondant sur une observation antérieure, vous pouvez aussi résoudre le problème final consistant à trouver l’information d’objet dans l’ESD d’entrée du journal. Tous les formats de types d’entrées du journal d’audit figurent dans les fichiers de modèles système, et IBM a pris soin d’imposer une convention de nommage pour les champs définis dans les formats d’enregistrement. Les champs contenant le nom d’objet, la bibliothèque et le type, ainsi que le nom de chemin d’accès d’objet IFS, le CCSID du nom de chemin, et la longueur du nom de chemin, sont nommés en respectant le même modèle de nom. Le nom d’objet, la bibliothèque et le type donnent xxONAM, xxOLIB et xxOTYP, respectivement, où xx est (à nouveau) remplacé par le type d’entrée du journal supporté par le format de fichier en question. Lister les champs du format d’enregistrement d’un fichier ainsi que l’emplacement des champs dans le format d’enregistrement, est quelque chose dont l’API Retrieve database file description (QDBRTVFD) est parfaitement capable.