Etablissement des droits adoptés

le système est correctement protégé, il faut d’abord examiner
les sécurités de niveau objet courantes. Il faut ensuite planifier les éventuelles
mises au point nécessaires, et déterminer comment ces modifications affecteront
les applications et les utilisateurs. Il faut effectuer les modifications proprement
dites en dernier lieu: quand on est sûr qu’elles n’entraîneront aucune perturbation.

La commande DSPPGM (Display Program information) comporte deux paramètres définissant
la manière dont un programme utilise les droits adoptés: User profile et Use adopted
authority (figure 3). Ces paramètres déterminent si un programme adopte des droits
et si les droits ainsi adoptés sont utilisables à  partir d’un programme situé
plus haut dans la pile d’appel.

Le paramètre User profile a deux valeurs possibles: *USER et *OWNER. *USER (valeur
par défaut) permet au programme de s’exécuter avec les droits de l’utilisateur
en cours. *OWNER conduit le programme à  s’exécuter sous les deux droits: celui
de l’utilisateur et celui du propriétaire du programme, tant que le programme
se trouve dans la pile d’appel.

Le paramètre Use adopted authority possède aussi deux valeurs possibles: *YES
(par défaut) et *NO. *YES permet au programme d’utiliser les droits adoptés venant
de programmes situés plus haut dans la pile d’appel; *NO empêche l’utilisation
des droits adoptés. La valeur retenue dépend de l’objectif recherché. Ainsi, si
le programme donne accès à  une ligne de commande aux utilisateurs, il faut donner
la valeur *NO à  ce paramètre, pour les empêcher d’accéder à  la ligne de commande
avec un niveau de droits excessif. Dans ce cas, il faut aussi donner au paramètre
User profile la valeur *USER, pour être certain que les utilisateurs n’effectuent
des opérations sur les lignes de commande qu’avec leurs droits respectifs. La
figure 4 montre comment ces deux paramètres ordonnent si (et comment) les droits
adoptés sont utilisés dans une pile d’appel.

Pour qu’un utilisateur tire parti de droits adoptés, le propriétaire du programme
droit avoir le droit d’utiliser les objets AS/400 nécessaires au programme. On
peut modifier le propriétaire du programme avec la commande CHGOBJOWN (Change
Object Owner). Pour changer le propriétaire d’un programme qui utilise des droits
adoptés, il faut soi-même posséder les droits spéciaux *ALLOBJ et *SECADM.

Si l’on doit modifier ses propres programmes pour adopter des droits ou pour utiliser
les droits adoptés provenant d’un programme en amont dans la pile, on utilise
la commande CHGPGM (Change Program). Par exemple, pour modifier le programme «monprog»
de la bibliothèque «mabib» pour qu’il adopte les droits du propriétaire du programme,
on écrira
CHGPGM PGM(mabib/monprog) +
USRPRF(*OWNER) +
USEADPAUT(*YES)

Pour définir l’un ou l’autre des attributs, il faut absolument que les programmes
soient observables. S’ils ne le sont pas, il faut les recompiler pour qu’ils le
deviennent. Et bien entendu, il faut posséder le code source correspondant. La
commande CHGPGM accepte les «wildcards», de sorte qu’on peut modifier plus d’un
programme à  la fois.

Après avoir donné aux programmes les attributs de droits adoptés appropriés, l’étape
suivante consiste à  configurer les fichiers base de données pour n’autoriser que
les opérations que l’on souhaite, confiées aux seules personnes autorisées. Pour
voir qui est autorisé à  mettre à  jour les objets AS/400, on utilise la commande
DSPOBJAUT (Display Object Authority) (figure 5). DSPOBJAUT montre quels utilisateurs
et groupes ont accès, et comment, à  un objet.
Le fichier CUSTMR de la figure 5 par exemple, possède les droits *PUBLIC *ALL,
ce qui signifie que tout le monde peut agir librement sur cet objet. Sauf à  vouloir
que tout le monde ait accès à  vos fichiers, vous devez attribuer la valeur *EXCLUDE
aux droits *PUBLIC. Tous seront écartés, sauf ceux qui ont les droits spéciaux
*ALLOBJ et ceux à  qui on a donné un droit explicite sur le fichier.

Pour modifier les droits sur un objet, on utilise la commande EDTOBJAUT (Edit
Object Authority). A l’invite de commande (figure 6), on peut modifier les droits
qu’un profil utilisateur doit posséder pour accéder à  un objet. On peut aussi
définir un objet pour qu’il utilise une liste d’autorisations pour déterminer
la sécurité (les listes d’autorisations permettent de modifier les droits sur
des fichiers pendant l’utilisation de ces derniers. Si l’on souhaite modifier
les droits d’un objet avec la commande EDTOBJAUT sans posséder de liste d’autorisations,
l’ouverture du fichier est impossible.)

Ce type de sécurité peut par exemple être instauré en créant un profil d’application
possédant tous les objets associés à  une application donnée. Ce profil doit être
créé avec un mot de passe *NONE, pour empêcher les signons avec ce profil. Ensuite,
le premier programme appelé par les applications peut être possédé par le profil
possesseur de l’application et adopter des droits.

Pour qu’une application puisse à  coup sûr mettre à  jour les fichiers base de données
de production, le profil de l’application doit soit posséder les fichiers de production,
soit, pour encore plus de sécurité, avoir les droits privés correspondant au minimum
requis pour procéder à  des opérations de mise à  jour précises sur le fichier.
Il faut autoriser les utilisateurs appropriés vis-à -vis du programme initial de
l’application et donner la valeur *EXCLUDE aux droits publics des objets de production.
Ainsi, les utilisateurs autorisés peuvent mettre à  jour les fichiers de production,
mais uniquement par le biais de l’application. Cela empêche également d’effectuer
des mises à  jour au moyen d’outils comme ODBC et DFU, sauf si leurs utilisateurs
y sont expressément autorisés.