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.
Aucun commentaire:
Enregistrer un commentaire