Présentation de SAP ERP
Pour les organisations qui l’ont adopté, SAP ERP (Enterprise Resource Planning) est souvent l’un des systèmes les plus critiques de leur environnement. Il collecte et exécute les commandes des clients, demande et suit les paiements, et fournit des données financières aux dirigeants et aux investisseurs. En bref, c’est l’épine dorsale de l’activité. Si SAP ERP tombe en panne ou subit une compromission, c’est toute l’activité qui peur être paralysée.
Malgré son importance, certains environnements SAP ERP doivent encore s’aligner davantage sur les principes du modèle de sécurité Zero Trust fréquemment utilisé par les solutions cloud et SaaS modernes. La cause en est souvent la flexibilité de SAP, ce qui signifie qu’il n’existe pas deux implémentations identiques et que toute modification nécessite souvent des efforts importants et spécialisés.
En tant qu’architecte en identité avec une expérience étendue de la sécurité SAP depuis divers points de vue, je peux offrir une perspective sur la façon dont les déploiements SAP ERP peuvent être modernisés pour profiter des derniers avantages en matière de sécurité.
Problèmes et défis courants
Avant d’envisager les caractéristiques d’un état futur idéal, abordons certains des domaines courants qui offrent les meilleures pistes d’amélioration.
Nomenclature et terminologie
Lorsque vous travaillez avec un fournisseur aussi important que SAP, il peut être difficile de bien maîtriser la terminologie et la nomenclature associées. Ainsi, j’ai eu du mal à trouver un titre approprié pour ce blog, car je voulais m’assurer que je faisais référence à la bonne technologie SAP.
SAP propose une grande variété de produits, et certaines des offres les plus récentes suivent des modèles différents de ceux que je vais traiter ici. Dans cet article, lorsque je fais référence à SAP ERP, je fais référence à la suite de produits que SAP a conçue et développée depuis 1972. Vous pouvez généralement identifier cette suite avec quelques mots clés : ABAP, S4/HANA, ECC, Basis ou Netweaver.
Authentification héritée
Malgré les avancées de SAP en matière de technologie d’interface web, il est encore courant pour les entreprises d’accéder à SAP via le client Windows traditionnel connu sous le nom de SAPGUI. Bien que l’authentification Zero Trust soit possible pour SAPGUI (nous y reviendrons plus tard), son déploiement et sa configuration sont complexes. Par conséquent, de nombreuses entreprises continuent de s’appuyer sur des mots de passe pour l’authentification.
Avec les mots de passe viennent tous les défis familiers : une expérience utilisateur insatisfaisante, la nécessité de déployer des outils de synchronisation des mots de passe et des méthodes d’authentification à faible assurance.
Cela étant, la plus grande préoccupation n’est pas l’expérience utilisateur, mais le risque potentiel pour la sécurité. Dans SAPGUI, le chiffrement réseau est étroitement lié à l’authentification. Dans de nombreux déploiements, cela signifie que les noms d’utilisateur et les mots de passe circulent en clair sur le réseau interne. Si des outils de synchronisation des mots de passe sont utilisés, cela peut également exposer les mots de passe Active Directory. Enfin, si le mode hybride Entra ID est activé, le même risque pourrait s’étendre aux identifiants Entra.
L’utilisation d’un VPN ou l’activation de l’authentification Windows peuvent atténuer une partie de ce risque, mais il ne s’agit pas de solutions complètes. Une véritable stratégie Zero Trust part du principe que le réseau est compromis et applique une authentification forte à chaque couche sans s’appuyer uniquement sur des protections basées sur le réseau.
Projets RBAC incomplets et dérive de configuration
Le modèle d’autorisation SAP est très détaillé et complexe. Au début de ma carrière d’administrateur, j’ai dû étudier le cours ADM940 de SAP sur la sécurité et les autorisations. Pas forcément une lecture facile, mais ce cours m’a appris les principes de fonctionnement des contrôles de sécurité SAP.
On considère souvent la sécurité SAP en termes de codes de transaction (T-codes), chacun étant associé à une tâche métier. Cependant, derrière chaque action utilisateur, des dizaines, voire des centaines, d’autorisations distinctes sont vérifiées. Ces contrôles d’autorisation peuvent être différents en fonction des conditions utilisateur ou de la version SAP déployée (nous y reviendrons plus tard).
La complexité est une chose, l’échelle en est une autre. Nous avons évoqué la complexité des rôles au sein de SAP, parlons à présent de l’échelle. De nombreux projets de contrôle d’accès basé sur les rôles (RBAC) se heurtent à des obstacles lorsqu’ils tentent de couvrir 100 % des accès avec des rôles de tâche dédiés. Cet objectif irréaliste peut conduire à une relation quasi unilatérale entre le nombre d’utilisateurs et de rôles. Bien que ce problème ne soit pas spécifique aux déploiements SAP, il se manifeste de plusieurs manières, ce qui peut compliquer un paysage SAP.
SAP fournit des outils de gestion des rôles qui sont utiles lorsqu’ils sont utilisés de manière cohérente. Cependant, dans de nombreux environnements, la cohérence est rare. Ce qui fonctionne dans un système SAP ne fonctionne souvent pas de la même manière ailleurs.
Par conséquent, de nombreuses entreprises s’appuient sur des méthodes de faible assurance pour l’attribution des accès :
- Copie à partir d’un utilisateur existant — SAP dispose même d’une fonctionnalité intégrée « modéliser en tant que »
- Accès attribué en fonction des codes de transaction (T-codes), une méthode simpliste pour déterminer le niveau d’accès d’un rôle donné
Les deux approches présentent des défis. La modélisation des utilisateurs basée sur le personnel existant risque de propager un accès inapproprié qui aurait pu s’accumuler au fil du temps. Les T-codes ne donnent qu’une vue partielle de ce qu’un utilisateur peut faire. De plus, une idée aussi fausse que répandue voudrait que les T-codes puissent être attribués directement, alors que n’est pas le cas. Enfin, les nouveaux modules SAP ne sont pas basés sur les T-codes, cette méthode devenant donc progressivement obsolète.
En terrain connu
Il ne devrait pas être surprenant que diverses itérations de solutions à ce problème aient été utilisées dans le passé (et le soient encore aujourd’hui). Voici un exemple de la façon dont les produits de gestion et de gouvernance des identités ont été utilisés pour fournir des solutions partielles :
Résumé des composants
Remarque : j’utilise volontairement des termes génériques pour ces composants ; très souvent, les produits d’identité remplissent une ou plusieurs de ces fonctions.
Service d’annuaire d’entreprise
Ce composant est responsable des services de contrôle des accès à l’exécution. Pour les situations où l’authentification SAP locale se produit, c’est là que le mot de passe de l’utilisateur serait synchronisé. Pour les situations où le SSO est configuré dans SAP, les services d’authentification Kerberos hérités seraient fournis par ce service.
Service de provisioning d’entreprise
Ce composant est responsable de l’exécution du contrôle des accès basé sur les rôles et du provisioning des accès dans l’ensemble de l’environnement. Ce service permet de s’assurer que les comptes utilisateurs appropriés sont configurés dans les systèmes appropriés, et que le bon niveau d’accès est configuré sur ces comptes (y compris le service d’annuaire).
Module SAP GRC
Ce module remplit de nombreuses fonctions, notamment la prise en charge du provisioning SAP automatisé à partir du service de provisioning global, la réalisation d’analyses de séparation des tâches et l’obtention des approbations d’accès appropriées pour tout accès SAP demandé.
Bien que ce modèle puisse contribuer à satisfaire aux exigences de conformité, il s’accompagne de certains défis qui peuvent limiter le succès du déploiement.
- Les approbations pour l’accès SAP sont complètement différentes de celles des autres applications d’entreprise. Cela signifie des systèmes d’audit différents, des moteurs de workflow différents pour les administrateurs et des processus d’approbation différents pour les approbateurs. De même, l’expérience utilisateur peut s’avérer déroutante, et difficile à appréhender si les approbateurs n’approuvent pas les tâches rapidement.
- Le service de provisioning d’entreprise a une visibilité limitée sur les accès au sein de chaque système SAP. Bien que SAP GRC dispose de mécanismes fiables pour synchroniser les données entre lui-même et les systèmes SAP individuels, le fait que le système à l’échelle de l’entreprise n’ait pas d’accès direct au système de référence peut rendre difficile l’identification et le monitoring des erreurs de synchronisation lorsqu’elles se produisent.
- Cette conception ne permet généralement pas la collaboration entre le contrôle des accès d’exécution par le service d’annuaire et l’accès au repos géré par le service de provisioning. Par exemple :
- Comment pouvons-nous accorder un accès temporaire d’une heure seulement ?
- Comment faire si nous souhaitons que l’authentification évolue en fonction du niveau d’accès d’un utilisateur ?
- Que se passerait-il si nous avions besoin d’une authentification forte pour les super utilisateurs SAP par rapport aux utilisateurs ayant un accès limité ?
Dans ce modèle, deux plateformes distinctes contrôlent deux types d’accès différents. Par conséquent, les cas d’usage Zero Trust comme ceux-ci ne peuvent généralement être mis en place que par le biais d’une orchestration complexe et fragile, et ne sont pas pris en charge nativement.
L’alternative souhaitable
La vision d’Okta est de permettre à toute organisation d’utiliser les technologies qu’elle souhaite, en toute sécurité. Cela signifie que SAP, en tant qu’élément stratégique pour toute organisation qui l’emploie, doit être géré de manière standardisée qui se prête à une stratégie Zero Trust globale.
Résumé des composants
Okta Platform
Ici, Okta fournit des services de gestion des identités, de gouvernance des identités et de gestion des accès à privilèges à l’échelle de l’entreprise. La solution aide à garantir que les identités sont correctement synchronisées et gérées conformément aux politiques. Elle offre une expérience unique en matière de demande et d’approbation d’accès, une expérience unifiée de certification des accès et, enfin, une plateforme d’authentification unique et contextuelle pour toute l’organisation.
SAP GRC
Pour les déploiements SAP plus importants et axés sur la conformité, SAP GRC joue un rôle essentiel. Il fournit les capacités d’analyse de la séparation des tâches très granulaires qui sont nécessaires pour répondre efficacement aux exigences de conformité. Cette fonctionnalité repose sur l’expertise du domaine inhérente à SAP. Qu’est-ce qui constitue un accès inapproprié ? Quel accès entre en conflit avec quel autre accès ? Ces questions relèvent fondamentalement du domaine du produit SAP et sont mieux traitées par SAP lui-même. Je dirais que cet ensemble de règles est l’un des composants les plus précieux du produit SAP GRC.
Bien que GRC joue un rôle important dans cette architecture, elle fonctionne davantage comme une API et un outil d’administration, et non comme un élément avec lequel les utilisateurs finaux ou les approbateurs interagissent généralement.
Ce diagramme illustre à un haut niveau les rôles et responsabilités d’Okta et de GRC dans ce modèle de déploiement recommandé.
À première vue, cette stratégie présente des avantages clairs pour l’utilisateur final et l’administration :
- Un système est responsable de toutes les tâches de synchronisation des identités à l’échelle de l’entreprise.
- Un seul processus d’approbation, de demande et d’audit est en place à l’échelle de l’entreprise.
- Les contrôles de sécurité SAP critiques sont maintenus.
- Les plateformes d’audit principales reçoivent les dernières informations directement des systèmes SAP, sans risque de défaillance intermédiaire.
À haut niveau, il s’agit d’utiliser le bon outil pour la bonne tâche. Cependant, nous évoluons aujourd’hui dans un monde où l’identité est la clé de la sécurité : Okta vous offre un écosystème de sécurité des identités qui transforme les outils d’identité en outils de sécurité.
Vous avez peut-être déjà entendu l’expression « plateforme d’identité convergée ». Il est reconnu par les leaders et les analystes du secteur. Mis en pratique, ce concept peut améliorer la sécurité non seulement de votre déploiement SAP, mais aussi de l’ensemble de votre entreprise.
Auparavant, j’ai mentionné deux types d’accès : « au repos » et « à l’exécution ».
- L’accès « au repos » fait référence aux comptes utilisateurs, aux droits et aux rôles qui sont configurés dans toute votre entreprise. Dans SAP, cela signifie vos enregistrements maîtres d’utilisateurs et leurs attributions de rôle. Je qualifie cet accès de « au repos » car il est relativement stable et ne tient pas compte du contexte d’exécution lors de l’évaluation des contrôles d’autorisation SAP.
- L’accès « à l’exécution » (ou runtime) est ce qui se passe lorsqu’un utilisateur essaie réellement d’exécuter une action. Sur quel terminal se trouve-t-il ? Quelle est la posture de ce terminal? De quel réseau vient-il ? Son comportement est-il anormal ? Comment s’est-il authentifié et depuis quand ?
Pour une véritable défense en profondeur et une stratégie Zero Trust, les deux types d’accès doivent fonctionner de concert. Il ne suffit pas qu’un utilisateur ait accès : il ne doit utiliser cet accès que dans les conditions appropriées.
En réunissant tous ces éléments sur une seule plateforme, comme Okta, vous pouvez appliquer ces couches de sécurité de manière évolutive. Le résultat est une approche Zero Trust moderne qui assure que votre environnement SAP est protégé avec la même rigueur que vos autres infrastructures critiques.
Résumé
Si vous m’avez lu jusqu’ici, merci tout d’abord de m’avoir accordé votre attention. Mon objectif était de clarifier trois idées principales :
- Un aperçu des possibilités de modernisation de l’identité disponibles pour les clients SAP aujourd’hui
- Une analyse des raisons pour lesquelles les approches traditionnelles et cloisonnées peuvent limiter le déploiement d’un véritable modèle de sécurité de niveau supérieur
- Une approche de conception moderne qui utilise les points forts de SAP, y compris ses fonctionnalités de sécurité, tout en connectant SAP aux programmes de sécurité d’entreprise plus vastes que de nombreuses organisations mettent en place aujourd’hui
Si vous souhaitez voir à quoi ressemble une plateforme d’identité convergée, consultez notre dernier webinar ici.
Le présent document et toute recommandation qu’il propose ne constituent pas des conseils juridiques, commerciaux ou en matière de confidentialité, sécurité ou conformité. Le contenu de ce document revêt un caractère purement informatif et pourrait ne pas refléter les normes de sécurité, de confidentialité et les réglementations les plus récentes, ou tous les problèmes pertinents. Pour obtenir de tels conseils, il vous revient de vous adresser à votre conseiller juridique ou à tout autre conseiller professionnel en matière de sécurité, confidentialité ou conformité, et de ne pas vous en remettre aux recommandations formulées dans le présent document. Okta décline toute responsabilité quant aux pertes ou dommages pouvant résulter de la mise en œuvre des recommandations fournies dans le présent document. Okta ne formule aucune déclaration, garantie ou autre assurance concernant le contenu de ce document. Pour en savoir plus sur les assurances contractuelles d’Okta à ses clients, rendez-vous à l’adresse okta.com/agreements.
Ce blog ne représente pas nécessairement la position, les stratégies ou l’opinion d’Okta.
