Michelin refond sa gestion des identités et des accès avec ForgeRock et SailPoint

Une infrastructure IAM de plus en plus difficile à faire évoluer

En 2019, alors que de nombreux nouveaux besoins d’évolution se multiplient dans le groupe, notamment avec une stratégie de développement d’API, l’équipe en charge de l’IAM peine à répondre à toutes ces demandes et à obtenir un consensus sur les évolutions à apporter. La décision est alors prise de faire évoluer cette plateforme et de lancer une RFP pour évaluer les offres du marché et confronter les éditeurs.

L’équipe se tourne alors vers le cabinet Gartner pour définir une longue liste de 344 exigences. Avec l’aide des consultants, l’équipe projet réalise une première sélection de solutions, puis convoque les éditeurs sélectionnés pour un deuxième round. « Même si nous avons souhaité rester en ligne avec le marché et minimiser les points spécifiques, Michelin avait un existant. L’IAM n’était pas un sujet nouveau pour Michelin ; nous avions déjà une solution en place », souligne Olivier Portail.

Dès lors, le groupe devait « remplacer cet existant, sachant que nous avons encore beaucoup d’applications on-premise, avec des ERP dans près de 70 usines dans le monde qui disposent encore de leurs propres datacenters. De plus, nous avons des applications sensibles, des secrets industriels à protéger qui sont conservés dans des datacenters dont nous assurons nous-mêmes la gestion ».

Même si Michelin a engagé un mouvement vers le cloud, avec une forte montée en puissance des services Microsoft Azure et de Salesforce dans son système d’information, l’IAM devait être capable de faire ce grand écart entre des ressources placées dans le cloud public, mais aussi des infrastructures on-premise amenées à rester.

Michelin a souhaité mener le projet IAM en interne

Dans son RFP, l’industriel a demandé aux éditeurs de lui présenter 3 scénarios de déploiement et un calcul de TCO à 5 ans. En effet, l’équipe IAM ne souhaite pas confier le déploiement de la plateforme IAM à un intégrateur, mais mener ce projet en interne. Olivier Portail explique ce choix : « nous considérons que l’IAM est un domaine extrêmement proche des processus et nécessite de bien les maîtriser. Nous nous appuyons sur des prestataires chez qui nous allons chercher de l’expertise technique sur tel ou tel produit, mais nous menons nous-mêmes la migration ».

Ainsi, les présentations des éditeurs n’ont pas seulement porté sur leurs solutions, mais aussi sur l’architecture cible qu’ils voyaient pour Michelin et le chemin de migration potentiel pour y parvenir : « certains éditeurs nous ont répondu que ce n’était pas leur métier, mais celui d’un intégrateur. Nous estimons qu’un éditeur doit être capable de conseiller une architecture et comment parvenir à la mettre en place ».

De même, le choix est fait de scinder le projet en 3 lots : Identity Gouvernance and Administration (IGA), Access Management (AM) et Directory Services (DS). C’est l’offre de l’éditeur SailPoint qui a été sélectionnée pour le lot IGA tandis que ForgeRock décroche les lots AM (Access Management) et Directory Service (DS). « Très vite, il a été clair pour nous que dans notre contexte, ces deux domaines étaient très liés. L’Access Management s’appuie fortement sur l’annuaire », raison pour laquelle ForgeRock a pu décrocher ces deux lots.

Objectif : consolider tous les annuaires LDAP en un seul

Le volet Directory Service est l’occasion pour Michelin de moderniser et unifier des annuaires LDAP dont certains ont été déployés il y a 15 à 20 ans : « les pratiques ont changé depuis cette époque, les réplications sont complexes à gérer ; autant de raisons pour lesquelles nous avons souhaité les consolider vers un seul annuaire ».

« Les pratiques ont changé […], les réplications sont complexes à gérer ; autant de raisons pour lesquelles nous avons souhaité les consolider vers un seul annuaire ».

En outre l’équipe domaine IAM souhaitait disposer d’outils de supervision afin de mieux analyser les interactions entre les applications et les annuaires, disposer d’indicateurs et de logs détaillés, notamment pour débugger certaines situations complexes où les temps d’accès à certaines applications étaient jugés bien trop longs. La plateforme IAM a ainsi été intégrée aux outils de Splunk et à Grafana pour assurer ce monitoring.

Pour mettre en place cette brique DS, l’équipe projet a fait le choix d’un déploiement transparent vis-à-vis des applications qui consomment les services d’annuaire : « dès le départ, nous avons décidé de ne pas passer des mois à essayer de dresser une liste exhaustive de toutes les applications qui ont besoin d’accéder aux annuaires. Nous avons préféré répliquer la structure de l’annuaire actuel et ne rien modifier au niveau des applications ».

Les applications Michelin n’accèdent pas en direct aux annuaires, mais voient leurs requêtes transiter par des équilibreurs de charge F5. La stratégie de déploiement a été de basculer les applications progressivement vers le nouvel annuaire en jouant sur ces load balancers. Le principal risque de ce basculement portait sur les certificats LDAPS, mais une issue a pu être trouvée en exposant le même certificat. L’approche a permis de passer de 4 instances d’annuaire à une seule et toutes les entités ont pu être ainsi basculées.

Access Management : Place à la fédération d’identité généralisée et au MFA

Pour la brique Access Management, la stratégie de déploiement fut complètement différente. Impossible de mener une transformation transparente comme ce fut le cas pour les services d’annuaire. Il fallait lister toutes les applications pour les interfacer avec la solution ForgeRock.

L’objectif de l’équipe projet était de mettre en place un service de fédération d’identité pour l’ensemble des applications, qu’elles soient on-premise ou SaaS, et d’implémenter l’authentification à facteurs multiples (MFA) pour sécuriser les accès utilisateurs : « les applications cloud ont déjà habitué les utilisateurs à la fédération d’identité, or, nos applications internes sont toujours branchées sur notre annuaire LDAP ou Active Directory. Nous avons voulu revoir cette approche et faire que toute nouvelle application doive s’appuyer sur une couche Access Management comprenant OpenID, OAuth ou SAML, qu’il s’agisse de solution on-premise ou cloud ».

Le service doit être déployé sur différentes zones géographiques afin d’être au plus proche des applications dans une architecture haute disponibilité à l’échelle mondiale. Actuellement 90 % des applications Michelin s’appuient sur SAML et seules quelques-unes exploitent OAuth 2.

« Sur l’Access Management, on voit de plus en plus des chemins d’authentification qui vont dépendre de l’utilisateur et de ce qu’il souhaite faire. Disposer d’une représentation graphique simplifie grandement les choses. »

Parmi les atouts de la solution ForgeRock qui ont été appréciés par l’équipe projet, la notion d’« Authentication Tree », une représentation graphique des différents chemins d’accès que peut prendre un utilisateur pour accéder à son application. « Sur l’Access Management, on voit de plus en plus des chemins d’authentification qui vont dépendre de l’utilisateur et de ce qu’il souhaite faire. C’est une approche qui rend le debugging très compliqué. Disposer d’une représentation graphique simplifie grandement les choses ».

L’autre grand chantier de ce volet Access Management a porté sur la mise en place de l’authentification multifacteurs. Michelin met en œuvre de l’authentification forte à base de certificats via la solution Atos IDnomic, pour les ressources qui contiennent des secrets. Pour des applications de type ERP ou CRM, qui ne sont pas considérées comme portant des secrets, l’accès repose donc sur une authentification classique. Avec ForgeRock, Michelin veut mettre en place une capacité d’authentification beaucoup plus granulaire, proposer une authentification MFA pour certaines transactions, avec notamment une vérification d’identité sur mobile au moment de la saisie d’une commande dont le montant dépasse un certain seuil, ou basculer sur une authentification forte via carte PKI pour accéder à une application critique.

Parmi les embûches auxquelles l’équipe projet a dû faire face dans ce déploiement de la brique accès : l’abandon du support de la fonctionnalité de connexion hybride des équipements à Azure AD. Cette fonctionnalité a été mise en place par Michelin lors du déploiement de Microsoft 365 afin de s’assurer que le smartphone ou le PC de l’utilisateur qui souhaite se connecter est bien celui qui est enrôlé dans le MDM. « ForgeRock a arrêté le support de cette technologie entre le moment de notre choix et la phase de déploiement. Cela nous a conduits à réunir toutes les parties prenantes du projet autour d’une table, car dans notre architecture, nous avions réellement besoin de cette interface. ForgeRock a fait l’effort de reconsidérer sa position et a finalement remis la solution à sa roadmap ».

Désormais, l’équipe projet va pouvoir concentrer ses ressources sur le volet IGA de la plateforme IAM. Le déploiement de SailPoint est en cours et la solution est interfacée avec le système RH de Michelin. C’est désormais SailPoint qui vient alimenter l’annuaire LDAP du groupe et gérer ainsi les arrivées de nouveaux collaborateurs, mais aussi les départs des collaborateurs, un point clé dans l’efficacité d’une plateforme IAM.

Texte rédigé à partir de la présentation d’Olivier Portail de Michelin lors des Assises de la Sécurité 2021