Nous observons qu’en moyenne 13% des sociétés utilisatrices de SAP* sont confrontés à la limitation des 312 profils ou autorisations maximum par utilisateur. Cela entraine la mise en oeuvre de solutions de contournement diverses (double comptes, mutualisation de roles, roles spécifiques et dédiés, détournement des utilisateurs de référence, multiplication à outrance des firefighters, ...). L’impact n’est pas sans conséquence : 7% d’entre elles dégrades fortement la fiabilité des analyses SoD utilisateurs et 24% génèrent une complexification du modèle d’autorisations.
La limitation des droits assignables aux utilisateurs est due à la façon dont SAP gère l’historisation des modifications des autorisations au niveau des utilisateurs.
Ci-dessous, je vais vous expliquer le mécanisme avant l’EHP8 et après l’EHP8.
NB : Cet article est issu des travaux de R&D menés par Inventy dans le cadre de la création de KPIs pour la plateforme d’amélioration des solutions SAP, PERFORMER for SAP.
Avant l'EHP8 :
Description du principe
La table SAP d’historique des modifications des autorisations est la table USH04 qui contient les zones ci-dessous :
Voici comment sont affichées les données de cette table :
Nous constatons plusieurs choses :
- La zone NRPRO ne donne pas le nombre de profils ou d’autorisations comme l’indique sa description synthétique mais le nombre de caractères contenus dans la zone PROFS (C signifie Création / M signifie Modification).
- A chaque modification, le système ajoute une ligne dans cette table en faisant une « photographie » de l’intégralité des profils ou autorisations dont disposent l’utilisateur à cette date.
- Ces profils ou autorisations sont agrégés dans la zone PROFS sans séparateur.
- La taille allouée à un profil ou autorisation est de 12 caractères.
Avantages avant EHP8
- A chaque modification, il très facile de connaitre les profils ou autorisations dont disposait l’utilisateur. Et ce, jusqu’à la prochaine modification.
- Il n’y a qu’une seule table dédiée aux modifications des profils ou autorisations à consulter pour avoir accès à l’historique.
Inconvénients avant EHP8
- Il n’est pas facile, sans faire de comparaison de la zone PROFS entre 2 dates de modifications, de connaitre les profils ou autorisations qui auraient été ajoutés ou supprimés.
- Il est difficile de connaitre le rôle qui était assigné sans faire un « découpage » de la zone PROFS pour le rapprocher de la table AGR_PROF (table liant le nom d’un rôle avec ses profils générés)
- La zone PROFS est définie sur 3750 caractères, ce qui limite le nombre de profils ou autorisations affectables à un utilisateurs ; 3750 caractères, moins 2 caractères définissant la création ou la modification, le tout divisé par 12 étant la taille allouée à un profil ou autorisation et nous trouvons le nombre 312 (arrondi à un nombre entier). Seuls 312 profils ou autorisations peuvent donc être affectés à un utilisateur.
Avec l'EHP8 :
Description du principe :
Les tables SAP d’historique des modifications des autorisations ne sont plus des tables dédiées mais les tables contenant tous les documents de modifications du système. Ce sont les tables CDHDR (En-tête de document de modification) et CDPOS (Postes du document de modification).
Pour accéder aux données de la table CDHDR pour les documents de modifications des utilisateurs, il faut sélectionner la classe d’objet (OBJECTCLAS) IDENTITY et l’ID de l’objet (OBJECTID) avec l’ID de l’utilisateur. Ci-dessous, l’exemple avec l’ID utilisateur I20160010
Voici toutes les modifications qui ont été faites au niveau du compte I20160010. Que ce soit pour un changement de nom/prénom, de date de validité, de blocage/déblocage, d’adresse mail… tout est là.
Les valeurs de changements ne sont pas dans cette table mais dans la table des postes CDPOS. Pour y accéder, nous avons besoin des zones OBJECTCLAS (=IDENTITY), OBJECTID (User ID) ainsi que du CHANGENR (N° du document de modification). Puisque nous ne recherchons que les modifications des profils ou autorisations, nous pouvons affiner notre sélection avec TABNAME = SUSR_UST04.
Nous constatons plusieurs choses :
Dans la table CDHDR, nous avons la transaction avec laquelle la modification a été faite
Il n’y a plus de zone contenant l’agrégation des profils ou autorisation mais 1 seule valeur du profil ou autorisation dans la zone TABKEY.
La zone CHNGIND nous indique clairement l’action qui a été faite : I = Insertion / D = Délétion
A chaque modification, le système ajoute autant de lignes que de profils ou autorisations modifiés.
Avantages avec EHP8 :
- A chaque modification, il très facile de connaitre les profils ou autorisations qui ont été ajoutés ou supprimés.
- Il est facilement identifiable de savoir qui a eu tel ou tel profil ou autorisation dans son historique.
- Du fait que les profils ou autorisations ne soient plus agrégés dans une seule zone, cela lève la limite des 312 profils ou autorisations affectables à un compte utilisateur.
-
Il est également plus rapide de connaitre quel est le rôle derrière un profil généré ajouté ou supprimé avec un lien direct entre la zone TABKEY de la table CDPOS et la zone PROFILE de la table AGR_PROF
Ex : à quel rôle correspond le profil T-E3551348 qui a été ajouté puis supprimé : Z :TABLE_ACCESS
Inconvénients avec EHP8
- Il est difficile de connaitre l’intégralité des profils ou autorisations que possédait un compte utilisateur à un instant donné. Il faut partir de l’intégralité des profils ou autorisation au jour de l’analyse (via UST04) puis remonter tout l’historique jusqu’à la date désirée en consolidant tous les changements (ajout/suppression) qui auraient été fait pour ce compte utilisateur.
-
Les tables CDHDR et CDPOS ne sont pas des tables dédiées aux modifications des profils ou autorisations donc une volumétrie importante de données dans ces tables. Cela aura pour effet, une charge machine et du temps supplémentaire lors de la recherche de données.
Ce sont 2 tables séparées qu’il faut joindre pour avoir l’intégralité des données intéressantes (date et transaction d’accès dans CDHDR, profil ou autorisation et indicateur d’ajout/suppression dans CDPOS).
Synthèse
A chacun son lot d’avantages et d’inconvénients, tout dépend des priorités de chacun.
Le nouveau mode de gestion des documents de modifications mis en place avec EHP8 n’est pas sans inconvénients : 2 tables non dédiées aux utilisateurs qui ont souvent de très grosses volumétries ; devoir « remonter » tout l’historique pour connaitre les profils ou autorisations d’un compte utilisateur à un instant T …
Cependant, je pense que pour le client et notamment pour le Business, c’est un réel progrès puisque la limitation de 312 profils ou autorisations est levée ; plus besoin de « découper » la zone PROFS pour identifier clairement un profil ou autorisation … Si une méthode de contournement était utilisée, elle pourra être abandonnée avec EHP8 et donc, avoir des analyses SoD correctes.
Il faut également savoir qu’une fois passé en EHP8, la nouvelle méthodologie est appliquée et que l’ancienne est abandonnée. MAIS, tout l’historique de l’ancienne méthodologie reste dans la table USH04. Donc, il n’y aura aucun historique perdu en changeant de méthodologie.
Cette nouvelle méthodologie de l’historisation des modifications des autorisations des utilisateurs peut être un véritable levier pour démontrer le gain de EHP8.
(*) Statistiques issues de la base de Benchmark PERFORMER FOR SAP. Cet article est issu des travaux de R&D menés par Inventy.