Quand la sécurité SAP rencontre la gestion des identités d'entreprise

L'identité SAP ne suit pas les modèles IGA d'entreprise standard. SAP utilise son propre modèle d'autorisation où l'accès est directement lié aux processus métier, aux transactions et aux risques liés à la séparation des tâches — ce qui nécessite une conception et des contrôles spécifiques à SAP parallèlement à la gouvernance des identités d'entreprise. Les organisations qui considèrent SAP comme une simple application connectée parmi d’autres constatent souvent l’apparition de lacunes de gouvernance concernant les conflits de séparation des tâches, les accès d’urgence et les comptes privilégiés. 

Après SAP IdM, les organisations choisissent généralement entre des approches natives SAP, IGA d’entreprise ou hybrides. SAP Cloud Identity Services et SAP IAG assurent la gouvernance au sein de l’écosystème SAP. Les plateformes IGA d'entreprise telles que SailPoint, One Identity et Saviynt étendent la gouvernance aux systèmes SAP et non-SAP. Les outils compatibles SAP tels que Pathlock régissent l'accès depuis l'environnement SAP vers l'extérieur. Le choix approprié dépend de la complexité de l'environnement SAP, des investissements existants en matière d'identité et de la nécessité ou non d'étendre la gouvernance aux systèmes SAP et non-SAP. 

Oui, les plateformes IGA d'entreprise peuvent gouverner efficacement l'accès à SAP lorsque le modèle d'accès de SAP est correctement pris en compte. Une gouvernance efficace dépend de la représentation précise des rôles SAP, des concepts d'autorisation et des règles de séparation des tâches (SoD) dans la plateforme IGA, plutôt que de traiter SAP comme une application connectée standard.

La plupart des plateformes IGA d'entreprise se connectent à SAP via des connecteurs certifiés. Sans configuration spécialisée, cependant, la gouvernance est souvent incomplète. 

Les organisations doivent revoir leur gestion des identités SAP lors de changements majeurs ou de points de tension en matière de contrôle. Les déclencheurs courants incluent les migrations vers S/4HANA ou RISE, le remplacement de SAP IdM, les restructurations organisationnelles, les conclusions d'audit, l'adoption du cloud et les lacunes non résolues en matière de propriété des accès.

Les organisations qui planifient des programmes de transformation SAP doivent s'attaquer à la gouvernance des identités avant le début de la migration. La mise en place de contrôles après la mise en service est nettement plus complexe et coûteuse que de les intégrer dès le départ.

Organizations planning SAP transformation programs should address identity governance before migration begins. Retrofitting controls after go-live is significantly more complex and costly than building them in from the start. 

La responsabilité des identités SAP est généralement partagée entre les équipes de sécurité SAP, les équipes chargées des identités et les services métier. Les équipes SAP gèrent l'accès technique et la conception des rôles, les équipes chargées des identités régissent l'attribution des droits et la certification des accès, et les services métier déterminent qui a besoin d'un accès et pourquoi. 

La place qu'occupent les identités SAP entre ces fonctions — en particulier en ce qui concerne les workflows d'attribution des droits, les révisions d'accès et les accès privilégiés — rend souvent la responsabilité peu claire. Les organisations qui définissent clairement les responsabilités entre les équipes parviennent à une gouvernance plus cohérente et à moins d’exceptions de conformité.