IBMi, Algorithme de sécurité

Et la réponse est : l’algorithme de recherche d’autorité de l’IBM i.

Mais avant d’entrer dans les détails, posons-nous la question suivante : qu’est-ce que l’autorisation d’accès ? Nous parlons ici d’un accès qui nous permet de changer ou de détruire l’objet. Si tout ce dont vous avez besoin est USE ou EXCLUDE (en supposant que vous voulez l’autorisation EXCLUDE), il vous suffit d’être chassé de cet algorithme purement et simplement. Et ce n’est pas aussi difficile que vous pourriez le croire. (Bien que, à la réflexion, si tout ce que je veux est l’autorité USE, alors l’algorithme n’entre probablement même pas en action. Honnêtement, je ne suis pas tout à fait sûr de cela : je n’y ai jamais pensé sous cet angle auparavant.) Une bonne navigation dans l’algorithme donnera CHANGE ou une autorité meilleure.

Et n’oubliez pas que quand nous disons « avoir accès, » il ne s’agit pas d’obtenir un certificat par mail ou de voir votre profil (ou l’objet) marqué d’une quelconque façon. Cela signifie tout simplement que le système va créer le pointeur système vers l’adresse de stockage à un seul niveau de cet objet.

L’algorithme de sécurité vu d’en haut

Vous vous en doutez certainement, l’algorithme d’autorisation n’est ni simple ni trop compliqué. Mais ce n’est pas un simple raisonnement binaire du genre “si cela, alors ceci”. Le processus de décision passe par neuf étapes de base.

1.    Examiner la propre autorité de l’objet.
2.    Examiner l’utilisateur pour voir si l’autorité spéciale *ALLOBJ est spécifiée.
3.    Voir si l’utilisateur possède des autorités spéciales sur cet objet.
4.    Vérifier si l’utilisateur figure sur des listes autorisations liées à l’objet.
5.    Si un ou plusieurs profils de groupes sont attachés à l’utilisateur, vérifier l’autorité spéciale *ALLOBJ pour le(s) profil(s) de groupes.
6.    Si l’utilisateur a un ou plusieurs profils de groupes, vérifier les autorités spéciales spécifiques sur cet objet.
7.    Si l’utilisateur a un ou plusieurs profils de groupes, vérifier si certains d’entre eux figurent sur une liste d’autorisations liée à l’objet.
8.    Examiner l’autorité publique sur l’objet et les éventuelles listes d’autorisation liées à l’objet.
9.    Enfin, si l’autorité adoptée est active, examiner l’autorité du propriétaire sur l’objet.

Si vous avez tendance à penser plus spatialement que verbalement, consultez la figure 13 de la page 143 de l’iSeries Security Reference Version 5 (SC41-5302-07) d’IBM, qui résume assez bien ces étapes. Étudiez et mémorisez ce tableau dès à présent (ne maugréez pas — jusqu’à présent je ne vous ai rien demandé à propos d’aucun article !).

L’algorithme de sécurité est mis en oeuvre chaque fois que vous essayez d’accéder à l’objet. Si vous recherchez un fichier de programmes, la vérification a lieu au moment de l’ouverture du fichier plutôt qu’avant chaque requête d’I/O.

À chaque étape couverte par l’algorithme, l’accès sera accordé ou non. Dans la négative, vous passerez à l’étape suivante. Si l’accès est accordé, n’importe quel accès, pas forcément celui dont vous avez besoin (par exemple si vous recevez l’autorité CHANGE alors que vous avez vraiment besoin de DELETE), pas de chance : l’algorithme se termine et vous êtes coincé avec les résultats. Si, à la fin de cette séquence, vous n’avez pas obtenu l’autorité souhaitée, vous êtes malchanceux. Vous n’aurez pas l’accès voulu et ce que vous essayez de faire échouera, ainsi que le programme que vous essayez d’exécuter.

À ce stade, vous vous dites peut-être : « D’accord, neuf étapes ce n’est pas rien, mais ce n’est pas insurmontable. Pourquoi ne pas voir ce qui se passe dans chaque étape et ainsi je connaîtrai tous les détails. » D’abord, je n’ai jamais dit que ce serait dur. J’ai dit que ce n’était pas simple. Et à l’intérieur de chaque étape, il y a un certain nombre de sous-étapes et de points de décision. Le sentier est tortueux et accidenté, et pour aller au fond des choses il faudrait ajouter un troisième article à cette série.

Pour vous faire plaisir, je vous renvoie à nouveau à l’iSeries Security Reference – cette fois-ci à la page 152 et la figure 18 – qui vous donne des détails sur la manière dont l’autorité de groupes est vérifiée dans l’algorithme. Cette figure montre bien la complexité du processus. Chacune de ces étapes est accompagnée de son propre organigramme qui dévoile le fonctionnement interne. Si la sécurité vous intéresse vraiment, je vous conseille d’explorer et de lire en détail le document mentionné ci-dessus. Outre les détails complets de chaque étape, il propose des exemples concrets sur l’attribution de l’autorité dans une situation donnée. C’est un bon livre qui se lit facilement. Et avec seulement un peu plus de 700 pages. Emportez le donc en vacances.

Et c’est tout

D’une certaine manière, tout cela est vraiment simple. Examinez l’objet, puis voyez si le profil utilisateur (pour *ALLOBJ) est assorti d’autorités spéciales et de listes autorisations. Faites le même genre de vérification sur les profils de groupes attachés à votre profil utilisateur, vérifiez l’autorité publique sur l’objet et, pour finir, regardez l’autorité adoptée. Vu sous un autre angle, tout cela est réellement complexe (comme cet organigramme de la page 152 de l’iSeries Security Reference). Et qu’avons-nous appris de tout cela ? C’est difficile à dire et cela dépend de ce que vous saviez au départ. Espérons qu’au moins vous avez une idée de la beauté, la complexité et la puissance de l’i sécurité. Merci pour votre persévérance.