Le monitoring et les correctifs répondent à des parties différentes du même problème de sécurité. Les correctifs éliminent les vulnérabilités connues avant leur exploitation. Le monitoring détecte les tentatives d’exploitation des failles non corrigées et les comportements inattendus après correctif ou changement de configuration. Les organisations en difficulté confondent souvent ces capacités : elles attendent du monitoring qu’il décide quand corriger, ce qu’il ne peut pas faire fiablement, ou appliquent les correctifs sans surveiller les régressions et les tentatives préalables d’exploitation.
Cet article précise ce que le monitoring apporte à un programme de sécurité et de correctifs SAP, ses limites et les configurations permettant d’en tirer parti.
Correctifs préventifs, monitoring détectif : une distinction essentielle
Un correctif du noyau SAP ferme une faille du code. Une fois appliqué, ce chemin d’exploitation disparaît du système. L’alerte spécifique à cette CVE n’est plus nécessaire pour cette faille, mais peut rester pertinente pour des CVE non corrigées de la même famille de modules fonction.
Les deux contrôles couvrent des fenêtres de risque différentes. Entre publication d’une CVE et déploiement du correctif, une période de plusieurs semaines ou mois selon le cycle, le monitoring peut révéler une tentative d’exploitation. Après correction, il continue de détecter les prochaines failles non corrigées ainsi que les applications incorrectes, incomplètes ou ayant des effets de bord sur la configuration.
Considérer le monitoring comme un substitut aux correctifs au motif que toute attaque serait détectée avant de réussir revient à compenser l’absence de prévention par de la détection. C’est une erreur structurelle de gestion du risque. Ces contrôles sont complémentaires.
Ce que le monitoring apporte à la sécurité et aux correctifs SAP
Détecter l’exploitation avant le déploiement
Entre la publication d’une SAP Security Note et son application en production, la faille demeure. Pour les notes prioritaires, les détails CVE, modules concernés et méthodes d’exploitation publiés sont également accessibles aux attaquants. Surveiller les appels à ces modules, notamment par RFC depuis des sources absentes de la liste d’intégration autorisée, signale les sondes ou attaques avant correction. Le monitoring de sécurité RFC SAP présente les motifs de détection propres à ces attaques, associées à de nombreuses CVE SAP sévères récentes.
Les classes DUF, pour les appels de modules RFC, et DUB, pour les échecs d’autorisation, fournissent le signal brut. Un appel à un module sensible refusé faute de droits suggère une tentative de sondage. Plusieurs appels rapprochés depuis la même source peuvent indiquer une reconnaissance automatisée. Sans configuration explicite, aucun de ces cas ne déclenche une alerte classique.
Établir une référence avant correctif et comparer après
Les correctifs noyau, HANA et Support Package Stacks modifient le code de production et parfois les performances. Un optimiseur SQL HANA modifié peut changer les plans d’exécution, avec amélioration ou forte régression. Une évolution de gestion des work processes peut affecter le dialogue seulement sous charge réelle.
Une référence capturée avant chaque correctif permet d’identifier les régressions en quelques heures plutôt qu’en plusieurs jours. Elle doit inclure temps de réponse dialogue, consommation mémoire HANA, durée des requêtes coûteuses et profils d’utilisation des WP. Tout changement notable après application mérite une analyse, avec la corrélation temporelle comme hypothèse initiale.
Sans référence, un problème apparu deux semaines après n’est pas facilement attribuable au correctif. L’équipe Basis explore toutes les causes et peut mettre plusieurs jours à découvrir le changement d’un plan SQL.
Détecter la dérive depuis une configuration durcie
Le durcissement produit une configuration vérifiée : paramètres de profil, mandants verrouillés, destinations RFC restreintes et fichiers ACL Gateway. Cet état constitue la référence. Détecter tout écart rend le durcissement durable plutôt que ponctuel. Le monitoring de dérive SAP décrit les mécanismes disponibles, y compris les modifications de tables produisant ou non des documents de changement.
Les limites du monitoring
Il ne détermine pas quelles SAP Security Notes concernent précisément votre version et votre configuration. Cela exige les outils SAP, comme l’analyse des correctifs Solution Manager ou Cloud ALM, ou un scanner de vulnérabilités tiers disposant de la base des Notes. Une plateforme observant des métriques d’exploitation ne possède pas nécessairement l’inventaire logiciel requis pour le croisement CVE.
Il ne remplace pas un audit de sécurité SAP. Celui-ci examine les autorisations, la sécurité RFC, les mandants, les paramètres, l’exposition réseau et les contrôles utilisateurs avec une expertise et des outils spécifiques.
Il n’applique pas les correctifs. Il peut détecter une régression, un système oublié dans le déploiement ou un noyau inférieur à un minimum défini. La planification, les tests et l’exécution du patching restent hors de son périmètre.
Point de vigilance : une alerte à chaque nouvelle Security Note produit du bruit sans prouver sa pertinence. Le signal utile est la présence de la version affectée et une éventuelle tentative d’exploitation. Le premier nécessite un inventaire ; le second, l’analyse du journal de sécurité selon des motifs connus.
Paramètres de profil à surveiller pour détecter la dérive
Les paramètres de durcissement peuvent être modifiés par un utilisateur autorisé dans RZ10. Le changement s’applique après redémarrage ou, pour certains paramètres, immédiatement via RZ11. Leur surveillance en temps réel rend le durcissement auditable.
login/fails_to_user_lock : valeur attendue de 3 à 5. Une valeur zéro désactive le verrouillage et permet des essais de mots de passe illimités. C’est une lacune de durcissement fréquemment rencontrée.
auth/object_disabling_active : valeur attendue N. Y permet de désactiver des objets d’autorisation et de contourner les rôles. En production, conserver N.
login/no_automatic_user_sapstar : valeur attendue 1. Ce paramètre contrôle la connexion SAP* avec un mot de passe par défaut lorsque la fiche utilisateur est supprimée. Zéro crée une porte dérobée critique. En production, utiliser 1.
gw/sec_info et gw/reg_info : chemins vers les fichiers secinfo/reginfo. Leur absence ou un contenu permissif autorise l’enregistrement de programmes non autorisés sur la Gateway, un vecteur de plusieurs CVE sévères.
icm/server_port_* : uniquement les ports nécessaires. Tout port inattendu expose un service SAP au réseau ; tout ajout doit passer par la gestion du changement.
Ces paramètres se surveillent par requêtes RZ11 ou via SCU3 et les tables de profils. Des alertes sur les écarts aux valeurs attendues assurent une vérification continue que l’audit ponctuel ne peut offrir. Les bonnes pratiques de configuration des alertes SAP détaillent la mise en place.
Après correctif : la fenêtre de 72 heures
Les 72 heures après un correctif majeur sont une période de risque élevé : les régressions apparaissent, les intégrations rencontrent les vrais flux et les utilisateurs signalent des changements qui peuvent ou non être des problèmes.
Le monitoring doit temporairement être plus sensible : seuils dialogue abaissés, surveillance active des WP, comparaison des requêtes coûteuses HANA à la référence et attention renforcée aux interfaces concernées. Cette posture de 72 heures confirme la stabilité avant retour à la cadence normale.
Les métriques HANA restent les mêmes, mais leur contexte change. Les écarts à la référence pré-correctif sont plus exploitables que ceux aux moyennes historiques, car la date fournit une hypothèse causale claire. Une plateforme avec instantanés de référence rend la comparaison immédiate ; sinon, il faut reconstituer l’état manuellement.
Construire une surveillance au service du durcissement
Sans monitoring, un durcissement dérive sous l’effet des urgences, projets et petites décisions successives. Le risque dépend de la détection de cette dérive. Le monitoring de sécurité et de fiabilité SAP inscrit ces fonctions dans un cadre plus large.
Trois composants sont nécessaires : détection immédiate des écarts de paramètres, analyse des appels RFC et regroupements d’échecs d’autorisation, puis comparaison après correctif à des instantanés capturés systématiquement avant déploiement.
Ces composants ne sont pas complexes une fois la plateforme connectée, mais demandent une conception explicite : paramètres suivis, motifs préoccupants et procédure de référence. C’est le lien entre un outil décrivant l’activité et une couche soutenant activement la sécurité et le patching.
Redpeaks surveille les paramètres de profil, événements de sécurité et références de performance via une connexion RFC sans agent, avec alertes sur les motifs de sécurité et les régressions. Découvrez la couverture du monitoring de sécurité.
