> Tech > L’autorité adoptée passée au crible

L’autorité adoptée passée au crible

Tech - Par iTPro - Publié le 22 février 2012
email


Tout fichier, bibliothèque, programme, et autre objet du système a une liste associée des autorités le concernant. Ces autorités déterminent qui peut lire, modifier, mettre à jour, accéder à ou manipuler l’objet. La liste des autorités contient les noms des utilisateurs et des groupes d’utilisateurs et leurs

droits d’accès sur l’objet. Cette liste d’autorités contient aussi les droits d’accès concernant *PUBLIC. *PUBLIC représente l’autorité qu’un utilisateur a sur l’objet quand l’utilisateur ou son groupe n’a pas de droits d’accès spécifiques précisés dans la liste.

La figure 1 contient un exemple d’un utilisateur BOB et du fichier PAYMAST dans la bibliothèque PAYDATA. BOB est un membre du groupe PAYUSER. Dans la figure, on voit la liste des autorisations pour la bibliothèque PAYDATA et pour le fichier PAYMAST. PAYOWNER a l’autorité *ALL, donnant l’accès illimité au fichier et à la bibliothèque, PAYQRY a des droits *USE sur le fichier et la bibliothèque, fournissant des droits READ-ONLY sur le fichier PAYMAST. La seule autre autorité listée est pour *PUBLIC. *PUBLIC a des droits *EXCLUDE sur le fichier et la bibliothèque, ce qui signifie que *PUBLIC ne peut accéder à aucun des deux.

Qui est *PUBLIC ? Dans cet exemple, *PUBLIC est tous les utilisateurs non spécifiquement listés par leur nom d’utilisateur ou groupe. Ainsi, tous les utilisateurs autres que PAYOWNER et PAYQRY tombent dans la catégorie *PUBLIC pour cette bibliothèque et ce fichier. Comme BOB ne figure pas dans la liste, pas plus que son groupe PAYUSER, BOB est *PUBLIC et par conséquent a des droits *EXCLUDE (c’est-à-dire pas d’accès au fichier ou à la bibliothèque).

BOB travaille dans le service paie et il doit être capable de mettre à jour le fichier maître payroll et les autres fichiers payroll, mais BOB n’a pas d’autorité sur la bibliothèque ou sur les fichiers. En réalité, dans ce scénario, aucun des utilisateurs du service payroll n’a de droits d’accès sur les fichiers payroll. Ce schéma d’autorisation a été créé intentionnellement afin qu’aucun utilisateur n’ait la possibilité de télécharger des fichiers de paie sensibles sur son PC à l’aide d’outils comme FTP ou iSeries Access File Transfer. Mais alors comment permettons-nous à BOB et aux autres utilisateurs du service payroll d’accéder aux fichiers de paie à partir de leur session de poste de travail à écran vert ?

Pour permettre aux utilisateurs du service payroll d’accéder aux fichiers de paie pour effectuer leur maintenance et leurs consultations normales, nous avons recours à un schéma d’autorité adoptée. Grâce à celle-ci, nous élevons temporairement l’autorité afin qu’un utilisateur puisse accéder aux données qui normalement lui sont interdites.

Dans la figure 2, BOB s’est connecté au système et à partir de son menu d’écran vert initial a invoqué un programme RPG nommé PAYMAINT. Un attribut spécial du programme PAYMAINT fait adopter temporairement à BOB l’autorité de l’utilisateur nommé PAYOWNER. Quand BOB quitte le programme PAYMAINT (F3 = Exit), l’autorité adoptée temporaire disparaît.
 

Téléchargez gratuitement cette ressource

Guide de Cloud Privé Hébergé

Guide de Cloud Privé Hébergé

Comment permettre aux entreprises de se focaliser sur leur cœur de métier, de gagner en agilité, réactivité et résilience en s’appuyant sur un socle informatique performant, évolutif et sécurisé ? Découvrez les avantages des solutions de Cloud Privé hébergé de la CPEM.

Tech - Par iTPro - Publié le 22 février 2012