La question nous arrive généralement de biais. Un programme S/4HANA passe en production, les auditeurs arrivent, et quelque part dans le périmètre se trouve un global account BTP que personne dans l'équipe sécurité n'a regardé. Il a été créé par l'équipe intégration ou par l'intégrateur, ceux qui l'ont créé sont administrateurs du global account, le Cloud Connector a été installé dans l'urgence pendant la phase de build, et les destinations contiennent le mot de passe d'un utilisateur technique aux droits larges dans le back-end.

Rien de tout cela n'apparaît dans une revue de sécurité SAP qui s'arrête à PFCG. BTP a ses propres comptes, son propre modèle d'autorisation, son propre fournisseur d'identité et ses propres journaux : il doit être conçu et revu comme une couche à part entière.

Pourquoi BTP demande sa propre conception de sécurité

BTP se trouve entre vos utilisateurs, internet et votre back-end SAP. Un launchpad Build Work Zone peut exposer des applications S/4HANA à des utilisateurs externes, un tenant Integration Suite fait transiter des données entre SAP et des tiers, et une application CAP peut lire et écrire dans l'ERP via le Cloud Connector. Chacun de ces éléments est un chemin vers le système central.

Le concept d'autorisation S/4HANA s'applique toujours au bout du chemin, mais seulement si l'identité qui atteint le back-end est celle de l'utilisateur réel. Lorsque BTP appelle le back-end avec un utilisateur technique partagé, les rôles S/4HANA de l'utilisateur réel ne comptent plus, et BTP devient le seul endroit où l'accès est contrôlé.

Le modèle de comptes

Un global account BTP contient des directories et des subaccounts (sous-comptes). Le sous-compte est l'endroit où vivent les services, les applications, la configuration de confiance et les autorisations : c'est la véritable frontière de sécurité.

  • Séparer les environnements : développement, test et production dans des sous-comptes différents, avec des administrateurs différents et idéalement des configurations de fournisseur d'identité distinctes. Un sous-compte partagé « tout le hors-production » devient vite un endroit où se retrouvent des données de production.
  • Peu d'administrateurs du global account : ils peuvent créer des sous-comptes, déplacer des entitlements et s'attribuer n'importe quel droit. Limitez ce rôle à quelques personnes nommées, et ne laissez pas les consultants de l'intégrateur dans ce rôle après le go-live.
  • Inventorier les sous-comptes : les sous-comptes d'essai, de proof-of-concept et de projet sont souvent oubliés avec des services et une configuration de confiance toujours actifs. Revoyez-les comme des utilisateurs dormants.
  • Rôles de plateforme et rôles métier : administrer le sous-compte (plateforme) et utiliser ses applications (métier) sont des accès différents. Gardez-les dans des role collections distinctes, attribuées à des groupes distincts.

Autorisations : les role collections

Les applications BTP déclarent des role templates, construits à partir de scopes et d'attributs. Les rôles sont créés à partir de ces templates, et les role collections regroupent les rôles. C'est la role collection que l'on attribue.

Les bonnes pratiques sont celles de la conception de rôles SAP, appliquées à un nouveau modèle :

  • Associer les role collections aux groupes du fournisseur d'identité via la configuration de confiance, plutôt que de les attribuer utilisateur par utilisateur. Les accès suivent alors le processus arrivée / mobilité / départ de votre annuaire, et un collaborateur qui part perd son accès BTP en même temps que son compte d'entreprise.
  • Concevoir les role collections par fonction métier, pas par application, et les documenter comme un rôle composite.
  • Utiliser les attributs pour restreindre les données lorsque l'application le permet (société, organisation commerciale, division), plutôt que de donner le périmètre complet à tout le monde.
  • Inclure BTP dans l'analyse de séparation des tâches. Si une application BTP permet de créer un fournisseur et qu'un autre chemin dans S/4HANA permet de le payer, le conflit existe même si les deux accès vivent dans des systèmes différents.
  • Recertifier les role collections BTP dans les mêmes campagnes de revue que l'ERP.

Identité : SAP Cloud Identity Services

Par défaut, un sous-compte fait confiance au SAP ID service, qui authentifie les utilisateurs avec des comptes gérés par SAP. Pour les utilisateurs métier, c'est le mauvais choix : ces comptes ne sont pas contrôlés par votre annuaire, et les collaborateurs partis les conservent.

L'architecture standard repose sur un tenant SAP Cloud Identity Services :

  • Identity Authentication (IAS) comme fournisseur d'identité du sous-compte, en proxy vers le fournisseur d'identité de l'entreprise (Microsoft Entra ID ou un autre fournisseur SAML / OpenID Connect). Les utilisateurs se connectent avec leur compte d'entreprise, avec SSO et la politique MFA que vous appliquez déjà.
  • Authentification conditionnelle et MFA pour les administrateurs et pour les accès depuis l'extérieur du réseau de l'entreprise.
  • Identity Provisioning (IPS) pour provisionner utilisateurs et groupes depuis l'annuaire source vers BTP et les autres applications cloud SAP, afin que l'appartenance aux groupes, et donc les role collections, reste synchronisée.
  • SAP ID service limité à quelques administrateurs nommés comme accès de secours, ou retiré complètement de la connexion des utilisateurs.

Connectivité : Cloud Connector et destinations

Le Cloud Connector relie un sous-compte BTP aux systèmes on-premise. Le tunnel est ouvert en sortie depuis votre réseau, donc rien n'est publié sur internet, mais le Cloud Connector devient lui-même un point de contrôle : tout ce qu'il expose est atteignable par toutes les applications du sous-compte connecté.

  • Exposer le minimum : associer les virtual hosts à des systèmes back-end précis, restreindre les ressources HTTP aux chemins d'URL dont les applications ont besoin et, pour le RFC, n'autoriser que les modules fonction réellement appelés. Exposer / sur un système ABAP ou autoriser tous les modules fonction avec un préfixe générique annule l'essentiel du bénéfice.
  • Préférer la principal propagation : l'identité de l'utilisateur est transmise au back-end via un certificat X.509 de courte durée, et ce sont les autorisations S/4HANA de l'utilisateur réel qui s'appliquent. Les utilisateurs techniques partagés doivent rester l'exception, avec des rôles étroits.
  • Durcir le serveur et l'administration : serveur dédié, mot de passe administrateur initial changé, administration raccordée à votre annuaire, version à jour, journalisation d'audit activée et transférée.
  • Intégrer le Cloud Connector au périmètre ITGC : les modifications de ses listes de contrôle d'accès sont des changements de configuration et doivent passer par la gestion des changements.

Les destinations contiennent l'URL cible et la méthode d'authentification de chaque connexion. Lorsqu'elles utilisent l'authentification basique ou des client credentials, elles contiennent des secrets.

  • Restreindre qui peut créer ou modifier des destinations : quelqu'un qui peut modifier une destination peut rediriger le trafic ou réutiliser les identifiants stockés.
  • Préférer les flux OAuth avec propagation de l'utilisateur aux mots de passe stockés.
  • Traiter les service keys et service bindings de l'environnement Cloud Foundry comme des identifiants de longue durée : les inventorier, limiter qui peut en créer, et les renouveler.

Supervision et journaux d'audit

BTP enregistre les événements de sécurité (connexions, modifications d'autorisations, changements de configuration) dans le service de journal d'audit. La rétention est limitée (90 jours par défaut dans l'environnement Cloud Foundry), ce qui est plus court que la plupart des périodes d'audit.

  • Récupérer régulièrement les journaux d'audit via l'API Audit Log Retrieval et les envoyer vers votre SIEM ou votre archive de logs.
  • Surveiller l'activité des administrateurs : nouveaux administrateurs du global account ou d'un sous-compte, modifications de la configuration de confiance, nouvelles attributions de role collections, nouvelles destinations.
  • Conserver les preuves pour l'auditeur : qui détient les rôles d'administration, comment les role collections sont attribuées, comment les départs sont traités, et comment les modifications du Cloud Connector sont approuvées.

SAP publie une liste de recommandations de sécurité pour SAP BTP qui constitue une bonne base pour une première revue. Elle ne remplace pas une conception adaptée à votre paysage, mais elle fournit une checklist structurée.

La place de la sécurité BTP dans un programme S/4HANA

La plupart des problèmes ci-dessus naissent pendant la phase de build, lorsque la priorité est de faire fonctionner les intégrations. Ils sont peu coûteux à éviter à ce moment-là, et coûteux à corriger après le go-live, une fois que des applications dépendent d'un utilisateur technique large ou d'un chemin ouvert sur le Cloud Connector.

Si votre programme inclut RISE with SAP, Integration Suite, Build Work Zone ou des extensions BTP, intégrez BTP au volet sécurité dès le départ, aux côtés de la refonte des autorisations S/4HANA et de la conception Firefighter. Pour l'accès externe à Fiori, BTP est souvent une architecture plus sûre que la publication d'un serveur frontal ; voir pourquoi ne pas exposer le serveur frontal Fiori sur internet.

Comment MTC aide

Nous revoyons et concevons la sécurité SAP BTP dans le cadre de notre pratique de sécurité SAP : modèle de comptes et de sous-comptes, role collections et leur association aux groupes de votre annuaire, configuration de SAP Cloud Identity Services, durcissement du Cloud Connector et des destinations, et journaux et preuves qu'un auditeur demandera. Nous intégrons BTP à l'analyse de séparation des tâches et aux revues d'accès, aux côtés de l'ERP. Sur les grands programmes, nous travaillons avec des cabinets internationaux de premier plan en audit, risque et technologie, avec une équipe senior basée en Suisse responsable du résultat en matière de sécurité.

À lire également

Questions fréquentes

Qu'est-ce que la sécurité SAP BTP ?

La sécurité SAP BTP est l'ensemble des contrôles qui protègent la SAP Business Technology Platform ainsi que les applications et intégrations qui y tournent. Elle couvre le modèle de comptes (global account, directories, subaccounts), les autorisations de plateforme et métier (role collections), l'identité et l'authentification via SAP Cloud Identity Services, la connectivité vers les systèmes on-premise via le Cloud Connector et les destinations, et la journalisation d'audit. C'est une couche distincte des autorisations S/4HANA, qui demande sa propre conception et sa propre revue.

Qu'est-ce qu'une role collection dans SAP BTP ?

La role collection est l'unité d'autorisation que l'on attribue dans SAP BTP. Les applications déclarent des role templates (scopes et attributs) ; les rôles sont créés à partir de ces templates, et les role collections regroupent un ou plusieurs rôles. Les role collections sont attribuées directement aux utilisateurs ou, de préférence, associées à des groupes fournis par le fournisseur d'identité, afin que les accès suivent le processus arrivée / mobilité / départ de l'annuaire de l'entreprise.

SAP BTP doit-il utiliser SAP ID service ou SAP Cloud Identity Services ?

Pour les utilisateurs métier, utilisez un tenant SAP Cloud Identity Services (Identity Authentication) comme fournisseur d'identité du sous-compte, généralement en proxy vers le fournisseur d'identité de l'entreprise comme Microsoft Entra ID. Vous obtenez ainsi le SSO de l'entreprise, le MFA, l'authentification conditionnelle et l'attribution des rôles par groupe. Le SAP ID service par défaut doit être limité à quelques administrateurs nommés ou retiré de la connexion des utilisateurs.

Comment sécuriser le SAP Cloud Connector ?

Installez-le sur un serveur dédié et durci ; changez le mot de passe administrateur initial et raccordez l'administration à votre annuaire ; n'exposez que les virtual hosts, chemins d'URL et modules fonction RFC dont les applications BTP ont réellement besoin, jamais un système entier ; préférez la principal propagation aux utilisateurs techniques partagés ; maintenez la version du Cloud Connector à jour ; et transférez son journal d'audit vers votre supervision. Le Cloud Connector est un point de contrôle entre le cloud et vos systèmes SAP et doit être revu comme tel.

Combien de temps SAP BTP conserve-t-il les journaux d'audit ?

Le service de journal d'audit BTP ne conserve les entrées que pendant une durée limitée (90 jours par défaut dans l'environnement Cloud Foundry). Si vous avez besoin d'une rétention plus longue pour l'audit ou les investigations, récupérez régulièrement les journaux via l'API Audit Log Retrieval et stockez-les dans votre SIEM ou votre archive de logs.