Sécuriser IBM i : niveau, valeurs système, profils et audit

Les niveaux de sécurité

La valeur système QSECURITY fixe le niveau de protection que le système impose. Chaque niveau ajoute des contrôles au précédent :

• 10 et 20 ne peuvent plus être choisis. Au niveau 20, tous les utilisateurs ont *ALLOBJ : chacun accède à tout.
• 30 contrôle les droits sur les objets, mais IBM ne le considère pas comme un niveau sûr : la protection de l'intégrité n'y est pas active.
• 40 protège le système contre les utilisateurs : un programme ne peut plus appeler une interface non documentée ou manipuler des pointeurs pour atteindre des blocs de contrôle. C'est le niveau de toute nouvelle installation, recommandé pour la plupart d'entre elles.
• 50 ajoute une protection renforcée, par exemple sur les messages entre programmes système et programmes utilisateur, et ne laisse voir que les données, pas les informations sur le système. IBM le présente comme le niveau recommandé pour la plupart des entreprises, car c'est le plus sûr.

Le changement prend effet à l'IPL suivant. Pour passer de 30 à 40, IBM conseille d'activer d'abord l'audit avec *AUTFAIL et *PGMFAIL, de faire tourner toutes les applications, puis de corriger les programmes qui laissent des entrées AF dans le journal (instruction interdite, interface non prise en charge…) avant de changer la valeur :

CHGSYSVAL  SYSVAL(QSECURITY) VALUE('40')
PWRDWNSYS  OPTION(*IMMED) RESTART(*YES)

Les valeurs système conseillées

La commande PRTSYSSECA imprime chaque valeur système de sécurité avec sa valeur actuelle et la valeur que recommande IBM. Voici la colonne « recommandée » relevée sur notre IBM i 7.5, regroupée par thème, sauf pour QSECURITY où nous gardons 40. Chaque nom mène à sa fiche détaillée ; la mention à tester signale un réglage qui peut bloquer une application ou un usage.

Niveau de sécurité et intégrité

Mots de passe

Ouverture de session

Communications et IFS

Audit

PRTSYSSECA contrôle aussi trois attributs réseau (commande CHGNETA), détaillés avec les accès à distance :

Pour comparer vos valeurs à ces recommandations, sans imprimer, une requête :

SELECT SYSTEM_VALUE_NAME, CURRENT_CHARACTER_VALUE, CURRENT_NUMERIC_VALUE
  FROM QSYS2.SYSTEM_VALUE_INFO
 WHERE SYSTEM_VALUE_NAME IN ('QSECURITY', 'QPWDLVL', 'QMAXSIGN', 'QMAXSGNACN',
       'QLMTSECOFR', 'QINACTITV', 'QALWOBJRST', 'QVFYOBJRST', 'QAUDCTL')
 ORDER BY SYSTEM_VALUE_NAME

Enfin, la plupart des valeurs de sécurité ne peuvent être changées que par un profil *ALLOBJ et *SECADM. Pour empêcher même ces profils de les modifier en exploitation, on les verrouille par les outils de service (SST, DST) ou la commande CHGSSTSECA.

Les outils d'IBM : GO SECTOOLS

Le menu des outils de sécurité, livré avec le système, regroupe les commandes de contrôle : GO SECTOOLS.

CFGSYSSEC mérite une précaution : elle règle d'un coup les valeurs système, met à *NONE le mot de passe des profils fournis par IBM et démarre l'audit. Elle demande *ALLOBJ, *SECADM et *AUDIT. Pour l'adapter, IBM indique de récupérer la source de son programme, QSYS/QSECCFGS, par RTVCLSRC, puis de la modifier et de la compiler sous un autre nom.

Les profils : fermer les portes connues

Les premiers essais d'un intrus visent les profils dont le mot de passe est publié. La documentation d'IBM donne la liste à vérifier :

1. Aucun profil avec un mot de passe égal à son nom. ANZDFTPWD les trouve, et peut les désactiver.
2. Les outils de service aussi. Les identifiants DST QSECOFR et QSRV ont des mots de passe publiés : changez-les, et rechangez celui de QSRV après chaque intervention d'un technicien.
3. Pas de connexion par simple Entrée. Essayez, sur plusieurs écrans, d'ouvrir une session sans rien taper. Si cela marche, passez en niveau 40 ou 50, ou mettez USER(*RQD) dans les descriptions de travail des postes écran.
4. Peu de *ALLOBJ. Chaque profil qui l'a peut tout lire et tout modifier (voir les droits spéciaux).
5. Pas de profil oublié. Désactivez les profils inutilisés avec ANZPRFACT, et faites expirer ceux des intérimaires (CHGEXPSCDE).
6. Un mot de passe à changer dès la première connexion : PWDEXP(*YES) à la création du profil (voir les profils utilisateurs).

Deux requêtes de contrôle, exécutées sur notre IBM i 7.5 (nous n'en publions pas le résultat). Les profils actifs, avec un mot de passe, sans connexion depuis 90 jours :

SELECT AUTHORIZATION_NAME, PREVIOUS_SIGNON, USER_CLASS_NAME
  FROM QSYS2.USER_INFO_BASIC
 WHERE STATUS = '*ENABLED'
   AND (PREVIOUS_SIGNON IS NULL OR PREVIOUS_SIGNON < CURRENT TIMESTAMP - 90 DAYS)
   AND NO_PASSWORD_INDICATOR = 'NO'
   AND AUTHORIZATION_NAME NOT LIKE 'Q%'
 ORDER BY PREVIOUS_SIGNON

Les profils actifs qui ont *ALLOBJ en propre (ajoutez ceux qui l'héritent d'un groupe avec QSYS2.GROUP_PROFILE_ENTRIES) :

SELECT AUTHORIZATION_NAME, USER_CLASS_NAME, SPECIAL_AUTHORITIES
  FROM QSYS2.USER_INFO_BASIC
 WHERE SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'
   AND STATUS = '*ENABLED'

IBM i 7.6 : activez le MFA

Depuis IBM i 7.6, le système intègre l'authentification multifacteur (MFA). En plus du mot de passe, l'utilisateur saisit un code à usage unique (TOTP, norme RFC 6238), calculé par une application d'authentification sur son téléphone, sa montre ou un jeton physique. Un mot de passe volé ou deviné ne suffit plus. Nous conseillons de l'activer, en commençant par les profils qui ont des droits spéciaux.

Notre système de démonstration est en 7.5 : cette partie s'appuie sur la documentation d'IBM i 7.6, sans démonstration.

Les prérequis

• QSECURITY à 40 ou plus : notre niveau conseillé suffit.
• QPWDLVL à 4 : on y passe par le niveau 2 ou 3, chaque changement attendant l'IPL (voir l'encadré plus haut).
• Des horloges à l'heure : le code dépend de l'heure, le système et les téléphones doivent être synchronisés à quelques secondes près. IBM conseille le client NTP (STRTCPSVR SERVER(*NTP), valeur système QTIMADJ).

Bon à savoir : sur une nouvelle installation en 7.6, QPWDLVL est livré à 3 et QPWDRULES à *ALLCRTCHG *LMTPRFNAME *MINLEN15 *REQANY3. Un système mis à niveau garde ses valeurs.

La mise en place, pas à pas

/* 1. Administrateur : activer le facteur supplémentaire, puis IPL */
CHGSECA    ADLSGNFAC(*ENABLED)

/* 2 et 3. Chaque utilisateur, sous son propre profil */
CHGTOTPKEY
CHKTOTP

/* 4. Administrateur : exiger le code pour ce profil */
CHGUSRPRF  USRPRF(DUPONTJ) AUTHMTH(*TOTP) TOTPOPTITV(*NONE)

• Activer le système ne suffit pas. L'attribut ajoute un champ « facteur supplémentaire » à l'écran de connexion, mais seuls les profils en AUTHMTH(*TOTP) doivent le remplir. Tous les profils existants ou créés restent en *NONE.
• Si CHGSECA refuse, l'attribut est verrouillé dans les outils de service : CHGSSTSECA CHGADLSGN(*YES) le déverrouille, et CHGADLSGN(*NO) le reverrouille une fois réglé. L'attribut n'est ni sauvegardé ni restauré.
• Chacun crée sa propre clé : l'administrateur ne peut pas le faire à sa place. IBM Navigator for i propose aussi un QR code à scanner (Manage My MFA Key).
• La clé de secours remplace le code si le téléphone est perdu. Elle ne vaut que 10 minutes après sa première utilisation, le temps de créer une nouvelle clé. Passé ce délai, la clé est supprimée et seul l'administrateur peut débloquer le profil en retirant *TOTP.
• Écran de connexion personnalisé ? Refaites-le à partir du format QDSIGNON3 avant l'IPL, sinon le champ du code n'apparaîtra pas.
• Sur une interface sans champ pour le code, on tape motdepasse:123456 dans le champ du mot de passe. Cela ne marche pas avec IBM i Access Client Solutions, Navigator ni DCM, qui ont leur propre champ.

Les profils _NC et QIBM_RUN_UNDER_USER_NO_AUTH

Le MFA protège la connexion, mais un profil *ALLOBJ peut encore agir sous le nom d'un autre sans connaître ni son mot de passe ni son code : SBMJOB USER(DUPONTJ), ou un « profile handle » obtenu avec *NOPWD. La 7.6 ferme cette porte par la fonction d'utilisation QIBM_RUN_UNDER_USER_NO_AUTH : un profil mis en *DENIED ne peut plus être la cible de ces opérations, qui échouent avec CPF4AF1.

/* D'abord observer : entrées d'audit GR-F *USAGEWARN */
CHGUSRAUD  USRPRF(DUPONTJ) AUDLVL(*AUTWARN)

/* Puis protéger le profil */
CHGFCNUSG  FCNID(QIBM_RUN_UNDER_USER_NO_AUTH) USER(DUPONTJ) USAGE(*DENIED)

IBM la réserve aux profils interactifs, qui s'authentifient : ne la refusez pas aux profils qui ne servent qu'en batch. Elle fonctionne même sans MFA, mais elle le complète.

C'est là qu'interviennent les quatre nouveaux profils fournis par IBM, suffixés _NC (not changeable) : QPGMR_NC, QSECOFR_NC, QSYSOPR_NC et QUSER_NC. Ils ont les mêmes droits que QPGMR, QSECOFR, QSYSOPR et QUSER, mais n'ont pas de mot de passe, ne peuvent pas être modifiés, et ne peuvent pas se voir refuser QIBM_RUN_UNDER_USER_NO_AUTH. Le système les utilise là où il prenait les profils d'origine : travaux soumis, profile handles, profil sous lequel tourne un serveur. IBM demande aux applications de faire de même : une chaîne qui lance SBMJOB USER(QPGMR) doit passer à QPGMR_NC si QPGMR est un jour protégé. Après la mise à niveau, vérifiez aussi les droits privés donnés aux profils d'origine sur vos objets : les profils _NC en ont peut-être besoin.

L'audit : savoir ce qui se passe

Le journal d'audit QSYS/QAUDJRN enregistre les événements de sécurité choisis par QAUDLVL et QAUDLVL2 : tentatives refusées, créations, suppressions, changements de droits ou de profils, restaurations. Une seule commande le met en route :

CHGSECAUD  QAUDCTL(*AUDLVL) QAUDLVL(*DFTSET)

CHGSECAUD crée le journal et son récepteur s'ils n'existent pas, met QAUDCTL à *AUDLVL et, avec *DFTSET, active les événements *AUTFAIL, *CREATE, *DELETE, *SECURITY et *SAVRST. Elle demande *ALLOBJ et *AUDIT. IBM conseille d'aller plus loin : la liste de QAUDLVL2 du tableau ci-dessus ajoute *OBJMGT, *PGMFAIL, *SERVICE et *SYSMGT.

Trois réglages complètent l'audit : QAUDENDACN dit quoi faire si le journal ne peut plus être écrit, QAUDFRCLVL quand écrire sur disque, et QCRTOBJAUD l'audit des nouveaux objets. Les entrées se lisent avec SYSTOOLS.AUDIT_JOURNAL_PW (mots de passe), SYSTOOLS.AUDIT_JOURNAL_CA (droits), SYSTOOLS.AUDIT_JOURNAL_CP (profils) : un exemple suit sur la page des attaques. Prévoyez la place et la purge des récepteurs : un audit complet produit beaucoup d'entrées.

Questions fréquentes