Discussion :

[Sankasssss]

Bonjour,
J'aurais voulu savoir si il était possible de bloquer l'accès à les commandes STRSQL et STRPDM afin que l'utilisateur ne puisse pas rentrer de requête sql sur le système...
Je suppose que via le profil d'un utilisateur on doit pouvoir donner des autorisations sur ce qu'il a accès ou pas .
Merci d'avance.

[Sankasssss]

J'ai trouvé en navigant dans les menus la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WRKOBJ

à laquelle j'ai mi comme paramètre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Objet  . . . . . . . . . . . . .   strsql  
  Bibliothèque . . . . . . . . .     *LIBL 
Type d'objet . . . . . . . . . .   *cmd

la je rentre l'option 2 =Réviser les droits.
J'obtiens un écran avec les droits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
                       Révision des droits sur un objet                      
                                                                             
Objet  . . . . . . . :   STRSQL          Propriétaire . . . . :   QSYS       
  Bibliothèque . . . :     QSYS          Groupe principal . . :   *NONE      
Type d'objet . . . . :   *CMD            Unité ASP  . . . . . :   *SYSBAS    
                                                                             
Indiquez les modifications sur les droits actuels, puis appuyez sur ENTREE.  
                                                                             
  Objet protégé par la liste d'autorisation . . . . . . . . . .   *NONE      
                                                                             
                         Droits                                              
Utilisat    Groupe      sur objet                                            
*PUBLIC                 *USE

que l'on a changé en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
                       Révision des droits sur un objet                      
                                                                             
Objet  . . . . . . . :   STRSQL          Propriétaire . . . . :   QSYS       
  Bibliothèque . . . :     QSYS          Groupe principal . . :   *NONE      
Type d'objet . . . . :   *CMD            Unité ASP  . . . . . :   *SYSBAS    
                                                                             
Indiquez les modifications sur les droits actuels, puis appuyez sur ENTREE.  
                                                                             
  Objet protégé par la liste d'autorisation . . . . . . . . . .   *NONE      
                                                                             
                         Droits                                              
Utilisat    Groupe      sur objet                                            
*PUBLIC                 *EXCLUDE                                             
PHIL                    *USE

Mais sans résultat , mon collègue a essayé de se re-logué et a fait la commande et il y a accès.

Je continue mes investigations

[K2R400]

Enlève *ALLOBJ à ton collègue et tu verras que ce que tu as fais marche très bien.

Avant de mettre de la sécurité en oeuvre, il faut savoir comment elle marche. Il y a des cours sur le sujet.

[Mercure]

+1 avec K2R400.

Et puis, si tu modifies les autorisations sur les commandes système, sois conscient que ces modifications ne seront pas reportées lors d'un upgrade du système.

[Sankasssss]

Très bonnes interventions de votre part
Ça fonctionne effectivement mieux sans le *ALLOBJ.

Concernant :

Avant de mettre de la sécurité en oeuvre, il faut savoir comment elle marche. Il y a des cours sur le sujet.

Je suis tout à fait d'accord avec toi, mais certaine pression de la direction font que l'on recherche une solution plus que rapide, trouvée en partie grâce à vous.
Si tu as des cours a m'indiquer sur le sujet, je suis tout à fait preneur...

[Invité]

Si tu as des cours a m'indiquer sur le sujet, je suis tout à fait preneur...

Ce n'est pas un cours, loin de là, mais voici un petit schéma que j'avais fait dans une mission qui explique les vérifications que l'OS fait quand on essaie d'accéder à un objet (hors IFS et folders).

James

[Invité]

Bonjour Sankasssss,

Quand on veut toucher aux commandes standard, le mieux est de les dupliquer dans une bibliothèque autre, qui sera en tête de LIBL.
Ainsi, tu pourras modifier les droits sur cette commande, sans impacter celle fournie en standard par IBM.
L'avantage est que les changements de version se feront sans avoir à remodifier les droits privés sur cette commande.
Les inconvénients (non exhaustifs) : s'assurer que la commande native IBM de la nouvelle version installée est compatible avec ton "ancienne" dupliquée (99% de chances, mais à tester), et surtout, rien n'empéchera ton utilisateur de faire QSYS/STRSQL, et donc les droits privés de ta commande dupliquée ne serviront à rien ...
Une autre solution est de faire un CL de post-installation : après chaque montée de version, tu passes un PGM que tu as fait, qui va modifier les droits privés des commandes IBM, qui change les valeurs pas défaut de ces dernières, etc ... Il faut par contre être très rigoureux sur la mise à jour du PGM ! Et ce n'est pas recommandé (en tout cas par moi ;-)
De plus, cela ne changera en rien le problème du droit *ALLOBJ (sur le profil, le profil de groupe, le PGM adoptant)
Autres solutions : faire un appel temporaire à un petit PGM qui vérifie le user courant, une ligne de commande "maison" qui empèche certaines commandes, etc ...
Une autre solution (mais à vérifier) : les points d'exit. En V7 il y en a maintenant un qui peut bloquer la modification de sources (http://www-01.ibm.com/support/docvie...id=swg21429591), il faudrait chercher si un point d'exit peut solutionner tes besoins ... Et si tu es dans une version adéquate ...
Tu parles de STRSQL et STRPDM, mais tu as aussi les accès ODBC qui peuvent faire les même "dégats", l'application QM, un petit SQLRPG, le Shell, etc ...

Pour être clair, même si l'image lui colle à la peau , la plateforme i (AS400, iSeries, IBM i & co) n'est plus à l'heure des menus qui rendaient l'administration de la sécurité simple (simpliste ?). Le monde i s'est largement ouvert et bénéficie de nombreuses nouvelles fonctionnalités, ce qui fait qu'il reste encore présent ... Le corollaire, c'est qu'il devient possible d'accéder à ses données de pas mal de manières et qu'il faut les connaître pour les sécuriser ...

En résumé, on ne sait pas bien ce que tu veux "interdire" (contrôler, tracer, interdire les update, la visualisation, les delete ??? A un utilisateur, tous, un groupe, une classe ??? Sur un fichier précis, les fichiers d'une bibliothèque, tous ???), ce qui ne nous aide pas à t'apporter une réponse
Soit un peu plus précis sur ce que tu souhaites

Amicalement,

James

[pwrdwnsys]

Bonjour Sankasssss,

Quand on veut toucher aux commandes standard, le mieux est de les dupliquer dans une bibliothèque autre, qui sera en tête de LIBL.
Ainsi, tu pourras modifier les droits sur cette commande, sans impacter celle fournie en standard par IBM.

Je pense que les commandes PROXY (commande CRTPRXCMD) sont encore plus pérennes : la compatibilité aux changements de versions est assurée et on ne touche jamais aux commandes système...
D'ailleurs, la commande STRPDM est une commande PROXY (fais un DSPCMD STRPDM et tu verras)

[FORMULARY]

Il faut aussi regarder les adoptions de droits :

Si c'est un programme compilé avec user(*owner) qui exécute la commande, et que le propriétaire a droit à la commande, n'importe qui qui utilise le programme pourra utiliser la commande.