Connecteurs de provisioning automatique : guide pratique à l’usage des entreprises
Le processus d’intégration des systèmes dans le cadre de la gestion des identités et des accès est un sujet phare en 2015. Les entreprises s’essaient de plus en plus à la généralisation de l’interconnexion de leurs systèmes.
La plupart des entreprises
souhaitent n’avoir à gérer qu’un seul et unique système source pour
l’ensemble de leurs données identitaires afin d’éviter de ressaisir
systématiquement ces données dans les différents systèmes, y compris lorsque
ces systèmes se trouvent à l’extérieur du réseau de l’entreprise et notamment
dans le cloud. En théorie, lorsque tous les systèmes sont interconnectés, les équipes support sont également en mesure
d’établir quels droits et ressources sont assignés à chaque compte AD, une
fonctionnalité appréciable notamment en cas d’audit. Au moment donc de procéder
à l’interconnexion de vos systèmes, il est cependant fort conseillé de
respecter certaines consignes de base, afin d’éviter les écueils en la matière.
Vous en trouverez le descriptif ci-après :
Les pièges à éviter !
- Tout connecter à tout prix.
L’un des écueils les plus fréquents concerne les connecteurs applicatifs, car les entreprises décident en général et d’emblée de relier tous les systèmes entre eux dans le cadre d’un projet de gestion des identités. Alors qu’il serait plus judicieux de se demander en premier lieu si l’interconnexion de tous les systèmes sera réellement avantageuse, notamment en termes de gain de temps. Si le but principal se résume à automatiser les flux entrant, transitant et sortant des identités dans le réseau, des gains substantiels (de temps notamment) ne seront avérés que si le taux de mouvement et d’enrichissement des données sur le réseau est très élevé. En effet, lorsque le volume de données est limité sur le réseau, un import périodique peut s’avérer préférable et bien plus rentable financièrement à une interconnexion automatisée.
- Penser que tout est faisable/ réalisable
Il est important d’observer la
plus grande prudence sur ce type de projet. Les entreprises ont parfois
tendance à penser que l’interconnexion représente un atout indéniable, or dans
les faits cela n’est pas toujours réalisable. Afin de connaître quelles sont
exactement vos possibilités d’interconnexion de vos systèmes, il peut s’avérer
utile de recourir aux services d’un spécialiste qui saura vous conseiller. En
ayant recours aux services de votre fournisseur d’applicatifs, vous risquez de vous
retrouver à devoir payer une facture regroupant des prestations de consulting
exorbitantes et à devoir vous y retrouver parmi toutes sortes de conjectures. Alors
qu’en faisant appel aux services d’un fournisseur indépendant, vous serez en
mesure de savoir si vous pouvez interconnecter « en l’état » (i.e. : provisioning de base comprenant
les fonctionnalités de création, modification et de suppression de comptes AD),
ou de façon « personnalisée » (i.e. : provisioning détaillé, permettant
notamment de paramétrer les accès au sein des applications). Prenons l’exemple
du dossier patient informatisé (DPI), bon nombre des fournisseurs de solutions
DPI ne permettent pas à des tiers de modifier les droits d’accès fonctionnels
des employés. En lieu et place, ils préfèrent travailler sur la base de modèles
prédéfinis. Le modèle sera alors lu par l’application DPI, laquelle déterminera
les accès DPI de l’utilisateur. L’avantage de ce procédé est qu’une connexion
directe est établie avec l’application, de sorte que la gestion fonctionnelle
des droits d’accès demeure intégrée dans l’application.
Les bonnes pratiques
- Etablir une connexion dès lors que le facteur « temps » entre en ligne de compte
En effet, dans le cas de changements devant être mis en place rapidement, pour des raisons de rendement ou de sécurité notamment, il peut s’avérer préférable de procéder à une connexion des applicatifs en temps réel. Prenons l’exemple d’un consultant extérieur se rendant sur site et devant accéder à certaines applications. Un compte réseau pourra dès lors être créé en temps réel et automatiquement. Dans le cas d’un employé qui serait licencié sur le champ, grâce à une connexion entre le système RH, le dispositif de mot de passe et le réseau, il suffira d’un simple clic pour bloquer tous ses accès logiques et physiques au réseau de l’entreprise.
- Vérifier le dispositif d’attribution des demandes d’accès
En interconnectant les applications, il est également possible d’assigner des droits d’accès automatiquement aux applications. Notamment en se basant sur les informations relatives aux attributions d’un employé enregistré dans le système RH. L’attribution et la suppression des droits est une tâche normalement dévolue à un administrateur système/applicatif/réseau. Or, les connaissances de ce dernier ne faisant parfois l’objet d’aucune documentation et/ou consignation, il est nécessaire de bien se renseigner sur le sujet et de trouver des supports documentés sur le processus d’attribution des autorisations pour tenter de les remplacer par cette nouvelle logique métier. Mais n’allez surtout pas jusqu’à mettre en place un modèle RBAC (Role Based Access Control), cela serait en effet disproportionné. Essayez dans un premier temps de déterminer quels rôles, quelles fonctions et quels droits d’accès sont définis par la direction.
- Effectuer en amont une estimation précise des coûts:
Effectuer en amont une estimation précise des coûts. En effet, par défaut, de nombreuses applications ne permettent pas l’intégration de systèmes tiers, celle-ci n’étant possible qu’avec l’acquisition d’un module complémentaire. Prenez donc bien soin de vérifier que vous possédez bien une licence d’intégration dédiée pour les applications, car la conjoncture actuelle étant synonyme de restrictions budgétaires, il y a de fortes chances pour que ce module n’ait pas été inclus lors de l’acquisition de la solution.
- Réfléchir à la clé unique ou encore l’identifiant qui sera utilisé par les utilisateurs
En effet, il s’agit là d’un élément déterminant pour que toutes les applications sachent quelle identité est partie prenante. Il pourra s’agir d’un matricule. Dans tous les cas, il faudra que cette clé soit stable et idéalement immuable. Il peut arriver, notamment au sein des établissements hospitaliers, qu’un matricule soit modifié. Il est par conséquent préférable de choisir une combinaison de type nom de naissance et de date/lieu de naissance.
- S’interroger sur le type de données que vos applications peuvent recevoir et transmettre
Vérifiez également comment se comporte vos applications afin de savoir si l’application à laquelle vous souhaitez vous connecter est uniquement capable de recevoir des informations ou si elle est en mesure de les retransmettre à son tour. Si vous souhaitez travailler avec un ESB (Enterprise Service Bus) ou un EAI, il est crucial qu’il ait été mis dans la boucle lors des notifications de changements. Dans l’hypothèse où une application ne serait pas capable de fournir cette information, il est fondamental de pallier cette situation sans tarder. Le système RH est un très bon exemple d’application incapable d’envoyer des informations basées sur des événements. Pour que cette opération soit possible depuis un système RH vers un EAI, par exemple un flux entrant, transitant ou sortant, un système de gestion des identités et des accès doit intervenir dans le processus global.