Demandez à la plupart des gens ce que signifie « sécurité SAP » et ils décriront des rôles, des autorisations et de la séparation des tâches. C'est la moitié du tableau. Les rôles décident qui peut faire quoi dans l'application, mais l'application tourne sur une plateforme : un kernel, des services réseau, des connexions RFC, un gateway, des fichiers de configuration et du code ABAP spécifique. Cette plateforme a sa propre surface d'attaque, et c'est la moitié que les programmes de sécurité génériques oublient systématiquement.

L'hypothèse selon laquelle « SAP est derrière le pare-feu, donc en sécurité » ne tient plus depuis des années. Les systèmes SAP se parlent entre eux et avec l'extérieur via RFC et HTTP ; le gateway démarre des programmes externes ; les utilisateurs standard sont livrés avec des mots de passe par défaut connus ; et des vulnérabilités critiques sont corrigées chaque mois. Cet article parcourt le versant plateforme de la cybersécurité SAP, les contrôles qui se trouvent sous votre concept d'autorisation.

La surface d'attaque SAP

Avant les contrôles, il est utile de voir ce qui est réellement exposé :

  • Vulnérabilités non patchées: les SAP Security Notes corrigent des failles réelles, souvent exploitables à distance. Chaque mois de report accroît l'exposition.
  • Le gateway et le message server: laissés ouverts, ils permettent à des programmes externes non autorisés de s'enregistrer et d'exécuter des commandes système sur l'hôte SAP.
  • Les connexions RFC: relations RFC de confiance et destinations avec identifiants stockés permettent à un attaquant de se déplacer latéralement d'un système peu sensible vers un système productif.
  • Utilisateurs standard et mots de passe par défaut: SAP*, DDIC, SAPCPIC, EARLYWATCH, TMSADM sont livrés avec des valeurs par défaut bien connues.
  • Services web exposés: services ICF dans SICF jamais nécessaires mais actifs.
  • Code ABAP spécifique: injection, directory traversal et contrôles d'autorité manquants dans vos propres développements.
  • Trafic non chiffré: trafic SAP GUI (DIAG) et RFC en clair sur le réseau.

Chacun de ces points est traitable. Voici comment.

1. SAP Security Notes et gestion des correctifs

SAP publie ses Security Notes lors du SAP Security Patch Day, le deuxième mardi de chaque mois. Chaque note porte une priorité : Hot News (les plus critiques, typiquement CVSS 9–10), High, Medium et Low.

Un processus de patching viable :

  • Utilisez System Recommendations (dans SAP Solution Manager ou Focused Run) pour voir les notes de sécurité manquantes par système, plutôt que de lire la liste mensuelle manuellement.
  • Traitez les Hot News et High d'abord, sur les systèmes exposés à internet et productifs.
  • Intégrez les security notes dans une cadence de maintenance régulière pour qu'elles ne s'accumulent pas en méga-projet annuel.
  • Tracez les notes appliquées comme preuve d'audit, « on patche » est une affirmation ; le relevé note par note est la preuve.

Le patching est ingrat et c'est le contrôle de cybersécurité SAP au plus fort impact. La plupart des compromissions SAP publiques remontent à une vulnérabilité pour laquelle un correctif était disponible.

2. Durcissement système : les paramètres de profil

Une grande partie du durcissement SAP passe par la configuration via les paramètres de profil. Les plus importants :

  • Politique de mot de passe et de logon: login/min_password_lng, la famille login/password_*, login/fails_to_user_lock, et la désactivation des hachages de mot de passe rétro-compatibles faibles.
  • login/no_automatic_user_sapstar = 1: empêche le logon de secours codé en dur de SAP* (mot de passe par défaut PASS) si l'enregistrement utilisateur SAP* venait à être supprimé.
  • auth/no_check_in_some_cases et interrupteurs associés, gouvernent le comportement des contrôles d'autorisation ; à définir délibérément, pas à laisser aux valeurs héritées.
  • rfc/reject_expired_passwd et snc/*: renforcent la sécurité RFC et des communications.

Ne réglez pas ces paramètres un à un de mémoire. Utilisez le SAP Security Baseline Template et Configuration Validation (dans Solution Manager / Focused Run) pour définir une configuration cible et mesurer en continu la dérive par rapport à celle-ci.

3. Sécurité du gateway et du message server

Le gateway démarre et communique avec des programmes externes. Laissé ouvert, c'est l'un des chemins d'attaque SAP les plus exploités. Il est contrôlé par deux listes de contrôle d'accès :

  • reginfo (paramètre gw/reg_info), quels programmes externes peuvent s'enregistrer auprès du gateway.
  • secinfo (paramètre gw/sec_info), quels programmes peuvent être démarrés par le gateway.

Définissez les deux en listes d'autorisation, activez la journalisation du gateway (gw/logging) pour voir ce qui se connecte réellement avant de resserrer, et appliquez les Security Notes de durcissement pertinentes.

Le message server doit séparer ses ports interne et externe (rdisp/msserv_internal) et restreindre l'accès avec une ACL de message server (ms/acl_info), de sorte que les serveurs d'application, et uniquement eux, puissent lui parler en interne.

4. Sécurité RFC et UCON

RFC est le moyen par lequel les systèmes SAP se parlent, et c'est un chemin de déplacement latéral classique. Trois choses à bien maîtriser :

  • RFC de confiance (trusted RFC): les relations de confiance doivent être minimales et directionnelles. Un bac à sable peu sécurisé ne doit jamais être digne de confiance pour la production.
  • Identifiants stockés: les destinations RFC (SM59) qui stockent un utilisateur et un mot de passe sont un risque permanent ; préférez le trusted RFC ou des utilisateurs techniques avec des autorisations S_RFC étroitement cadrées.
  • UCON (Unified Connectivity): le scénario RFC basique permet de construire une liste d'autorisation des modules fonctionnels RFC réellement appelés depuis l'extérieur, puis de bloquer les milliers d'autres. Cela réduit fortement la surface joignable à distance.

5. Communication sécurisée (SNC / TLS)

Par défaut, le trafic SAP GUI (DIAG) et RFC peut circuler en clair sur le réseau. Secure Network Communications (SNC) chiffre DIAG et RFC ; TLS/HTTPS protège le trafic Fiori et web. Sur tout système portant des données réglementées ou financières, c'est-à-dire la plupart des systèmes SAP, la communication chiffrée doit être la base, pas une option. C'est aussi un contrôle que les auditeurs attendent de plus en plus de voir démontré.

6. Surveillance : le Security Audit Log et au-delà

La prévention n'est jamais complète, il faut donc voir ce qui se passe :

  • Security Audit Log (SAL): configuré via RSAU_CONFIG (ou l'ancien SM19) et lu via RSAU_READ_LOG / SM20. Journalisez les événements pertinents pour la sécurité : logons échoués, usage de transactions critiques, changements de configuration sensible et, surtout, les sessions Firefighter / accès d'urgence.
  • Enterprise Threat Detection (ETD) ou intégration SIEM, pour une corrélation en temps réel entre systèmes, transférez les événements de sécurité SAP dans une plateforme de surveillance plutôt que de relire les logs après coup.
  • Analyse du code spécifique: le Code Vulnerability Analyzer (CVA) détecte les failles d'injection et de contrôle d'autorité dans votre ABAP avant leur mise en production.

Là où cela rejoint la gouvernance des accès

Durcissement de la plateforme et gouvernance des accès sont les deux moitiés d'un même contrôle. Un système durci avec un catalogue de rôles pléthorique et truffé de SAP_ALL reste grand ouvert de l'intérieur ; un ruleset SoD propre sur un système non patché au gateway ouvert est un faux sentiment de sécurité.

Ils se renforcent aussi mutuellement. L'accès d'urgence en est l'exemple le plus clair : un processus Firefighter SAP bien conçu est un contrôle de gouvernance des accès, mais il ne produit une preuve fiable que si le Security Audit Log capture les sessions et que la plateforme sous-jacente est saine. Et la surveillance continue des risques d'accès, celle que fournit notre outil MTC Skopos, boucle la boucle entre « qui a accès » et « ce qui se passe réellement » avec cet accès.

Une feuille de route de durcissement pragmatique

Si vous partez d'un paysage typique jamais durci, séquencez ainsi :

  1. Maîtriser le patching: System Recommendations, Hot News d'abord.
  2. Fermer le gateway et le message server: listes d'autorisation reginfo/secinfo, ACL, journalisation.
  3. Verrouiller les utilisateurs standard: mots de passe, logon de secours SAP*, comptes inutilisés.
  4. Établir une baseline de configuration: Security Baseline Template + Configuration Validation, puis gérer la dérive.
  5. Réduire la surface RFC: nettoyage du trusted RFC, UCON.
  6. Chiffrer les communications: SNC et TLS.
  7. Activer une vraie surveillance: Security Audit Log réglé sur des événements pertinents, transféré vers un SIEM ou ETD.

Vous n'avez pas besoin de tout faire d'un coup. Vous avez besoin d'un plan qui les traite comme un seul programme plutôt que comme sept tickets déconnectés.

Comment MTC aide

Nous évaluons et durcissons les plateformes SAP pour des organisations suisses et internationales : mise en place de la gestion des correctifs, baseline de configuration, réduction de l'exposition gateway/RFC, communication sécurisée et surveillance de sécurité, articulés avec le versant gouvernance des accès (SoD, Firefighter, autorisations) pour obtenir une posture de sécurité SAP cohérente plutôt que deux équipes résolvant chacune la moitié du problème. Sur les grands programmes, nous collaborons avec des cabinets internationaux de premier plan en audit, risque et technologie, tout en gardant le résultat de sécurité maîtrisé par une équipe senior basée en Suisse.

À lire également

Questions fréquentes

Qu'est-ce que la cybersécurité SAP ?

La cybersécurité SAP est la protection de la plateforme SAP elle-même, kernel, communications, configuration et code, contre le détournement et l'attaque, par opposition à la gestion des autorisations (qui peut faire quoi dans l'application). Elle couvre les SAP Security Notes et le patching, le durcissement système via les paramètres de profil, la sécurité gateway et RFC, la communication sécurisée (SNC/TLS) et la surveillance via le Security Audit Log.

À quelle fréquence SAP publie-t-il des Security Notes ?

SAP publie ses Security Notes lors du SAP Security Patch Day, le deuxième mardi de chaque mois. Les notes sont classées par priorité, Hot News (les plus critiques), High, Medium et Low. Les notes Hot News et High affectant vos systèmes doivent être évaluées et planifiées rapidement ; l'outil System Recommendations (dans SAP Solution Manager ou Focused Run) identifie les notes manquantes sur chaque système.

Quelle différence entre sécurité SAP et autorisations SAP ?

Les autorisations SAP contrôlent qui peut faire quoi dans l'application via les rôles et objets d'autorisation. La sécurité SAP (cybersécurité) est plus large : elle protège aussi la plateforme sur laquelle tournent les autorisations, patching, durcissement gateway et RFC, communication sécurisée, verrouillage des utilisateurs standard et surveillance. Des autorisations solides sur un système non patché et ouvert ne suffisent pas ; les deux couches doivent être sécurisées ensemble.

Comment sécuriser le gateway SAP ?

Le gateway SAP se durcit principalement via ses listes de contrôle d'accès : le fichier reginfo (quels programmes externes peuvent s'enregistrer, contrôlé par le paramètre gw/reg_info) et le fichier secinfo (quels programmes peuvent être démarrés, gw/sec_info). Laisser le gateway ouvert permet à des programmes externes non autorisés de s'enregistrer et d'exécuter des commandes. Combinées à la journalisation (gw/logging) et aux SAP Security Notes pertinentes, ces ACL ferment l'un des chemins d'attaque SAP les plus courants.