> Tech > Se protéger contre la ligne de commande

Se protéger contre la ligne de commande

Tech - Par iTPro - Publié le 22 février 2012
email


L’option 5 du PAYMENU présente une autre difficulté que nous devons régler. Nous voulons permettre aux utilisateurs d’examiner leurs rapports à l’aide de la commande WRKSPLF, mais nous savons que l’affichage de celle-ci contient une 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.
 

Téléchargez gratuitement cette ressource

Guide de Services Cloud Managés

Guide de Services Cloud Managés

Accélérer votre transformation digitale, protéger et sécuriser vos environnements Cloud avec les offres de support, d'accompagnement et de services managés. Découvrez le TOP 3 des Services Managés pour accompagner la transformation de vos environnements Cloud, gagner en agilité et en sécurité dans un monde d'incertitudes.

Tech - Par iTPro - Publié le 22 février 2012