Analyse du journal d’audit avec RPG

Votre journal d’audit système QAUDJRN contient énormément d’informations, à la condition d’être bien configuré. Son contenu révèle bien sûr l’activité système, mais recense aussi les tentatives éventuelles contre la sécurité du système et les contrôles d’accès.

Face à cette source complète d’informations d’audit et de sécurité et à l’impressionnante quantité de données souvent disponibles, le défi est évident : filtrer les événements et les actions intéressants pour les responsables de la sécurité système en général, et bien entendu pour les auditeurs système internes et externes en particulier. Cet article explique comment filtrer ces événements et actions à l’aide de notre commande favorite Analyze Audit Journal (ANZAUDJRN).

Outils d’audit embarqués

L’IBM i dispose de certains outils d’audit natifs sous la forme de commandes CL, y compris les commandes Display Journal (DSPJRN) et Display Audit Journal Entry (DSPAUDJRNE), en service depuis un certain temps, ainsi que la petite dernière : Copy Audit Journal Entry (CPYAUDJRNE). Elle est particulièrement utile pour mener une enquête, parce qu’elle établit la correspondance entre l’information qui se trouve dans la section de données spécifiques à l’entrée du journal et les champs de données individuels. A partir de là, vous pouvez interroger différents aspects : le type d’événement d’entrée, le nom, la bibliothèque, le type d’objet associé à l’entrée du journal et d’autres informations spécifiques à l’entrée.

Comme son nom l’indique, la commande CPYAUDJRNE copie l’information extraite dans un fichier de sortie que vous devez traiter à l’aide de Query/400 ou d’un outil similaire, ce qui transforme l’enquête en une procédure à deux étapes. Par ailleurs, la commande CPYAUDJRNE est dépourvue de certains des paramètres de DSPJRN, ce qui élimine la possibilité d’exclure d’emblée des entrées du journal basées sur, par exemple, le nom du job ou le nom du programme. Ce qui me fascine dans ce genre de situation, c’est que le kit d’outils complet de l’IBM i me permet de concevoir et de créer facilement les utilitaires qui correspondent à mes besoins précis et ce, à moindre frais. Il suffit de posséder le compilateur ILE RPG et le manuel API.

Cela dit, pour traiter des entrées de journal, il existe d’autres moyens que les API. Pour effectuer ce traitement en temps réel, j’ai souvent utilisé la commande Receive Journal Entry (RCVJRNE) qui permet d’extraire et de traiter les entrées du journal dès qu’elles arrivent dans le récepteur. Il existe aussi une commande Retrieve Journal Entry (RTVJRNE) dont le rôle est d’extraire les entrées du journal dans un programme CL. Cependant, si l’on veut spécifier un sous-ensemble arbitraire d’entrées du journal, l’API Retrieve Journal Entries (QjoRetrieveJournalEntries) est difficile à battre, à deux égards : le jeu de paramètres complet qu’elle offre et la vitesse à laquelle elle traite et renvoie les entrées du journal sélectionnées.

Documentation API — Au premier et second coups d’oeil

Au premier coup d’oeil, les paramètres de l’API QjoRetrieveJournalEntries (figure 1) semblent tout à fait surmontables. C’est le second coup d’œil qui impressionne quelque peu quand vous essayez de vous y retrouver dans le paramètre de longueur variable de la sélection d’entrée Journal entries to retrieve, avec toutes ses sous-structures facultatives. Pourtant, en utilisant ce paramètre, vous pourrez spécifier les mêmes critères de sélection que ceux des commandes DSPJRN et RCVJRNE. Sur l’IBM i 5.4, cela représente 22 critères de sélection d’entrée facultatifs, et en 6.1, 23.

Après avoir lu et compris la documentation, vous verrez qu’il est plutôt simple de coder à la fois le prototype API et les structures de données des paramètres de sélection d’entrée, grâce à la cohérence des structures de paramètres de longueur variable. La figure 2 affiche le prototype d’API QjoRetrieveJournalEntries et la figure 3 les structures de données définissant le jeu de paramètres de sélection d’entrée. Le fait de coder les structures de données de sélection d’entrée de cette manière permet d’introduire et de retirer facilement chaque critère de sélection d’entrée individuel. La figure 4 montre comment l’appel d’API est effectué et (on l’espère) démontre l’affirmation ci-dessus.

Notez aussi l’utilisation, par la documentation API, du terme omissible concernant le cinquième et le sixième paramètre d’API. Pour que le prototype soit conforme au comportement de l’API, vous devez utiliser le mot-clé Options avec la valeur spéciale *Omit for these parameters — par opposition à la convention plus couramment employée des groupes de paramètres optional définis par Options(*NoPass). Cette dernière implique que vous pouvez simplement ignorer le paramètre sur l’appel d’API, mais, dans ce cas, aucun autre paramètre appartenant au même groupe ou aux groupes de paramètres facultatifs suivants ne peut être spécifié. Pour les paramètres omissibles, vous devez spécifier la valeur spéciale *Omit in place of the parameter, ce qui permet d’autoriser les paramètres suivants, indépendamment de celui qui a été omis.