Introduction : pourquoi la cybersécurité SAP merite un traitement distinct
Il y a encore trois ans, dans la plupart des grandes DSI que j'accompagnais, la cybersécurité SAP etait un sous-chapitre negligeable de la stratégie de sécurité IT globale. L'equipe SOC surveillait les postes de travail, le reseau, les serveurs Windows et Linux, et consacrait a l'ERP une attention symbolique, souvent limitee a un scan de vulnerabilites annuel. Ce modèle est aujourd'hui intenable.
Le paysage SAP concentre ce qu'une entreprise a de plus sensible : la paie, la tresorerie, les données clients, les previsions financieres, les contrats fournisseurs, parfois les specifications produits. Le compromettre, ce n'est pas perdre un poste de travail : c'est offrir a un attaquant les clés du coffre-fort et de la chambre forte en même temps. Les menaces ne viennent pas uniquement de l'extérieur : dans un projet recent pour un grand groupe de BTP, l'audit a revele que le risque majeur etait un administrateur fonctionnel devenu interne-malveillant potentiel, disposant de SAP_ALL depuis sept ans sur la production.
Dans cet article, je propose un cadre en trois couches pour structurer la cybersécurité SAP, je partage les erreurs les plus frequentes que j'observe en prod, et je detaille une démarche pratique en quatre étapes, avec des exemples sectoriels concrets. L'objectif : donner a une DSI un plan d'action réaliste, ni minimaliste, ni paralysant pour les equipes métier.
Pourquoi la cybersécurité SAP n'est pas un sous-ensemble de la sécurité IT
Un périmètre a part, avec ses protocoles et ses codes
La sécurité SAP repose sur des mécanismes spécifiques que les outils generalistes du marche ne savent pas inspecter nativement. Le protocole RFC, la Gateway, le Message Server, le format de roles PFCG, les parametres sec/*, les Security Notes, l'architecture d'autorisations basee sur les valeurs organisationnelles... tout cela constitue un univers technique dont la maîtrise demande plusieurs années d'exposition terrain.
Un CASB generique, un EDR, un SIEM non specialise SAP passeront a cote de 80% des attaques ciblees sur un ERP. J'ai vu un EDR remonter des alertes sur des PowerShell suspects pendant qu'au même moment, sur le même paysage, un compte technique RFC exfiltrait trois mois de données clients sans declencher la moindre alerte cote sécurité IT.
Des données et des processus critiques concentres
Un seul système S/4HANA heberge typiquement :
- les données financieres consolidees (comptabilité, tresorerie, cloture)
- les données RH et de paie, soumises au RGPD
- les données clients (CRM, facturation)
- les données fournisseurs et contrats d'achat
- parfois des specifications produits ou des nomenclatures sensibles (industrie, defense)
Cette concentration rend l'ERP particulièrement attractif. Le niveau d'exigence reglementaire suit : RGPD pour les données personnelles, SOX pour les sociétés cotees aux États-Unis, ISO 27001 pour la certification globale, normes sectorielles (NIS2, DORA pour le financier, exigences defense). L'auditeur externe qui intervient pour SOX ou ISO 27001 demande des preuves spécifiques au SAP, que la sécurité IT générale ne sait pas produire.
Des processus métier qui ne tolerent pas l'interruption
Si vous detectez une compromission sur un serveur de fichiers, vous pouvez l'isoler quelques heures sans arreter l'activité. Si vous isolez un serveur d'application SAP PRD en pleine matinee, vous arretez la paie, les commandes, la facturation, parfois la production. La reponse a incident SAP doit être concue avec cette contrainte : discretion, precision, et capacité a agir sans provoquer un arret generalise.
Les trois couches a securiser
Couche 1 : acces et authentification
C'est la porte d'entree. La majorite des incidents SAP que j'analyse commencent par un compte compromis ou un provider d'identité mal gouverne.
Le SSO et ses pièges. La plupart des grands comptes ont bascule en SSO federe, typiquement via Azure AD ou SAP IAS (Identity Authentication Service). En théorie, cela elimine les mots de passe locaux et centralise la gouvernance. En pratique, je découvre régulièrement des systèmes ou plusieurs Identity Providers coexistent sans gouvernance : un IAS pour le BTP, un Azure AD pour le corporate, un AD local pour l'historique ECC. Le bypass devient trivial pour un attaquant qui identifie le provider le plus faible.
Le MFA systématique. Le MFA doit être exige pour tout compte a privilege sur SAP (SAP_ALL, SAP_NEW, roles administrateurs fonctionnels), et idéalement pour tous les utilisateurs métier. Sur un projet defense, nous avons déployé IAS + MFA via application mobile pour 12 000 utilisateurs en huit mois : la bascule a ete techniquement fluide grace au SSO existant, le blocage etait organisationnel (support utilisateur, gestion des exceptions).
Les roles et la SoD. La transaction PFCG gouverne la construction des roles ; SU01 les affecte. Le vrai sujet est la Segregation of Duties (SoD) : aucun utilisateur ne doit avoir simultanement le droit de créer un fournisseur et de valider un paiement, par exemple. Les grands cabinets d'audit verifient ce point systématiquement. Les outils comme SAP GRC Access Control ou SAP Cloud IAG permettent de modéliser ces règles et de les vérifier en continu.
La purge des comptes SAP_ALL. Le reflexe historique consistait a accorder SAP_ALL aux admins, aux consultants, aux chefs de projet "le temps du projet". Ces droits ne sont presque jamais revoques. Dans un projet recent pour un acteur du BTP, la purge a concerné 340 comptes SAP_ALL herites, dont 180 etaient encore actifs.
Couche 2 : paysage et infrastructure
C'est la couche que les equipes sécurité IT comprennent le moins. Elle concentre pourtant les vulnerabilites les plus exploitees.
La surface d'attaque. Un système SAP expose typiquement plusieurs services reseau : Dispatcher (port 3200+instance), Gateway (port 3300+instance), Message Server (port 3600+instance), ICM pour HTTP/HTTPS (port 8000/44300+instance), HANA (port 3xx15/xx13). Chacun est une porte potentielle. La règle : lister exhaustivement ces ports, restreindre leur exposition au strict nécessaire, et journaliser les acces.
La Gateway, talon d'Achille. Une Gateway non durcie accepte les connexions RFC externes de n'importe quelle source. Les fichiers reg_info et sec_info permettent de declarer explicitement quels programmes et quelles IP sont autorises. Sur un projet énergie, l'audit Gateway a revele 47 programmes RFC externes connectes sans declaration formelle. Certains etaient legitimes mais non documentes, d'autres relevaient de systèmes obsolètes deconnectes depuis des années mais dont la Gateway continuait d'accepter les connexions. La fermeture contrôlée a pris quatre semaines.
Les Security Notes et le patching. SAP publie chaque deuxième mardi du mois (Patch Tuesday SAP) un lot de Security Notes, categorisees par criticité CVSS. La transaction SNOTE permet de les appliquer. La réalité que je rencontre : la plupart des systèmes accusent 6 à 18 mois de retard sur les patchs critiques. Cela revient a laisser des CVE publiques connues exploitables sur un ERP de production. La solution : un processus mensuel dedie, avec fenêtre de maintenance prévue, et un suivi transverse qui alerte quand une note critique (CVSS >= 9) n'a pas ete appliquee dans les 30 jours.
Le durcissement des parametres. Les parametres sec/* et quelques parametres profile-level structurent la posture de sécurité. Quelques exemples clés :
- login/password_min_length : minimum 12 caractères
- login/password_expiration_time : 90 jours maximum
- login/fails_to_user_lock : 5 tentatives avant verrouillage
- gw/reg_no_conn_info : 1 pour durcir la Gateway
- snc/enable : 1 pour chiffrer les communications SAP GUI
- icm/HTTPS/verify_client : 1 pour vérifier les certificats clients
Un audit rapide via RSPARAM ou via SAP EarlyWatch Alert liste en quelques minutes les parametres non conformes aux recommandations SAP.
Les interfaces OData, RFC, API. Les integrations entre S/4HANA, BTP, SuccessFactors, Ariba, et les systèmes legacy passent par une multitude d'interfaces. Chacune est une potentielle fuite : un endpoint OData non authentifie, un compte RFC technique a fort privilege dont le mot de passe n'a pas tourne depuis cinq ans, un Cloud Connector mal configure. Le durcissement consiste a inventorier toutes ces interfaces, a leur affecter un compte technique dedie avec le minimum de droits, a chiffrer les flux (SNC, TLS), et a journaliser les appels.
Couche 3 : audit et conformité
La cybersécurité SAP ne se pilote pas sans mesure. L'audit periodique est ce qui permet de savoir ou on en est, et de démontrer la conformité aux auditeurs externes.
L'audit technique. Il couvre le paysage complet : ECC, S/4HANA, BTP, HANA DB, systèmes satellites. Il examine la surface d'attaque, les Security Notes, les roles, la SoD, les interfaces, les logs. Je recommandé un audit complet annuel, complète par des checks trimestriels automatisés.
Les outils SAP natifs. SAP EarlyWatch Alert (gratuit, envoye par SAP chaque semaine) fournit déjà une première ligne de checks : parametres critiques, patchs manquants, indicateurs de sécurité. SAP Solution Manager (en fin de vie mais encore largement déployé) et SAP Focused Run offrent des capacités de monitoring etendu. L'ATC (ABAP Test Cockpit) avec les profils de check security permet de detecter les failles dans le code custom : injections SQL, traversal path, appels dangereux.
La conformité RGPD, ISO 27001, SOX. Chaque referentiel impose des preuves spécifiques : traces d'acces aux données personnelles, separation des droits, revue periodique des comptes, procédures de gestion des incidents. La clé est de mettre en place les mécanismes de collecte AVANT l'audit externe, pas dans la panique trois semaines avant. Un plan d'action priorise, avec des preuves versionnees (rapports d'audit, captures de parametres, rapports d'ATC), rend les auditeurs externes beaucoup plus bienveillants.
Les erreurs recurrentes que j'observe en production
Après une dizaine de missions de cybersécurité SAP ces deux dernières années, je retrouve les mêmes defaillances, avec une regularite deconcertante :
1. SAP_ALL distribue a des comptes actifs. Plus d'un système sur deux conserve des comptes SAP_ALL actifs sans justification métier : anciens consultants, comptes de depannage, admins fonctionnels devenus responsables métier mais jamais depossedes.
2. Patchs Security Notes en retard de 6 à 18 mois. Y compris sur des systèmes SOX avec auditeur externe annuel. Le retard persiste parce qu'aucun budget n'est explicitement alloue au patching de sécurité.
3. Gateway ouverte sans reg_info ni sec_info. La Gateway est souvent la première vulnerabilite critique découverte lors d'un pentest SAP.
4. Password policy faible. login/password_min_length a 6 ou 8, pas de MFA sur les comptes a privilege, absence de durcissement SNC sur SAP GUI. Le test de brute force en moins d'une heure suffit alors a compromettre un compte admin.
5. Identity Providers multiples non gouvernes. L'attaquant cible l'IdP le plus faible et contourne le MFA du principal. La gouvernance IdP est un sujet transversal qui depasse la seule equipe SAP.
6. Comptes techniques RFC a fort privilege. DDIC non verrouille en prod, comptes COMMUNICATION ou BATCH avec SAP_ALL, mots de passe identiques sur DEV/QAS/PRD. C'est une faille classique exploitable par mouvement lateral depuis un environnement de dev moins surveille.
7. Absence de plan de reponse à incident spécifique SAP. Le SOC de l'entreprise a un playbook generique. Personne ne sait qui appeler a 3h du matin si un administrateur SAP constate une activité anormale sur SM20 (log de sécurité). Les premières 48h, cruciales, sont gaspillees en coordination.
Une démarche pratique en quatre étapes
Étape 1 : audit initial (6 à 10 semaines)
L'audit initial etablit la cartographie reelle de la posture de sécurité. Il couvre :
- Inventaire du paysage : liste des systèmes (ECC, S/4HANA, BTP, HANA DB, satellites), versions, niveaux de patch
- Surface d'attaque : ports ouverts, Gateway, Message Server, ICM, exposition Internet
- Security Notes : état des patchs critiques, retards identifies
- Roles et SoD : revue des roles critiques, contrôle SoD sur les processus sensibles (O2C, P2P, R2R)
- Interfaces : inventaire RFC, OData, API, Cloud Connectors, avec comptes techniques associes
- Conformité : mapping avec les exigences ISO 27001, RGPD, SOX (si applicable)
Livrables : rapport d'audit, matrice de risque priorisee, plan d'action a 12-18 mois.
Étape 2 : quick wins (3 à 4 mois)
L'objectif est de faire disparaitre les failles les plus beantes sans attendre la refonte structurelle :
- Application des Security Notes critiques en retard
- Durcissement Gateway (reg_info, sec_info)
- Renforcement password policy et bascule MFA sur les comptes a privilege
- Purge des comptes SAP_ALL actifs inutiles
- Rotation des mots de passe des comptes techniques RFC
- Verrouillage de DDIC, SAP*, EARLYWATCH en prod
Ces quick wins ne demandent pas de transformation majeure et reduisent souvent 60 à 70% du risque exploitable.
Étape 3 : durcissement structurel (6 à 12 mois)
On attaque ici les sujets qui demandent un effort projet :
- Identity and Access Governance. Mise en place ou consolidation de SAP IAS, integration avec SAP IAG pour la gouvernance SoD continue, gouvernance unifiee des IdP (un seul IdP principal, les autres federes ou retires).
- MFA generalise. Bascule progressive de tous les utilisateurs sur MFA, avec communication et support adaptes.
- Audit des interfaces. Refactoring des comptes techniques RFC avec principe du moindre privilege, rotation automatique des secrets, journalisation centralisee.
- SIEM SAP. Integration des logs SAP (SM20, HANA Audit, ICM logs) dans un SIEM general, avec règles de correlation spécifiques.
Étape 4 : run sécurité continu
La cybersécurité SAP ne se fait pas en mode projet one-shot. Le run continu inclut :
- Patching mensuel : application des Security Notes critiques dans les 30 jours
- Revue trimestrielle des roles, de la SoD, des comptes a privilege
- Audit annuel complet, avec rapport executif pour le COMEX et le RSSI
- Monitoring continu via SIEM SAP, avec astreinte spécifique SAP integree au SOC
- Formation : sensibilisation des equipes fonctionnelles, technique pour la Basis et les développeurs ABAP
Exemples concrets par secteur
Énergie : 47 RFC externes non declarees
Chez un gestionnaire de reseau énergétique, l'audit Gateway a revele 47 programmes RFC externes connectes au système central sans declaration dans reg_info. Après analyse, 18 correspondaient a des systèmes legitimes mais non documentes (outils de reporting, integrations partenaires), 11 a des systèmes de test oublies mais encore connectes, et 18 restaient non identifies. La fermeture s'est faite en deux vagues sur quatre semaines, avec une première passe de whitelisting explicite puis une seconde passe de fermeture après confirmation que les 18 non identifies n'etaient plus actifs. Un vrai cas ou le principe de moindre privilege a reduit drastiquement la surface d'attaque sans aucun impact métier.
Defense : IAS + MFA + IAG pour 12 000 utilisateurs
Dans l'industrie defense, ou les exigences de sécurité sont particulièrement elevees, nous avons déployé une architecture d'authentification unifiee sur un paysage hétérogène (S/4HANA, BTP, SuccessFactors, plusieurs ECC de filiales). Le socle : SAP IAS comme IdP unique, MFA via application mobile pour tous, SAP IAG pour la gouvernance des acces et des contrôles SoD automatisés. Le déploiement s'est etale sur 8 mois, avec une vague pilote de 500 utilisateurs, puis deux vagues massives de 5 000 et 6 500. Les trois mois suivants ont servi au stabilisation et au traitement des exceptions. Le point critique a ete la gouvernance des exceptions MFA : chaque dispense devait être documentee, motivee, et revue mensuellement.
Construction : purge de 340 comptes SAP_ALL
Chez un acteur majeur du BTP, l'audit initial a remonte 340 comptes disposant de SAP_ALL sur la production. L'analyse detaillee a montre que 180 etaient actifs (connexion dans les 6 derniers mois) et 160 dormants. La purge s'est organisee en trois temps : desactivation immediate des 160 dormants (aucun impact constate), analyse poste par poste des 180 actifs avec leurs managers fonctionnels (85 etaient illegitimes et ont ete remplaces par des roles composite adaptes, 95 ont ete conserves mais rationalises avec des roles intermédiaires), rationalisation des roles composite pour éviter la reemergence de SAP_ALL-équivalents. Le chantier complet a dure cinq mois et a reduit significativement la surface interne d'attaque.
Les outils qui aident (et ceux a éviter)
Outils SAP natifs
- SAP EarlyWatch Alert : gratuit, inclus dans le support SAP. A lire chaque semaine. Premier filtre pour les indicateurs de sécurité basiques.
- SAP Solution Manager / SAP Focused Run : monitoring opérationnel et sécurité. Focused Run est le successeur recommandé.
- SAP Cloud ALM : pour les paysages cloud/hybrides recents. Monte en puissance sur les capacités de sécurité.
- SAP GRC Access Control : la référence pour la SoD et la gouvernance des acces, lourde a déployer mais puissante.
- SAP Cloud Identity Access Governance (IAG) : équivalent SaaS pour les paysages cloud, plus leger a mettre en oeuvre.
- SAP Enterprise Threat Detection (ETD) : SIEM SAP natif, pertinent pour les grands comptes avec equipe sécurité SAP dediee.
Acteurs tiers specialises
- Onapsis : leader historique de la sécurité SAP, très complet sur la detection des vulnerabilites et la conformité.
- SecurityBridge : alternative européenne (autrichienne) en forte croissance, integration native SAP.
Ces outils ne remplacent pas la discipline interne, mais ils accelerent la detection et structurent le run.
A éviter
- Les CASB generiques sans connecteur SAP dedie : ils n'inspectent pas le RFC, ne comprennent pas PFCG, ne correlent pas les logs SM20.
- Les EDR generalistes comme unique defense : nécessaires mais insuffisants sur l'ERP.
- Les scans de vulnerabilites reseau généraux (Nessus, Qualys) sans module SAP : ils detectent les ports mais pas les vulnerabilites applicatives SAP.
Conclusion : la cybersécurité SAP est une discipline continue
La cybersécurité SAP n'est pas un projet que l'on livre et que l'on oublie. Elle se construit dans la duree, par iterations, avec un equilibre permanent entre durcissement technique et fluidite opérationnelle. Les entreprises qui reussissent cette discipline partagent trois caracteristiques : elles ont une gouvernance claire (qui decide, qui patch, qui audit), un budget recurrent dedie (pas un one-shot de mise en conformité), et une equipe ou la compétence SAP et la compétence sécurité se parlent.
Investir dans la gouvernance est plus rentable que d'acheter un outil isole. J'ai vu des entreprises depenser plusieurs centaines de milliers d'euros dans un outil tiers puis laisser les Security Notes en retard de 12 mois, faute d'une equipe pour les appliquer. J'ai vu, inversement, des DSI avec peu d'outils mais une discipline mensuelle de patching et une revue trimestrielle de la SoD atteindre un niveau de posture superieur.
Mon conseil final : commencez par l'audit, sincerement, sans chercher a vous rassurer. La photo initiale est souvent brutale, mais c'est le seul point de depart credible. Priorisez les quick wins. Construisez la gouvernance. Ensuite seulement, outillez. Votre ERP heberge ce que votre entreprise a de plus precieux : il merite une attention a la hauteur de sa valeur.