10 DES MYTHES DE SÉCURITÉ LES PLUS COURANTS SUR L'IBM i
Débusquez ces mythes pour améliorer la sécurité
>> Par Carol Woodbury
Cet article se propose de dévoiler certaines des idées fausses
et des erreurs courantes en matière de
sécurité IBM i. 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 N°2 : autorité adoptée
On sait que l'autorité adoptée est validée par l'activation
d'un attribut d'un programme. Malheureusement, beaucoup
regardent le mauvais attribut. Deux attributs de programmes
contrôlent l'autorité adoptée : Use Adopted
Authority (USEADPAUT) et User Profile (USRPRF). 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
Toujours à propos d'autorité adoptée, dès lors que vous
définissez *OWNER comme attribut de programme de
User Profile, tout ce qui se passe dans le programme adopte
l'autorité, n'est-ce pas ? 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 (CHG PGM).
Malheureu sement, 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
Ce mythe concerne l'autorité spéciale
*ALLOBJ. J'ai vu des organisations
attribuer *ALLOBJ au profil de groupe
d'un utilisateur puis accorder l'autorité
privée *EXCLUDE à divers fichiers ou
commandes, en pensant que cela leur
donnait le contrôle sur les actions de
l'utilisateur. (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
Beaucoup supposent à tort qu'il n'y a
pas de contrôle d'autorité au niveau de
sécurité 20. Or, malgré les apparences,
le fait est que le même algorithme de
contrôle d'autorité est exécuté au
niveau de sécurité 20 qu'au niveau 50.
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
L'un des rapports produits par une
évaluation de la sécurité donne la liste
des profils dont l'intervalle d'expiration
du mot de passe est réglé sur
*NOMAX. En regardant de plus près
ces profils, nous constatons que certains n'ont pas de 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
J'ai constaté que, le plus souvent, la sauvegarde des récepteurs
de journaux d'audit est mal pensée. 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
Toujours à propos de l'audit, parlons de la valeur
système QAUDCTL (qui active ou désactive l'audit).
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éfail lances 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.
Remarque: il peut y avoir une autre raison pour laquelle
vous ne voyez pas d'entrées d'audit d'objets : tout simplement
parce que l'action appliquée à l'objet n'est pas censée
générer une entrée d'audit. Pour savoir quelles actions génèrent
des entrées d'audit d'objets pour un type d'objet particulier,
consultez le manuel Security Reference, annexe E
(publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rz
arl/sc415302.pdf).
Mythe N° 9 : entrées du journal d'audit
Un autre mythe concernant l'audit : dès lors que l'audit est
activé, vous devez examiner chaque entrée du journal d'audit
générée. 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.
Mythe N° 10 : profils inactifs
Le dernier mythe dont je voudrais parler est celui de la
découverte des profils inactifs. Beaucoup d'utilisateurs semblent
hésiter à supprimer les profils inactifs ou même à leur
donner le statut *DISABLED. J'ai entendu parler de profils
supprimés alors même qu'ils étaient actifs. C'est toujours
parce que l'on examinait la mauvaise date. J'ai constaté que,
quand des profils actifs étaient supprimés par mégarde,
c'était parce que la date de dernière connexion (sign-on)
était examinée. Alors qu'il faut rechercher la date de dernière
utilisation. En effet, celle-ci est actualisée quel que soit le
mode d'utilisation du profil : FTP, ODBC, soumission d'un
job, ou connexion au système. Donc, cessez de regarder la
date de dernière connexion et regardez celle de dernière
utilisation.
Dites-le à tous vos amis
J'espère que cet article vous a aidé à éclaircir certains des
mystères de la sécurité IBM i. N'hésitez pas à répandre largement
la bonne parole pour améliorer la sécurité de tous.
|
Pour être contacté par les experts IBM sur le thème de la sécurité des environnements Power Systems : cliquez ici
|
|
|
|
Le POWER7 marque un renouveau de l'univers 
Quelle vision associée au Power 7 aujourd'hui ? Quelles évolutions ? Quelles perspectives ? Les premiers retours de la communauté des utilisateurs ?
AIX est l'un des trois systèmes d'exploitation natifs de la plateforme Power. Il en est le 
Comment réduire les coûts énergétiques et d'administration système d'environ 30% dans un centre de données type ?
Découvrez ou redécouvrez l'IBM i, l'infrastructure de référence pour les applications stratégiques d'entreprise au travers de ce guide...
