La plupart des dérives de configuration SAP ne sont pas dues à des accès non autorisés. Elles sont provoquées par des utilisateurs autorisés qui effectuent des changements pour de bonnes raisons, mais qui sont imparfaitement documentés et jamais annulés. Un ingénieur Basis augmente le nombre de work processes de dialogue dans RZ10 pendant un incident et résout le problème. Un consultant déverrouille temporairement le client de production pour appliquer une correction urgente et oublie de le verrouiller à nouveau. Un administrateur des autorisations attribue temporairement un rôle à un utilisateur pendant une clôture mensuelle, puis la tâche de suppression reste dans le backlog jusqu’à ce que l’urgence soit oubliée trois semaines plus tard.
Chacun de ces événements est réel et justifié. Aucun n’est nécessairement non autorisé. Pourtant, chacun laisse le système de production dans un état différent de la baseline documentée. Cet écart entre l’état documenté et l’état réel constitue la dérive de configuration. C’est également dans cet écart que se trouvent souvent les explications d’incidents qui semblent, au premier abord, ne pas avoir de cause évidente.
Pourquoi la dérive de configuration est différente d’un échec du change management
Le change management dans SAP, notamment via le système de transport STMS et les workflows d’approbation associés, permet de suivre les changements qui transitent par le paysage de transport formel : code ABAP, configuration transportée du développement vers la qualité puis la production. La dérive de configuration apparaît précisément dans les zones que la gestion des transports ne couvre pas.
Modifications directes de tables via SM30 ou SE16N en production. Ajustements de paramètres de profil réalisés directement dans RZ10. Changements de configuration HANA effectués via HANA Studio ou SQL sans passer par un outil de gestion de configuration. Modifications de destinations RFC qui ne génèrent aucun transport. Changements dans les fiches utilisateurs en dehors du workflow habituel de provisioning basé sur les rôles. Toutes ces actions sont techniquement possibles, parfois nécessaires en situation d’urgence, et systématiquement absentes du journal des transports.
Lorsqu’une investigation post-incident conclut par « nous ne savons pas quand ce paramètre a changé », elle fait presque toujours référence à l’une de ces catégories. STMS n’affiche rien, car aucun transport n’a eu lieu. Le changement existe pourtant réellement. Les informations indiquant quand il a été effectué et par qui se trouvent éventuellement dans les documents de modification SAP, mais uniquement si leur journalisation a été configurée pour la table concernée et si quelqu’un sait où chercher.
Les trois couches de configuration qui peuvent dériver indépendamment
Dérive des autorisations et des données utilisateurs
La configuration des autorisations SAP peut évoluer par plusieurs canaux. Les modifications de rôles transportées via STMS sont visibles. Les changements directs dans les fiches utilisateurs via SU01, les attributions de rôles via PFCG ou les reconstructions du buffer d’autorisations ne sont pas visibles dans les transports. Ils génèrent des documents de modification dans l’historique des tables USR*, mais ces documents ne sont généralement consultés que lorsqu’une personne ouvre explicitement SCU3 et recherche les changements apportés aux tables d’administration des utilisateurs.
Le scénario de dérive qui provoque le plus souvent des incidents dans cette couche est l’attribution temporaire d’un accès sans limite de durée, puis jamais révoqué. Un utilisateur dispose toujours d’une autorisation sensible obtenue pour un projet terminé trois mois plus tôt. Un compte de service a reçu des droits étendus pour une migration, mais n’a jamais été nettoyé après sa finalisation. Un administrateur a ajouté un rôle « juste pour tester », avec l’intention de le retirer ensuite, puis l’a oublié.
La question du monitoring n’est pas de savoir si ces changements étaient autorisés au moment où ils ont été effectués. Il s’agit de savoir si l’état actuel des autorisations correspond encore à ce qui devrait être en place aujourd’hui et quand toute déviation par rapport à cet état attendu a été introduite.
Dérive de la configuration système et des instances
Les paramètres de profil définis dans RZ10 déterminent le comportement du serveur d’applications SAP : nombre de work processes, allocation mémoire, taille des buffers, valeurs de timeout. Les modifications de ces paramètres nécessitent généralement un redémarrage pour prendre effet et sont, en théorie, réalisées dans un cadre contrôlé. En pratique, elles sont parfois effectuées sous la pression d’un incident, avec une documentation incomplète, puis ne sont pas annulées lorsque le problème initial est résolu.
Les paramètres du client dans SCC4 constituent une zone particulièrement sensible. Le paramètre « No changes allowed » sur un client de production impose que les changements de customizing passent par un transport. Si ce paramètre est temporairement modifié afin d’autoriser un changement direct pour une correction urgente puis n’est pas rétabli, le client de production reste ouvert au customizing direct pour tout utilisateur disposant des droits de maintenance de tables.
Cette configuration peut rester dégradée pendant plusieurs mois sans produire de conséquence opérationnelle visible, jusqu’à ce qu’un auditeur la détecte ou qu’un développeur commence à effectuer des changements directement en production simplement parce que le système le permet.
Les paramètres de configuration HANA modifiés via HANA Studio ou avec des commandes ALTER SYSTEM SET constituent l’une des catégories les moins visibles. Ils ne génèrent pas de documents de modification ABAP. Ils sont enregistrés dans l’historique de configuration propre à HANA, accessible notamment via M_INIFILE_CONTENT_HISTORY, mais ne font partie ni d’un transport SAP ni du framework de change documents ABAP.
Un changement de paramètre HANA qui améliore les performances dans une zone mais les dégrade ailleurs, effectué six semaines plus tôt puis oublié, peut ainsi rester invisible pour l’équipe Basis qui cherche aujourd’hui la cause d’une dégradation.
Dérive de la configuration des intégrations et interfaces
Les destinations RFC définies dans SM59, les définitions de systèmes logiques, les profils partenaires IDoc dans WE20 et les paramètres du modèle de distribution ALE sont des objets de configuration d’intégration qui, dans de nombreux environnements établis, ne transitent pas systématiquement par les transports. Ils sont souvent créés ou modifiés directement dans le système cible.
Un scénario classique de dérive entraînant un incident d’intégration est une destination RFC temporairement modifiée pour pointer vers un autre système pendant une phase de test, puis jamais rétablie. Autre exemple : un paramètre outbound d’un profil partenaire est modifié pendant un projet et le système de production commence ensuite à envoyer des IDocs avec un mauvais type de message.
Ces changements peuvent exister dans les documents de modification SAP associés aux tables concernées, mais personne n’a nécessairement configuré le monitoring permettant de les faire remonter automatiquement.
Où se trouvent les traces de changement et ce qu’elles ne couvrent pas
SAP conserve des informations de modification pour les tables dont la journalisation est activée. SCU3, le journal des modifications de tables, permet d’identifier quelles tables ont été modifiées, quand et par qui, mais uniquement lorsque le logging est activé. Cela ne concerne qu’une partie des tables et la configuration varie fortement d’une implémentation à l’autre.
SM20, le Security Audit Log, enregistre notamment des événements liés à l’administration des utilisateurs, aux échecs d’autorisation et aux changements de paramètres des clients. Sa couverture dépend néanmoins entièrement de la configuration du journal d’audit : classes d’événements actives, clients audités, utilisateurs concernés ou non.
STMS et SE01 montrent ce qui a transité par le système de transport. Ils n’affichent rien concernant les changements effectués en dehors du paysage de transport, précisément là où se produit une grande partie des dérives ayant un impact opérationnel.
Cet écart entre le changement réellement effectué et la trace disponible après l’incident explique pourquoi tant de post-mortems aboutissent à une conclusion du type : « nous pensons que ce paramètre a changé il y a environ trois semaines, mais nous ne pouvons confirmer ni la date exacte ni la modification effectuée ».
| Attention : dans de nombreuses implémentations SAP, le logging des modifications a été activé sur certaines tables pendant le projet initial, puis n’a jamais été réévalué à mesure que le paysage évoluait. Des tables considérées comme peu sensibles au moment du go-live peuvent aujourd’hui contenir des configurations critiques. Vérifiez quelles tables disposent du logging des modifications dans leurs propriétés SE11 et comparez cette liste avec les tables correspondant à vos zones de configuration les plus sensibles. |
|---|
Ce que nécessite le monitoring de la dérive de configuration
Des snapshots de référence dans un état validé
Une dérive ne peut être détectée que par rapport à une baseline définie. Cette baseline représente un état de configuration examiné, approuvé et documenté comme correct. Sans elle, n’importe quel état de configuration actuel pourrait être considéré comme valide puisqu’il n’existe aucun point de comparaison.
Des baselines pratiques pour le monitoring de la dérive peuvent inclure les attributions de rôles et de profils utilisateurs à la fin de chaque trimestre après les revues d’accès, les valeurs des paramètres RZ10 après chaque fenêtre de maintenance, la liste des destinations RFC après la fin de chaque projet d’intégration ou encore les paramètres SCC4 lors de chaque revue de santé du système.
Ces snapshots capturent l’état attendu à un instant précis et deviennent ensuite la référence pour les comparaisons futures.
Les événements qui doivent déclencher une alerte immédiate
Tous les changements de configuration ne nécessitent pas la même vitesse de réaction. Certains représentent un risque suffisamment important pour déclencher une alerte quelques minutes après leur apparition.
Le passage du paramètre SCC4 de « No changes allowed » à une autre valeur sur un client de production en fait partie. Une modification directe de USR02, qui contient des données des fiches utilisateurs, en dehors des horaires habituels en est une autre. Les modifications de destinations RFC SM59 associées à des connexions critiques et les changements dans le fichier HANA global.ini appartiennent également à cette catégorie.
Lorsqu’elles ne sont pas intentionnelles, ces modifications peuvent immédiatement créer un risque de sécurité ou un risque opérationnel.
Les changements à examiner quotidiennement
Un ensemble plus large de changements de configuration mérite une revue quotidienne sans nécessiter d’alerte immédiate. Les modifications de AGR_USERS pour les attributions de rôles, de TVARVC pour certaines variantes utilisées dans les traitements de fond, des planifications de jobs dans SM36 ou des profils partenaires WE20 entrent notamment dans cette catégorie.
Aucun de ces changements ne justifie nécessairement de réveiller quelqu’un à 3 heures du matin. En revanche, ils devraient être examinés avant de rester en production pendant plus de 24 heures afin de confirmer qu’ils sont intentionnels et correctement documentés.
| En pratique : une revue quotidienne de la dérive peut prendre quinze minutes si le résultat du monitoring est bien structuré : une liste des changements de configuration des dernières 24 heures, classés par catégorie, avec l’utilisateur et le timestamp associés à chaque modification. La plupart des équipes SAP ne disposent pas automatiquement de cette vue. Elles ont accès aux journaux individuels, comme SCU3, SM20 ou STMS, mais pas à une vue consolidée. Mettre en place un rapport planifié ou une alerte de monitoring qui génère cette liste chaque jour demande moins d’efforts qu’on pourrait le penser et apporte beaucoup de valeur dès la première anomalie détectée. |
|---|
L’incident que le monitoring de la dérive permet d’éviter
La dérive de configuration apparaît dans les analyses post-incident de manière très prévisible. Le système se comporte de façon inattendue. L’équipe enquête. Elle découvre une configuration différente de celle indiquée dans la documentation. Elle cherche quand cette configuration a été modifiée. Le journal ne contient soit aucune trace, soit une modification datant de six semaines qu’aucune équipe ne parvient à associer à une demande de changement documentée.
L’investigation prend des heures ou des jours. La remédiation prend encore du temps. Et à la fin, la cause racine est parfois documentée comme un « changement de configuration non autorisé », alors qu’une formulation plus exacte serait : « changement de configuration autorisé qui n’a pas été suivi, documenté ou monitoré ».
Le monitoring de la dérive de configuration n’empêche pas les utilisateurs autorisés d’effectuer des changements. Il rend ces changements visibles au moment où ils se produisent, lorsque la personne qui les a effectués est encore en mesure d’en expliquer la raison et qu’un retour en arrière reste une opération mineure plutôt qu’une investigation d’incident en production.
Cette visibilité, obtenue de manière constante et sans effort manuel, fait toute la différence entre une gestion de configuration réellement opérationnelle et une gestion de configuration qui existe uniquement sur le papier.
Redpeaks monitore les événements liés aux changements de configuration SAP, notamment les modifications d’autorisations, les changements de paramètres de profil et les paramètres des clients, avec des synthèses quotidiennes de dérive et des alertes immédiates pour les événements de configuration à haut risque.
