Risques liés à  la gestion de l’autorité sur les objets

héberge.

Autorité *PUBLIC. Dans l’OS/400, le terme *PUBLIC indique le paramètre de sécurité par défaut d’un objet (bibliothèque, fichier, programme, profil utilisateur, par exemple). Chaque objet présent sur le système a un paramètre d’autorité *PUBLIC pour déterminer le niveau d’autorité que chacun a sur l’objet, en supposant que l’utilisateur ne possède pas d’autorité privée spécifique sur cet objet. Vous pouvez utiliser la commande DSPOBJAUT (Display Object Authority) pour voir les autorités privées et *PUBLIC d’un objet.

Souvent, les fichiers et les programmes de production sont mal sécurisés, avec des paramètres tels que *PUBLIC AUT(*CHANGE), AUT(*ALL) ou AUT(*USE). Vous devez sécuriser les objets de production avec *PUBLIC AUT(*EXCLUDE), ce qui rend les objets inaccessibles à quiconque. Vous attribuerez ensuite des autorités privées aux utilisateurs et aux groupes nécessitant l’accès.

AUT(*USE) peut être considéré comme des droits en lecture seule sur des fichiers. AUT(*CHANGE) donne des droits de mise à jour sur des fichiers, et AUT(*ALL) accorde le contrôle complet d’un fichier, jusqu’aux droits de suppression.
La plus haute autorité sur les objets est attribuée au niveau bibliothèque. Les objets vivent dans une bibliothèque. Si *PUBLIC a l’autorité AUT(*USE) sur une bibliothèque, le premier venu peut accéder à tous les objets à l’intérieur de la bibliothèque en fonction des autorités *PUBLIC ou privées attribuées aux objets individuels.
On a donc la possibilité de supprimer des objets si l’autorité sur l’objet individuel est AUT(*ALL). Quand *PUBLIC AUT(*CHANGE) est spécifié au niveau bibliothèque, n’importe quel utilisateur peut contrôler les objets d’après leurs autorités individuelles et ajouter de nouveaux objets à la bibliothèque.

Quand *PUBLIC AUT(*ALL) est spécifié au niveau bibliothèque, tout utilisateur peut contrôler la bibliothèque – et donc la supprimer ainsi que tous les objets qu’elle contient. Cela suppose que l’utilisateur ou *PUBLIC possède l’autorité AUT(*ALL) sur les objets à l’intérieur de la bibliothèque.
D’après l’enquête sur la sécurité iSeries, beaucoup de bibliothèques sont dangereusement configurées. Dix pour cent en moyenne des bibliothèques de chaque système examiné étaient configurées comme *PUBLIC AUT(*ALL) ; pas moins de 55 % des bibliothèques étaient configurées comme *PUBLIC AUT(*CHANGE) ; et 24 % d’entre elles étaient configurées comme *PUBLIC AUT(*USE). De tels chiffres dévoilent une dangereuse exposition de nos ressources. Toute personne travaillant sur le système peut accéder aux bibliothèques non sécurisées, en violation des préceptes de base : séparation des tâches, contrôle d’accès et confidentialité des données.
Problèmes de listes de bibliothèques. Dans l’OS/400, quand on ouvre un fichier ou qu’on invoque un programme, le système recherche le fichier ou le programme en question en se fondant sur une liste ordonnée des bibliothèques associées au job sollicitant l’accès. Cette liste ordonnée des bibliothèques est appelée liste des bibliothèques du job. Le système explore la liste de haut en bas. Ce mode de résolution dynamique d’un objet est l’un des points forts de l’OS/400 car il assure l’exécution dynamique fondée sur les paramètres d’exécution du job.

Les bibliothèques placées en tête de liste (c’est-à-dire celles qui sont explorées en premier) sont établies par l’administrateur système et sont connues sous le nom de liste des bibliothèques système. Tous les jobs partagent ces bibliothèques supérieures. La liste des bibliothèques système contient généralement les bibliothèques de système d’exploitation fournies par IBM, comme QSYS, QSYS2, QUSRSYS et QHLPSYS. La présence de ces bibliothèques dans la liste des bibliothèques système permet au système d’exploitation de trouver ses propres fichiers et programmes pendant l’exploration des listes de bibliothèques pour la résolution d’objets.
Souvent, les administrateurs système iSeries placent des bibliothèques supplémentaires dans la liste des bibliothèques système pour diveres raisons.
Certains fournisseurs de logiciels ajoutent aussi des bibliothèques à la liste des bibliothèques système pendant leur processus d’installation. Il n’est pas forcément mauvais d’avoir votre propre bibliothèque ou une bibliothèque de fournisseur dans la liste des bibliothèques système – mais ce peut être dangereux si cette bibliothèque est mal sécurisée.

Comme la liste des bibliothèques système est explorée en premier pour tous les objets référencés par chaque job, les bibliothèques présentes dans cette liste doivent être bien sécurisées. En effet, si quelqu’un peut changer les objets d’une bibliothèque figurant dans la liste des bibliothèques système, il peut supplanter telle ou telle fonction du système d’exploitation et des applications de gestion.

Par exemple, supposons que la bibliothèque CUSTOM existe dans la liste des bibliothèques système et qu’elle soit dangereusement configurée avec *PUBLIC AUT(*CHANGE) ou AUT(*ALL). Un employé mécontent ou peu scrupuleux pourrait créer une version nuisible d’un programme applicatif de production et la placer dans une bibliothèque de la liste des bibliothèques système. Un programme modifié de la sorte constitue le fameux cheval de Troie. Quand le programme est invoqué dans le cours de l’activité normale, le système trouve la version altérée dans la liste des bibliothèques système avant le programme de production légitime et, en toute ignorance, invoque cette version corrompue.

Pour empêcher l’implantation des chevaux de Troie, assurez- vous que toutes les bibliothèques de la liste des bibliothèques système sont sécurisées avec *PUBLIC AUT(*USE).

L’OS/400 exige que les utilisateurs aient au moins l’autorité *USE sur chaque bibliothèque dans leur liste de bibliothèques.
Beaucoup de logiciels procurés par les fournisseurs placent des bibliothèques non sécurisées dans la liste des bibliothèques système. Tenez-en bien compte et contactez le fournisseur fautif pour qu’il vous aide à changer la configuration de telles bibliothèques en *PUBLIC AUT(*USE).

Appartenance à un groupe. Chaque objet du système appartient à un profil utilisateur. Le profil utilisateur propriétaire a tous les droits sur l’objet, y compris bien sûr ceux de changement et de suppression. Donc, si je crée un fichier, j’en suis propriétaire et je peux manipuler l’objet à ma guise, et même le supprimer.

« Dans des temps et dans des lieux très éloignés », quelqu’un a déclaré aux principaux fournisseurs de logiciels de gestion OS/400 que c’était une bonne idée d’avoir un profil propriétaire pour tous les objets contenus dans leurs applications.
C’était une brillante idée… Très intelligente ! Mais la recommandation s’est effondrée dès qu’il a été précisé que le profil propriétaire devrait être un profil de groupe dont les utilisateurs finaux d’applications seraient membres. C’était une très mauvaise idée !

Si tous les utilisateurs finaux d’une application deviennent membres d’un profil de groupe qui possède tous les objets de l’application, tous les utilisateurs finaux de l’application deviennent propriétaires de ces objets, avec tous les droits afférents à cette possession. Par conséquent, chaque utilisateur final a l’autorité AUT(*ALL) sur chaque objet d’application et peut manipuler les objets à sa guise, voire les supprimer.
Quand un ensemble intégré d’applications de gestion est la propriété du même profil de groupe, cela veut dire que l’employé de la paie, par exemple, a le droit d’approuver un bon de commande et d’entrer de nouveaux clients, de rédiger des factures, de payer des factures, de modifier des tarifs, et ainsi de suite. C’est la transgression pure et simple des préceptes : confidentialité des données, accès aux données et séparation des tâches et responsabilités.
L’argument courant en la matière consiste à dire qu’un utilisateur de la paie n’a pas sur son menu d’écran vert (passif) une option lui permettant d’approuver un bon de commande ou de rédiger une facture. C’est vrai ! Mais l’écran vert n’est pas le seul chemin pour manipuler des données.
L’argument vaut tant que Telnet sur écran vert est le seul service d’accès fonctionnant sur votre iSeries, mais je n’ai jamais rencontré ce cas. Nous utilisons tous des serveurs FTP, des serveurs ODBC, des serveurs de fichiers, des serveurs à commande distante, des serveurs Web, et autres. Dans de tels scénarios de tous les jours, la sécurité fondée sur S/3x et sur les premiers menus AS/400 s’évanouit.

Cela nous amène à un autre genre de risques : ceux de l’accès au réseau à distance. Là, une mauvaise gestion des autorités objet peut causer des ravages sur les données.