Listes d'autorisation et droits adoptés, et nos conseils

Les listes d'autorisation

Une liste d'autorisation est un objet de type *AUTL, toujours rangé dans QSYS. Elle contient des utilisateurs (ou des groupes) avec leur droit. Un objet protégé par la liste donne à chacun le droit qu'elle indique ; si son droit public vaut *AUTL, il prend aussi son droit public dans la liste.

Notre démonstration :

CRTAUTL    AUTL(JOBIAUTL) AUT(*EXCLUDE) +
             TEXT('Liste d''autorisation de démonstration')
ADDAUTLE   AUTL(JOBIAUTL) USER(JOBIUSER) AUT(*CHANGE)
CRTDTAARA  DTAARA(JOBIPRF/DTA6) TYPE(*CHAR) LEN(20) AUT(JOBIAUTL)

Créer l'objet avec AUT(JOBIAUTL) le protège par la liste et met son droit public à *AUTL. Pour un objet existant : GRTOBJAUT OBJ(…) OBJTYPE(…) AUTL(JOBIAUTL).

Résultat de l'essai 6, sous le profil JOBIUSER, qui n'a aucun droit privé sur DTA6 : la modification est permise, par la liste.

Pourquoi les préférer

IBM présente la liste d'autorisation comme la méthode préférée pour des objets qui ont les mêmes besoins de sécurité, même peu nombreux :

• une seule opération donne ou retire l'accès à tous les objets de la liste ;
• chaque utilisateur n'a qu'un droit privé, sur la liste, au lieu d'un par objet : des profils plus petits, des SAVSYS et SAVSECDTA plus rapides ;
• on peut changer les droits d'un fichier même ouvert, ce que GRTOBJAUT ne permet pas par défaut ;
• le nom de la liste est sauvegardé avec l'objet : restauré sur le même système, il y est rattaché à nouveau.

Les règles

• Un objet n'est protégé que par une liste à la fois. Une liste ne protège ni un profil utilisateur, ni une autre liste.
• Seuls le propriétaire de l'objet, un utilisateur *ALL sur l'objet ou un profil *ALLOBJ peuvent rattacher l'objet à une liste ou l'en détacher.
• Le droit *AUTLMGT permet de gérer les utilisateurs de la liste, sans pouvoir donner plus que son propre droit, ni rattacher de nouveaux objets.
• Les objets livrés par IBM (hors QGPL et QUSRSYS) sont remplacés à chaque nouvelle version : leur lien avec une liste se perd, il faut le refaire (EDTOBJAUT ou GRTOBJAUT).

Les programmes qui adoptent les droits

Le cas typique, donné par IBM : un utilisateur doit pouvoir modifier le fichier des clients avec l'application, mais seulement le consulter avec un outil comme SQL. La solution : lui donner *USE sur le fichier, et faire adopter par les programmes de mise à jour les droits de leur propriétaire. Un *PGM, un *SRVPGM ou un *SQLPKG adopte quand il est créé avec USRPRF(*OWNER).

Le programme LIRESECR, compilé avec CRTBNDCL … USRPRF(*OWNER) puis donné à JOBIAPP (CHGOBJOWN … NEWOWN(JOBIAPP)), un profil désactivé et sans droit spécial qui n'a qu'un droit *USE sur SECRET :

/* Lit la zone de données SECRET, protégée par *PUBLIC *EXCLUDE.       */
/* Compilé avec USRPRF(*OWNER) et possédé par JOBIAPP : il adopte les  */
/* droits de JOBIAPP, qui a *USE sur SECRET.                            */
             PGM
             DCL        VAR(&VALEUR) TYPE(*CHAR) LEN(20)
             RTVDTAARA  DTAARA(JOBIPRF/SECRET) RTNVAR(&VALEUR)
             SNDPGMMSG  MSG('LIRESECR a lu SECRET : ' *CAT &VALEUR) +
                          TOPGMQ(*EXT)
             ENDPGM

Lancé sous JOBIUSER, il écrit dans l'historique du travail LIRESECR a lu SECRET : Code 1234, alors que la lecture directe, une instruction plus tôt, avait reçu CPF1016.

Les règles de l'adoption

• Les droits adoptés s'ajoutent à ceux de l'utilisateur ; ils ne sont consultés que si ses propres droits, ceux de ses groupes et le public ne suffisent pas.
• Les droits spéciaux du propriétaire sont adoptés aussi : un programme possédé par un profil *ALLOBJ donne *ALLOBJ.
• Ni les droits des groupes du propriétaire ni le droit public ne sont adoptés : seuls comptent ses droits de propriétaire, de groupe principal et ses droits privés. Les autres attributs du profil (comme LMTCPB) ne le sont pas non plus.
• L'adoption dure tant que le programme est dans la pile d'appels ; les programmes qu'il appelle en profitent, sauf s'ils sont créés avec USEADPAUT(*NO) (voir aussi la valeur système QUSEADPAUT).

Bien utilisée, l'adoption renforce la sécurité : IBM décrit la technique qui met tous les objets d'une application en *PUBLIC *EXCLUDE et ne les ouvre qu'à travers les programmes de l'application, qui adoptent le profil propriétaire. Hors de l'application, l'utilisateur n'a plus accès aux données.

Dix conseils pour des droits clairs

Ces conseils reprennent les recommandations d'IBM, avec ce que nos essais ont montré :

1. Faites simple. IBM le dit en premier : un plan de sécurité simple est plus facile à gérer et à auditer, et plus rapide, à l'exécution comme à la sauvegarde.
2. Ne protégez que ce qui doit l'être. Repérez les fichiers confidentiels et protégez-les ; laissez un droit public aux objets sans enjeu (zones de données, files de messages).
3. Allez du général au particulier. Les bibliothèques d'abord, les objets un par un seulement si nécessaire ; puis le droit public, ensuite les groupes, enfin les utilisateurs.
4. Donnez les droits aux groupes, pas aux personnes. Et n'ajoutez pas à un membre un droit plus faible que celui de son groupe ou du public : il le masquerait, comme dans notre essai 3.
5. Regroupez par listes d'autorisation les objets qui ont les mêmes besoins.
6. Réglez le CRTAUT de chaque bibliothèque sur le droit public de la majorité de ses objets, et surveillez qui peut le changer.
7. Ne comptez pas sur les menus. IBM prévient : avec un produit comme IBM i Access ou des lignes de communication, ne vous fiez pas seulement aux menus et à LMTCPB ; un client ODBC lit un fichier sans passer par aucun menu. Seuls les droits sur les objets protègent vraiment les données.
8. Adoptez avec parcimonie. Faites adopter un profil propriétaire de l'application plutôt que QSECOFR ou un profil *ALLOBJ ; n'offrez pas de ligne de commande dans un programme qui adopte ; qualifiez les bibliothèques de ses appels (pas de *LIBL) ; retirez de la liste de bibliothèques ce qu'il y a ajouté avant de rendre la main.
9. Gardez les droits spéciaux pour ceux qui en ont besoin. Un *ALLOBJ passe outre tous les droits sur les objets (voir les droits spéciaux).
10. Contrôlez régulièrement, et laissez le système vous dire ce qui suffit : la collecte des droits (STRAUTCOL) enregistre les vérifications faites pendant que l'application tourne, pour ne garder que les droits nécessaires.

Contrôler les droits en SQL

Trois requêtes exécutées sur notre IBM i 7.5. Les objets d'une bibliothèque que le public peut modifier :

SELECT SYSTEM_OBJECT_NAME, OBJECT_TYPE, OBJECT_AUTHORITY
  FROM QSYS2.OBJECT_PRIVILEGES
 WHERE SYSTEM_OBJECT_SCHEMA = 'JOBIPRF'
   AND AUTHORIZATION_NAME = '*PUBLIC'
   AND OBJECT_AUTHORITY IN ('*ALL', '*CHANGE')

Sur JOBIPRF, elle renvoie une ligne : DTA5, public *CHANGE, celle de l'essai 5. Les programmes qui adoptent, avec leur propriétaire :

SELECT PROGRAM_LIBRARY, PROGRAM_NAME, PROGRAM_OWNER, USE_ADOPTED_AUTHORITY
  FROM QSYS2.PROGRAM_INFO
 WHERE PROGRAM_LIBRARY = 'JOBIPRF'
   AND USER_PROFILE = '*OWNER'

Elle renvoie LIRESECR, propriétaire JOBIAPP. Et ceux, plus dangereux, dont le propriétaire a *ALLOBJ (aucun dans JOBIPRF) :

SELECT P.PROGRAM_LIBRARY, P.PROGRAM_NAME, P.PROGRAM_OWNER
  FROM QSYS2.PROGRAM_INFO P
  JOIN QSYS2.USER_INFO_BASIC U
    ON U.AUTHORIZATION_NAME = P.PROGRAM_OWNER
 WHERE P.PROGRAM_LIBRARY = 'JOBIPRF'
   AND P.USER_PROFILE = '*OWNER'
   AND U.SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'

Les commandes et services pour aller plus loin :

Questions fréquentes