Préparer les environnements SAP à NIS2 en France

Découvrez comment évaluer la sécurité SAP, renforcer la gouvernance et préparer votre organisation au futur cadre français de NIS2.

Pour les organisations opérant en France, NIS2 inscrit davantage la cybersécurité dans les mécanismes de gouvernance de l’entreprise. La sécurité ne peut plus être envisagée uniquement sous l’angle des infrastructures ou des réseaux dès lors que des activités critiques reposent sur des ERP, des services cloud, des applications interconnectées et des prestataires externes. Alors que le cadre national de transposition continue de se préciser, l’ANSSI encourage déjà les organisations susceptibles d’entrer dans le champ d’application de NIS2 à renforcer leur démarche de cybersécurité.

Cette évolution concerne directement les environnements SAP. La finance, les achats, la production, la logistique, les ressources humaines et d’autres processus métiers critiques reposent souvent sur des applications SAP et sur les systèmes qui leur sont connectés. L’enjeu n’est donc pas de déterminer si une solution SAP peut être qualifiée de « conforme à NIS2 », mais de savoir si la sécurité SAP est intégrée à la gouvernance globale de la cybersécurité et au dispositif de résilience opérationnelle de l’organisation.

Pour les organisations françaises, la préparation à NIS2 suppose d’aborder de manière cohérente les obligations réglementaires, les risques liés aux environnements SAP, la gouvernance de la sécurité et les contrôles nécessaires à la continuité des activités critiques. Ce guide présente les principaux éléments permettant de structurer cette démarche et explique comment les capacités SAP peuvent contribuer à un programme plus large de préparation à NIS2 en France.

Ce que NIS2 implique pour les organisations opérant en France

Pour les organisations présentes en France, la première question à se poser concerne le champ d’application de NIS2. La directive étend le cadre de cybersécurité instauré par NIS1 à un nombre beaucoup plus important d’entités publiques et privées, tout en introduisant deux catégories réglementaires : les entités essentielles et les entités importantes. Selon les estimations de l’ANSSI, ce dispositif élargi devrait à terme concerner plusieurs milliers d’organisations, réparties dans plus de 18 secteurs et environ 600 types d’entités en France.

De NIS1 à un cadre de cybersécurité élargi

L’assujettissement d’une organisation à NIS2 dépend principalement de la nature de ses activités et des secteurs couverts par la directive, ainsi que de critères tels que les effectifs, le chiffre d’affaires et le total du bilan. Certaines entités peuvent également entrer dans le champ d’application indépendamment de leur taille, selon les dispositions concernées. L’ANSSI recommande donc aux organisations d’évaluer leur propre situation au regard de la directive et met à leur disposition MonEspaceNIS2 comme ressource indicative pour les accompagner dans cette analyse.

Le champ d’application couvre notamment l’énergie, les transports, la santé, les infrastructures et services numériques, l’administration publique ainsi que certaines activités industrielles. Pour les groupes aux activités diversifiées, l’analyse doit être menée au niveau de chaque entité et de chaque activité concernée, et non déduite des technologies utilisées. La présence d’un environnement SAP ne détermine pas, à elle seule, l’applicabilité de NIS2.

Cette distinction est déterminante pour les décisions qui concernent ensuite la sécurité SAP. Avant de définir les contrôles à mettre en place ou de sélectionner des solutions technologiques, les organisations doivent identifier les entités juridiques et les activités entrant potentiellement dans le champ de NIS2. Elles doivent également disposer d’un inventaire des activités et services fournis par l’entité, ainsi que des systèmes d’information qui les prennent en charge. Cette cartographie constitue la base permettant de déterminer quels systèmes doivent être soumis aux mesures de cybersécurité applicables.

NIS2 place la cybersécurité au niveau de la direction

NIS2 renforce également le rôle de la gouvernance dans la gestion des risques cyber. L’article 20 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques en matière de cybersécurité et d’en superviser la mise en œuvre. La directive prévoit également que les membres de ces organes suivent une formation à la cybersécurité. Les dispositions relatives à leur responsabilité dépendent du cadre juridique national applicable.

La cybersécurité ne peut donc plus être considérée comme une responsabilité exclusivement technique, déléguée aux équipes sécurité ou infrastructure. Pour la direction, l’enjeu consiste à s’assurer que les risques cyber sont compris, que les décisions font l’objet d’une gouvernance claire et que les mesures adoptées sont suivies de manière appropriée.

Le modèle opérationnel détaillé de la sécurité SAP s’inscrit à un niveau plus concret. La responsabilité de la gestion des accès, la gestion des exceptions, l’attribution des actions de remédiation et les procédures d’escalade doivent découler de ce cadre de gouvernance, plutôt que d’être traitées comme des sujets techniques indépendants.

Les principales exigences de NIS2

L’article 21 impose aux entités essentielles et importantes de mettre en œuvre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées aux risques auxquels elles sont exposées. La directive adopte une approche tous risques et couvre notamment la sécurité des systèmes d’information et l’analyse des risques, la gestion des incidents, la continuité d’activité et la gestion de crise, la sécurité de la chaîne d’approvisionnement, la sécurité du développement et de la maintenance des systèmes, la gestion des vulnérabilités, l’évaluation de l’efficacité des mesures de sécurité, la sensibilisation et la formation à la cybersécurité, la cryptographie, la gestion des identités et des accès ainsi que l’authentification.

Dans les environnements SAP, ces exigences ne doivent pas être interprétées comme une liste de contrôle de conformité propre à SAP. Elles définissent le cadre général de cybersécurité dans lequel les systèmes SAP doivent être gérés. Les conséquences concrètes en matière d’identités, d’intégrations, de développements spécifiques, de vulnérabilités, de supervision et de reprise dépendent de l’architecture et du profil de risque propres à chaque organisation. Ces aspects sont abordés plus loin dans ce guide.

L’ANSSI et la mise en œuvre de NIS2 en France

Le contexte français reste particulièrement important, car le cadre national de mise en œuvre continue d’évoluer. En septembre 2026, l’ANSSI présente toujours la transposition de NIS2 en droit français comme imminente et qualifie les organisations concernées de futures entités essentielles et importantes. Les entreprises doivent donc distinguer les obligations directement issues de la directive européenne des dispositions qui dépendront du cadre législatif et réglementaire français définitif.

L’ANSSI a toutefois déjà fourni aux organisations des repères plus précis pour préparer leur démarche NIS2. En mars 2026, elle a publié le Référentiel Cyber France (ReCyF), qui présente les mesures recommandées par l’Agence pour répondre aux objectifs de sécurité associés à NIS2. À ce stade, le ReCyF est publié comme document de travail et n’a pas, par défaut, de caractère contraignant. Il ne constitue donc pas, à lui seul, un référentiel réglementaire obligatoire.

En septembre 2026, l’ANSSI a également commencé à publier les fiches pratiques « ReCyF en pratique » via MesServicesCyber. Ces contenus s’articulent autour de quatre grands piliers de gestion des risques : Défense, Protection, Gouvernance et Résilience, auxquels s’ajoute une catégorie spécifique consacrée aux obligations liées à NIS2.

Pour les organisations françaises, le ReCyF constitue ainsi un référentiel utile pour structurer leur préparation à NIS2 pendant que le cadre national continue de se préciser. Il doit toutefois être utilisé dans le cadre d’une analyse plus large intégrant les obligations juridiques applicables, les dispositifs de cybersécurité déjà en place et le profil de risque propre à l’organisation.

Votre paysage SAP est-il prêt pour NIS2 ?

Évaluer la préparation d’un paysage SAP à NIS2 suppose d’aller au-delà de l’examen d’applications SAP prises isolément ou d’une simple vérification des configurations techniques. L’environnement SAP s’inscrit dans un système d’information plus large, qui comprend les identités, les infrastructures, les interfaces, les prestataires externes, les applications connectées, les développements spécifiques et les dépendances opérationnelles.

L’objectif de l’évaluation est donc d’identifier les zones dans lesquelles se situent réellement les risques de sécurité. Il faut d’abord délimiter le périmètre de l’environnement SAP, puis analyser les domaines dans lesquels des choix techniques historiques, les modèles d’accès, les intégrations ou un manque de visibilité peuvent accroître l’exposition au risque.

Commencer par identifier les systèmes SAP concernés

Les paysages SAP complexes se limitent rarement à un seul ERP. Ils peuvent associer SAP S/4HANA ou SAP ERP Central Component (SAP ECC) à SAP Business Technology Platform (SAP BTP), des applications SaaS, des plateformes d’intégration, des bases de données, des services de gestion des identités, des solutions d’analytique, des applications tierces et des développements spécifiques. Certaines connexions restent internes à l’entreprise, tandis que d’autres relient l’environnement à des fournisseurs, des banques, des prestataires logistiques, des clients ou d’autres partenaires externes.

Un inventaire pertinent doit donc aller au-delà des seuls produits SAP installés. Il doit notamment recenser :

• Les principales applications SAP et leurs composants associés
• Les systèmes cloud et on-premise
• Les services de gestion des identités et d’authentification
• Les interfaces, API et middleware
• Les développements ABAP spécifiques et les extensions
• Les add-ons tiers et les applications connectées
• Les bases de données et les environnements de reporting
• Les connexions externes et les comptes techniques
• Les dépendances vis-à-vis des prestataires et partenaires métiers

L’objectif est de comprendre comment ces systèmes et leurs dépendances soutiennent les activités opérationnelles de l’organisation. Une interface relativement limitée ou une application périphérique peut nécessiter autant d’attention qu’un composant ERP central si sa compromission ou son indisponibilité est susceptible de perturber un processus critique.

Cet inventaire sert également de base aux décisions de sécurité ultérieures. Il est difficile d’évaluer les contrôles de manière cohérente sans disposer d’une vision fiable des systèmes, interfaces, identités et dépendances qui composent le paysage SAP.

Systèmes historiques et accumulation des dépendances techniques

Les environnements SAP exploités depuis de nombreuses années comportent souvent des composants et des configurations qui ont évolué au fil des déploiements, montées de version, acquisitions et transformations de l’activité. Le risque ne tient pas nécessairement à l’ancienneté d’un système, mais plutôt aux dépendances techniques qui se sont progressivement accumulées autour de lui.

L’analyse doit notamment porter sur les composants obsolètes, les niveaux de correctifs hétérogènes, les interfaces anciennes, les dépendances non documentées, les configurations historiques, les autorisations héritées et les comptes techniques dont la finalité d’origine n’est plus clairement établie. Les développements spécifiques anciens peuvent également dépendre de composants ou de schémas d’intégration difficiles à maintenir dans des conditions de sécurité satisfaisantes.

SAP ECC ne doit pas être considéré comme intrinsèquement incompatible avec NIS2. La question est de savoir si, maintenu, sécurisé, corrigé et supervisé, son fonctionnement et ses dépendances sont suffisamment bien compris au regard du profil de risque de l’organisation.

Un environnement historique fortement personnalisé peut rendre cette maîtrise plus complexe. Les équipes de sécurité doivent parfois déterminer non seulement si les vulnérabilités connues sont traitées, mais également si la suppression ou la modification d’un composant ancien risque d’affecter d’autres systèmes qui en dépendent. Lorsque ces relations sont mal documentées, les actions de remédiation comme les investigations en cas d’incident deviennent plus difficiles.

Repenser la gestion des données SAP historiques avant un passage à S/4HANA ?

Découvrez comment différentes approches de migration et de décommissionnement peuvent réduire la complexité des systèmes historiques, clarifier les dépendances et faciliter la transition vers SAP S/4HANA.

En savoir plus

Gestion des identités et des accès à privilèges

La gestion des identités est l’un des domaines dans lesquels les risques peuvent s’accumuler au fil du temps dans un environnement SAP. Les collaborateurs changent de poste, les missions des prestataires prennent fin, des utilisateurs techniques sont créés pour les intégrations, les administrateurs obtiennent des droits étendus et des accès d’urgence peuvent être mis en place pour répondre à des contraintes opérationnelles. Sans révision systématique, le modèle d’autorisation peut progressivement s’éloigner des besoins métiers réels.

Une évaluation de la préparation à NIS2 doit notamment vérifier si :

• Les droits d’accès correspondent aux rôles et responsabilités actuels
• Les comptes sont supprimés ou ajustés lors des départs ou changements de fonction
• Les comptes inactifs sont identifiés
• L’utilisation des comptes partagés est limitée et dûment justifiée
• Les comptes administrateurs et autres comptes à privilèges sont clairement distingués des comptes utilisateurs standards
• Les accès d’urgence sont contrôlés et traçables
• Les comptes de service et comptes techniques ont un propriétaire et une finalité clairement définis
• Les conflits de séparation des tâches (SoD) sont identifiés
• Des revues ou certifications des accès sont réalisées lorsque cela est nécessaire
• Les exigences d’authentification sont adaptées à la sensibilité des accès concernés
• Les accès aux environnements de production font l’objet de contrôles renforcés par rapport aux accès utilisateurs courants

Ce sujet revêt une importance particulière dans le contexte français. Les recommandations pratiques du ReCyF publiées par l’ANSSI en septembre 2026 abordent notamment la gestion du cycle de vie des identités, les comptes partagés et les mécanismes d’authentification dans le cadre de la gestion des identités.

À ce stade, l’objectif d’une évaluation SAP n’est pas encore de refondre le modèle de gouvernance des accès. Il s’agit d’abord de vérifier que l’organisation peut identifier de manière fiable qui dispose de quels accès, pour quelle raison, comment les identités à privilèges sont utilisées et dans quels domaines l’accumulation de droits peut créer une exposition inutile.

Intégrations et accès de tiers

Les paysages SAP dépendent de plus en plus de connexions situées en dehors du cœur de l’ERP. Les API, connexions RFC, middleware, transferts de fichiers, intégrations B2B, canaux de support externes et services cloud peuvent tous créer des voies d’accès aux systèmes ou aux données qui font parfois l’objet de moins de contrôles que les accès utilisateurs directs.

L’évaluation doit permettre de comprendre le fonctionnement de ces connexions et d’identifier les responsables associés. Une attention particulière doit être portée aux éléments suivants :

• Connexions avec les fournisseurs et partenaires métiers
• Prestataires de services managés
• Équipes SAP externes assurant le support
• API et connexions RFC
• Middleware et plateformes d’intégration
• Échanges automatisés de fichiers
• Certificats, secrets et identifiants stockés
• Comptes techniques et comptes d’intégration
• Accès administratifs à distance

L’enjeu central est la traçabilité. L’organisation doit être en mesure de déterminer quel tiers ou quel système peut se connecter, comment cette connexion est authentifiée, à quelles ressources elle donne accès et qui est responsable de sa révision.

C’est également dans ce domaine que des dépendances peu visibles peuvent apparaître. Une interface techniquement simple peut être critique sur le plan opérationnel, tandis qu’un compte d’intégration créé plusieurs années auparavant peut toujours disposer de droits plus étendus que nécessaire. Ces dépendances et chemins d’accès doivent être visibles, documentés et placés sous la responsabilité d’un responsable clairement identifié.

Développements spécifiques et exposition aux vulnérabilités

Les développements spécifiques doivent faire l’objet d’une analyse distincte, car ils peuvent introduire des risques que la maintenance standard de la plateforme ne permet pas de traiter à elle seule. Le code ABAP, les extensions side-by-side, les API spécifiques, les applications développées par des prestataires externes et les composants tiers peuvent créer de nouveaux vecteurs d’attaque ou rendre certaines vulnérabilités plus difficiles à corriger.

L’évaluation doit déterminer si ces composants spécifiques sont toujours nécessaires, s’ils restent maintenables et de quelle manière la sécurité est prise en compte lors de leur évolution. Les éléments à examiner comprennent notamment :

• Les applications ABAP spécifiques
• Les extensions et enhancements
• Les interfaces et API spécifiques
• Les composants tiers
• Les bibliothèques ou dépendances obsolètes
• Les vulnérabilités connues affectant des composants spécifiques ou connectés
• Les tests de sécurité lors de changements significatifs
• L’attribution des responsabilités et l’état d’avancement des remédiations

Cette question doit être distinguée de celle des systèmes historiques dans leur ensemble. Un composant techniquement récent peut malgré tout introduire un risque si son code spécifique, la conception de ses interfaces ou son processus de gestion des changements. À l’inverse, un système plus ancien peut rester sécurisé si ses risques sont identifiés et maîtrisés.

L’évaluation doit permettre d’identifier les sources potentielles de vulnérabilité, de vérifier qu’elles peuvent être détectées de manière cohérente et de rendre visible l’état des actions de remédiation pour les composants concernés.

Lacunes en matière de journalisation et de détection

La visibilité constitue un autre volet essentiel de l’évaluation. Une organisation peut disposer de contrôles préventifs solides tout en rencontrant des difficultés à déterminer ce qui s’est produit lorsqu’une activité suspecte est détectée.

L’analyse doit établir si les événements de sécurité issus des environnements SAP sont collectés sous une forme exploitable par les équipes de sécurité. Il convient notamment de vérifier si les anomalies d’authentification, les activités liées aux comptes à privilèges, les modifications de configuration et d’autres événements pertinents peuvent être détectés et analysés.

Les principaux points à examiner sont les suivants :

• Les événements de sécurité SAP pertinents sont-ils centralisés ?
• Les activités d’authentification inhabituelles peuvent-elles être identifiées ?
• Les activités liées aux comptes à privilèges sont-elles suffisamment visibles ?
• Les événements SAP peuvent-ils être corrélés avec ceux provenant d’autres systèmes ?
• Les équipes de sécurité peuvent-elles reconstituer les activités en cas de suspicion d’incident ?
• Les alertes importantes sont-elles accessibles aux équipes chargées des opérations de sécurité ?

L’évaluation doit faire apparaître les domaines dans lesquels les équipes de sécurité ne disposent pas d’une visibilité suffisante pour détecter les activités suspectes, analyser les événements ou reconstituer le déroulement d’un incident.

Évaluation de la préparation de la sécurité SAP

Une évaluation de diagnostic doit permettre de déterminer dans quels domaines l’environnement SAP offre déjà un niveau de visibilité et de contrôle suffisant, où subsistent des zones d’incertitude et quels sujets nécessitent une analyse plus approfondie. Elle fournit ainsi une base factuelle pour l’étape suivante : définir la gouvernance des responsabilités et des contrôles de sécurité SAP à l’échelle de l’organisation.

Vous envisagez une migration vers le cloud SAP ?

Découvrez les principales approches de migration, les modèles cloud, la répartition des responsabilités de sécurité et les points à prendre en compte pour préparer la migration de vos environnements SAP vers le cloud.

Lire l’article

Aligner la gouvernance SAP sur les attentes françaises en matière de cybersécurité

Une fois les écarts et lacunes de sécurité identifiés, les organisations doivent définir un modèle opérationnel permettant de les traiter dans la durée. Pour les environnements SAP, cela suppose de préciser qui prend les décisions de sécurité, comment les risques sont gérés et de quelle manière les équipes techniques collaborent avec les fonctions cybersécurité, métiers et conformité.

Clarifier les responsabilités avant de définir les contrôles

La sécurité SAP relève rarement d’une seule équipe. Selon l’organisation, les responsabilités peuvent être réparties entre la DSI/CIO, le RSSI/CISO, les responsables de plateformes SAP, les responsables de processus métiers, les spécialistes IAM, les équipes infrastructure et cloud, les fonctions risques et conformité, l’audit interne ainsi que les équipes chargées de la gestion des fournisseurs.

L’objectif n’est pas d’ajouter une nouvelle couche de gouvernance, mais de clarifier les responsabilités décisionnelles. L’organisation doit savoir qui peut approuver un accès sensible, accepter une dérogation de sécurité, prioriser une action de remédiation susceptible d’avoir un impact opérationnel ou faire remonter un risque qui ne peut pas être traité au seul niveau technique.

La responsabilité des métiers est particulièrement importante. Les administrateurs SAP peuvent mettre en œuvre des contrôles, mais ils ne peuvent pas déterminer seuls les conséquences métier d’une restriction d’accès, de la mise hors service d’un système ou de la modification d’un processus qui soutient la finance, les achats, la production ou une autre fonction critique.

Les procédures de réponse aux incidents doivent également être testées dans des conditions réalistes plutôt que validées uniquement sur le plan documentaire. Les exercices permettent de vérifier si les équipes peuvent accéder rapidement aux informations nécessaires, prendre des décisions dans les délais requis, coordonner efficacement leurs actions et mettre en œuvre les mesures techniques sans provoquer de perturbations évitables.

Dans les environnements SAP, ces tests doivent notamment porter sur les délais de décision, l’accès à des informations techniques et métiers fiables, la coordination entre les équipes concernées, l’exécution des mesures de confinement ou de reprise et la capacité à conserver une chronologie précise des événements au fur et à mesure de l’évolution de l’incident.

Les enseignements tirés de ces exercices doivent permettre d’améliorer les procédures, de clarifier les responsabilités, de combler les lacunes d’information et d’affiner les scénarios de test ultérieurs. Les exercices de réponse aux incidents deviennent ainsi un moyen concret de vérifier que le modèle opérationnel reste efficace en situation de crise.

Intégrer la gestion des vulnérabilités aux opérations SAP

Un processus de gestion des vulnérabilités doit couvrir l’ensemble du cycle, depuis l’identification d’un constat jusqu’à sa priorisation, sa remédiation, sa vérification et sa clôture formelle. Pour les composants fournis par SAP, cela implique notamment d’examiner les SAP Security Notes applicables et de déterminer le niveau d’urgence avec lequel les correctifs doivent être déployés. SAP continue de publier régulièrement ses Security Notes dans le cadre du SAP Security Patch Day et recommande de prioriser les correctifs pertinents pour les paysages concernés.

La priorité ne doit pas dépendre uniquement de la gravité technique. Le contexte métier doit également être pris en compte. Une vulnérabilité affectant un composant exposé vers l’extérieur ou un système supportant un processus critique peut nécessiter un traitement différent de celui de la même faiblesse technique dans un environnement davantage isolé.

Le processus doit aussi couvrir le code spécifique, les interfaces, les dépendances d’infrastructure et les faiblesses de configuration. Lorsqu’une remédiation immédiate n’est pas possible, l’organisation doit désigner un responsable, documenter la décision relative au risque, mettre en place des mesures compensatoires appropriées et fixer une date de réexamen. Cela évite que des exceptions initialement temporaires deviennent, sous l’effet de la complexité opérationnelle, des sources d’exposition permanentes.

Relier la supervision à la réponse aux incidents

Lorsqu’une activité suspecte est détectée, le processus de réponse doit déjà être défini. La sécurité SAP doit être intégrée aux opérations du SOC, à la plateforme SIEM de l’organisation lorsqu’elle existe, aux procédures de gestion des incidents ainsi qu’aux équipes métiers responsables des processus concernés.

Le modèle opérationnel doit préciser comment les alertes liées à SAP sont qualifiées et priorisées, à quel moment une expertise SAP spécialisée doit être mobilisée, qui peut autoriser des mesures de confinement et dans quelles situations un incident doit être remonté aux responsables métiers, à la direction, aux fonctions juridiques ou aux équipes conformité.

Cette coordination devient particulièrement importante lorsqu’une mesure technique risque d’interrompre l’activité. Désactiver un compte, couper une interface ou isoler un système peut réduire un risque cyber tout en perturbant un processus critique. Les responsables cybersécurité et métiers doivent donc disposer de circuits de décision et d’escalade définis à l’avance.

En vertu de l’article 23 de NIS2, une alerte précoce doit être transmise sans retard injustifié et au plus tard dans les 24 heures suivant la prise de connaissance d’un incident significatif. Elle est suivie d’une notification d’incident, également sans retard injustifié et au plus tard dans les 72 heures. Pour les prestataires de services de confiance, le délai de notification est de 24 heures lorsqu’un incident significatif affecte la fourniture de leurs services de confiance. Un rapport final doit généralement être remis au plus tard un mois après la notification de l’incident. Si celui-ci est toujours en cours à cette date, un rapport d’avancement doit être fourni, puis un rapport final dans un délai d’un mois après le traitement de l’incident.

Les organisations françaises doivent aligner leurs procédures internes sur le cadre national définitif et les recommandations applicables de l’ANSSI, plutôt que de considérer ces délais européens comme un processus complet de gestion des incidents.

Intégrer la continuité d’activité à la sécurité SAP

La planification de la continuité doit porter sur les processus métiers soutenus par SAP, et non sur les systèmes pris isolément. Restaurer une instance ERP présente peu d’intérêt si les interfaces, les services d’identité, les bases de données ou les connexions externes indispensables au processus restent indisponibles.

Les organisations doivent donc définir leurs priorités de reprise en fonction de processus tels que la gestion des commandes, les opérations d’entrepôt, la production, les achats, la clôture financière ou la paie, selon leur niveau de criticité propre. Les objectifs de reprise, les dépendances techniques, les responsabilités liées aux sauvegardes et à la restauration ainsi que les rôles en situation de crise doivent découler de ces priorités.

Ces dispositifs doivent également être testés. Les exercices de reprise permettent de vérifier si les systèmes peuvent être restaurés dans l’ordre requis et si l’environnement rétabli est effectivement exploitable par les métiers. Lorsque des procédures manuelles ou des modes dégradés peuvent temporairement assurer la continuité de processus critiques, ils doivent être intégrés au dispositif plutôt que supposés disponibles au moment d’une crise.

Assurer la traçabilité des décisions de sécurité

Les processus de gouvernance doivent produire des enregistrements traçables des principales décisions de sécurité et des activités de contrôle. La responsabilité de leur conservation doit être clairement attribuée afin que les validations importantes, les dérogations, les décisions de remédiation et les actions de contrôle puissent être vérifiées en cas de besoin.

Renforcer la gouvernance de vos programmes SAP S/4HANA

Découvrez comment un comité de pilotage structuré peut clarifier les responsabilités décisionnelles, aligner les parties prenantes métiers et IT et faciliter le pilotage de programmes SAP S/4HANA complexes.

Lire l’article

Le rôle des solutions SAP dans une stratégie NIS2

Les technologies SAP peuvent contribuer à certains volets d’un programme de préparation à NIS2, mais elles ne suffisent pas, à elles seules, à assurer la conformité d’une organisation. Leur rôle consiste à fournir des capacités dans des domaines tels que la gouvernance des accès, la gestion des identités, la détection des menaces et la supervision du paysage SAP, dans le cadre plus large de la gouvernance et de la cybersécurité défini par l’organisation.

Pour les organisations françaises, la question n’est donc pas de savoir quel produit SAP « couvre NIS2 », mais d’identifier les capacités nécessaires pour traiter les risques recensés et de déterminer comment elles s’intègrent aux dispositifs IAM, SOC, SIEM, de gestion des risques et aux processus opérationnels déjà en place.

Gouvernance des accès : SAP Access Control et SAP Cloud Identity Access Governance

Au sein du portefeuille SAP GRC, SAP Access Control prend en charge des processus structurés de gouvernance des accès, notamment l’analyse des risques liés aux autorisations, les contrôles de séparation des tâches (SoD), les demandes d’accès, la gestion des rôles métiers, les accès d’urgence et les révisions périodiques des accès utilisateurs. La solution est particulièrement pertinente pour les organisations qui doivent encadrer de manière structurée les autorisations et les risques d’accès dans leurs environnements SAP.

SAP Cloud Identity Access Governance (SAP Cloud IAG) fournit des services cloud pour l’analyse des accès, les demandes d’accès, les revues de certification, la gestion des accès à privilèges et la conception des rôles. D’après la documentation SAP, ces capacités peuvent être utilisées avec des systèmes sources, qu’ils soient dans le cloud ou on-premises.

Ces deux solutions ne doivent pas être présentées comme des outils permettant, à eux seuls, d’assurer la conformité à NIS2. Elles contribuent au volet gouvernance des accès d’un dispositif de sécurité plus large en aidant les organisations à appliquer, revoir et documenter leurs contrôles d’autorisation.

Authentification et cycle de vie des identités : SAP Cloud Identity Services

Pour l’authentification et la gestion du cycle de vie des identités, les composants les plus pertinents de SAP Cloud Identity Services sont Identity Authentication et Identity Provisioning. Identity Authentication fournit des fonctions d’authentification et d’authentification unique, tandis qu’Identity Provisioning permet de gérer la distribution et le cycle de vie des utilisateurs et des groupes dans les applications connectées.

SAP positionne ce service autour de l’authentification sécurisée, des autorisations et de la gestion du cycle de vie des identités, avec des capacités de provisioning pour les environnements SAP et les autres systèmes connectés.

Dans le cadre de NIS2, ces capacités peuvent aider les organisations à appliquer leurs politiques d’identité de manière plus cohérente, à relier les processus d’intégration et de départ des utilisateurs aux droits d’accès applicatifs et à réduire la fragmentation de l’administration des identités. Elles complètent les solutions de gouvernance des accès sans les remplacer : l’authentification et le provisioning déterminent comment les identités sont créées, accèdent aux applications et évoluent dans le paysage, tandis que la gouvernance des accès permet de vérifier si les autorisations qui leur sont attribuées restent appropriées.

Détection et investigation: SAP Enterprise Threat Detection

SAP Enterprise Threat Detection est dédié à l’analyse des événements de sécurité dans les environnements SAP. La solution peut collecter et analyser les événements de journalisation pertinents, générer des alertes et faciliter l’investigation d’activités suspectes. Ses fonctions d’investigation permettent d’obtenir une visibilité sur les utilisateurs et systèmes concernés, les alertes générées et les événements consignés à l’origine des alertes.

Son rôle doit être envisagé dans le cadre plus large de l’architecture de cyberdéfense de l’organisation. Une détection spécialisée des menaces SAP peut fournir un niveau de contexte difficile à obtenir à partir de la seule supervision des infrastructures, mais elle ne remplace ni les processus SOC à l’échelle de l’entreprise, ni la gestion des incidents, ni l’ensemble des capacités d’une plateforme SIEM.

La distinction est importante : le modèle de gouvernance détermine la manière dont une alerte doit être traitée ; SAP Enterprise Threat Detection apporte les informations spécifiques à SAP nécessaires pour détecter et analyser les activités concernées.

Supervision opérationnelle : SAP Cloud ALM et SAP Focused Run

SAP Cloud ALM et SAP Focused Run répondent à des besoins de supervision opérationnelle et de suivi du paysage SAP, distincts du cas d’usage de sécurité couvert par SAP Enterprise Threat Detection.

SAP Cloud ALM fournit des fonctions centralisées de supervision et d’alerte pour les environnements SAP pris en charge, y compris les paysages hybrides, et permet de mettre en relation la supervision technique avec les scénarios métiers et d’intégration.

SAP Focused Run est conçu pour la supervision à grande échelle des systèmes et applications. Il couvre notamment l’état des systèmes, la disponibilité, la configuration, les exceptions, les performances et la supervision des intégrations. Il peut également prendre en charge des scénarios hybrides associant des systèmes on-premise et des services cloud pris en charge.

Le choix entre ces solutions dépend de la taille et de la complexité de son paysage SAP, des outils déjà en place et de son modèle opérationnel. Il serait réducteur d’opposer « Cloud ALM pour le cloud » à « Focused Run pour l’on-premise », puisque les deux solutions peuvent prendre en charge des environnements hybrides.

Contribution des capacités SAP à la préparation à NIS2

La combinaison pertinente dépend de chaque organisation. L’objectif n’est pas de déployer l’ensemble des solutions SAP disponibles en matière de sécurité, mais de sélectionner les capacités qui répondent aux risques identifiés et de les intégrer à l’architecture de gouvernance et de cybersécurité déjà en place.

Se préparer aux contrôles de l’ANSSI et aux futures exigences de cybersécurité

La préparation à NIS2 doit s’inscrire dans le fonctionnement courant de la cybersécurité, plutôt que de rester un programme de remédiation limité dans le temps. Pour les environnements SAP, cela suppose de maintenir un lien clair entre les exigences applicables, les contrôles mis en œuvre, les responsables désignés et les éléments permettant de démontrer, dans la durée, le bon fonctionnement de ces contrôles.

Cette approche est particulièrement importante en France, alors que le cadre national continue de se préciser. L’ANSSI encourage déjà les futures entités essentielles et importantes à anticiper ces exigences et met le ReCyF à leur disposition comme référentiel de travail pour les objectifs de sécurité liés à NIS2. L’ANSSI indique également que les organisations qui choisissent d’appliquer le ReCyF pourront s’en prévaloir lors d’un contrôle de l’ANSSI.

Mettre en correspondance les contrôles existants avec NIS2 et le ReCyF

Les organisations qui ont déjà évalué leur paysage SAP n’ont pas besoin de recommencer l’exercice d’inventaire. L’étape suivante consiste à mettre en correspondance les contrôles de sécurité existants avec les exigences et mesures de référence qui leur sont applicables.

Par exemple, un processus de certification des accès peut répondre à certaines exigences de gestion des identités et des accès, tandis que la gestion des vulnérabilités, la supervision, la reprise ou les contrôles appliqués aux fournisseurs correspondent à d’autres composantes du cadre de cybersécurité. L’objectif est de rendre les écarts visibles et d’éviter de maintenir plusieurs dispositifs de conformité parallèles pour des contrôles qui répondent déjà à plusieurs exigences.

L’ANSSI propose également un outil de comparaison des référentiels permettant de rapprocher le ReCyF des normes, réglementations et cadres de cybersécurité déjà utilisés par l’organisation. Cette approche est particulièrement utile pour les entreprises qui s’appuient déjà sur ISO/IEC 27001 ou sur d’autres dispositifs structurés et souhaitent capitaliser sur les contrôles existants plutôt que de les recréer spécifiquement pour NIS2.

Structurer les éléments de preuve

Un contrôle de sécurité est plus facile à évaluer lorsque l’organisation peut démontrer concrètement son fonctionnement. Les éléments de preuve doivent donc être produits dans le cadre des processus courants, plutôt que rassemblés uniquement à l’occasion d’un audit, d’un contrôle ou d’une demande réglementaire.

Selon le type de contrôle, ces éléments peuvent comprendre les inventaires des systèmes et de leurs dépendances, les revues des accès, les enregistrements relatifs aux accès à privilèges, les référentiels de configuration, les enregistrements relatifs aux vulnérabilités et aux actions de remédiation, la documentation des incidents, les résultats des tests de reprise, les informations relatives à la sécurité des fournisseurs ainsi que les décisions documentées d’acceptation des risques.

Ces exemples ne doivent pas être interprétés comme une liste de contrôle prescriptive de l’ANSSI. Ils visent à démontrer que les contrôles ont un responsable identifié, qu’ils sont réalisés selon la fréquence prévue et qu’ils produisent des résultats traçables. L’organisation doit également définir où ces informations sont conservées, pendant combien de temps elles restent disponibles et qui est chargé de les maintenir à jour.

Tester la réponse aux incidents en amont

Une procédure de réponse aux incidents doit être testée et non considérée comme opérationnelle au seul motif qu’elle est documentée. Les exercices permettent de vérifier si les équipes techniques, la fonction RSSI/CISO, les responsables métiers, les équipes juridiques et conformité ainsi que les parties prenantes de la direction peuvent accéder aux informations nécessaires et prendre des décisions dans les délais requis.

Pour les environnements SAP, les scénarios doivent refléter des dépendances et des impacts métiers réalistes. Un exercice peut, par exemple, vérifier si les équipes sont capables d’identifier les systèmes et comptes concernés, d’évaluer l’impact sur un processus critique, de préserver les informations techniques pertinentes, de coordonner les mesures de confinement et de réunir les éléments nécessaires aux décisions réglementaires.

L’objectif n’est pas de reprendre le modèle de gestion des incidents décrit précédemment, mais de vérifier que les rôles, les communications, les procédures techniques et les mécanismes d’escalade réglementaire fonctionnent ensemble sous contrainte de temps. Les enseignements tirés de ces exercices doivent ensuite être intégrés aux procédures, aux contrôles et aux actions de formation.

Inscrire les contrôles de cybersécurité dans un cycle récurrent

Les contrôles de cybersécurité doivent s’inscrire dans un cycle opérationnel défini plutôt que de reposer sur une mise en œuvre ponctuelle. Chaque contrôle doit avoir un responsable clairement identifié, une fréquence de revue adaptée ou des événements déclencheurs précis, ainsi que des critères permettant de déterminer quand une nouvelle évaluation est nécessaire.

Ces déclencheurs peuvent inclure des évolutions importantes des systèmes, de nouvelles intégrations, des changements organisationnels, l’apparition de nouveaux risques ou des évolutions réglementaires. Les constats doivent également donner lieu à un suivi documenté afin que les faiblesses identifiées soient traitées jusqu’à leur résolution, plutôt que de les redécouvrir lors de la revue suivante.

Cette approche facilite le maintien des contrôles de cybersécurité à mesure que le paysage SAP et l’environnement réglementaire évoluent, sans imposer de reprendre l’ensemble de la démarche de préparation après chaque changement significatif.

Articuler NIS2 avec les autres cadres réglementaires

NIS2 ne doit pas être gérée indépendamment des autres obligations réglementaires susceptibles de s’appliquer à une même organisation ou à un même incident.

Certains fournisseurs d’infrastructures et de services numériques sont soumis à des règles européennes complémentaires prises en application de NIS2. Le règlement d’exécution (UE) 2024/2690 de la Commission définit notamment des exigences techniques et méthodologiques spécifiques en matière de cybersécurité ainsi que des critères permettant de qualifier les incidents significatifs pour plusieurs catégories d’acteurs, dont les fournisseurs de services d’informatique en nuage, de services de centres de données, de services gérés et de services de sécurité gérés. Pour les organisations entrant dans son champ d’application, ces exigences directement applicables doivent être prises en compte parallèlement au cadre français de mise en œuvre de NIS2.

Le RGPD reste, quant à lui, un cadre distinct consacré à la protection des données à caractère personnel. Lorsqu’un incident de cybersécurité constitue également une violation de données à caractère personnel, une organisation peut être soumise aux obligations des deux régimes. En vertu de l’article 33 du RGPD, le responsable du traitement doit notifier la violation à l’autorité de contrôle compétente dans les meilleurs délais et, si possible, au plus tard 72 heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques.

Pour les entités financières soumises à DORA, l’articulation avec NIS2 est plus spécifique. DORA est considérée comme une législation sectorielle de l’Union pour les obligations concernées en matière de gestion des risques liés aux TIC et de notification des incidents. Lorsque ses exigences sont au moins équivalentes dans leurs effets, les dispositions correspondantes de NIS2, y compris celles relatives à la supervision et à l’exécution, ne s’appliquent pas. Les organisations relevant de DORA doivent donc déterminer quelles obligations sont régies par ce règlement et quelles dispositions de NIS2 restent applicables, afin d’éviter de mettre en place des processus de conformité redondants.

Pour les organisations opérant en France, le ReCyF et les recommandations de l’ANSSI, qui continuent d’évoluer, constituent les principaux points de référence nationaux pour préparer les mesures de cybersécurité associées à NIS2. L’objectif opérationnel consiste à articuler ces exigences avec les dispositifs de gouvernance et de contrôle déjà en place, afin que les travaux de conformité renforcent le modèle opérationnel plutôt que de créer une nouvelle couche documentaire parallèle.

Comment LeverX accompagne les organisations françaises dans leur préparation à NIS2

LeverX accompagne les initiatives de sécurité SAP qui peuvent s’inscrire dans un programme plus large de préparation à NIS2. Ses compétences couvrent notamment l’évaluation du paysage SAP et de son niveau de sécurité, la gouvernance des identités et des accès, le durcissement des systèmes, la gestion des vulnérabilités, la supervision de la sécurité et la réponse aux incidents. Ces services permettent de renforcer les contrôles liés aux environnements SAP dans le cadre plus global de la cybersécurité et de la conformité réglementaire de l’organisation.

Évaluer le niveau de sécurité de l’environnement SAP

LeverX réalise des évaluations de sécurité SAP et des missions de conseil afin d’identifier les vulnérabilités, les risques liés aux accès, les faiblesses de configuration et les autres domaines nécessitant des actions de remédiation. Les constats issus de cette analyse peuvent ensuite servir à prioriser les améliorations de sécurité SAP dans le cadre du programme global de cybersécurité de l’organisation.

Renforcer la gouvernance des identités et des accès

LeverX accompagne la gestion des utilisateurs et des rôles, la conception des autorisations, les contrôles de séparation des tâches, la gestion des accès à privilèges, les revues d’accès et la mise en œuvre de SAP GRC. Selon le paysage SAP concerné, cet accompagnement peut notamment inclure SAP Access Control et SAP Cloud Identity Access Governance.

Renforcer la sécurité des systèmes SAP et traiter les vulnérabilités

LeverX propose des services de gestion des correctifs et de durcissement des systèmes SAP. Pour les développements ABAP spécifiques, LeverX accompagne également l’évaluation et la remédiation des vulnérabilités à l’aide de SAP Code Vulnerability Analyzer et de processus de revue de sécurité associés.

Améliorer la supervision de la sécurité et la réponse aux incidents

LeverX fournit des services de supervision de la sécurité SAP et de réponse aux incidents, et accompagne l’utilisation de SAP Enterprise Threat Detection. Ces capacités peuvent être intégrées aux opérations de sécurité déjà en place afin d’améliorer la visibilité sur les menaces propres aux environnements SAP et de faciliter leur investigation et leur traitement.

Assurer une gouvernance continue de la sécurité SAP

LeverX peut accompagner les organisations dans la mise en place de revues d’accès récurrentes, d’évaluations de sécurité, d’activités de supervision et de remédiation à mesure que les environnements SAP évoluent. Pour les organisations qui se préparent à NIS2 en France, ces capacités peuvent contribuer au volet SAP d’un dispositif plus large de gouvernance de la cybersécurité et de la conformité.

Conclusion

Pour les organisations qui exploitent des environnements SAP en France, la préparation à NIS2 doit être envisagée comme un dispositif opérationnel appelé à évoluer, et non comme une simple étape de conformité à franchir. À mesure que le cadre français de transposition se précise et que les recommandations de l’ANSSI évoluent, les organisations devront réévaluer l’adéquation de leurs contrôles, de leurs responsabilités et de leurs éléments de preuve avec les nouvelles exigences, puis ajuster en conséquence leurs pratiques de sécurité SAP.

LeverX peut accompagner cette démarche en aidant les organisations à maintenir la sécurité SAP alignée sur leur gouvernance globale de la cybersécurité, au fur et à mesure de l’évolution des attentes réglementaires.

Foire aux questions