IBMi : l’autorité des objets

Nous avons déjà dit que tout ce qui est dans l’i est un objet et que chaque objet a une certaine structure et certaines règles à respecter. Et l’une de ces règles exprime les contraintes de l’autorité par défaut que cet objet suivra. En bref, qu’est-ce que le système permettra à un utilisateur (*PUBLIC) générique (autre que le propriétaire) de faire, en supposant qu’aucun autre privilège n’est accordé à cet utilisateur. Il y a quelques valeurs qui peuvent être attribuées.

Mais avant de parler de ces valeurs, voyons où elles sont attribuées. Il y a pas de commande CRTOBJ, bien entendu ; chaque type d’objet a sa propre commande CRT (par exemple, CRTPF, CRTLF, CRTDTAARA). Mais sur chacune de ces commandes, il y a un paramètre AUT, qui est l’endroit où ces valeurs sont spécifiées. Et vous savez ce qui est drôle ? Généralement, ce paramètre est le dernier de la commande et il n’est visible que moyennant F10 (oui, je suis un adepte de PDM et fier de l’être). Par conséquent, il y a beaucoup de chances pour que vous sélectionniez la valeur par défaut pour ce paramètre. Les valeurs possibles sont les suivantes :

*LIBCRTAUT : C’est la valeur par défaut utilisée dans n’importe quelle commande d’objet CRT (CRTPF, CRTDTAARA, etc.), et elle renvoie la décision à la valeur dans le paramètre CRTAUT de la bibliothèque dans laquelle l’objet est créé. Si vous examinez la commande CRTLIB, vous observerez que la valeur par défaut pour son paramètre CRTAUT est aussi *LIBCRTAUT, ce qui semble curieux. Mais tout cela est bon parce que la valeur par défaut dans la commande CRTLIB signifie qu’elle prend la valeur établie pour la bibliothèque IBM QSYS. Et si vous utilisez la commande DSPLIBD pour examiner QSYS, vous verrez que la valeur du paramètre CRTAUT est *SYSVAL. Vous suivez toujours ? Et si vous examinez *SYSVAL QCRTAUT, il est probablement réglé sur *CHG.

Bien entendu, vous n’êtes pas obligé d’utiliser la valeur par défaut. Vous pouvez spécifier ici votre propre valeur et choisir parmi les valeurs suivantes.

*EXCLUDE : L’utilisateur ne peut pas utiliser l’objet, et encore moins le changer. Vu sous l’angle de la sécurité pure, c’est ce que tout le monde aimerait utiliser, mais d’un point de vue pratique, votre système serait difficile à utiliser. Il faut être raisonnable.

*USE : Pour les fichiers, cela signifie que l’utilisateur peut accéder aux enregistrements. Pour tout autre objet (programmes, etc.), cela signifie que l’utilisateur peut s’en servir (c’est-à-dire l’exécuter). Mais il est clair que l’utilisateur ne peut pas changer l’objet ou ses attributs de sécurité. Certes, cette situation présentera quelques inconvénients pour l’équipe technique et les utilisateurs (parfois, la fonction que vous exécutez risque de supprimer des enregistrements ou d’effacer des fichiers, par exemple).

*CHANGE : Là encore, tout dépend du type d’objet. Pour les fichiers, l’utilisateur peut effacer, lire, même mettre à jour les enregistrements. Mais pour les objets de programme ou de commande, il peut uniquement les utiliser. Cette valeur ne permet jamais à l’utilisateur de supprimer un objet ou de changer ses attributs de sécurité.

*ALL : Ici, c’est très simple : l’utilisateur peut faire tout ce qu’il veut sur l’objet sauf pour les choses limitées au propriétaire ou contrôlées par des listes d’autorisations. Et, bien entendu, c’est exactement ce que tous les programmeurs jugent nécessaire pour faire leur travail.

En conclusion : Il est attribué à chaque objet une autorité par défaut qui indique ce qu’un utilisateur *PUBLIC est autorisé à lui faire, sans que l’utilisateur en question ait reçu des privilèges supplémentaires. En matière d’i sécurité, réfléchissez bien aux privilèges supplémentaires accordés à un utilisateur. Par exemple, un nombre important d’utilisateurs ou de programmes peuvent avoir besoin de supprimer ou d’effacer des fichiers—ce qui revient à avoir des droits « destructeurs » sur eux—et ce n’est pas forcément négatif. En fait, c’est parfois nécessaire.

Mais ne donnez pas ces droits à quelqu’un simplement parce que c’est pratique. Réfléchissez bien. Respectez le principe du moindre privilège : n’accorder que les privilèges dont une entité a besoin pour faire son travail, et pas plus. Et n’oubliez jamais que l’autorité par défaut ne s’applique que quand les listes d’autorisations n’entrent pas en jeu. Les listes d’autorisations (dont il sera question dans un futur article) vous permettent de grouper des objets ayant les mêmes exigences de sécurité et d’associer le groupe à une liste d’utilisateurs et d’autorités utilisateur. Elles ont priorité sur les autorisations de profils objet/utilisateur normales.