Gestion des utilisateurs du cloud
L’usage d’applications dans le cloud ou en mode SaaS est de plus en plus répandu en entreprise. Il s’agit d’une tendance profonde du marché car elle simplifie la mise à disposition d’applications et rapproche les fournisseurs de services de leurs consommateurs sans passer par l’IT.
Les entreprises doivent prendre en compte ces nouveaux modes de gestion des applications. En effet, celles-ci sont décentralisées, et bien que leurs interfaces soient très récentes, les personnes en charge de ces applications doivent gérer les utilisateurs « à la main » avec toutes les sources d’erreurs inhérentes à ce type de fonctionnement. Les conséquences de cette gestion sont connues en terme de sécurité (oubli des mots de passe par les utilisateurs, nombreux comptes dormant, politiques de mots de passe faibles induisant des trous de sécurité) et en terme d’économie (le prix de l’utilisation du service dépend de son utilisation). La solution IAM (Identity & Access Management), qui donne la main aux fonctionnels en intégrant un support des applications dans le cloud ou en mode SaaS prend alors tout son sens.
Comment réaliser le provisioning du cloud ?
Il n’y a pas aujourd’hui de standard unique pour gérer le provisioning des applications en mode SaaS. Le standard SPML (Service Provisioning Markup Language) n’a pas pris sur ce segment. Quant au SCIM (System for Cross-domain Identity Management), il est encore très peu utilisé, même par les promoteurs de ce standard (Google, Ping Identity et SalesForce par exemple, ne l’utilisent pas pour le provisioning de leurs applications) , ou bien il est utilisé comme bannière marketing pour les nouveaux arrivants sur le marché de l’IAM. Il n’en reste pas moins que le standard SCIM, qui sera plus abouti en version 2.0, a de nombreux atouts pour l’avenir car il est simple d’utilisation via son interface REST, plus facile à paramétrer que le SPML et enfin plus extensible dans la définition de l’utilisateur.
En pratique, la gestion du provisioning de ces applications est basée sur des connecteurs réalisés « à façon », par exemple :
- Le provisioning GoogleApps est basé sur les API REST. Les premières versions avaient également des implémentations en Java et Python, mais ce n’est plus le cas dans la version courante. Google propose une API très complète et ne cesse de la faire évoluer : il faut être régulièrement à jour. Sachez que l’API a des limitations au niveau de l’usage (par exemple la fréquence d’utilisation), et que Google se dégage de toute responsabilité dans l’utilisation du service.
- Le provisioning Office 365 et Exchange Online n’est vraiment opérationnel qu’en utilisant les API PowerShell, l’interface REST étant plutôt destinée à l’interrogation. La complexité tient donc dans la maîtrise de l’exécution du PowerShell depuis les serveurs Microsoft dédiés.
- Salesforce a une gestion intéressante de la création de compte car elle peut se faire à la volée lors de la connexion. Pour cela, il faut être dans une fédération d’identités où le serveur d’identités indiquera au service Salesforce les paramètres nécessaires à la création de l’utilisateur, réalisant ainsi le Just-In-Time (JIT) provisioning. Quant à la gestion des modifications et suppressions de comptes il faut utiliser l’API REST.
Comment mettre en œuvre le provisioning du cloud dans l’entreprise ?
Le cloud révolutionne les usages et la façon dont les entreprises utilisent et administrent ses services. Quant à la gestion des identités, elle doit rester le garant de la politique de sécurité de l’entreprise qui, tout en étant agile, doit être unique et centralisée. Les outils qui promeuvent une gestion des identités dans le cloud et uniquement pour le cloud font fausse route (ou du bricolage). Les outils de gestion des identités doivent s’adapter pour gérer les applications du cloud de la même façon que les applications internes. Le niveau de service et la simplicité d’utilisation des fonctions de gestion des identités ne dépendent pas de la localisation des serveurs !
Pour être complet, il faudrait évoquer aussi comment les mécanismes de Fédération des identités peuvent également renforcer de façon définitive la sécurité de ces systèmes. Ce sera l’objet d’un prochain billet.
En conclusion, les solutions d’IAM ont encore un bel avenir car si l’on veut maîtriser la sécurité et les coûts, il faut être capable de gérer au plus juste ses utilisateurs internes et externes, consommateurs de services internes et externes.
