Blocage de commande (STRSQL et STRPDM)

Sankasssss · 03/03/2011, 13h50

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 · 03/03/2011, 15h42

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 · 03/03/2011, 16h02

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 · 03/03/2011, 16h12

+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 · 03/03/2011, 16h31

Très bonnes interventions de votre part

Ça fonctionne effectivement mieux sans le *ALLOBJ.

Concernant :

Citation:

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 · 03/03/2011, 16h39

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 · 03/03/2011, 17h12

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 · 03/03/2011, 17h40

Citation:

Envoyé par Sankasssss

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 · 03/03/2011, 17h48

Citation:

Envoyé par James_uc

...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 · 03/03/2011, 18h10

Citation:

Envoyé par 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.

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 · 03/03/2011, 18h28

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 · 03/03/2011, 19h15

Citation:

Envoyé par K2R400

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 · 03/03/2011, 19h18

Citation:

Envoyé par pwrdwnsys

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 · 03/03/2011, 19h31

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 · 04/03/2011, 11h17

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.

03/03/2011, 13h50	#1
Sankasssss Modérateur Gaëtan Wauthy Développeur .NET Inscription : novembre 2006 Messages : 1 000 Détails du profil Informations personnelles : Nom : Gaëtan Wauthy Âge : 29 Localisation : Belgique Informations professionnelles : Activité : Développeur .NET Secteur : Administration - Collectivité locale Informations forums : Inscription : novembre 2006 Messages : 1 000 Points : 1 831 Points : 1 831	Blocage de commande (STRSQL et STRPDM) 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. __________________ Règles du forum + Comment utiliser Developpez.com = Si vous développez en .NET, la FAQ, les tutos et l'aide MSDN sont vos amis !!! LINQ c'est puissant...
	00

03/03/2011, 16h39	#6
FORMULARY Membre éclairé Inscription : septembre 2008 Messages : 251 Détails du profil Informations personnelles : Sexe : Localisation : France Informations forums : Inscription : septembre 2008 Messages : 251 Points : 309 Points : 309	Blocage de commande (STRSQL et STRPDM) 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.
	10

04/03/2011, 11h17	#15
Sankasssss Modérateur Gaëtan Wauthy Développeur .NET Inscription : novembre 2006 Messages : 1 000 Détails du profil Informations personnelles : Nom : Gaëtan Wauthy Âge : 29 Localisation : Belgique Informations professionnelles : Activité : Développeur .NET Secteur : Administration - Collectivité locale Informations forums : Inscription : novembre 2006 Messages : 1 000 Points : 1 831 Points : 1 831	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. __________________ Règles du forum + Comment utiliser Developpez.com = Si vous développez en .NET, la FAQ, les tutos et l'aide MSDN sont vos amis !!! LINQ c'est puissant...
	00

03/03/2011, 16h02	#3
K2R400 Membre Expert Patrick Inscription : mai 2008 Messages : 821 Détails du profil Informations personnelles : Nom : Patrick Âge : 42 Localisation : France, Hérault (Languedoc Roussillon) Informations forums : Inscription : mai 2008 Messages : 821 Points : 1 041 Points : 1 041	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.
	10

03/03/2011, 16h12	#4
Mercure Membre Expert Inscription : novembre 2004 Messages : 1 298 Détails du profil Informations forums : Inscription : novembre 2004 Messages : 1 298 Points : 1 355 Points : 1 355	+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.
	10

03/03/2011, 17h12	#7
James_uc Nouveau Membre du Club Inscription : mai 2008 Messages : 16 Détails du profil Informations forums : Inscription : mai 2008 Messages : 16 Points : 25 Points : 25	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
	10

03/03/2011, 18h28	#11
guesswho Invité régulier Inscription : février 2011 Messages : 3 Détails du profil Informations forums : Inscription : février 2011 Messages : 3 Points : 6 Points : 6	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 !
	10

03/03/2011, 19h31	#14
K2R400 Membre Expert Patrick Inscription : mai 2008 Messages : 821 Détails du profil Informations personnelles : Nom : Patrick Âge : 42 Localisation : France, Hérault (Languedoc Roussillon) Informations forums : Inscription : mai 2008 Messages : 821 Points : 1 041 Points : 1 041	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.
	10

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email