Les types d’autorité IBM i

Il n’est pas question ici du niveau de sérieux de l’autorité, mais plutôt de savoir où regarder pour voir si l’on possède le niveau d’autorité nécessaire ; autrement dit, qui sont ceux qui « dispensent » l’autorité.

Par exemple, dans la vie de tous les jours, vous vous demandez peut-être si vous avez le droit d’élever des hamsters puis de les dresser pour le combat. Vous pouvez consulter, dans l’ordre : les décrets municipaux, les arrêtés préfectoraux, enfin la Loi.

Dans le même esprit, cinq points de vérification différents déterminent si vous avez le droit d’accéder à l’objet de vos rêves. Bien entendu, ces cinq points sont hiérarchisés pour savoir dans quel ordre le système les examine. Ce point sera couvert plus loin dans cet article. Pour l’instant, nous allons les aborder dans un ordre différent : celui que je préfère et qui me semble plus naturel.

Autorité publique

Quand on parle d’autorité publique, c’est généralement sur un ton peu flatteur, comme quelque chose à éviter ou à redouter. Mais qu’est-ce en réalité ? Tout simplement, l’autorité publique est l’autorité par défaut dont dispose un utilisateur en l’absence de toute autre autorité. Pour être plus précis, elle est intégrée dans l’objet au moment où celui-ci est créé, elle pourrait être changée mais ne le sera probablement pas, et n’a rien à voir avec vous (ou plutôt avec votre profil utilisateur). Par conséquent, le degré d’autorité publique pour un objet est le même, indépendamment de la personne.

L’autorité publique est définie dans le paramètre AUT de la commande create object (quelle qu’elle soit). Bien que vous puissiez la définir vous-même, comme nous l’avons vu dans l’article du mois dernier, elle sera généralement définie par défaut. Et si vous remontez la piste, elle provient le plus souvent des valeurs système (QCRTAUT).

Voici donc le premier point d’autorité (mais, comme nous le verrons, ce n’est pas le premier que l’algorithme de sécurité examine ; c’est juste le premier point d’autorité qui me vient toujours à l’esprit). L’autre terme que vous verrez souvent est autorité privée. Si l’autorité publique est l’autorité attachée à l’objet indépendamment de l’utilisateur qui y accède, l’autorité privée est celle qui vous a été spécifiquement accordée sur l’objet, généralement par une commande Grant Object Authority (GRTOBJAUT).

Donc, l’autorité publique ne concerne que l’objet. L’autorité privée est celle que quelqu’un ou quelque chose vous a donnée, en tant qu’utilisateur spécifique et très spécial, un certain niveau d’autorité sur un objet bien précis (même si cette autorité est EXCLUDE). Elle est différente des privilèges accordés aux simples utilisateurs ordinaires. Les quatre types d’autorité suivants — qui sont le reste des cinq autorités que j’ai mentionnées précédemment — sont tous des variantes d’une autorité privée.

Autorité utilisateur

Comme son nom l’indique, l’autorité utilisateur vous concerne directement, vous et l’accès dont vous avez besoin pour accomplir votre travail. Et c’est parfaitement logique. Dans la première partie de cet article, nous avons vu comment l’i utilise un croisement (objet et profil utilisateur) pour déterminer si l’objet auquel vous voulez accéder est vraiment accessible.

Quand nous parlons de l’autorité inhérente à votre profil utilisateur, il est question de trois choses : premièrement, si une valeur de classe utilisateur est attachée à votre profil (avec éventuellement un ensemble d’autorités par défaut) ; deuxièmement, si des autorités spéciales sont listées sous le paramètre SPCAUT ; et troisièmement, si une quelconque autorité privée sur un objet spécifique vous a été octroyée par le propriétaire de cet objet, au moyen de la commande GRTOBJAUT.

Le paramètre sur le profil utilisateur qui indique la classe utilisateur est CLASS, et si quelque chose y est spécifié, c’est accompagné d’un ensemble d’autorités spécifique. Par exemple, dans la première partie de cet article, nous avons vu que *SECADM est accompagné de l’autorité *SECADM, *SYSOPR a *SAVSYS et *JOBCTL, et les pauvres *PGMR et *USER n’ont rien. Par conséquent, la classe utilisateur à elle seule ne fait rien. L’algorithme ne l’examine jamais. Mais la classe utilisateur définit les autorités spéciales initiales et c’est là l’important. Bien entendu, vous pouvez toujours remplacer ce qui est appelé par la classe utilisateur en entrant quelque chose directement dans le paramètre des autorités spéciales.

Le paramètre des autorités spéciales est SPCAUT, et il peut avoir des valeurs diverses, comme *NONE, *SAME, *USRCLS, ou les valeurs d’autorité réelles elles-mêmes (par exemple, *SYSOPR, *SECADM, etc.). Ce point ayant été couvert dans le premier article, vous pouvez y revenir pour plus de détails.

L’autorité (ou les autorités) de chacun permettent à l’i de savoir précisément qui peut accéder à quoi. Revers de la médaille, l’i peut être très exigeant quant au temps qu’il faut à quelqu’un pour connaître exactement l’autorité de chacun. Au bon vieux temps, il était courant qu’un groupe de personnes exercent les mêmes activités sous un profil unique, ce qui simplifiait l’autorité. Mais les auditeurs d’aujourd’hui n’y sont pas favorables. Par conséquent, le nombre de profils a augmenté et il est beaucoup plus long de les établir et de les superviser tous.

Même si vous avez davantage de profils aujourd’hui, rien ne vous interdit de les rendre semblables, d’autant plus que vous avez sûrement beaucoup d’utilisateurs justiciables de la même autorité. Il est un peu fastidieux d’établir l’autorité individuellement dans chaque profil utilisateur ou objet. Il serait donc séduisant de pouvoir définir la sécurité à un niveau supérieur, en regroupant des gens qui partagent les mêmes besoins et désirs de sécurité. Heureusement l’i est de cet avis et les trois derniers types d’autorité concernent le niveau privé. Il sera donc plus facile d’octroyer la même autorité à plusieurs utilisateurs différents.

Profil de groupe

Vous avez un profil utilisateur qui vous est probablement unique (après tout, vous n’êtes pas comme tout le monde). Mais vous pouvez aussi faire partie d’un groupe d’utilisateurs. À ne pas confondre avec une classe utilisateur : il s’agit ici d’être en relation avec un ou plusieurs autres profils d’utilisateur réels.

C’est l’objet du paramètre USRGRP sur la commande CHGUSRPRF. Vous pouvez entrer ici n’importe quel profil utilisateur valide. Après quoi, ce profil est un membre de ce groupe utilisateur, de la même manière que vous devenez membre du club de pétanque de votre village après avoir payé votre adhésion. Désormais, vous bénéficiez des autorités spéciales attachées à ce profil de groupe.

Sachez aussi que chaque fois que vous obtenez l’autorité d’une autre source, il y a ajout. Autrement dit, si vous êtes rattaché à un profil de groupe dont l’autorité est inférieure à la vôtre propre, vous ne perdrez pas d’autorité … mais vous n’en aurez pas davantage.

Souvent, le profil de groupe est générique et personne ne s’identifie avec lui. Mais il possède l’autorité nécessaire pour sa mission. C’est souvent le cas si vous travaillez avec un package logiciel. Quelle qu’en soit la raison, cette technique est un excellent moyen pour gérer les autorités d’un grand nombre d’utilisateurs.

Listes d’autorisations

Une liste d’autorisations est un objet système qui présente un ou plusieurs profils utilisateur avec un ou plusieurs objets système (fichiers, programmes, zones de données, etc.). Vous pouvez spécifier qui a des droits sur un certain ensemble d’objets. La commande CRTAULT permet de créer un objet liste d’autorisations. Les commandes de listes d’autorisations les plus courantes sont : Create Authorization List (CRTAUTL), Add Authorization List Entry (ADDAUTLE), et Work With Authorization List (WRKAUTL).

Vous commencez par nommer la liste d’autorisations (avec la commande CRTAUTL ou l’option 1 de la commande WRKAUTL) et vous pouvez l’accompagner d’une description. Vous définissez aussi la liste des privilèges, ou autorités, que les utilisateurs de la liste obtiennent sur les objets de celle-ci. L’autorité par défaut dans la liste d’autorisations est CHANGE, mais vous pouvez modifier cela quand vous créez la liste (ou ultérieurement). Autre détail important : seul le créateur de la liste d’autorisations (le propriétaire) peut la modifier, sauf si vous accordez l’autorité « list management » (gestion de listes)  aux autres utilisateurs présents sur la liste.

À ce stade, la liste n’en est pas vraiment une. Elle le sera quand vous lui aurez ajouté des profils utilisateur et des objets. Les objets, vous l’aurez deviné, sont ceux auxquels les utilisateurs de la liste peuvent accéder grâce aux autorités figurant sur la liste. Quant aux profils utilisateur, ce sont les utilisateurs autorisés à accéder à ces objets. Tout cela est carré et symétrique et me convient parfaitement.
Des objets sont ajoutés à la liste par la commande GRTOBJAUT (et en sont retirés par la commande Revoke Object Authority—RVKOBJAUT). D’ailleurs vous verrez que cette commande comporte un paramètre pour une liste d’autorisations. Vous pouvez bien sûr remplacer les autorités assignées, pour donner à des objets différents divers niveaux d’autorité dans la liste d’autorisations. Ou vous pouvez accepter par défaut l’autorité présente dans la liste d’autorités elle-même.

Des utilisateurs sont ajoutés à la liste d’autorisations par la commande ADDAUTLE ou l’option 2 de la commande WRKAUTL. En principe, vous devriez pouvoir ajouter des objets à une liste d’autorisations de la même manière que vous ajoutez des profils, mais vous ne le pouvez pas. Cela m’a contrarié au début mais je m’en suis accommodé.

À première vue, une liste d’autorisations peut être vue comme une chose de plus à mettre en place. En réalité, elle vous simplifiera considérablement la tâche en vous permettant —moyennant un seul paramètre — d’octroyer un ensemble d’autorités à un grand nombre d’utilisateurs et d’objets. Les listes d’autorisations ont leurs avantages : vous pouvez changer facilement la liste des utilisateurs, par exemple les employés, qui ont accès à un ensemble d’objets associés. Par les temps qui courent, cela simplifie les mouvements de personnel.  Vous n’êtes pas obligés de les utiliser, mais elles sont un outil de plus dans votre panoplie.

Autorité adoptée

L’autorité adoptée vient clore cette liste. Elle se situe au niveau du programme plutôt que comme quelque chose de défini dans le profil utilisateur. Quand un programme s’exécute, il utilise les autorités du profil utilisateur qui l’a lancé. L’autorité adoptée permet au programmeur de choisir un autre profil utilisateur pour définir les privilèges en vigueur au moment de l’exécution.

L’autorité adoptée est donc définie au moment où un programme est compilé. Un paramètre de la commande compile, USRPRF, contrôle quelles autorisations serviront à déterminer l’accès pendant l’exécution du programme. Deux valeurs sont possibles. La première est *USER. C’est la valeur par défaut selon laquelle l’autorité de celui qui exécute le programme servira à déterminer la possibilité d’un accès. La seconde est *OWNER. Comme son nom l’indique, l’autorité sera toujours celle du propriétaire du programme, indépendamment de son exécutant.

Dans ce cas, il suffit d’être certain que le propriétaire du programme a le droit d’accomplir quelque chose. L’autorité adoptée se prête à l’interprétation et à la controverse et, à mon avis, vous ne devriez pas trop l’utiliser. Et si vous l’appliquez, méfiez-vous de tout usage abusif (merci du conseil, Dave). Elle peut avoir sa place dans un genre de routine appelée qui ne s’exécute jamais seule et qui justifie un accès de sécurité spécial.

Ce n’est pas que l’autorité adoptée soit mauvaise en soi, mais il est facile d’en perdre la maîtrise. Si vous pensez devoir utiliser l’autorité adoptée, demandez donc un ordre écrit … par simple précaution.