Comment cette fonction permet de sécuriser une application ou des fonctions à l'intérieur d'un programmeVous
est-il déjà arrivé de vouloir sécuriser une partie de programme applicatif
et de ne pas avoir d'objet AS/400 à sécuriser ? Vous avez probablement créé
une liste de droits d'accès ou un autre objet et vérifié les droits d'accès
à celui-ci pour contrôler l'accès à la fonction du programme. Grâce à la
fonction de restriction d'accès (Limit Access to Program) de la V4R3, on peut
contrôler l'accès à une application, à certaines parties d'une application
ou aux fonctions d'un programme. Le support de cette fonction Limit Access to
Program passe par des API permettant d'identifier une fonction à sécuriser
(une application ou une partie d'une application par exemple), récupérer des
informations sur la fonction, définir qui est autorisé ou non à l'utiliser et
vérifier si un utilisateur donné à le droit de l'utiliser. On peut également
utiliser la fonction de restriction d'accès pour gérer la sécurité des
fonctions via Operations Navigator.
On
peut utiliser cette fonction via Operations Navigator
La
fonction Limit Access to Program compte sept API; la figure 1 liste ces API
ainsi que leurs paramètres associés. Les fichiers en-tête RPG des API se
trouvent dans les bibliothèques QSYSINC/QRPGSRC et QSYSINC/QRGPLESRC, les
fichiers en-tête C dans QSYSINC/H et les fichiers en-tête Cobol dans QSYSINC/QCBLSRC
et QCBLLESRC. Pour utiliser le support de la fonction de restriction d’accès
dans une application, inscrivez vos fonctions lorsque vous installez
l’application sur une machine de production. Lorsqu’une application est sur le
point d’invoquer la portion de code qui correspond à une fonction inscrite,
l’application appelle l’API QSYCKUFU (Check User Function Usage) pour vérifier
si l’utilisateur a le droit d’utiliser la fonction. Si c’est bien le cas, la
portion de code peut être exécutée. Dans le cas contraire, le code que vous
avez rédigé dans l’application empêche l’utilisateur d’exécuter la fonction
et renvoie un message au programme appelant ou un code erreur. La figure 2 présente
un exemple de code CL qui vérifie si un utilisateur bénéficie de l’accès à
une fonction.
Pour inscrire des fonctions, déterminez d’abord le support auquel vous
souhaitez limiter l’accès et définissez une fonction pour chaque interface à
contrôler. Une fonction présente les caractéristiques suivantes :
-
Un nom (ID) de 30 caractères de long qui identifie de façon
unique la fonction à laquelle on souhaite limiter l’accès. Il est préférable
que l’ID commence par le nom de l’entreprise pour éviter d’entrer en conflit
avec les ID des fonctions d’autres entreprises (comme par exemple celles d’éditeurs
de logiciels).
-
La possibilité de classer les fonctions en fonction du système
sur lequel le code associé à la fonction s’exécute: sur l’AS/400, sur le
client ou comme un plug-in Operations Navigator sur le client.
-
La possibilité de définir une hiérarchie des fonctions qui
illustre la façon dont elles s’accordent entre elles et permettent à un
administrateur de gérer l’accès à toutes les fonctions au sein d’un groupe hiérarchique
-
La possibilité d’affecter un nom à la fonction qui soit plus
"lisible" que l’ID de la fonction
-
La possibilité d’empêcher un utilisateur disposant des droits spéciaux
*ALLOBJ d’accéder à une fonction
La figure 3 présente les différentes catégories de fonctions et
l’utilisation du support hiérarchique et des noms textes des fonctions. Depuis cette
fenêtre, un administrateur peut modifier les paramètres sous les colonnes
Default Usage, All Object Usage et Customized Usage pour l’ensemble des
fonctions dans un groupe hiérarchique en changeant les paramètres de la
fonction "parent". Par exemple, la modification un paramètre de la
fonction Operations Navigator Basic Operations change également ce paramètre
pour les fonctions Messages, Printer Output et Printers.
Lorsqu’on a déterminé les fonctions à contrôler dans une application,
on peut écrire un programme qui appelle l’API QSYRGFN (Register Function) pour
inscrire les fonctions. L’application ne devra appeler ce programme qu’une seule
fois, lors de l’installation de l’application. La figure 4 présente un extrait
du programme CL qui inscrit les fonctions.
Après qu’une fonction ait été inscrite, le responsable de la sécurité
(un utilisateur disposant des droits spéciaux *SECADM par exemple) peut spécifier
qui a ou n’a pas le droit d’accéder à cette fonction. Le moyen le plus simple
de gérer l’utilisation d’une fonction reste l’interface graphique Application
Administration d’Operations Navigator (OpNav). Parallèlement, on peut utiliser
l’API QSYCHFUI (Change Function Usage Information) dans un programme. Pour avoir
plus d’informations sur l’utilisation de cette API et sur les autres API de la
fonction Limit Access to Program, consultez le manuel System API Reference (SC41-5801).
OpNav lui-même utilise la fonction de restriction d’accès pour
permettre aux administrateurs de contrôler l’accès aux fonctions OS/400. OpNav
a inscrit des fonctions qui correspondent à tous les dossiers de niveau supérieur
et à quelques sous-dossiers de la hiérarchie OpNav. Lorsqu’un utilisateur se
sert de OpNav pour travailler sur un AS/400, celui-ci vérifie les fonctions
(par exemple, dossiers/sous-dossiers) auxquelles l’utilisateurs peut accéder et
n’affiche que ces fonctions-là .
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre dossier Green IT sur les actions engagés par inmac wstore pour réduire son impact environnemental