Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Protéger SJ sous SDSF
Bonjour,
nous cherchons à protéger la commande SJ (Show Jcl) sous SDSF.
Nous avons mis en place le profile JESSPOOL node.userid.jobname.jobid.JCL en UACC=NONE(seuls quelques groupes d'informaticiens ont le droit READ). Ceci permet de bloquer le visionnage des jcl soumis par d'autres utilisateurs.
Ce que nous cherchons à faire et de bloquer pour les utilisateurs lamdas la commande SJ pour leurs propres jobs.
Quelqu'un a-t-il déjà eu le problème ? Et surtout a-t-il trouvé une solution ?
Merci.
Le JCL restera visible en browsant l'output du job (JESJCL)
Bonjour, oui je viens de trouver dans une doc z/Os deux phrases qui tuent ! Je cite : All users can access the JESSPOOL resources they own. Users do not need access authority to work with their own jobs and output.Envoyé par Peut-êtreUneRéponse
Le seul moyen est donc a priori de bloquer l'accès à SDSF pour la population concernée.
Dans ce cas,
pourquoi ne pas bloquer SDSF et afficher tous les comptes rendus sous un Beta92 ou quelque chose comme ça.
Cette technique est normalement utilisée pour tous les environnements de recette ou de production afin d'éviter la manipulation intempestive de jobs planifiés ou autres...
Mais quel est l'intérêt de ce blocage ?
La confidentialité surement.
oui mais pour leur propres jobs ? ... curieux ...
Bonjour,
j'ai effectivement aussi connu ça dans une banque, pour la confidentialité en production, tous les accès aux output SDSF des jobs étaient verrouillés via RACF.
pas grand intérêt sachant que de toute façon les comptes rendus de Jobs étaient dans BEta92 et dispo aux développeurs internes comme les accès TSO sur la production d'ailleurs, et heureusement, j'imagine mal comment debugger sinon.
Je me demande si ce genre de chose n'est pas inclus dans les règles très strictes de confidentialités de certains pays , genre regles PSF pour le Luxembourg par exemple.
Il est vrai que restreindre les accès au spool est assez surprenant.
J'ai pas accès à l'Output Queue sur l'environnement Production ou Recette mais :
En codant PRE* puis OWNER* dans l'Input Queue, si tu arrives à choper le job => mettre un S devant et PAF! display des sysouts à la suite ... (et pas de RACF :p)
Bonjour,
je donne quelques détails pour préciser l'action que nous souhaitons effectuer. Il s'agit effectivement d'une production bancaire, pour laquelle existe un atelier Infocentre qui lance des requêtes via WebFocus. Ces requêtes ne sont pas de la production "pure", et ceux qui les soumettent sont des banquiers. Les jobs soumis sont donc disponibles sous SDSF, et il arrive que certains se débrouillent à effectuer à partir de celà d'autres requêtes plus ou moins consommatrices, et plus ou moins "confidentielles". Du coup la production est impactée régulièrement, et certains débordent du cadre de leurs attributions.
Je cherche des pistes avec d'autres ressources RACF. Je vous tiens au courant.
@ Skylyn, le S devant le job résoud pas tout car seules les sysout définies et autorisées apparaissent. Par exemple, si il n'y a pas de sortie définie pour un IDCAMS, tu ne vois pas la commande :
//xxxxxxxR JOB xxxxxxxx,REGION=4M,NOTIFY=&SYSUID,CLASS=x,
// MSGLEVEL=(1,1),MSGCLASS=x,COND=(4,LT)
//AA01 EXEC PGM=IDCAMS
//SYSPRINT DD DUMMY
//SYSIN DD *
DEFINE ALIAS(NAME(XXXXXXX) RELATE(USERCAT.USERID))
Résultat en faisant S
2 //AA01 EXEC PGM=IDCAMS
3 //SYSPRINT DD DUMMY
4 //SYSIN DD *
ICH70001I xxxxxxxx LAST ACCESS AT 16:10:41 ON THURSDAY, FEBRUARY 21, 2013
IEF236I ALLOC. FOR xxxxxxxR AA01
IEF237I DMY ALLOCATED TO SYSPRINT
IEF237I JES2 ALLOCATED TO SYSIN
IEF142I xxxxxxxR AA01 - STEP WAS EXECUTED - COND CODE 0012
IEF285I xxxxxxxx.xxxxxxxR.JOBnnnnn.D0000101.? SYSIN
IEF373I STEP/AA01 /START 2013052.1612
IEF032I STEP/AA01 /STOP 2013052.1612
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
VIRT: 320K SYS: 300K EXT: 8K SYS: 12728K
IEF201I xxxxxxxR AA01 - JOB TERMINATED BECAUSE OF CONDITION CODES
IEF375I JOB/xxxxxxxR/START 2013052.1612
IEF033I JOB/ExxxxxxxR/STOP 2013052.1612
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
******************************** BOTTOM OF DATA *********************************
Donc tu ne peux pas récuperer dans ce cas le contenu de la Sysin.
Dans mon cas, la requête n'apparait pas non plus, elle n'est donc disponible que via la commande SJ qui donne le JCL effectivement soumis.
En espérant avoir été clair dans mes explications
Je travaille en banque aussi, j'ai quelquefois utilisé un peu trop de ressources aux goûts des pilotes de la prod.
Après m'être fait remonter les bretelles, je fais nettement plus attention à ce que je lance.
Au lieu de tout bloquer, engueuler les gens, ça marche aussi!
Bonjour,
@rg903 : Tu ne peux pas tout récupérer mais dans les listes de sysouts dans la B92, tu vois une liste sysout qui s'appelle JESJCL et qui te permet de voir la trame JCL utilisée, les steps etc...
Déjà, Je trouve plutôt curieux que des utilisateurs "métier" aient accès à un Mainframe de production directement à travers TSO et SDSF.
En général, ce type d'accès est réalisé à travers des outils décisionnels avec une interface sur un poste de travail et un retour des résultats. Mais bon, la mise en place est plus complexe et plus coûteuse et peut générer d'autres problèmes.
Sur notre site de production nous disposons d'un mécanisme un peu voisin de celui que tu évoques mais réservé à la MOE, strictement limité en temps CPU et dont le résultat est écrit dans un fichier avec une règle de nommage précise. La problématique de la sécurité est alors déportée sur ce fichier et est sans doute plus facile à gérer.
Sinon, pour ton problème précis, n'est pas plutôt la commande SUB de TSO qu'il faudrait interdire à cette classe d'utilisateurs plutôt que la commande SJ de SDSF ?
Bonjour,
concernant les utilisateurs, il s'agit d'un atelier que l'on appelle Infocentre, ils sont dans ce cadre autorisés à soumettre des jobs. C'est limité en temps CPU, mais le problème est que certains sont d'ex-informaticiens, et grâce à SJ récupèrent les jobs, se les stocke, et les adaptent afin de requêter en dehors du cadre de leur outil. Ils peuvent donc changer les classes d'exécution de sortie, ...
Il n'y a pas pour ainsi de fraude ou de manque de respect au niveau confidentialité. C'est juste pour éviter les JCL "sauvages".
Ensuite pour Beta92, je ne connais pas cet outil, nous avons WSF2 (ou EOS) pour le stockage des sysout. Là il est possible de limiter l'accès aux retours de jobs pour les utilisateurs et de ne leur permettre de voir que les états (sorties) qu'ils génèrent. Il s'agit de Spool différents.
De toute façon, nous avions d'autres chats à fouetter, nous n'avons pas poussé plus loin dans les investigations. Et puis, je pars sur une autre mission, donc un autre client, une autre banque en fin de semaine prochaine.
Dommage, j'aurai bien aimé savoir si il y avait une solution.
A bientôt peut-être
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager