Configuration et contrôle des politiques de sécurité SAP (SECPOL)
Depuis l’EHP 6, les règles de mot de passe se renforcent par groupe d’utilisateurs via des politiques de sécurité. Qui ne contrôle que les paramètres de profil passe à côté. Comment les configurer et les contrôler.
Les règles de mot de passe dans SAP ont longtemps été une affaire de paramètres de profil : une règle, un système, tous les utilisateurs. Depuis l’EHP 6, il existe des politiques de sécurité (security policies), qui permettent de différencier les exigences par groupe d’utilisateurs. C’est un gain pour l’exploitation et, pour l’audit, un endroit de plus à lire.
Situation de départ : une règle pour tous
Les exigences de mot de passe d’un système SAP figurent dans les paramètres de profil préfixés login/, maintenus par exemple dans la transaction RZ10 : login/min_password_lng pour la longueur minimale, login/password_expiration_time pour la validité en jours, login/fails_to_user_lock pour le nombre de tentatives infructueuses avant verrouillage, plus les règles sur les chiffres, les lettres, les caractères spéciaux et l’historique des mots de passe.
Ces paramètres s’appliquent à l’échelle du système et indépendamment des autorisations d’un utilisateur. Les identifiants privilégiés, par exemple pour l’administration système ou pour les interventions d’utilisateurs d’urgence, ne peuvent pas être sécurisés séparément avec eux. Une validité de mot de passe de 30 jours au lieu de 90 pour les administrateurs ne se modélise pas avec les seuls paramètres de profil.
Politiques de sécurité à partir de l’EHP 6
Avec l’EHP 6 sont arrivées les politiques de sécurité. Elles se créent dans la transaction SECPOL, ou bien dans le guide d’implémentation sous SAP NetWeaver › Application Server › Utilisateurs et autorisations › Politiques de sécurité. Une politique reçoit un nom et une description ; les exigences proprement dites y figurent sous forme d’attributs, accessibles par double-clic sur « Attributs ».
Les attributs portent d’autres noms que les paramètres de profil, mais suivent la même logique. Les paires les plus importantes :
| Attribut de la politique | Paramètre de profil |
|---|---|
MIN_PASSWORD_LENGTH | login/min_password_lng |
PASSWORD_CHANGE_INTERVAL | login/password_expiration_time |
MAX_FAILED_PASSWORD_LOGON_ATTEMPTS | login/fails_to_user_lock |
PASSWORD_LOCK_EXPIRATION | login/failed_user_auto_unlock |
MIN_PASSWORD_DIGITS, MIN_PASSWORD_LETTERS, MIN_PASSWORD_SPECIALS | login/min_password_digits, login/min_password_letters, login/min_password_specials |
PASSWORD_HISTORY_SIZE | login/password_history_size |
La correspondance complète figure dans l’aide SAP sur les politiques de sécurité.
Une politique s’attribue par utilisateur dans la transaction SU01, onglet « Données de connexion », champ « Politique de sécurité ». Les politiques agissent en complément : les paramètres de profil continuent de s’appliquer à tous les utilisateurs, les attributs de la politique uniquement aux utilisateurs auxquels elle est attribuée. Une politique peut fixer des valeurs plus strictes, par exemple pour les administrateurs, mais aussi des règles différentes pour les identifiants techniques.
Deux remarques tirées de la pratique :
- Définir explicitement chaque attribut pertinent. Ne comptez pas sur le fait qu’un attribut non maintenu dans la politique retombe sur le paramètre de profil. Le bouton « Effectif » dans SECPOL montre quelles valeurs s’appliquent réellement pour la politique.
- Documenter les politiques. Qui reçoit quelle politique et pourquoi relève du concept d’autorisations ; sinon, un second référentiel de règles, non documenté, se forme à côté des rôles.
Conséquences pour l’audit
Un contrôle des règles de mot de passe limité aux paramètres de profil, par exemple via le rapport standard RSPARAM, donne une image incomplète à partir de l’EHP 6. Des utilisateurs peuvent être protégés plus strictement ou plus faiblement par une politique que ne le laissent supposer les paramètres. Sans outil de contrôle, la démarche suivante est recommandée :
- Lire les politiques et les attributs : vérifier dans SECPOL ou dans le guide d’implémentation quelles politiques de sécurité existent et quels attributs sont définis avec quelles valeurs. Les données se trouvent dans les tables SEC_POLICY_CUST et SEC_POLICY_ATTR.
- Contrôler l’attribution : dans la table USR02, le champ SECURITY_POLICY montre à quels utilisateurs une politique est attribuée. Sont surtout intéressants les identifiants pour lesquels on attend une politique plus stricte, et ceux qui en portent étonnamment une plus faible.
- Retracer les modifications : la transaction SECPOL_CHANGES montre quand des politiques ont été créées ou modifiées. Les auditeurs regardent si une politique a vu le jour peu avant l’audit.
Notre appréciation
Les politiques de sécurité résolvent un vieux problème : les identifiants privilégiés peuvent enfin être traités plus strictement que les autres, sans régler tout le système sur la règle la plus sévère. Pour l’audit, cela signifie que la question « quelles règles de mot de passe s’appliquent ? » ne se répond plus d’un coup d’œil dans RZ10. Depuis l’EHP 6, elle comporte trois parties : les paramètres, les politiques et leur attribution aux utilisateurs.
Une version plus détaillée de cet article, en allemand et avec des captures d’écran, est parue sur le blog d’experts rz10.de : SAP-Passwortregeln: Profilparameter und Security Policies via SECPOL.