Meylan Technologies & ConsultingLa question arrive sur tous les programmes S/4HANA qui comptent des techniciens itinérants, des responsables de site, des auditeurs externes ou une force de vente qui n'installera pas de client VPN. Quelqu'un a besoin du launchpad Fiori depuis l'extérieur du réseau d'entreprise, et l'architecture proposée est presque toujours la même : publier le serveur frontal, placer un SAP Web Dispatcher en DMZ devant lui, acheter un certificat, mettre en production.
C'est une erreur, et la raison est plus précise que l'argument habituel de défense en profondeur. Il ne s'agit pas de dire que plus de couches valent mieux que moins. Il s'agit du fait que ce que vous publiez est un serveur d'applications ABAP, et que le contrôle qui a réellement protégé les clients SAP au cours des quatre dernières années de vulnérabilités critiques n'était pas le patching. C'était l'accessibilité réseau.
Ce qui se retrouve exposé
Un serveur frontal Fiori n'est pas un serveur web qui se trouve à proximité de SAP. C'est un serveur d'applications ABAP complet qui sert accessoirement une application web. Le publier place l'Internet Communication Manager sur internet, et derrière l'ICM se trouve l'intégralité de l'arbre de services Internet Communication Framework.
Fiori lui-même a besoin d'une douzaine de chemins : le shell du launchpad sous /sap/bc/ui2/, les ressources UI5 sous /sap/bc/ui5_ui5/, les services OData sous /sap/opu/odata/. Un serveur frontal S/4HANA standard compte plusieurs centaines de noeuds ICF actifs. Le reste de l'arbre contient typiquement :
| Chemin | De quoi il s'agit |
|---|---|
/sap/bc/gui/sap/its/webgui | SAP GUI dans le navigateur, avec tout le jeu de transactions derrière |
/sap/bc/soap/rfc | RFC via SOAP |
/sap/bc/webdynpro/ | Une pile d'interface distincte, avec son propre historique de CVE |
/sap/bc/adt | Le point d'entrée de développement ABAP |
/sap/public/info | SID, version du kernel, nom d'hôte et fuseau horaire, sans authentification |
Ce dernier livre l'étape de reconnaissance. Rapprocher un niveau de patch kernel des notes publiées par SAP relève ensuite de la comptabilité.
Le launchpad en ajoute davantage. Les documents $metadata OData décrivent vos entity sets, soit une carte lisible des fonctions métier que le système propose. Et sauf modification de votre part, le formulaire de connexion accepte l'authentification basique contre le référentiel utilisateurs SAP, sans second facteur, au rythme que l'ICM voudra bien servir.
L'écran de connexion n'est pas la frontière
Deux vulnérabilités SAP montrent pourquoi « l'attaquant doit quand même s'authentifier » est un mauvais modèle mental.
La CVE-2022-22536, baptisée ICMAD par Onapsis, est une désynchronisation des memory pipes de l'ICM. CVSS 10.0, exploitable par un attaquant non authentifié avec une seule requête HTTP forgée, avec pour conséquence le détournement de session et la prise de contrôle du système. SAP l'a corrigée en février 2022. Elle affectait NetWeaver ABAP et Java, l'ABAP Platform, SAP Content Server et le SAP Web Dispatcher. La CISA l'a ajoutée au catalogue Known Exploited Vulnerabilities au mois d'août suivant.
La CVE-2025-31324 est un contrôle d'autorisation manquant dans le metadata uploader de NetWeaver Visual Composer, également CVSS 10.0. Un POST non authentifié sur un seul endpoint permettait de déposer un web shell JSP. SAP a publié un correctif hors cycle le 24 avril 2025. Censys a dénombré plus de 7 500 serveurs d'applications NetWeaver exposés et estimé qu'une majorité des piles Java accessibles depuis internet avait le composant vulnérable activé. EclecticIQ a ensuite récupéré les propres fichiers de journalisation d'un attaquant, listant 581 systèmes compromis et 1 800 domaines supplémentaires en file d'attente, attribués à des groupes liés à la Chine, touchant la distribution de gaz, des services des eaux, la fabrication de dispositifs médicaux et des ministères.
Ce sont les dates qui comptent.
| Quand | Ce qui s'est passé |
|---|---|
| Fin janvier 2025 | Palo Alto Unit 42 observe des sondages contre l'endpoint vulnérable |
| À partir du 27 mars 2025 | Rapid7 confirme une exploitation active |
| 24 avril 2025 | SAP publie une note de sécurité hors cycle |
| Les semaines suivantes | Censys dénombre plus de 7 500 serveurs exposés ; EclecticIQ récupère des journaux d'attaquant nommant 581 systèmes compromis |
Pendant un mois, et vraisemblablement trois, tout système exposé sur internet avec ce composant activé était compromettable sans correctif disponible, sans signature à déployer et sans avis de sécurité à lire.
Visual Composer est un composant de la pile Java : cette CVE-là n'est donc pas une histoire de serveur frontal Fiori. ICMAD, si : elle touchait l'ICM, c'est-à-dire exactement ce que vous publiez quand vous publiez un serveur Fiori. Ce qui se transpose, c'est la forme de l'événement, pas le composant. Une exécution de code à distance avant authentification dans une pile web SAP exposée, divulguée après des semaines d'exploitation.
Aucune discipline de patching n'aurait aidé. Aucune politique de mots de passe n'aurait aidé. Le contrôle qui comptait était l'accessibilité réseau. Si un attaquant non authentifié ne peut pas ouvrir une connexion TCP vers votre ICM, une RCE avant authentification dans votre ICM devient un ticket de maintenance plutôt qu'un incident.
Ce que le Web Dispatcher fait, et ne fait pas
Le SAP Web Dispatcher a sa place dans cette architecture. Il n'est pas une frontière de sécurité à lui seul, et le traiter comme telle est l'erreur de conception la plus fréquente dans ce domaine.
| Ce qu'il fait | Ce qu'il ne fait pas |
|---|---|
| Terminer le TLS | Inspecter les charges utiles |
| Répartir la charge entre serveurs d'applications | Limiter le débit d'un credential stuffing |
| Masquer les noms d'hôtes et les ports internes | Imposer une MFA |
| Filtrer les URL via une table de permissions | Évaluer la posture du poste |
| Réécrire les en-têtes | Décider qui est l'utilisateur |
| Offrir au navigateur une origine unique, pour que la same-origin policy ne casse pas vos appels OData | Autre chose que transmettre, par défaut |
Il exécute par ailleurs le même code ICM que les serveurs d'applications situés derrière lui, ce qui explique qu'ICMAD l'ait également affecté. Onapsis a relevé que la CVE-2022-22536 était exploitable précisément lorsqu'un proxy se trouve entre les clients et le backend, ce qui décrit tout paysage de production. La couche proxy fait partie de la surface d'attaque, elle n'est pas à l'extérieur.
L'architecture
La quatrième couche est celle que les équipes ont du mal à nommer, ce qui explique en partie qu'elle passe à la trappe. Le terme est proxy d'authentification, ou reverse proxy de pré-authentification. Les éditeurs le commercialisent sous les noms d'identity-aware proxy, access gateway, web access management ou broker ZTNA : Microsoft Entra ID Application Proxy, F5 BIG-IP APM, NetScaler Gateway, NetIQ Access Gateway. La version SAP est Network Edge Authentication avec SAP Single Sign-On, où le Web Dispatcher réalise lui-même l'étape d'authentification.
La mécanique d'identité repose sur SAML 2.0. Le serveur frontal est le Service Provider, l'IdP de l'entreprise authentifie l'utilisateur avec MFA et accès conditionnel appliqués à cet endroit, et la redirection que voit l'utilisateur est le binding SAML HTTP-Redirect. L'identité se propage ensuite vers l'intérieur par principal propagation : un certificat X.509 à durée de vie courte, une variable d'en-tête, ou un ticket de connexion SAP.
Deux conséquences. Vous pouvez désactiver entièrement l'authentification par formulaire et l'authentification basique sur le serveur frontal, ce qui retire d'internet l'oracle à mots de passe. Et la MFA devient possible tout court, parce que la pile d'authentification native de SAP ne fournit pas de second facteur pour le launchpad. Déplacer l'authentification vers l'IdP signifie que SAP hérite de ce que construit votre équipe identité, sans projet SAP.
La configuration qui doit suivre
Un schéma d'architecture n'est pas un contrôle. Chaque couche tient à une poignée de paramètres qui décident si elle fait réellement le travail que le schéma annonce.
Sur le WAF, exécutez l'OWASP Core Rule Set en mode blocage plutôt qu'en mode détection, limitez le débit sur le chemin d'authentification et vérifiez que vous disposez du virtual patching. Quand la prochaine note HotNews tombera, vous voudrez bloquer un chemin en quelques heures, pas attendre une fenêtre de mise à jour kernel.
Sur le proxy d'authentification, aucun passage anonyme sur aucun chemin, y compris les health checks et les ressources statiques. Imposez la MFA depuis les réseaux externes, fixez une durée de session plus courte qu'en interne, et journalisez chaque requête vers le SIEM.
Le Web Dispatcher est l'endroit où je trouve le plus d'écarts. Configurez wdisp/permission_table comme une liste d'autorisation en deny-by-default, qui permet les chemins Fiori et refuse explicitement le reste. Positionnez icm/HTTP/support_http2 de manière délibérée. Ajoutez HSTS, X-Content-Type-Options et une Content-Security-Policy avec une directive frame-ancestors, puisqu'un launchpad qui peut être encadré peut être victime de clickjacking. Maintenez le kernel au niveau de patch des systèmes situés derrière lui, au minimum, et traitez l'hôte comme un actif exposé sur internet pour le patching, non comme de l'infrastructure Basis.
Sur le serveur frontal, parcourez SICF et désactivez tout service hors du périmètre Fiori, en commençant par WebGUI, SOAP RFC, ADT et /sap/public/info. Positionnez is/HTTP/show_detailed_errors = FALSE pour arrêter la fuite des traces d'exécution. Positionnez icf/set_HTTPonly_flag_on_cookies et login/ticket_only_by_https. Activez la gestion des sessions de sécurité HTTP avec un http/security_session_timeout raisonnable. Vérifiez ensuite que les services OData actifs sont uniquement ceux que consomment les applications publiées, parce que l'activation d'un service est une décision que personne ne revisite. C'est la même discipline que le reste du durcissement de la plateforme SAP, appliquée à un hôte qui n'a aucune marge d'erreur.
Le backend doit être atteignable depuis le serveur frontal via une RFC de confiance avec un utilisateur contraint, et depuis rien d'autre. Le changement de protocole fait un vrai travail : OData en entrée, RFC en sortie, aucun chemin HTTP de la bordure vers le coeur. C'est l'argument le plus solide en faveur du déploiement hub plutôt qu'embedded lorsque le système est exposé sur internet, et cela vaut la peine de rouvrir le sujet si votre serveur Fiori est embedded dans S/4HANA.
Dans le SIEM, les journaux d'accès HTTP de l'ICM et le Security Audit Log ABAP doivent tous deux arriver, corrélés avec les journaux du proxy d'authentification. Sans cette corrélation, vous ne pouvez pas reconstituer ce qu'une session authentifiée a fait une fois à l'intérieur.
L'alternative BTP
SAP Business Technology Platform évite l'exposition plutôt que de l'atténuer. SAP Build Work Zone héberge le launchpad, SAP Cloud Identity Services gère l'authentification et SAP Cloud Connector relie le système on-premise au subaccount.
Cloud Connector établit son tunnel par reverse invoke : la connexion s'ouvre en sortie depuis l'intérieur de votre réseau. Aucune règle de pare-feu entrante, aucune adresse publiée, aucun service en écoute sur internet. La liste des ressources autorisées est appliquée de votre côté du tunnel, chemin par chemin.
Les contreparties sont réelles : dépendance à la disponibilité de BTP, coût d'abonnement, et un hôte Cloud Connector qui devient un point de contrôle exigeant son propre durcissement et sa propre surveillance. Pour les organisations déjà sur BTP, c'est généralement la meilleure réponse, et elle mérite d'être chiffrée avant de construire la pile à cinq couches.
Si vous héritez d'un système déjà exposé
Ne patchez pas en premier. Partez du principe que la fenêtre entre exploitable et corrigé a déjà été utilisée.
- Contrôlez les journaux d'accès de l'ICM à la recherche de requêtes vers des chemins qu'aucune application Fiori légitime n'appelle.
- Cherchez dans les répertoires servlet et JSP des fichiers que personne n'a créés.
- Passez en revue les utilisateurs, les affectations de rôles et les destinations RFC ajoutés depuis le dernier état connu comme sain.
- Menez une évaluation de compromission. Onapsis et Mandiant ont publié un outil conjoint pendant la réponse à la CVE-2025-31324 ; l'approche se généralise au-delà de cette CVE.
Ensuite patchez, ensuite fermez l'exposition. Patcher en premier détruit les preuves et ne fait rien contre un web shell déjà présent sur le disque.
La formulation pour le dossier d'audit
L'accès externe est intermédié par un reverse proxy d'authentification qui réalise une pré-authentification contre l'annuaire d'identité de l'entreprise, et le launchpad SAP Fiori n'est pas directement atteignable depuis les réseaux non fiables.
Les objectifs de contrôle derrière cette phrase sont ordinaires. L'annexe A de l'ISO 27001 exige la ségrégation des réseaux et la sécurité des services réseau. L'article 21 de NIS2 exige une sécurité des réseaux et un contrôle d'accès proportionnés au risque, et pour les entités concernées, un ERP qui porte le cycle order-to-cash entre dans ce périmètre. Tout auditeur ayant de l'expérience SAP demandera ce qui se trouve entre internet et l'ICM. « Le Web Dispatcher » n'est pas une réponse.
Comment MTC intervient
Nous concevons et revoyons les architectures de sécurité SAP pour des paysages réglementés et multi-pays, depuis Genève, y compris l'accès Fiori externe : réduction de l'arbre de services ICF, configuration du Web Dispatcher et du WAF, conception du proxy de pré-authentification et de la fédération SAML, déploiement hub ou embedded, alternatives BTP et Cloud Connector, et la corrélation de journaux que l'audit demandera. Sur les grands programmes, nous travaillons aux côtés de cabinets mondiaux de référence en audit, risque et conseil technologique, le résultat sécurité restant porté par une équipe senior basée en Suisse.
À lire également
- Conseil en sécurité SAP, notre périmètre complet
- Cybersécurité SAP : durcir la plateforme SAP, pas seulement les accès
- Migration SAP S/4HANA en Suisse : Greenfield, Brownfield ou Selective ?
- Contrôles généraux informatiques (ITGC) : guide pratique pour l'audit
- SAP GRC Access Control : ce que c'est et quand vous en avez besoin
Questions fréquentes
Peut-on exposer un launchpad SAP Fiori sur internet ?
Pas directement. Un serveur frontal Fiori est un serveur d'applications ABAP complet : le publier place l'Internet Communication Manager et l'ensemble de l'arbre de services Internet Communication Framework à portée d'attaquants non authentifiés. L'accès externe doit être intermédié par un reverse proxy de pré-authentification qui authentifie l'utilisateur auprès de l'annuaire d'identité de l'entreprise avant que la moindre requête n'atteigne SAP, avec un pare-feu applicatif web devant lui et le SAP Web Dispatcher derrière. L'alternative est SAP Build Work Zone sur BTP avec SAP Cloud Connector, qui ne nécessite aucune règle de pare-feu entrante.
Le SAP Web Dispatcher constitue-t-il une frontière de sécurité ?
Non, et le traiter comme telle est l'erreur de conception la plus fréquente sur les accès Fiori externes. Le Web Dispatcher termine le TLS, répartit la charge, masque les noms d'hôtes et les ports internes, filtre les URL via sa table de permissions et offre au navigateur une origine unique. Il n'inspecte pas les charges utiles, ne limite pas le débit d'un credential stuffing, n'impose pas de MFA et ne prend aucune décision sur l'identité de l'utilisateur : par défaut, il transmet. Il exécute par ailleurs le même code ICM que les serveurs d'applications situés derrière lui, ce qui explique que la CVE-2022-22536 l'ait également affecté. Il a sa place dans l'architecture, comme reverse proxy, pas comme le seul rempart entre internet et votre pile ABAP.
Qu'est-ce qu'un proxy d'authentification pour SAP Fiori ?
Un reverse proxy qui authentifie l'utilisateur auprès de l'annuaire d'identité de l'entreprise avant de transmettre quoi que ce soit à SAP, de sorte qu'aucune requête anonyme n'atteigne jamais la pile ABAP. Les éditeurs le commercialisent sous les noms d'identity-aware proxy, access gateway, web access management ou broker ZTNA : Microsoft Entra ID Application Proxy, F5 BIG-IP APM, NetScaler Gateway, NetIQ Access Gateway. La variante SAP est Network Edge Authentication avec SAP Single Sign-On, où le Web Dispatcher réalise lui-même l'étape d'authentification. La mécanique d'identité repose sur SAML 2.0, le serveur frontal jouant le rôle de Service Provider, l'identité se propageant ensuite vers l'intérieur par principal propagation.
Quels services ICF faut-il désactiver sur un serveur frontal Fiori exposé ?
Fiori a besoin d'une douzaine de chemins : le shell du launchpad sous /sap/bc/ui2/, les ressources UI5 sous /sap/bc/ui5_ui5/ et les services OData sous /sap/opu/odata/. Tout le reste de l'arbre SICF doit être revu et désactivé, en commençant par /sap/bc/gui/sap/its/webgui (SAP GUI dans le navigateur), /sap/bc/soap/rfc (RFC via SOAP), /sap/bc/webdynpro/, /sap/bc/adt (le point d'entrée de développement ABAP) et /sap/public/info, qui renvoie le SID, la version du kernel, le nom d'hôte et le fuseau horaire sans aucune authentification. Un serveur frontal S/4HANA standard compte plusieurs centaines de noeuds ICF actifs.
Qu'a démontré la CVE-2025-31324 sur l'exposition SAP sur internet ?
La durée réelle de la fenêtre entre exploitable et corrigeable. La faille était un contrôle d'autorisation manquant dans le metadata uploader de NetWeaver Visual Composer, CVSS 10.0, où un POST non authentifié sur un seul endpoint permettait de déposer un web shell JSP. Unit 42 a observé des sondages fin janvier 2025, Rapid7 a confirmé une exploitation active à partir du 27 mars au moins, et SAP a publié un correctif hors cycle le 24 avril. Pendant un mois, et vraisemblablement trois, tout système exposé sur internet avec ce composant activé était compromettable sans correctif disponible, sans signature à déployer et sans avis de sécurité à lire. Aucune discipline de patching ne pouvait aider : seule l'accessibilité réseau comptait.
SAP BTP est-il une manière plus sûre de publier Fiori vers l'extérieur ?
Le plus souvent oui, parce que cette approche évite l'exposition au lieu de l'atténuer. SAP Build Work Zone héberge le launchpad, SAP Cloud Identity Services gère l'authentification et SAP Cloud Connector relie le système on-premise au subaccount par reverse invoke : le tunnel s'ouvre en sortie depuis l'intérieur de votre réseau. Aucune règle de pare-feu entrante, aucune adresse publiée, aucun service en écoute sur internet, et la liste des ressources autorisées est appliquée de votre côté du tunnel, chemin par chemin. Les contreparties sont la dépendance à la disponibilité de BTP, le coût d'abonnement et un hôte Cloud Connector qui devient un point de contrôle exigeant son propre durcissement et sa propre surveillance.