Sécurité de l’IBM i – Les autorités

Le mois dernier, nous avons commencé à nous intéresser à la sécurité de l’i en examinant certaines de ses briques de base : objets, profils utilisateur, et autres. Cela nous a déjà permis de voir en quoi cette sécurité i est unique dans le monde informatique. Le moment est venu de voir comment le système utilise ces briques, ou blocs élémentaires, pour répondre à cette question primordiale : avez-vous le droit, ou non, de manipuler un certain objet ? Et si vous êtes chargé de définir ces droits ou règles d’autorisation, dans quel ordre le système prend-il ces décisions ?

Avant d’aborder un autre volet de la sécurité i, récapitulons ce que nous avons couvert le mois dernier dans la première partie (voir : Sécurité de l’IBM i – Les briques de base).

La sécurité a été intégrée dans l’i dès sa conception. Et, bien sûr, elle a été améliorée en cours de route—comme beaucoup de choses (je vous laisse le soin de compléter)—mais les principes de base étaient présents dès le début. Ajoutez à cela le fait que la sécurité est présente dans l’OS autant que dans l’interface machine, et vous obtenez une protection qui n’a rien à voir avec un mur contournable. C’est plutôt une philosophie multicouche qui s’intéresse sans cesse aux objets et à leurs utilisateurs potentiels.

Tout ce qui se trouve dans l’i est un « objet. » Quand nous parlons d’un objet, il s’agit bien de quelque chose qui a une structure interne définie par des règles d’autorité. Cette structure inclut des informations sur qui possède l’objet et qui peut le manipuler ou s’en servir. Et pour les utilisateurs autorisés à faire certaines choses, l’objet contient des informations précisant ce qu’ils peuvent faire exactement.

L’i n’attache pas simplement un ensemble de privilèges à un objet (à la façon d’UNIX) qui donnent carte blanche à une masse d’utilisateurs. Pour chaque utilisateur qui accède à un objet, l’i crée un pointeur système obéissant au hardware qui combine l’adresse de stockage à un seul niveau de l’objet, aux possibilités—lecture, écriture, mise à jour, exécution, etc.—accordées à cet utilisateur pour l’objet. Comme l’accès aux objets dans l’i ne peut se faire que par l’intermédiaire de ce pointeur système, rien ne peut être atteint sans passer par ce strict mécanisme de sécurité.

Malgré le pointeur système autoritaire, l’i n’est pas un système de sécurité à-tout-faire et polyvalent répondant à tous les cas. Il comporte des variables globales, appelées valeurs système, qui vous permettent de doser la sécurité : du caramel mou à l’acier trempé.

Le profil utilisateur avec lequel vous vous connectez fournit l’empreinte de sécurité de base que le système utilise quand vous essayez d’accéder aux objets. Là aussi il y a beaucoup de souplesse : classes utilisateur, autorités spéciales, profils de groupe, liens de raccourci de sécurité, listes d’autorisations, et autres.

Un algorithme multi-niveaux détermine si vous (votre profil utilisateur) pouvez faire ce que vous voulez sur l’objet que vous essayez d’atteindre. Cet algorithme multi niveaux examine l’objet et l’utilisateur, puis applique un ensemble de règles standard pour accorder l’accès ou non. Cette décision est ensuite codée dans le pointeur système afin que l’algorithme de sécurité ne doive s’exécuter qu’une fois, par souci de rapidité et d’efficacité.

Après ce rappel de la première partie de cet article, vous êtes en mesure d’aborder tout ce qui touche aux types d’autorité : Publique, Utilisateur, Profil de groupes, Listes d’autorisations et Adoptée. Vous apprendrez aussi Le Secret : l’algorithme qui combine tous ces composants pour élaborer un pointeur système qui ne donne à l’utilisateur que les privilèges voulus par vous, rien de plus.