Se protéger contre la ligne de commande

Si les utilisateurs ne sont pas configurés comme étant restreints vis-à-vis de la ligne de commande, ils peuvent faire beaucoup de dégâts à partir d’une ligne de commande, y compris supprimer des fichiers de production. Bien qu’il soit fortement recommandé de ne pas donner aux utilisateurs finaux l’accès par ligne de commande, cette recommandation n’est pas toujours facile à appliquer.

Dans ce scénario, nous supposons que BOB a l’accès par ligne de commande (c’est-à-dire, CRTUSRPRF LMTCPB(*NO)). Comme nous devons fournir l’accès à la commande WRKSPLF, nous devons contrôler l’adoption à nouveau comme nous l’avons fait en donnant l’accès à Query. Mais cette fois-ci, il y a une différence : nous n’adopterons aucune autorité, et nous n’utiliserons pas l’autorité adoptée passée. Nous donnerons à BOB l’accès à la ligne de commande mais seulement quand toute autorité adoptée aura été supprimée. Pour cela, il nous faut à nouveau écrire un programme CL simple qui exécute la commande WRKSPLF :

PGM
MONMSG CPF0000 /* Ignore any Errors */
QSYS/WRKSPLF
ENDPGM

Nous créons le programme et spécifions qu’il adopte l’autorité avec USRPRF(*USER). Ensuite, avec USEADPAUT(*NO), nous changeons le programme afin qu’il n’utilise aucune autorité adoptée qui lui a été passée :

CRTCLPGM PGM(PAYOBJ/RPTPGM) USRPRF(*USER)
SRCFILE(MYLIB/QCLSRC) SRCMBR(RPTPGM)

CHGPGM PGM(PAYOBJ/RPTPGM) USEADPAUT(*NO)

Adopter ou ne pas adopter

Je suis partisan d’utiliser l’autorité adoptée dans la mise en œuvre des systèmes applicatifs de gestion et des utilitaires opérationnels. Nous avons tendance à donner bien trop de latitude aux utilisateurs, au risque d’en payer le prix : applications détruites, données volées et de mauvaises notes dans nos audits IT.

Je vous engage à rechercher les occasions d’utiliser l’autorité adoptée et la possibilité de stopper l’adoption en utilisant USEADPAUT(*NO) quand vous devez contrôler l’accès dans une application adoptante. Voir aussi l’encadré (ci-dessous) à propos de l’utilisation de la fonction MODINVAU de préférence à USEADPAUT(*NO).

Une dernière chose : la liste de bibliothèques

Si possible, essayez de qualifier tout vis-à-vis de la bibliothèque quand vous êtes en autorité adoptée. Les utilisateurs intelligents savent comment créer des programmes et changer leur liste de bibliothèques. S’ils créent un programme avec le même nom que votre programme qui utilise l’autorité adoptée, puis placent leur bibliothèque devant la bibliothèque de production, ils peuvent usurper l’autorité adoptée. Qualifiez vis-à-vis de la bibliothèque tous vos appels dans les programmes adoptants, pour déjouer de telles tentatives. Au lieu de

CALL MYPGM

ou

CALL *LIBL/MYPGM

utilisez

CALL MYLIB/MYPGM

Et souvenez-vous : n’adoptez que l’autorité dont vous avez besoin, jamais plus.

Pour aller plus loin avec les experts iTPro.fr sur la thématiques des lignes de commandes, c’est ici :

Tips pour le travail en réseau et l’administration des systèmes · iTPro.fr

Gérer l’état des machines virtuelles avec PowerShell · iTPro.fr