Aller à  la racine (/Root) du sujet

et autorités objet OBJAUT (*ALL). Je recommande de définir DTAAUT (*RX) et OBJAUT (*NONE) pour le répertoire racine. Vous pourrez ainsi contrôler ce qui y est créé ou supprimé. De plus, les objets (comme les répertoires) que vous créerez ultérieurement sous root auront ce genre d’autorité publique.
Autrement dit, vous arrêtez la propagation d’un schéma de sécurité grand ouvert : c’est une bonne chose !

Avant d’utiliser CHGAUT, WRKAUT (Work with Authorities), ou la fonction Permissions dans iSeries Navigator, pour changer l’autorité sur le répertoire racine, il est bon de mener une petite enquête préalable. Plus précisément, il faut déterminer si des objets sont habituellement créés directement ou supprimés dans le répertoire racine. C’est souvent le cas avec une application ou un processus développé en interne. En effet, quand des développeurs ou des administrateurs n’ont pas déjà travaillé avec des répertoires, ils ne se rendront peutêtre pas compte qu’ils auraient dû créer un répertoire spécifique pour y travailler. Comme exemple d’un objet qui pourrait être couramment supprimé et recréé, on prendra un fichier stream qui contient des données « en transit », c’est-à-dire des données provenant d’un fichier base de données puis envoyées hors du site via FTP ou EDI vers un autre site, ou vers un partenaire : banque, fournisseur ou autre.

Parfois il est facile de déterminer si des objets sont créés directement dans le répertoire racine ou s’ils en sont supprimés. Pour le savoir, vous pouvez soit utiliser iSeries Navigator pour ouvrir le répertoire racine, soit exécuter la commande WRKLNK (Work with Object Link) et rechercher les fichiers stream ou autres objets listés parmi les répertoires sous root. En règle générale, leurs noms indiquent bien le processus auquel ils appartiennent (comme uploadtobank.stmf, orderdownload.stmf). En cas de doute, regardez la date de création et la date de dernière utilisation du fichier stream. Si vous utilisez la commande WRKLNK, utilisez l’option 8 (Display Attributes). Si vous utilisez iSeries Navigator, faites un clic droit sur l’objet et choisissez Properties. Une date au-delà de deux ans indique probablement qu’un programmeur a essayé un nouveau logiciel ou l’un des programmes exemples d’iSeries Network et n’a jamais nettoyé l’objet obsolète. Cependant, pour être certain qu’aucun processus n’est en train de créer des objets dans le répertoire racine, ou d’en supprimer, j’examine les entrées du journal d’audit. Mais, pour utiliser les entrées du journal d’audit à cet effet, les valeurs *CREATE et *DELETE doivent être spécifiées dans la valeur système QAUDLVL afin que le journal d’audit puisse générer les entrées qui m’intéressent. La valeur *CREATE génère une entrée du journal d’audit chaque fois qu’un nouvel objet est créé sur le système – même les objets dans l’IFS. De la même manière, la valeur *DELETE génère une entrée du journal d’audit chaque fois qu’un objet est supprimé Si vous n’avez jamais consulté des entrées du journal d’audit auparavant ou si vous n’en avez jamais consultées qui correspondent aux objets IFS, sachez que cette opération, bien que pas très difficile, comporte quelques étapes. J’ai pour habitude de transférer toutes les entrées dans un fichier de sortie et d’exécuter ensuite une requête simple pour obtenir l’information nécessaire. Si je ne recherchais pas des entrées d’audit pour des objets IFS, j’exécuterais simplement la commande DSPAUDJRNE (Display Audit Journal Entry). Toutefois, DSPAUDJRNE ignore les objets IFS : le seul moyen d’indiquer que vous recherchez une entrée correspondant à un objet IFS est que « *N » figure dans le champ Object Name. DSPAUDJRNE ne présente pas le nom de chemin d’accès de l’objet. Par conséquent, dans ce cas, DSPAUDJRNE ne nous est d’aucune utilité.

Pour trouver l’information nécessaire à mon enquête, je vais couvrir les étapes suivantes. Rappelons que l’objectif est de nous assurer que rien n’est créé ou supprimé dans le répertoire racine, afin de pouvoir réduire l’autorité *PUBLIC à l’autorité données *RX et l’autorité objet *NONE.

Premièrement, créez une copie du fichier de sortie modèle pour les entrées du journal d’audit CREATE (l’OS/400 offre un fichier de sortie modèle dans QSYS pour chaque type d’entrée du journal d’audit). Exécutez la commande suivante :

CRTDUPOBJ OBJ(QASYCOJ5) FROMLIB(QSYS)
OBJTYPE(*FILE) TOLIB(QTEMP)
NEWOBJ(QASYCOJ5)

Ensuite, exécutez la commande DSPJRN (Display Journal) pour le journal d’audit, en envoyant les résultats au fichier que vous avez créé avec la commande précédente :

DSPJRN JRN(QSYS/QAUDJRN) RCVRNG(*CURCHAIN)
FROMTIME(’07/15/05′) JRNCDE((T)) ENTTYP(CO)
OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5)
OUTFILE(QTEM/QASYCOJ5)

Une entrée de journal d’audit contient beaucoup d’informations dont une grande partie n’est pas pertinente pour cette enquête. C’est pourquoi j’exécute une requête, en sélectionnant les champs que montre la figure 2. Si je veux savoir en particulier quand le processus est exécuté, je sélectionne aussi le champ COTSTP (Timestamp). Comme je ne m’intéresse qu’aux entrées de l’IFS, je peux filtrer mon nom d’objet et n’obtenir que les entrées où le nom d’objet est *N, comme le montre la figure 3. Au moins cet indicateur sert à quelque chose !

La figure 4 montre les résultats fournis par ma requête (pour voir le nom de chemin complet, il vous faudra faire défiler l’affichage vers la droite). Si vos processus créent régulièrement les objets, et en suppriment, dans d’autres répertoires de l’IFS, vous verrez aussi les entrées concernant ces jobs, et votre rapport risque d’être très long. Si c’est le cas, je commence par éliminer (par filtrage) ces jobs « connus » en spécifiant le nom du programme ou du job dans mes critères de filtrage. Ainsi, la plupart des jobs connus seront éliminés et un rapide coup d’oeil me suffira pour vérifier si les entrées montrent qu’un objet est créé directement dans le répertoire racine. Vous savez cela parce que le nom de chemin est du genre /stream_file_name.stmf plutôt que /Application_Directory/stream_file_name.stmf. Pour analyser les entrées du journal d’audit à la recherche des objets supprimés, je répète l’opération avec une différence : je dois créer une copie du fichier modèle pour les suppressions (QASYDOJ5) et exécuter la commande DSPJRN en spécifiant DO pour le champ ENTTYP. Je répète ensuite l’opération qui consiste à écrire une requête et à supprimer l’activité « connue » jusqu’à pouvoir examiner facilement les entrées restantes. Toute cette opération ne dure pas plus de 30 minutes et donne l’assurance que rien de fâcheux ne se produira quand on réduira root à DTAAUT(*RX) et OBJAUT (*NONE).

Que se passe-t-il si je trouve un processus qui crée des objets, et/ou en supprime, directement dans le répertoire racine ? J’incite alors mon client à réécrire ce processus pour utiliser son propre répertoire au lieu du répertoire racine.

Pourquoi s’en préoccuper ? Tout simplement parce que le fait de laisser les processus travailler directement sous root est un peu comme si des applications OS/400 créaient leurs objets dans QSYS : cela ne se fait pas. La technique que je viens de décrire permet d’analyser et de sécuriser d’autres répertoires, pas simplement le répertoire racine.