De nombreuses organisations gèrent toute leur couche d'identité à partir d'un seul site. Active Directory se trouve sur site, une couche de fédération devant celui-ci authentifie des dizaines d'applications en aval, et l'accès à distance repose sur la même chaîne. Cela fonctionne, jusqu'à ce que le site ne fonctionne plus. Une panne de courant, de réseau ou matérielle dans cet unique emplacement ne met pas seulement Active Directory hors service. Elle met hors service tous les services qui en dépendent pour la connexion.

La réponse habituelle consiste à externaliser l'authentification vers un fournisseur d'identité cloud, le plus souvent Microsoft Entra ID, afin que les utilisateurs puissent toujours se connecter lorsque le site sur site est inaccessible. Cela résout effectivement le problème de disponibilité. Cela déplace également le répertoire utilisateur et la décision d'authentification hors du périmètre de l'organisation et vers une infrastructure régie par une autre juridiction. Avant d'accepter cela comme la seule voie possible, il convient d'examiner comment l'identité sur site peut être rendue résiliente sans dépendre d'un hyperscaler.

C'est la question à laquelle un grand opérateur public européen travaille actuellement avec nous, et c'est une question courante pour toute entité essentielle qui ne peut pas se permettre un point de défaillance unique en matière d'identité.

Pourquoi un Active Directory à site unique met tous les services connectés en danger

L'opérateur exécute Active Directory sur un seul site. En amont, une couche de fédération locale (Active Directory Federation Services, dans ce cas) authentifie un grand nombre de services, y compris l'accès à distance. Les identités sont créées et gérées de manière centralisée, ce qui est judicieux. La faiblesse est géographique : tout ce qui s'authentifie auprès de cet annuaire vit ou meurt avec un seul emplacement.

C'est la partie facile à sous-estimer. Le problème n'est pas une base de données corrompue ou un service défaillant qu'un cluster local pourrait absorber. C'est la perte du site lui-même. Lorsque le bâtiment, son réseau ou son alimentation tombent en panne, les deux moitiés d'une paire de haute disponibilité sur le même site disparaissent avec lui. Un cluster actif-actif de deux nœuds protège contre une défaillance de serveur. Il ne protège en rien contre la défaillance du site qui héberge les deux nœuds.

Donc, l'exposition réelle n'est pas Active Directory isolément. C'est la chaîne qui se trouve derrière. Une seule panne dans un emplacement peut empêcher les utilisateurs de s'authentifier pour l'accès à distance, pour l'accès interne SSO et à toutes les applications fédérées à la fois. Pour une organisation dont les services doivent continuer à fonctionner, cette concentration est le problème à résoudre.

Le déplacement de l'authentification vers Entra ID résout-il réellement la résilience, et quel est son coût ?

Déplacer l'authentification vers Entra ID est une idée raisonnable. Si la connexion s'effectue dans le cloud, elle ne dépend plus de la disponibilité du site sur site. Dans le modèle envisagé par l'opérateur, les utilisateurs seraient toujours créés dans Active Directory et synchronisés avec Entra ID, l'authentification étant gérée dans le cloud. La disponibilité s'améliore, car le fournisseur d'identité cloud n'est pas affecté par la perte d'un site local.

Ce qui change également, c'est l'endroit où réside l'identité et qui la contrôle. L'annuaire des utilisateurs est répliqué dans un service exploité par un fournisseur basé aux États-Unis, et la décision d'authentification s'y déplace également. Les options de résidence des données proposées par les principaux fournisseurs peuvent maintenir le stockage en Europe, mais, comme nous le verrons plus loin, la résidence et la juridiction ne sont pas la même chose.

Il existe un deuxième coût facile à négliger. Une fois que l'authentification dépend d'un fournisseur d'identité dans le cloud, l'organisation a troqué une dépendance contre une autre. Le site unique sur site n'est plus le point unique de défaillance, mais le locataire cloud et la connectivité à celui-ci le sont maintenant. Pour un service essentiel, c'est un échange qui vaut la peine d'être fait consciemment plutôt que par défaut.

Ajout de redondance géographique à l'identité sur site sans hyperscaler

Il existe une autre façon de supprimer le point de défaillance unique, et elle ne nécessite pas de déplacer l'authentification hors site. La couche d'identité sur site peut être étendue avec un deuxième nœud dans un emplacement séparé, y compris un cloud souverain ou européen, de sorte que la perte du site principal n'entraîne pas l'indisponibilité de l'authentification.

Voici comment WebADM, notre console d'administration LDAP et IAM, est conçue pour fonctionner. Elle prend en charge un cluster actif-actif dont les nœuds peuvent se trouver dans différents sites ou centres de données, avec le répertoire, le magasin SQL et l'état de session répliqués entre eux. Un nœud sur site et un nœud dans un cloud souverain offrent à l'organisation une redondance géographique du même type que celle proposée par un hyperscaler, tout en gardant l'infrastructure sous son propre contrôle. Il existe une contrainte pratique qu'il convient de mentionner dès le début : un cluster réparti sur plusieurs sites nécessite une latence contrôlée entre les nœuds, ce qui doit être vérifié lorsque le second site est une région cloud.

The federation layer can be made redundant in the same way. Where the operator’s downstream services currently depend on an on-premise ADFS service, OpenOTP, our authentication server, can act as the identity provider through its Federation Services (SAML, OIDC and OAuth), and can add multi-factor authentication to remote access over the Pont RADIUS, le composant qui apporte l'authentification multifacteur (MFA) aux VPN et aux équipements réseau. Comme ceux-ci fonctionnent sur les mêmes nœuds clusterisés, les points d'entrée de fédération et de VPN ne constituent plus non plus un point de défaillance unique. L'objectif n'est pas de remplacer l'annuaire mais de faire en sorte que toute la chaîne d'authentification survive à la perte d'un site.

Comment l'authentification survit à une panne de site ou d'Active Directory

Pour que l'alternative soit crédible, une question doit être répondue avec précision : si le site sur site ou Active Directory devient inaccessible, comment l'authentification continue-t-elle de fonctionner ?

Pour que cette architecture soit résiliente, le point important est la façon dont OpenOTP et WebADM sont déployés avec Active Directory.

Dans la conception proposée, Active Directory reste la source d'identité de référence. WebADM et OpenOTP peuvent être configurés pour lire les utilisateurs et les groupes depuis Active Directory sans modifier le schéma AD ni les objets AD, à condition que le compte de service LDAP dispose de droits en lecture seule et qu'aucune fonctionnalité de réécriture dans AD ne soit activée. L'annuaire opérationnel utilisé par la plateforme RCDevs peut être hébergé dans l'annuaire OpenLDAP propre à la suite et répliqué sur les nœuds WebADM.

En fonctionnement normal, les informations d'identification de l'utilisateur sont validées par rapport à Active Directory. Une fois qu'un utilisateur s'est authentifié avec succès, OpenOTP peut maintenir des données de validation locales hors ligne conformément à la politique, permettant à l'authentification de se poursuivre pendant une perte temporaire de connectivité à Active Directory ou au site principal. Ce mécanisme ne doit pas être décrit comme une copie du mot de passe Active Directory dans OpenLDAP ; la méthode exacte de stockage et de validation dépend de la politique OpenOTP configurée.

Lorsque Active Directory redevient accessible, la validation en ligne par rapport à AD reprend. Associé aux nœuds WebADM et OpenOTP déployés sur deux sites distincts, cette conception permet à la chaîne d'authentification de survivre à la perte d'un site tout en gardant le répertoire faisant autorité sous le contrôle de l'organisation.

Garder les données d'identité sous juridiction européenne : NIS2 et le CLOUD Act

Pour un opérateur du secteur public, deux considérations réglementaires sous-tendent cette architecture.

Le premier est NIS2. Un opérateur de ce type entre généralement dans le champ d'application en tant qu'entité essentielle, avec des obligations en matière de gestion des risques, de contrôle d'accès, de cryptographie et d'authentification multifacteur. La directive NIS2 ne prescrit pas de produit spécifique, ni n'interdit de fournisseur particulier. Ce qu'elle exige, c'est que le risque soit traité, et une authentification forte pour l'accès aux services critiques est l'une des mesures qui traite le risque visé par NIS2. L'extension de l'authentification multifacteur à l'accès à distance, aux applications fédérées et aux comptes administratifs répond directement à cette exigence.

La deuxième est la juridiction, et c'est là que la résidence des données et la portée juridique divergent. L'opérateur lui-même n'est pas soumis au CLOUD Act américain. Mais un fournisseur de cloud basé aux États-Unis, ou contrôlé par une société mère américaine, y reste soumis, quelle que soit la localisation physique des données. Cela signifie qu'un répertoire d'utilisateurs répliqué dans un tel service peut tomber sous le coup d'une procédure judiciaire américaine, même s'il est conservé dans une région européenne. Les principaux fournisseurs offrent des garanties et des options de limites de données pour l'UE, et l'accès direct aux centres de données européens n'est pas l'événement quotidien que certains titres suggèrent. L'argument ne repose pas sur la fréquence des demandes. Il repose sur le fait structurel que les données se trouvent sous un régime juridique étranger, ce qui est précisément ce qu'une exigence de souveraineté est censée exclure.

Garder le répertoire et la décision d'authentification sur site, étendus à un cloud souverain plutôt qu'à un locataire hyperscaler, permet à l'opérateur de répondre aux exigences de résilience tout en conservant les données d'identité sous juridiction européenne. C'est le compromis que le passage à Entra ID n'offre pas.

La résilience et la souveraineté sont souvent présentées comme un choix : garder le contrôle et vivre avec un point de défaillance unique, ou obtenir de la redondance en déplaçant l'identité vers un hyperscaler. Lorsque aucun des deux ne peut être abandonné, la question est de savoir si la fondation sur site peut être consolidée au lieu d'être remplacée. Pour ce type de contrainte, c'est possible.

Pour aller plus loin : une comparaison des fonctionnalités et des niveaux d'OpenOTP et Microsoft Entra ID.