> 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 cette ressource

Guide de réponse aux incidents de cybersécurité

Guide de réponse aux incidents de cybersécurité

Le National Institute of Standards and Technology (NIST) propose un guide complet pour mettre en place un plan de réponse aux incidents de cybersécurité, nous en avons extrait et détaillé les points essentiels dans ce guide. Découvrez les 6 étapes clés d'un plan de réponse efficace aux incidents de cybersécurité.

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