+ Répondre à la discussion
Affichage des résultats 1 à 15 sur 15
  1. #1
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut 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.

  2. #2
    Membre chevronné Avatar de Peut-êtreUneRéponse
    Homme Profil pro
    z/OS Senior Technical Leader, IBM Certified Database Associate - DB2 10.1 Fundamentals
    Inscrit en
    décembre 2006
    Messages
    543
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : z/OS Senior Technical Leader, IBM Certified Database Associate - DB2 10.1 Fundamentals
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2006
    Messages : 543
    Points : 732
    Points
    732

    Par défaut

    Le JCL restera visible en browsant l'output du job (JESJCL)

  3. #3
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Peut-êtreUneRéponse Voir le message
    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.
    Le seul moyen est donc a priori de bloquer l'accès à SDSF pour la population concernée.

  4. #4
    Membre habitué
    Homme Profil pro
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    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...

  5. #5
    Membre Expert

    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 226
    Points : 2 272
    Points
    2 272

    Par défaut

    Citation Envoyé par rg903 Voir le message
    ...
    Ce que nous cherchons à faire et de bloquer pour les utilisateurs lamdas la commande SJ pour leurs propres jobs.
    Mais quel est l'intérêt de ce blocage ?

  6. #6
    Membre Expert Avatar de bernard59139
    Profil pro
    Administrateur de base de données
    Inscrit en
    octobre 2006
    Messages
    752
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : octobre 2006
    Messages : 752
    Points : 1 431
    Points
    1 431

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Mais quel est l'intérêt de ce blocage ?
    La confidentialité surement.

  7. #7
    Membre Expert

    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 226
    Points : 2 272
    Points
    2 272

    Par défaut

    Citation Envoyé par bernard59139 Voir le message
    La confidentialité surement.
    oui mais pour leur propres jobs ? ... curieux ...

  8. #8
    Membre confirmé
    Femme Profil pro
    Architecte technique
    Inscrit en
    janvier 2008
    Messages
    159
    Détails du profil
    Informations personnelles :
    Sexe : Femme

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2008
    Messages : 159
    Points : 278
    Points
    278

    Par défaut

    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.

  9. #9
    Expert Confirmé Sénior
    Homme Profil pro
    Ingénieur d'Etude Mainframe
    Inscrit en
    novembre 2012
    Messages
    808
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'Etude Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : novembre 2012
    Messages : 808
    Points : 4 893
    Points
    4 893

    Par défaut

    Il est vrai que restreindre les accès au spool est assez surprenant.

  10. #10
    Membre habitué
    Homme Profil pro
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    Citation Envoyé par xfanx Voir le message
    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.
    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)

  11. #11
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Skylyn Voir le message
    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

  12. #12
    Nouveau Membre du Club
    Profil pro
    Développeur COBOL
    Inscrit en
    mai 2009
    Messages
    30
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : mai 2009
    Messages : 30
    Points : 28
    Points
    28

    Par défaut

    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!

  13. #13
    Membre habitué
    Homme Profil pro
    Ingénieur d'étude Mainframe
    Inscrit en
    septembre 2012
    Messages
    61
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur d'étude Mainframe
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2012
    Messages : 61
    Points : 114
    Points
    114

    Par défaut

    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...

  14. #14
    Membre Expert

    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 226
    Points : 2 272
    Points
    2 272

    Par défaut

    Citation Envoyé par rg903 Voir le message
    ... 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.
    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 ?

  15. #15
    Invité de passage
    Homme Profil pro
    Analyste d'exploitation
    Inscrit en
    octobre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste d'exploitation
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 11
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •