Sécurité sur IBM iSeries

Sommaire :

• Niveaux de sécurité |
• Assistant de configuration de sécurité iSeries Navigator |
• Diverses questions |
• Mesures préventives |

Sécurisation de l’AS400. Voir aussi des listes de commandes et paramètres de sécurité dans la page «pêle-mêle AS400».

Niveaux de sécurité

Le niveau s’établit avec la valeur système QSECURITY

• 10 – accès libre. N’existe plus.
• 20 – Accès par mot de passe. Tous les utilisateurs ont accès à tous les objets du sytème. Attention: le passage du niveau 20 à 30 peut être très difficile.
• 30 – Apparition des autorités sur les objets. On peut être amené à redescendre à ce niveau si des conflits de logiciels empêchent un fonctionnement correct au niveau 40.
• 40 – Niveau par défaut à la livraison. L’intégrité de la partie système est préservée. On ne peut programmer sa propre interface.
• 50 – Protection de l’intégrité renforcé.

La meilleure approche est de bien séparer les utilisateurs en groupes et d’utiliser le contrôle de groupe.

Assistant de configuration de sécurité iSeries Navigator

Dans le panneau de gauche, ouvrir Mes connexions > choisir le serveur > Sécurité. Dans la partie « Tâches liées à la sécurité » (en bas à droite), choisir Configuration de la sécurité du serveur. Après une série de questions sur le système et ses connexions, on obtient deux fichiers texte qui énumèrent et explicitent les préconisations d’IBM. Ces dernières peuvent ensuite être choisies individuellement (cases à cocher) et on peut les appliquer si on le désire.

Diverses questions

Contrôle d’audit

L’audit se gère avec la valeur système QAUDCTL et les suivants (QAUDLVL…). Il est utilisable quel que soit le niveau de sécurité. Son utilisation est particulièrement utile si on veut monter aux niveaux 40 ou 50.

Pour passer au niveau 40, il faut activer les audits *AUTFAIL et *SECURITY (valeur sytème QAUDLVL). Le journal obtenu permettra de découvrir déventuelles violations de protection au niveau 40.

Profils ayant le droit spécial *ALLOBJ

Un tel utilisateur peut faire ce qu’il veut, et si d’autres peuvent soumettre une commande avec ce profil…

*ALLOBJ ne devrait pas être utilisé au niveau groupe. On peut utiliser d’autres droits, par exemple *JOBCTL permet de voir le joblog d’un utilisateur. Operation Navigator fournit des outils : Clic droit sur le nom du système > Administration d’application > Application hôte > ouvrir l’arbre OS/400 > ouvrir "tous objets" > Cocher dans la colonne "Accè à tous les objets" > Personnalisation > A ce point on peut choisir le/les utilisateur(s). Dans ce cas particulier, il existe une commande équivalente (Work with Function Usage, WRKFCNUSG). Si nécessaire on pourra créer un programme dont le propriétaire aura une autorité ou le droit spécial suffisant pour accomplir la tâche. Cette approche évite d’avoir trop d’utilisateur élevés au rang de *SECADM.

Mesures préventives

Vite-vite et pêle-mêle, quelques saines habitudes : investigations et vérifications.

Mots-de-passe utilisateurs

• ANZDFTPWD : (Analyze Default Passwords) liste des profils qui ont un mot de passe identique à l’userid.
• CRTUSRPRF : créer les profils avec mot de passe *NONE, et création d’un mot de passe seulement quand l’utilisateur demandera à se servir du profil qu’on lui a attribué. Et encore on le crée *EXPIRED, ce qui l’obligera à le changer illico.
• ANZPRFACT : permet de désactiver les profils inactifs depuis n. jours.

Fonctions réalisées par plusieurs commandes ou API

Recherche dans les bibliothèques AS400 : WRKOBJ *ALL/[nom_cde] *CMD

Recherche dans l’IFS. Ne pas oublier les commandes UNIX équivalentes. Exemple : CRTDIR et MKDIR.

Rechercher dans les API de programmation réalisant la fonction qu’on recherche. Exemples : remove() et rename(). Il convient d’avoir une sérieuse sécurité des objets pour éviter l’utilisation de commande par qui n’en a pas besoin.

Objets inutilisés

Ceci concerne particulèrement les produits pas ou plus utilisés.

Noter que dans une bibliothèque *PUBLIC *CHANGE (ou plus), des utilisateurs peuvent y stocker (donc camoufler) des programmes et données.

Profils *PUBLIC *USE ou plus

Il est possible de soumettre une tâche sous un profil, si on a l’autorité *USE sur ce dernier (à la création, un profil a l’autorité *PUBLIC mise à *EXCLUDE). On se méfiera particulièrement des profils ayant *ALLOBJ parmi les droits spéciaux.

Au niveau de sécurité 30, il suffit d’avoir l’autorité sur la job description pour pouvoir l’utiliser.

Au niveau de sécurité 40 et plus, les utilisateurs doivent être autorisés à la fois sur la job description et sur le profil qu’elle contient. Mais si un profil est autorisé *PUBLIC, les utilisateurs peuvent toujours utiliser la job description, même au niveau 50.

Pour trouver les utilisateurs ayant une autorité privée sur les profils, et les profils *PUBLIC : PRTPVTAUT *USRPRF

Copies non sécurisées de données de production

Il s’agit notamment des bibliothèques et partitions de test qui ne sont pas sécurisées comme celles de production, pour de pures raisons de commodité pour les équipes de développement.

On laisse aussi souvent des bandes de sauvegardes au fond de tiroirs ou sur des rayonnages. Les emplacements de rangements devraient être formellement déterminés.

Serveurs démarrés et non utilisés

A vrai dire, comme ce qui précède, pas un problème spécifique à l’AS400.

Attention : des serveurs qui ne sont pas paramétrés à démarrage automatique peuvent être quand même lancés explicitement par le QSTRUP ou des applications tiers.

Profils IBM

On use et abuse parfois de profils comme QUSER ou QPGMR. Il est regrettable de leur voir ajoutées des autorités spéciales. Notamment *ALLOBJ.

Attention aux Groupes de profils. Supposons QPGMR avec le droit spécial *ALLOBJ et une application (cas fréquent) possédée par QPGMR. Tout profil du même groupe peut faire ce qu’il veut avec tout objet possédé par QPGMR. Commandes de vérification :

• DSPUSRPRF USRPRF(Qxxxxxxx) *OBJOWN
• DSPUSRPRF USRPRF(Qxxxxxxx) *OBJAUT