L'architecture d'identité moderne repose encore sur Active Directory pour beaucoup

Pour de nombreuses organisations, en particulier celles des secteurs très réglementés, l'architecture d'identité repose sur Active Directory (AD) en son cœur. AD authentifie les utilisateurs, applique les politiques d'accès et sous-tend les applications dont l'entreprise dépend. C'est différent de la façon dont les éditeurs cadrent le sujet : la gestion des identités et des accès (IAM) est cloud-first, avec AD repositionné comme un connecteur legacy. Temporaire et obsolète, ou du moins destiné à être déprécié avec le temps.

Il existe un décalage entre la réalité du terrain et, dans une certaine mesure, la perception véhiculée par les éditeurs. Le marché présente l'abandon d'Active Directory (AD) sur site au profit de systèmes d'identité cloud tels qu'Entra ID comme inévitable.

Jusqu'à récemment, quiconque s'opposait à ce point de vue risquait d'être qualifié d'excentrique, au mieux. Aujourd'hui, il est de plus en plus admis que le débat cloud vs sur site est moins tranché. Le monde réel est simplement plus complexe que ce que laissent entendre les brochures marketing. On peut adopter le cloud sans tout y migrer. L'idée de maintenir AD sur site comme plan à long terme n'est plus perçue comme une idée si farfelue.

Pour les équipes IT, ce décalage est un problème.

• D'abord, il est opérationnel, car elles sont chargées de piloter une migration qui peut prendre des années.

• C'est aussi un problème de sécurité. Lorsqu'on traite un système d'authentification principal comme un simple bouche-trou temporaire, on cesse d'investir dans sa sécurisation. La mauvaise nouvelle, c'est que les attaquants n'attendent pas la fin de la migration.

Presque toutes les entreprises ont aujourd'hui une identité hybride, qu'elles utilisent ce terme ou non. Et ce que cela signifie en pratique varie considérablement. Certaines entreprises ont migré vers Entra ID ou d'autres IdP cloud, en synchronisant ceux-ci avec leur AD legacy. D'autres font l'inverse, maintenant un AD en interne comme système d'identité principal.

Ceux qui migrent vers des plateformes d'identité cloud ont tendance à partager deux caractéristiques principales :

• Une infrastructure legacy minimale et un parc applicatif orienté SaaS,

• Une équipe IT disposant de la capacité de mener une migration sur plusieurs années.

C'est particulièrement vrai pour les organisations dans les secteurs très réglementés. Les entreprises manufacturières exploitent des systèmes intégrés à AD sur les lignes de production qui ne peuvent pas être mis hors ligne durant un projet de migration. Les organisations de santé opèrent dans des environnements où une transition d'identité mal menée peut enfreindre la réglementation HIPAA et perturber les soins aux patients. Les organismes gouvernementaux gèrent des environnements AD portant des décennies d'UO, de GPO, de comptes de service et de structures de permissions qui représentent non seulement une complexité technique, mais aussi un registre de conformité juridique et de cybersécurité. Les institutions financières font face à la même réalité réglementaire, aggravée par PCI DSS, SOX et des cycles d'audit qui font de la perturbation architecturale un risque actif.

Pour ces organisations, « migrez simplement vers le cloud » n'est pas une recommandation technique, c'est un transfert de risque. La plupart des équipes IT qui gèrent ces environnements le savent déjà.

Migrer depuis AD vers une plateforme d'identité cloud a été comparé à réviser les moteurs d'un avion en plein vol. On ne le ferait pas à moins d'y être contraint. En général, c'est un dirigeant ambitieux en croisade pour convertir les CapEx en OpEx.

Les organisations qui disposent déjà d'AD ont un système d'authentification opérationnel. Désormais, les équipes IT doivent migrer des fonctions clés vers une seconde plateforme entièrement différente que tout le monde ne maîtrise pas, généralement contrôlée par un tiers.

Mais AD n'est pas seulement un système d'identité et d'authentification. C'est aussi une base de données de permissions, de relations et d'associations accumulées au fil des années d'exploitation réelle. Plonger dans ses entrailles relève davantage de l'archéologie numérique que de l'informatique.

Migrer ou établir un pont vers le cloud implique de déterrer ces couches, de déterminer quels éléments d'AD sont suffisamment importants pour être conservés, et de répliquer leur conception et leur intention dans un système entièrement différent.

C'est comme essayer d'assembler des engrenages qui ne peuvent physiquement pas s'emboîter. Par exemple, de nombreuses structures AD, telles que les Unités d'Organisation (UO) et les objets de stratégie de groupe (GPO), n'ont pas d'équivalent direct dans Entra ID.

Par ailleurs, AD présente de nombreuses dépendances telles que le DNS intégré à AD, l'infrastructure de certificats, les comptes de service, les protocoles legacy et un enchevêtrement de permissions accumulées au fil du temps. Tout cela doit être mis à jour, documenté, analysé et, le cas échéant, répliqué côté cloud.

Ce n'est pas un argument pour rester immobile. Nous savons tous que de nombreuses organisations peuvent et devraient migrer vers Entra ID. Il s'agit plutôt de ne pas laisser une décision de migration arbitraire dicter les décisions de sécurité pour un environnement qui n'est pas près de disparaître. Surtout lorsque le cœur de cet environnement est opérationnellement peu risqué et peu coûteux par rapport à un projet de migration entrepris avant que l'environnement ne soit prêt.

En pratique, presque toutes les organisations utilisent encore AD quelque part. Un bon nombre continue de l'utiliser comme magasin d'identités principal. Elles se répartissent principalement en deux groupes :

• Petites organisations : la généralisation est difficile, mais de nombreuses petites organisations n'ont pas les ressources ni le besoin d'un coûteux projet de migration cloud.

• Grandes organisations : de nombreuses organisations de taille intermédiaire et de niveau entreprise maintiennent AD pour soutenir des applications vitales. C'est particulièrement vrai dans des secteurs tels que l'industrie manufacturière, l'énergie, la santé, le secteur public et la finance. Dans ces secteurs, conserver la couche d'identité en interne offre des avantages évidents en matière de sécurité et de conformité.

Ce qu'ils ont tous en commun : une infrastructure AD conséquente. Répliquer parfaitement ce qu'elle fait dans un IdP cloud ne sera ni rapide ni simple.

Et pourtant, il est possible d'avoir les deux sans déplacer l'identité. Adopter le cloud et le SaaS ne signifie pas nécessairement que le système d'identité doit suivre.

L'adoption du cloud peut se faire de manière pragmatique.

Les organisations ne remplacent pas leur AD de fond en comble ; elles étendent plutôt très progressivement ce qu'elles ont déjà vers un nouvel environnement, en déployant SaaS et cloud pour compléter les applications existantes. Au lieu de remplacer chaque système sur site par un équivalent cloud, les deux coexistent pour des usages différents, une approche qui offre une nouvelle lecture de la notion de « hybride ».

Appeler cela « hybride » ne signifie pas que ce n'est pas complexe et potentiellement éprouvant. Gérer deux environnements complètement différents, chacun construit sur des technologies et des hypothèses distinctes, est un défi qui peut prendre du temps à maîtriser.

Le sur site et le cloud peuvent fonctionner indépendamment l'un de l'autre dans une certaine mesure, mais pas totalement. Quelque part dans le réseau, la façon dont les utilisateurs accèdent à chaque environnement via la couche d'identité doit être unifiée et sécurisée sans laisser de failles.

Lorsqu'AD est présenté comme un connecteur temporaire sur la voie d'une migration cloud, donner la priorité à sa sécurisation entre en conflit avec l'agenda des éditeurs. Les investissements vont vers la migration, et non vers le renforcement du système qui assure encore le travail. Cela crée une fenêtre d'exposition qui peut durer des années.

Le problème est en partie lié à la visibilité. Dans les environnements hybrides, les équipes IT peuvent surveiller chaque environnement séparément, mais rarement la façon dont ils interagissent. Les outils dédiés capables de couvrir les deux restent rares.

Cela risque de créer une surface d'attaque non gérée. Lorsqu'on connecte AD à un environnement cloud, avec ou sans Entra ID, cela crée un problème de visibilité. On peut voir chaque environnement, mais pas toujours comment ils interagissent et s'exposent mutuellement.

L'analyse réalisée par Microsoft de l'attaque du groupe de ransomware Storm-0501 contre un client non identifié illustre bien ce scénario. Dans une chaîne d'événements complexe, les attaquants ont pu exploiter des faiblesses dans l'environnement AD sur site, en utilisant le serveur de pont Entra Connect Sync pour obtenir des privilèges leur permettant de basculer vers Azure. AD était le point d'entrée des attaquants, mais ils ont finalement ciblé Entra ID par la porte dérobée.

Microsoft n'explique pas clairement comment AD était utilisé dans ce cas, mais d'une certaine façon, cela importe peu. AD peut représenter un risque de sécurité, qu'il soit ou non le système d'authentification principal.