Quelles sont les meilleures pratiques en matière de normes de sécurité interne dans les entreprises disposant d'importants investissements SAP?

Question

Je travaille dans une grande entreprise et je m'intéresse aux meilleures pratiques en matière de normes de sécurité internes. Nous avons un investissement important (plus de 500 millions de dollars) dans SAP, et nous avons aussi .Net et un peu de Java EE dans notre environnement interne.

J'ai trouvé de la documentation de MS et SAP, mais elle est obsolète et pas très spécifique. Jusqu'ici, il semblerait que nous puissions utiliser Active Directory comme magasin d'utilisateurs standard pour toutes les applications non-SAP et pour les applications SAP CUA/Portal for SAP.

Certaines de mes préoccupations concernant AD sont:

• Être en mesure de manière agressive temps pour des applications sur des ordinateurs partagés (Un petit nombre de nos applications exécutées dans des bureaux distants dans les zones rurales avec un nombre limité de Dans ce cas, un superviseur avec un privilège «utilisateur privilégié» pourrait utiliser une application, puis un employé qui ne devrait avoir que des privilèges de base pourrait utiliser la même machine immédiatement après)

• Etre capable de forcer l'utilisateur à entrer un nom d'utilisateur et mot de passe au lieu de simplement lire les informations d'identification de la poste de travail de l'utilisateur - Comme il utilise les mêmes informations d'identification pour le bureau et le courrier électronique, il ne demande pas actuellement aux utilisateurs de se connecter. Cela est également un problème pour les applications sur les ordinateurs partagés. (Voir l'explication dans la puce précédente)

  En ce qui concerne la synchronisation entre AD et CUA, je veux aborder cela très attentivement. Nous avons un budget limité, et je veux m'assurer que si nous finissons par mettre quelque chose en place pour synchroniser les magasins, qu'ils soient vendus sur le marché et qu'ils offrent une excellente valeur. Si nous ne pouvons pas trouver quelque chose comme ça, je serais heureux de revenir avec une recommandation que les magasins restent indépendants. SSO serait idéal, mais j'ai travaillé avec essayer d'obtenir une application SSO avant SAML, et ce n'était pas joli.

Sigles:

• SSO: Single Sign-On SAML: Sécurité

• Assertion Markup Language

• ACU: Central User Administration (Pour SAP)

Answer 1

Il y a beaucoup de possibilités sur ce sujet.

Nous avions un client qui a mis à jour à la fois leur AD et leur liste d'utilisateurs SAP de SAP HR. L'idée était que le module OM contenait tous les employés.Vous pouvez exporter tous les jours une liste de tous les employés actifs vers le LDAP, avec des informations de base (prénom, nom de famille, employeeId, login ...). Pour le système SAP, l'unité/la fonction/le travail nécessitant un accès sap est marqué et l'utilisateur a été créé/supprimé quotidiennement.

En fait, tous les employés ont un compte SAP, mais seulement ceux marqués avaient une « de dialogue ». Ces comptes sont autorisés à se connecter via SAPGUI, d'autres ont dû utiliser le portail, qui est une licence moins coûteuse. Un ensemble de règles autorisées à définir les rôles pour les utilisateurs gérés. L'objectif était de minimiser la gestion des utilisateurs et de limiter les augmentations inexorables d'autorisation qui découlent du passage d'un emploi à un autre. (C'était pour 105000 employés, avec beaucoup de mouvement de personnel).

Ainsi SAP n'a pas été directement lié à l'AD, mais où synchronisé. En fonction du système (développement, qualité, intégration, production), SAP a été configuré avec un délai d'expiration. Vous pouvez également avoir un mot de passe différent pour des systèmes distincts.

Bien sûr, l'inverse est également possible: interroger un LDAP de SAP pour gérer les comptes de SAP, sans beeing directement lié au LDAP. transaction LDAP peut problablement vous donner quelques informations.

espérons que cette aide

Modifier: la synchronisation a été effectuée par un programme ABAP. ce programme était exécuté tous les jours à quatre heures, et créait/supprimait/modifiait certains comptes dans le LDAP. Après cela, un autre programme a ajouté des informations techniques aux entrées LDAP, des informations qui n'étaient pas disponibles pour le système SAP RH (comme le serveur de messagerie à utiliser pour un employé donné, en fonction de son emplacement dans le monde). Les entrées ont alors été vérifiées pour la cohérence et envoyées au maître LDAP.

Ce programme du personnel et des unités gérées uniquement. Groupes (autorisation pour d'autres applications) où gérés manuellement ou par d'autres programmes. Ainsi, les données non SAP étaient également stockées dans le LDAP.

Cordialement

Answer 2

Pourquoi est-ce un problème si les utilisateurs n'ont pas à se connecter? Cela ne serait-il pas plus pratique pour les utilisateurs? Cela ne les inciterait-il pas davantage à se déconnecter de la demande?

Le projet sur lequel je travaille utilise maintenant AD, et nous avons une table de mappage dans SAP pour mapper les comptes AD et les comptes SAP. La synchronisation est manuelle, ce qui peut ou peut ne pas fonctionner pour vous, mais il n'y a pas de réel risque technique.

Je voudrais pouvoir vous donner plus d'informations, mais je n'ai pas été très impliqué dans ce domaine. Je peux regarder, cependant.

Answer 3

Vous voudrez peut-être regarder OpenSSO - il a des agents pour SAP et il intégrera avec AD comme le magasin d'utilisateurs. C'est aussi assez solide - Verizon use it for 40 million customers to log in to their web site.