IBM i, 10 mythes de sécurité courants

En tant que consultant, j’ai répondu à ces questions et j’ai mis un terme aux idées fausses sur un plan individuel. Mais il me semble intéressant de faire partager cette connaissance plus largement.

Mythe N° 1 : classe utilisateur

Le premier sujet abordé est l’attribut classe utilisateur (user class) du profil utilisateur. La classe utilisateur n’est jamais utilisée pour le contrôle d’autorité. J’aimerais avoir reçu un dollar chaque fois que quelqu’un m’a posé une question et, pour décrire la situation, a déclaré : « L’utilisateur est dans la classe utilisateur *SECOFR user class. » Lorsque vous voulez déterminer pourquoi un utilisateur ne peut pas accéder, ou peut mais ne devrait pas pouvoir accéder à un objet, vous devez ignorer l’attribut classe utilisateur. La classe à laquelle l’utilisateur appartient n’a aucune importance : l’algorithme de contrôle d’autorité ne regarde jamais cet attribut.

L’utilisateur pourrait être dans la classe *USER et avoir toutes les autorités spéciales. Ou bien, il pourrait être assigné à la classe utilisateur *SECOFR et n’avoir aucune autorité spéciale. Donc, en regardant la classe utilisateur, vous risquez de faire de fausses suppositions. Cette classe n’est utilisée que quand le profil est créé pour prendre par défaut l’attribution d’autorité spéciale de l’utilisateur, pour déterminer quelles options du menu IBM i il voit, et pour déterminer si les autorités spéciales devraient être ajustées quand on applique IPL au système entre le niveau de sécurité 20 et un niveau supérieur.

Mythe de sécurité N°2 : autorité adoptée

Compte tenu des termes utilisés, on voit bien pourquoi la plupart des gens pensent que le paramètre USEADPAUT contrôle si un programme adopte –
mais il ne fait pas cela. C’est l’attribut USRPRF qui contrôle. Quand USRPRF est réglé sur *USER – par défaut – le programme n’adopte pas. Quand USRPRF
est réglé sur *OWNER, le programme utilise l’autorité du propriétaire du programme si la personne qui appelle le programme a une autorité insuffisante.

Mais alors, que contrôle l’attribut USEADPAUT ? tout d’abord, permettez-moi d’expliquer qu’une fois qu’un programme adopte (USRPRF est réglé sur *OWNER),
l’autorité adoptée se répercute à tous les programmes appelés par la suite. Le paramètre USEADPAUT contrôle si un programme consommera ou utilisera l’autorité adoptée qui lui est transmise à partir d’un programme situé plus haut dans la pile d’appels des programmes. C’est le seul moyen pour
que l’autorité adoptée ne soit pas utilisée : vous ne pouvez pas contrôler le flux de l’autorité adoptée dans le programme qui adopte.

Mythe N° 3 : autorité adoptée et SQL dynamique

Pas exactement. S’il y a du SQL dynamique dans le programme, l’instruction dynamic SQL n’a pas accès à l’autorité adoptée provenant du programme.
Pour que l’instruction dynamic SQL adopte l’autorité, vous devez régler l’attribut Dynamic User Profile sur *OWNER lorsque vous compilez le programme.
Notez bien que j’ai dit lorsque vous compilez le programme. Vous pouvez définir les attributs d’autorité adoptée d’un programme soit quand vous le compilez, soit par la commande Change Program (CHGPGM).
Malheureusement, il n’existe pas d’interface permettant de changer l’attribut Dynamic User Profile une fois que le programme a été compilé. Pour changer la valeur, vous devrez recompiler le programme.

Mythe N° 4 : autorité spéciale *ALLOBJ

(Si vous attribuez *ALLOBJ directement à l’utilisateur, l’algorithme de vérification d’autorité IBM i reconnaîtra toujours le *ALLOBJ de l’utilisateur et n’ira jamais plus loin pour
vérifier si l’utilisateur a été exclu d’un fichier ou d’un autre objet.) Malheureusement, le fait d’attribuer *ALLOBJ au groupe de l’utilisateur procure une fausse impression de sécurité.
Oui, l’utilisateur recevra le message « Not authorized to object xxx » s’il essaie d’accéder directement à un objet duquel il a été exclu. Le problème est que tout ce que l’utilisateur
doit faire pour contourner ce blocage est de soumettre un job à exécuter comme un profil qui n’a pas été exclu de l’objet. Et ce n’est que l’un des modes de contournement.
Il y a tout simplement trop d’objets desquels vous devriez omettre l’utilisateur, pour couvrir toutes les méthodes d’accès alternatives. Vous ne seriez jamais sûr de les avoir couvertes toutes.
De plus, vous devriez passer le système au peigne fin après chaque mise à niveau pour découvrir les éventuelles nouvelles méthodes introduites par la nouvelle release.
Admettez donc que, quand vous attribuez l’autorité spéciale *ALLOBJ à un utilisateur – au niveau de l’utilisateur du groupe – il pourra accéder à tout objet sur le système.

Mythe N° 5 : niveau de sécurité 20

Il semble qu’il n’y ait pas de contrôles de sécurité, parce que, par défaut, tous les profils sont créés avec l’autorité spéciale *ALLOBJ. Par conséquent, par défaut, tous les utilisateurs
ont accès à tous les objets du système. Comme le même algorithme est utilisé à tous les niveaux, une fois qu’un profil a été créé, vous pouvez supprimer toute son autorité spéciale
*ALLOBJ et tester votre configuration de sécurité avant de passer à un niveau de sécurité supérieur.

Mythe N° 6 : intervalle d’expiration du mot de passe

Certains administrateurs donnent *NOMAX comme intervalle d’expiration de mot de passe aux profils qui n’ont pas de mot de passe (c’est-à-dire dont l’attribut PASSWORD est réglé sur *NONE).
Cela, parce qu’ils supposent à tort que le système vérifie ou que, d’une certaine manière, il demandera au profil de changer son mot de passe. Mais il n’en est rien : si le profil n’a pas de mot de passe,
l’intervalle d’expiration n’est jamais pris en considération. Par conséquent, il vaut mieux laisser l’intervalle d’expiration du mot de passe à sa valeur par défaut *SYSVAL.
On évitera ainsi des rapports des auditeurs (et de nous-mêmes) qui recherchent des profils avec des mots de passe qui ne changent jamais.

Mythe N° 7 : QAUDLVL2

En réalité, certaines entreprises les suppriment du système sans les sauvegarder du tout. Or, cette absence de sauvegarde peut être considérée comme une transgression des règles de conformité.
Par exemple, la Payment Card Industry (PCI) demande que l’information d’audit reste en ligne ou facilement accessible pendant 90 jours et que toute l’information d’audit soit conservée pendant un an au moins.
Donc, votre méthode de sauvegarde des récepteurs de journaux d’audit doit remplir deux conditions : 1) vous donner le moyen de savoir facilement quels récepteurs devront être restaurés pour analyser un événement ;
2) prendre en compte les exigences de conformité de votre organisation.

Mythe N° 8 : audit des objets

Si la valeur *OBJAUD n’est pas spécifiée dans la valeur système QAUDCTL, il n’y aura aucun audit sur les objets individuels. Voyons cela de plus près. Il existe deux types d’audit sur le système : l’audit d’actions,
qui journalise des événements tels que la création ou la suppression d’objets, les tentatives d’accès quand l’utilisateur n’a pas l’autorité suffisante (défaillances d’autorité), etc. ; et l’audit d’objets, qui lit ou met à jour
des objets individuels. On m’a demandé plusieurs fois d’aider des utilisateurs à trouver pourquoi il n’y a pas d’entrées d’audit quand un objet est mis à jour. Ils avaient configuré l’audit sur l’objet (en émettant la commande
Change Object Auditing—CHGOBJAUD), mais avaient négligé d’ajouter *OBJAUD à la valeur système QAUDCTL.

Mythe N° 9 : entrées du journal d’audit

C’est inexact. En fait, même ceux qui produisent des rapports réguliers à partir du journal d’audit n’en examinent pas chaque entrée. Je n’ai vu qu’un seul cas où chaque entrée était examinée,
et cette entreprise y consacrait un employé à plein temps : le pauvre, qu’est-ce qu’il a dû s’ennuyer ! Je recommande que l’audit soit toujours activé et aussi que certains rapports soient exécutés régulièrement.
Mais même si vous choisissez de n’exécuter aucun rapport, je vous conseille d’activer l’audit afin que, si quelque chose se passe, vous ayez l’information nécessaire pour analyser l’événement.
Veillez à sauvegarder vos récepteurs de journaux d’audit de telle sorte que, si l’événement remonte à neuf mois, vous sachiez quel média il faut ramener du stockage.

Tous les articles trucs et astuces System i et AS/400 sont sur iTPro.fr : Actualités IT, Dossiers Experts pour Décideurs et Professionnels IT (itpro.fr)