Bases de la sécurité IBM i pour l'administration : droits spéciaux, droits sur les objets, QSECURITY et QAUDJRN

Ce que c'est

Le contrôle d'accès d'IBM i comporte deux couches indépendantes. Les droits spéciaux (special authorities), attribués au moyen du paramètre SPCAUT d'un profil utilisateur, régissent des capacités valables pour tout le système plutôt que l'accès à un seul objet. *ALLOBJ (all-object) permet à un utilisateur d'accéder à n'importe quelle ressource du système, quels que soient les droits définis sur l'objet lui-même : même un objet explicitement réglé sur *EXCLUDE pour cet utilisateur devient accessible. En revanche, ce droit ne permet pas à lui seul de créer ou de modifier des profils utilisateur, ce qui exige le droit spécial distinct *SECADM (administrateur de la sécurité). Pour accorder *SECADM à quelqu'un d'autre, il faut posséder à la fois *ALLOBJ et *SECADM.

Les droits sur les objets (object authority) constituent la couche propre à chaque objet : ils déterminent qui peut lire, modifier ou gérer une bibliothèque, un fichier ou un programme donné. DSPOBJAUT affiche les personnes autorisées sur un objet (propriétaire, droits privés, *PUBLIC et éventuelle liste d'autorisation qui le protège) ; EDTOBJAUT modifie ces droits de façon interactive, tandis que GRTOBJAUT et RVKOBJAUT le font de façon non interactive. Une entrée *GROUP dans la colonne User de cet affichage signifie que le demandeur a obtenu l'autorisation sur l'objet par l'intermédiaire d'un profil de groupe, et non directement par son propre profil utilisateur. Il vaut la peine de le vérifier avant de conclure qu'un utilisateur n'a aucun moyen d'accéder à un objet.

La valeur système QSECURITY définit le niveau global d'application de la sécurité (20, 30, 40 ou 50, par ordre croissant de rigueur dans les versions actuelles ; le niveau 10 ne peut plus être défini). À partir du niveau 40, les programmes qui utilisent des interfaces non prises en charge ou qui présentent d'autres failles d'intégrité sont en outre rejetés. DSPSYSVAL QSECURITY affiche le niveau en vigueur ; une modification ne prend effet qu'au prochain IPL et constitue une action à fort impact, valable pour l'ensemble du système, qui relève d'une fenêtre de changement et non d'une tâche courante.

Le journal QAUDJRN est la piste d'audit de sécurité d'IBM i : les accès aux objets, les échecs d'autorisation, les modifications de profils et d'autres événements y sont consignés dès lors que le journal existe et que l'audit est activé par les valeurs système QAUDCTL et QAUDLVL (par exemple *AUTFAIL et *PGMFAIL pour journaliser les échecs d'autorisation et de programme). CHGSECAUD crée le journal si nécessaire et définit ces valeurs en une seule étape, sans passer par une configuration manuelle ; contrairement à QSECURITY, les modifications de ces valeurs système d'audit prennent effet sans IPL.

Pourquoi c'est important

Un agent qui effectue des tâches d'administration sur IBM i doit recourir au droit spécial le plus restreint permettant d'accomplir le travail (*SECADM seul pour la gestion des profils, plutôt que *ALLOBJ). Il doit aussi savoir que relever QSECURITY ou activer l'audit QAUDJRN sont des changements lourds de conséquences et soumis à traçabilité, et non de la configuration courante.

Comment l'appliquer

• Vérifier les droits spéciaux d'un profil (DSPUSRPRF) avant d'accorder *ALLOBJ ; se demander si un droit plus restreint (*SECADM, *JOBCTL, *SAVSYS, etc.) suffit.
• Utiliser DSPOBJAUT/EDTOBJAUT pour vérifier et définir les droits sur des objets précis, plutôt que de recourir par défaut à un accès *ALLOBJ pour contourner une erreur d'autorisation.
• Consulter DSPSYSVAL QSECURITY ainsi que la configuration de QAUDJRN/QAUDLVL avant de supposer ce qui est ou n'est pas journalisé.
• Traiter toute modification de QSECURITY, de QAUDCTL ou des droits spéciaux avec le même contrôle des changements qu'une modification de configuration en production.

Pièges

• Interpréter *ALLOBJ comme « peut tout faire », y compris administrer les profils : ce n'est pas le cas sans *SECADM.
• Supposer que QAUDJRN capture tout par défaut ; l'audit est optionnel et dépend des valeurs QAUDLVL configurées.
• Oublier que relever QSECURITY à 40 ou plus peut casser des programmes qui reposaient sur des failles d'intégrité tolérées par les niveaux inférieurs ; tester avant toute modification en production.