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

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

[James_uc]

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

[James_uc]

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

[K2R400]

...mais voici un petit schéma ... qui explique les vérifications que l'OS fait quand on essaie d'accéder à un objet (hors IFS et folders).

James,

Les droits fonctionnent aussi au niveau de l'IFS (les vieux folders sont une des branches de l'IFS).
C'est l'adoption de droits qui ne fonctionne pas avec l'IFS

[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)

[guesswho]

Bonjour,
tout a fait d'accord avec Jame uc....

en fait, c'est la politique de sécurité de son infra qu'il faut mettre à plat lorsque l'on veut sécuriser ses serveurs et applications....

d'où une remise à plat de la sécurité : matrice des fonctions des utilisateurs, matrice des flux (FTP, DRDA, ODBC, JDBC,...), utilisation de groupes, de liste d'autorisation, des valeurs systèmes, des exits, analyse de la sécurité des logiciels, des accès externes et internes,....
bref un vrai projet de plusieurs semaines.

pour le problème de commandes à bloquer : ce n'est réellement possible que si on respecte certaines règles : pas de droits spéciaux *allobj, pas de classe secofr, pas de ligne de commande (utilisation de menu controlé !), pas de ATTN (ou contrôlé), contrôle des logiciels (attention aux install qui laisse des profils avec QSECOFR/ALLOBJ/SECADM/SPLCTL et programme avec délégation de droits, suppression des profils génériques,.... et c'est pas toujours gagné lorsqu'on traine un historique.
La solution exit système (REGINF) me parait la meilleure (ou la moins pire !)car elle permet de traçer si ce n'est d'empécher les accès (tu es libre de mettre les controles et blocages que tu souhaites dans les exit : DRDA, ODBC/JDBC, FTP, Telnet, ...)
on ne vit pas dans un monde parfait !

[James_uc]

James,

Les droits fonctionnent aussi au niveau de l'IFS (les vieux folders sont une des branches de l'IFS).
C'est l'adoption de droits qui ne fonctionne pas avec l'IFS

Bonjour K2R400,

c'est vrai, mais je voulais juste préciser le concept de base "AS400", pour commencer, et ne pas noyer notre ami avec le concept IFS et sa gestion un moins facile du fait du multi-niveau.
Autant la partie /QSYS.LIB n'a que le niveau "bibliothèque" et "fichier / PGM / dtaara /etc ..." => assez facile à gérer.
La partie "root" peut rapidement devenir galère quand les répertoires s'imbriquent sur de nombreux niveaux : quand soucis de droits, il faut se taper les vérifications de niveau en niveau jusqu'à trouver le répertoire sur lequel le user n'a pas les droits :-(
A moins qu'il n'y ai une manipulation que je ne connais pas (genre héritage des droits)

James

[James_uc]

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)

Bonjour pwrdwnsys,

je ne connaissais pas
Merci pour l'info, je vais regarder ça.

James

[K2R400]

Les commandes proxy ne règlent pas les problèmes de droits.
Si la commande originale est en *EXCLUDE, même si la proxy est en *USE, la commande sera interdite.
Les proxy sont utiles pour donner des noms courts ou personnalisés à des commandes CL.

[Sankasssss]

Un très grand merci à tous les intervenants pour ces réponses très complète

Nous allons digérer tout cela et faire des tests afin de bloquer les principales commandes au plus vite.

Bonne journée à vous tous et encore pour votre professionnalisme.