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

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

Tech - Par Renaud ROSSET - 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.

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

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 Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 22 février 2012