le forum IBM i

Bonjour à tous,

Je cherche à protéger une outq, ou plutôt les spools qu'elle contient des utilisateurs, même les utilisateur avec droits *ALLOBJ ou *SPLCTL. Et cela doit être actif en 5250 mais aussi par tout autre moyen d'accéder au spool (sortie imprimante via ACS par exemple).

Pour cela j'ai essayé de brancher un programme sur le point d'Exit QIBM_QSP_SECURITY. Cela ne fonctionne pas, j'ai l'impression que mon programme n'est même pas appelé.
Est-ce que quelqu'un a déjà utilisé ce point d'exit ? Avec succès ?

Si vous avez d'autres idées pour protéger des spools, je prends aussi

Au plaisir d'échanger.
Merci
Delphine

Bonjour,

As tu essayé simplement en gérant les droits sur l'OUTQ (EDTOBJAUT) ?

Bonjour Delphine,

Difficile de protéger des spools des utilisateurs *ALLOBJ et *SPLCTL par définition !

Pour l'API, la doc (https://www.ibm.com/docs/en/i/7.5?topic ... urity.html) indique :

Exit Point QIBM_QSP_SECURITY allows registered exit programs to control access to spooled files on a file-by-file basis. The exit programs will be called at the beginning of each IBM i spool command or API, except under any of the following conditions:

1. The job or thread has spool control (*SPLCTL) special authority. The special authority may originate from the user profile, group profile, or adopted authority.
2.The job or thread has job control (*JOBCTL) special authority and the spooled file resides on an output queue with OPRCTL(*YES). The special authority may originate from the user profile, group profile, or adopted authority.
3.The command or API is executed in a system job (including SCPF), a subsystem monitor job, or any job that is running under one of the following system user profiles:
QAUTPROF, QCLUMGT, QCOLSRV, QDBSHR, QDBSHRDO, QDFTOWN, QDIRSRV, QDLFM, QDOC, QDSNX, QFNC, QGATE, QLPAUTO, QLPINSTALL, QMSF, QNETSPLF, QNFSANON, QNTP, QPEX, QPM400, QRJE, QSNADS, QSPL, QSPLJOB, QSRVAGT, QSYS, QTCP, QTFTP, QTSTRQS.

=> En plus clair :

1. Si le travail qui accède au spoule est démarré (ou adopté, y compris par un programme en *OWNER) par un utilisateur ayant *SPLCTL, le point d'exit n'est pas déclenché (y compris si provient d'un profil de groupe)
2. Idem pour un utilisateur *JOBCTL si l'outq contenant le spoule a OPRCTL(*YES)
3. Si l'accès se fait par un job système


De plus, il semble que pour des questions de performance, lors du premier accès à un spoule dans un travail, le système charge la liste des programmes associés au point d'exit QIBM_QSP_SECURITY et l'utilise ensuite durant la durée du job. Si cette liste vient à changer, il faut arrêter/démarrer un nouveau travail pour accéder au spoule et vérifier la prise en compte du point d'exit.


A vérifier pour commencer que les utilisateurs (y compris profils de groupe ou owner de programmes) ne disposent pas de *SPLCTL (ou *JOBCTL si les OUTQ sont avec OPRCTL(*YES)).

Hurri a écrit : ↑

jeu. 01 déc. 2022, 13:32:57

Bonjour,

As tu essayé simplement en gérant les droits sur l'OUTQ (EDTOBJAUT) ?

Bonjour, oui mais les utilisateurs *ALLOBJ passent les contrôles. Normal par définition pour les listes d'autorisation ...
Merci pour la proposition

nbonnet a écrit : ↑

jeu. 01 déc. 2022, 13:35:23

Bonjour Delphine,

Difficile de protéger des spools des utilisateurs *ALLOBJ et *SPLCTL par définition !

Pour l'API, la doc (https://www.ibm.com/docs/en/i/7.5?topic ... urity.html) indique :

Exit Point QIBM_QSP_SECURITY allows registered exit programs to control access to spooled files on a file-by-file basis. The exit programs will be called at the beginning of each IBM i spool command or API, except under any of the following conditions:

1. The job or thread has spool control (*SPLCTL) special authority. The special authority may originate from the user profile, group profile, or adopted authority.
2.The job or thread has job control (*JOBCTL) special authority and the spooled file resides on an output queue with OPRCTL(*YES). The special authority may originate from the user profile, group profile, or adopted authority.
3.The command or API is executed in a system job (including SCPF), a subsystem monitor job, or any job that is running under one of the following system user profiles:
QAUTPROF, QCLUMGT, QCOLSRV, QDBSHR, QDBSHRDO, QDFTOWN, QDIRSRV, QDLFM, QDOC, QDSNX, QFNC, QGATE, QLPAUTO, QLPINSTALL, QMSF, QNETSPLF, QNFSANON, QNTP, QPEX, QPM400, QRJE, QSNADS, QSPL, QSPLJOB, QSRVAGT, QSYS, QTCP, QTFTP, QTSTRQS.

=> En plus clair :

1. Si le travail qui accède au spoule est démarré (ou adopté, y compris par un programme en *OWNER) par un utilisateur ayant *SPLCTL, le point d'exit n'est pas déclenché (y compris si provient d'un profil de groupe)
2. Idem pour un utilisateur *JOBCTL si l'outq contenant le spoule a OPRCTL(*YES)
3. Si l'accès se fait par un job système


De plus, il semble que pour des questions de performance, lors du premier accès à un spoule dans un travail, le système charge la liste des programmes associés au point d'exit QIBM_QSP_SECURITY et l'utilise ensuite durant la durée du job. Si cette liste vient à changer, il faut arrêter/démarrer un nouveau travail pour accéder au spoule et vérifier la prise en compte du point d'exit.


A vérifier pour commencer que les utilisateurs (y compris profils de groupe ou owner de programmes) ne disposent pas de *SPLCTL (ou *JOBCTL si les OUTQ sont avec OPRCTL(*YES)).

Merci Nathanael.
Ceci explique cela ... car c'est justement les utilisateurs *SPLCTL et *ALLOBJ que je veux verrouiller. Pour les autres users la sécurité classique fait parfaitement le job. Du coup, j'essaie de passer via une api.

Jai retrouvé ca ...

La sécurité

petit rappel

Il convient de différencier 2 éléments à sécuriser

Les ressources
objets
objets avec data
les données de l'objets
fichiers de l'ifs

Les services
NETSERVER
ODBC
FTP

Pour les ressources

les autorisations spécifiques au niveau des profils sont rédhibitoires

on est le plus souvent sur de mécanisme IBMI natif

et une fois ces droits mis en place il est impossible d'agir derrière

*ALLOBJ
donne droit à tous les objets et fichiers de l'IFS
*JOBCTL
donne droit à la gestion de tous les travaux
*SPLCTL
donne droit à la gestion de tous les SPOOLs

il est donc très important de bien attribuer ces autorisations qu'aux personnes qui en ont réellement besoin

comment contourner

*ALLOBJ
aucun palliatifs

*JOBCTL et *SPLCTL

Les Programmes d'exit sur les spools ne sont pas pris en compte si vous avez ces droits

il va donc falloir agir sur les commandes liées au travaux et aux spools par exemple

Pour la gestion des spools et des travaux on peut éventuellement gérer les autorisations sur les commandes

ENDGJOB par exemple avec *EXCLUDE pour MICHEL

conseil:

dupliquer la commande dans une bibliothèque entête de liste de bibliothèque avant qsys

ou utiliser la programme d'exit de gestion de commandes et faire un programme qui dit quand c'est ENJOB et Michel je lui refuse

ca reste du bricolage , voir si d'abord on ne peut pas retirer ces droits

Bonjour,

Merci pour ce rappel important sur la sécurité informatique ! Il est essentiel de bien différencier les ressources et les services à sécuriser pour protéger les données et les objets sensibles.