La gestion des accès et des habilitations, une problématique centrale dans la mise en œuvre d’applications sur le Cloud au sein d’un Système d’Information

La fonctionnalité d’identification permet de définir l’identité de la personne connectée (via son identifiant unique) tandis que la fonctionnalité d’authentification permet de vérifier que la personne qui se connecte est bien celle identifiée via différentes solutions de sécurisation.

Une des solutions d’authentification les plus populaires est la solution du Single Sign On (SSO) ou authentification unique en français,  qui délègue l’authentification de l’utilisateur à un tiers de confiance appelé fournisseur d’identité (IDP ou Identity Provider en anglais). 

Plusieurs technologies existent pour mettre en œuvre cette solution d’authentification comme OpenID ou le SAMLv2. Cette dernière sera par ailleurs présentée plus loin dans l’article. 

Le SSO présente des avantages sur différents axes : 

• pour l’utilisateur du service (ou de l’application) en lui permettant de s’authentifier une seule fois, et donc de limiter le temps passé à saisir les différents mots de passe sur l’ensemble des applications ; 
• pour le responsable de la sécurité de l’applicatif, puisque cette solution vient centraliser à l’endroit souhaité (qui peut être on-premise ou dans le Cloud comme nous l’aborderons plus tard) l’annuaire et les habilitations des différents utilisateurs. Cela permet aussi de ne pas multiplier les lieux de stockage des mots de passe de chacun des utilisateurs. 

Plusieurs difficultés sont constatées régulièrement chez nos clients concernant l’intégration de la solution d’authentification dans l’écosystème de l’entreprise. Ces dernières sont accrues particulièrement lors de la mise en place de solutions de type SaaS/PaaS.  

Mise en place d’une solution SaaS avec l’intégration d’un Identity Provider (IdP) interne 

La plupart des entreprises historiques disposent de leur propre IdP en interne (on-premise) utilisé par l’ensemble de leurs applications. C’est pourquoi beaucoup de solutions de type SaaS proposent des connexions simplifiées avec la plupart des protocoles populaires. 

Chez plusieurs de nos clients, nous avons constaté l’utilisation du protocole SAMLv2 dans ce type d’architecture dite hybride où la solution SaaS est hébergée sur un fournisseur Cloud et l’IdP est en interne chez le client. Ce protocole est normé et repose sur l’échange de jetons sécurisés entre le fournisseur d’identité (IdP) et le fournisseur de service (Service Provider (SP) en anglais). 

Image 1 : Processus d’authentification SAMLv2 

Cependant, plusieurs problématiques se posent lors de la mise en place d’un IdP interne sur une application SaaS, telle que la gestion de la sécurité. Celle-ci est liée à la maturité de l’entreprise sur la technologie Cloud et à sa politique de sécurité. En effet, les accès à l’IdP depuis le Cloud sont souvent cause de discussions sur leur sécurisation puisque l’acceptation de flux en provenance du Cloud dans un SI est souvent vue comme l’ouverture d’une porte vers l’extérieur et potentiellement à des personnes malveillantes. 

La première étape pour accéder à un IdP interne depuis le Cloud est de paramétrer le firewall de l’entreprise afin d’accepter certains flux en provenance d’internet. Sur un autre axe, et dans une idée de sécurisation de ces accès, les fournisseurs Cloud et les outils SaaS proposent, pour la plupart, l’utilisation de VPN ou de connexion directe (exemple AWS DC) entre l’applicatif sur le Cloud et le réseau interne de l’entreprise.

Une limite que nous avons rencontrée lors de nos interventions sur des projets similaires, est la faible scalabilité d’un IdP on-premise par rapport à l’applicatif SaaS souvent scalable. Cette limite n’intervient pas dans tous les cas mais peut remettre en question l’utilisation d’un IdP interne dans le cadre de l’ouverture du service à une plus grande population que celle de l’entreprise prévue initialement.  

Par ailleurs, nous avons constaté que les coûts induits tels que la mobilisation d’un RSSI, l’étude d’éligibilité au Cloud, le contrôle des procédures mises en place, sont souvent négligés lors du cadrage des projets et des estimations de charge. Or, ces activités seront nécessaires au déploiement en production du projet et sont chronophages. Différentes causes peuvent être la raison de cette négligence : le manque d’implication des équipes en charge de la sécurité lors de la phase de cadrage ou le manque de maturité sur la solution à mettre en œuvre.  

Mise en place d’une solution PaaS avec intégration d’un nouvel annuaire chez le fournisseur Cloud  

Une autre solution possible est celle de configurer l’IAM directement sur le Cloud.  La majorité des fournisseurs Cloud leaders sur le marché proposent la mise en place de solutions IDaaS (Identity as a Service) facilitant la gestion des accès aux applications sur le Cloud et éventuellement aux applications historiques d’une entreprise.  

 Par exemple, Microsoft Azure propose comme solution l’IAM Azure AD qui est la continuité de Microsoft Active Directory sur le Cloud. Ainsi, il est possible pour une entreprise utilisant ce fournisseur Cloud, de souscrire à ce service et de le synchroniser avec son Active Directory utilisé on-premise à l’aide du service de synchronisation. Cela permet de conserver le lien avec cet AD historique afin de continuer à gérer certains aspects hors Cloud, comme les mots de passe d’applications on-premise. Azure Active Directory est également compatible et utilisable avec des applications sur le Cloud qui sont hébergées chez d’autres fournisseurs Cloud tels que Google ou AWS.  

Image 2 : Architecture Azure AD  

L’utilisation d’un IAM directement sur le Cloud est scalable ce qui peut être un avantage dans le cas où l’entreprise s’agrandit ou qu’une application est ouverte à un plus grand nombre d’utilisateurs (internes ou externes). De plus, la responsabilité sur la sécurité de l’authentification revient en grande partie au fournisseur de la solution IAM, qui se charge par exemple de mettre en place les dernières mises à jour de protocoles de son côté. Ainsi, une entreprise n’a pas nécessairement à avoir la connaissance pour mettre en place et gérer un IAM sur le Cloud, et le déploiement de moyens d’authentifications tels que SSO ou MFA (Multi Factor Authentification) sont directement configurables et faciles à mettre en place.  

Néanmoins, l’utilisation d’un annuaire sur le Cloud peut, dans certains cas, être imposée par le fournisseur Cloud. C’est notamment le cas des solutions PAAS, comme Microsoft Azure ou Google Cloud, qui imposent leur propre solution d’IAM, respectivement Azure Active Directory et Google Cloud Identity. Dans ce cas d’usage, l’entreprise devra bien mettre en place une synchronisation entre son IAM on premise et le nouvel annuaire Cloud via les outils proposés par les fournisseurs Cloud.   

Cependant, être sur le Cloud et exposé sur Internet rend les infrastructures et applications d’une entreprise plus vulnérables. A titre d’exemple, Microsoft relève 300 millions de connexions frauduleuses par jour. Pour se prémunir des attaques, un paramétrage sécurisé de l’IAM est important mais nécessite des compétences spécifiques. De plus, dans un projet de mise en place d’un IAM sur le Cloud, il faut prendre en compte et anticiper cette charge de travail de configuration et sécurisation de l’IAM, tout envisageant la maintenance de l’infrastructure de l’IAM on-premise, ce qui peut être coûteux sur le long terme. Ce point sur la vulnérabilité, couplé à la possible maintenance en double de l’annuaire (on-premise/Cloud), peut engendrer des freins dans la mise en œuvre de cette solution.  

Les problématiques adressées dans cet article sur la gestion des accès des utilisateurs lors de la mise en place d’une application sur le Cloud dans un écosystème existant se retrouvent dans de nombreux projets de transformation digitale. Notre conviction est d’adapter la solution à mettre en œuvre au(x) technologie(s) utilisée(s) et à la population destinée à utiliser l’application. En ce sens, dans le cas où vous disposez d’un annuaire interne, il parait intéressant d’utiliser un protocole comme le SAMLv2 pour gérer l’authentification de vos utilisateurs majoritairement internes à l’entreprise. Au contraire, si l’utilisation d’un annuaire sur le Cloud n’est pas un problème pour l’entreprise, ou que l’application à vocation à être utilisée par un grand nombre d’utilisateurs, alors il est intéressant de profiter des solutions inclues proposées par le fournisseur Cloud, tel que OAuth2 ou OpenID comme le font déjà les principaux acteurs du web comme Facebook, Google ou encore Franceconnect.   

Pour aller plus loin, il nous parait nécessaire de rappeler que le SSO est une solution d’authentification nécessaire, mais qu’elle est de plus en plus complétée par des solutions d’authentification à multiple facteurs (MFA) comme l’empreinte digitale, ou la réception d’un code sur le téléphone portable de l’utilisateur par exemple, qui permettent d’améliorer sa sécurité et de parer certaines vulnérabilités.   

---

Auteurs :

• Thomas Schollaert, Senior Consultant
• Madeleine Bailleux, Consultant
• Anne-Sophie Meyer, Senior Manager
• Maxime Houllier, Manager