Sécurité de l’IBM i

Comprendre et apprécier le dispositif de sécurité de l’i.

Jadis, le monde était très simple et très sûr. Vous pouviez vous déplacer à vélo sans trimbaler un antivol en titane. Vous pouviez sortir la nuit sans aucune crainte. Vous pouviez laisser n’importe qui accéder à votre ordinateur : après tout, si les données étaient là, c’était bien pour être utilisées, non ?

Hélas, le monde d’aujourd’hui ressemble davantage à une scène d’un film de Stanley Kubrick que de Walt Disney. Quand je fais une balade à vélo, je ne m’en sépare pas et surtout je ne le laisse pas n’importe où. Je ne m’aventure pas dehors après la nuit tombée. Et je développe des applications pour certains clients qui ne me donnent même pas le droit de mettre à jour les fichiers de base des programmes.

Dans tous les domaines les temps ont changé et ce n’est plus la sécurité de l’ordinateur de papa. Vous devez vous soucier de menaces internes et externes, d’erreurs et de sabotage délibéré. Sans oublier bien sûr les défaillances du matériel du logiciel. Autrement dit, tout se ligue contre vous.

Malheureusement, beaucoup de gens réagissent aux questions de sécurité comme ils le feraient pour parler de comptabilité générale ou … de l’extraction d’une dent : ils essaient de l’éviter. L’une des principales raisons de ce comportement est que la plupart ne comprennent pas ce qu’est la sécurité. Pour eux, c’est un ensemble de faits, mais ils ne ressentent pas la structure et l’âme du dispositif de sécurité de l’IBM i. Et dans le monde d’aujourd’hui, ce manque de compréhension n’est plus acceptable. En tant que spécialiste de l’IBM i, vous devez bien comprendre les bases de l’i sécurité : objets, pointeurs et autorités. Quand vous aurez compris ces éléments fondamentaux de la sécurité de l’IBM i, vous apprécierez mieux son vrai potentiel et la meilleure manière d’utiliser les moyens à votre disposition.

L’i sécurité est intégrée

Commençons par passer en revue quelques faits et réalités. Tout d’abord, je tiens à souligner que la sécurité a été intégrée dans l’i dès sa conception. Elle n’a pas été ajoutée à l’occasion de la release 5.4 ou lors du passage de CISC à RISC. Je pourrais dire que cette solide fondation est présente parce que l’i a été développé par de vrais informaticiens dans un vrai labo et pas par quelques adolescents dans un garage. Mais disons plutôt que la sécurité faisait partie du plan original parce que cet ordinateur était d’emblée destiné à un usage professionnel.

Au risque de me répéter, sachez que l’i sécurité a été homogène depuis le début. Et même si elle a dû changer au fil des ans, elle s’appuie sur un cadre solide. Et elle est multicouche. En effet, il y a des fonctions de sécurité dans l’i OS ainsi qu’au niveau machine : adressage basé sur les possibilités, stockage à un niveau (single-level-storage, SLS), interface machine indépendante de la technologie (technology-independent machine interface, TIMI), et code interne sous licence système (System Licensed Internal Code, SLIC). C’est donc une sécurité qu’il est difficile de contourner. L’i sécurité n’est pas comme une barrière ou un mur. Ce n’est pas un barrage statique dont quelqu’un peut imaginer le contournement. C’est quelque chose qui est tissé dans chaque objet et fonction de l’i, quelque chose qui est intimement lié à sa structure.

Au fil de la lecture de cet article, plusieurs questions devront rester présentes à votre esprit et nous essaierons d’y répondre. Premièrement, qu’est-ce qui est à la base de l’i sécurité ? Nous savons que c’est beaucoup de choses, mais sur quoi tout cela repose-t-il au niveau le plus élémentaire ? Deuxièmement, quelle est la première étape de création du profil de sécurité de votre i ? Troisièmement, quel est le rôle du profil utilisateur dans la définition de votre autorité ? Et finalement, quand vous créez un objet, comment le système détermine-t-il le niveau d’autorité à lui associer, ou est-ce un critère que vous définirez pendant la création ?

Sécurité de l’IBM i Tout commence par des objets

Commençons par dire clairement que tout ce qui se trouve dans l’i est un objet. Et cet objet n’est pas simplement « une chose. » C’est bien « une chose qui a une structure interne et un ensemble de règles qui contrôlent son mode de fonctionnement. » Il peut faire tout ce que sa structure et son ensemble de règles permettent, et rien de ce qu’ils ne permettent pas. Chacun de ces « objets » est constitué d’un en-tête qui précise son type, et d’un composant fonctionnel (l’ensemble de règles), différent pour chaque type d’objet.

Les objets ont une particularité importante : les programmes ne peuvent y accéder que par un mécanisme obéissant au hardware, appelé pointeur système. Celui-ci contient l’adresse SLS d’un objet, combinée aux privilèges—ou aux possibilités—que le programme possesseur du pointeur a par rapport à l’objet.

Autre particularité notable : un objet n’appartient qu’à un seul profil utilisateur. Ce dernier peut, par défaut, agir à sa guise sur l’objet. Le nom du profil utilisateur propriétaire est l’un des attributs stockés dans la structure interne de l’objet.
Les conséquences sont triples. Premièrement, les objets ne peuvent pas se transformer ; ils sont ce qu’ils sont et ne peuvent devenir rien d’autre. Les données sont toujours des données et elles ne peuvent pas se métamorphoser soudain en un module exécutable.

Deuxièmement, seules certaines forces externes peuvent agir sur un objet. Autrement dit, les objets sont là pour que des instructions machines puissent les manipuler ou les traiter. Mais, sur l’i, chaque type d’objet ne peut être affecté que par un certain jeu d’instructions. Il existe des règles régissant ce que nous pouvons faire aux objets, et donc il ne peut pas y avoir de mauvaises surprises.

Troisièmement, tout programme manipulant un objet ne peut le faire que selon les possibilités du pointeur système qui sert à accéder à l’objet. Cet agencement vaut bien mieux que d’attacher des privilèges à l’objet lui-même puis d’essayer de les faire fonctionner pour tous les utilisateurs possibles — comme le fait UNIX. Avec l’adressage basé sur les possibilités, la sécurité de chaque objet est réglée finement pour ne permettre que ce dont chaque programme a besoin pour accomplir sa tâche. Et rien de plus.

Grâce à un système d’objets aussi strict, on élimine beaucoup de problèmes de sécurité.

En conclusion : L’i sécurité commence par le fait que tout dans le monde i est un objet structuré qui a des règles spécifiques—des règles qui ne peuvent pas être contournées—régissant ce qu’il est et ce qu’il peut faire.