VPN, bastions, serveurs : comment un centre de données européen applique l'authentification multifacteur pour chaque client

Un fournisseur qui héberge l'infrastructure d'autres entreprises n'a pas un seul ensemble d'utilisateurs à protéger. Il en a des dizaines, chacun appartenant à une organisation différente, et chacun s'attend à ce que ses identités, ses politiques et ses administrateurs restent strictement séparés de ceux des autres. L'ajout de l'authentification multi-facteurs dans ce contexte n'est pas le même problème que le déploiement de l'AMF au sein d'une seule entreprise. La plateforme doit se comporter comme plusieurs services d'authentification indépendants à la fois, tout en fonctionnant comme un seul système qu'une petite équipe peut gérer.

Voici la situation présentée par un centre de données européen. Il protège des informations sensibles et exécute des opérations critiques pour le compte de ses clients, hébergeant leurs systèmes et, dans de nombreux cas, leurs répertoires. Il souhaitait proposer à ses clients une authentification forte et une authentification unique, gérées comme un service d'identité et d'accès plutôt que comme un second facteur ajouté, et il se désengageait d'un déploiement RSA existant. L'étendue fonctionnelle était large dès le départ : plusieurs VPN, la connexion Windows en ligne et hors ligne, et l'authentification multifacteur (MFA) sur un large éventail d'environnements clients, y compris les bastions utilisés pour accéder aux systèmes clients. La population d'utilisateurs se comptait en plusieurs milliers parmi tous les clients.

Deux aspects de ce déploiement méritent une attention particulière, car ils sont bien généralisables au-delà de ce fournisseur unique. Le premier est la façon dont le modèle de licence et de partage de locataire se transpose sur l'offre commerciale du fournisseur. Le second est la façon dont le contrôle d'accès, et pas seulement le second facteur, s'intègre dans une architecture d'accès multicouche construite autour de bastions. Nous avons déployé OpenOTP, le serveur d'authentification RCDevs, géré via WebADM, la console IAM centrale qui exécute et pilote tous les services de la suite, de la fédération d'annuaires et de l'authentification unique aux politiques d'accès et à l'administration déléguée, l'authentification multifacteur étant l'une des couches parmi celles-ci. Les centres de données et les fournisseurs de services gérés entrent pleinement dans le champ d'application de la NIS2, ce qui explique pourquoi la question de savoir qui peut s'authentifier à quoi, et comment cela est enregistré, revêt une importance particulière.

Pourquoi la multi-location est la partie difficile de la gestion des identités et des accès (IAM) pour un fournisseur de services

La difficulté ne réside pas dans le second facteur lui-même. Les notifications push, les OTP ou FIDO2 sont bien compris. La partie difficile est l'isolement à grande échelle. La clientèle d'un fournisseur est rarement uniforme : une poignée de très petits clients avec quelques utilisateurs chacun côtoient des clients plus importants qui gèrent leur propre annuaire et attendent de leurs propres administrateurs qu'ils gèrent leur propre personnel. Un produit qui suppose une seule organisation, un seul annuaire et une seule limite administrative ne convient pas à cette configuration. Il oblige le fournisseur, soit à mettre en place une installation séparée par client, ce qui multiplie les coûts opérationnels, soit à tout mettre à plat dans un seul espace, ce qui brise l'isolement.

Ce dont ce fournisseur avait besoin, c'était d'une plate-forme capable d'accueillir les deux configurations à la fois : un espace partagé pour les petits clients et des espaces entièrement séparés pour les plus grands, sous une seule console et une seule équipe opérationnelle.

Licence qui reflète le modèle client du fournisseur.

OpenOTP est proposé dans une édition "Service Provider" conçue exactement pour cela. Au lieu de licencier un produit fixe à une seule organisation, le fournisseur s'appuie sur une plateforme multi-locataire et une allocation d'utilisateurs mutualisée qu'il répartit entre ses clients comme il l'entend. Un client qui se développe prend une part plus importante, un client qui se réduit la libère à nouveau, et le fournisseur ne renégocie pas de contrat séparé pour chaque mouvement. Les composants sont sélectionnés à la carte, de sorte que chaque client ne reçoit que ce qu'il utilise, et l'ensemble de la pile peut être présenté sous la marque du fournisseur.

Opérationnellement, cela reste compact. WebADM gère les locataires depuis une seule console, la suite est conçue pour héberger des centaines de locataires clients individuels sur un cluster actif/actif, et la même équipe les gère tous. Le modèle de licence, en d'autres termes, suit le modèle commercial du fournisseur plutôt que l'inverse : le fournisseur vend l'authentification comme il vend déjà l'hébergement, et la plateforme est dimensionnée par rapport à la population entière plutôt que par rapport à un décompte rigide par client.

Héberger le répertoire de chaque client côte à côte

Le modèle de tenancy repose sur la manière dont les annuaires sont attachés. Pour les plus petits clients, le fournisseur exécute une seule tenancy partagée, prise en charge par un Active Directory mutualisé qui les regroupe tous. Pour les plus grands clients, chacun bénéficie d'une tenancy dédiée connectée à son propre Active Directory. Dans ce déploiement, cela signifiait un annuaire partagé pour les plus petits clients, aux côtés d'une série d'annuaires dédiés, par client, sur la même plateforme.

OpenOTP se connecte nativement à chacun de ces répertoires. Active Directory reste la source de vérité pour chaque client : à la connexion, OpenOTP valide le mot de passe de l'utilisateur par rapport au répertoire propre à ce client, puis applique le second facteur, notification push, OTP ou FIDO2, selon les politiques définies pour ce locataire. WebADM présente chaque répertoire comme son propre locataire isolé, ainsi le répertoire partagé et les répertoires dédiés coexistent sans que le fournisseur n'ait à exécuter des installations distinctes. La même approche s'étend au-delà d'Active Directory : OpenOTP fonctionne avec d'autres répertoires LDAP et s'intègre avec Entra ID, Okta, Google et d'autres fournisseurs d'identité, de sorte qu'un fournisseur dont les clients ne sont pas tous sur Active Directory n'est pas bloqué.

Permettre à chaque client de gérer sa propre administration d'utilisateurs, sans franchir les limites des locataires

Un fournisseur ne souhaite pas faire office de service d'assistance pour chacun des utilisateurs de ses clients. L'application Help Desk permet au fournisseur de déléguer la gestion quotidienne des utilisateurs à chaque client ; ainsi, ce sont les administrateurs du client qui réinitialisent les mots de passe token, enregistrent les utilisateurs et assurent le support de première ligne au sein de leur propre tenant.

Cette délégation est disponible pour les locataires dédiés, et délibérément pas pour le locataire partagé. Un client assis dans le locataire mutualisé partage ce répertoire avec d'autres clients, donc lui accorder un accès administratif lui permettrait de voir des utilisateurs qui ne lui appartiennent pas. L'isolement qui rend le locataire partagé économique pour les petits clients est la même propriété qui empêche une délégation sûre à l'intérieur de celui-ci. Les clients plus importants sur des locataires dédiés n'ont pas de chevauchement similaire, ils obtiennent donc leur propre administration déléguée. La distinction n'est pas une limitation ajoutée ultérieurement. Elle découle directement de l'emplacement des identités de chaque client.

Comment l'AMF et les politiques d'accès s'intègrent dans une architecture de bastion multicouche

De nombreux fournisseurs activent l'authentification multifacteur (MFA) sur le VPN et considèrent l'accès à distance comme résolu. Dans un environnement d'hébergement, ce n'est que la porte extérieure. Les systèmes qui comptent, les serveurs d'un client et les comptes privilégiés sur ceux-ci, se situent plusieurs couches plus profondément, et chaque couche est un endroit où un attaquant qui détient déjà des identifiants essaie d'avancer. La conception vise à rendre un ensemble d'identifiants volés insuffisant à lui seul, et une vérification d'identité régie par la politique d'accès du locataire est placée à chaque couche afin que le vol d'identifiants ne se traduise pas par un mouvement latéral. Le chemin d'accès comporte trois points de contrôle, et cette vérification doit être appliquée aux trois.

Un VPN protège le périmètre du réseau, pas la frontière des privilèges

La connexion VPN ouvre l'accès à un segment défini de l'infrastructure plutôt qu'à tout à la fois. Elle prouve qu'une personne connue a atteint un segment connu. Elle ne dit rien sur le fait que cette personne doive ouvrir une session privilégiée sur un serveur à l'intérieur. L'authentification multifacteur (MFA) sur le VPN est nécessaire et non suffisante : elle protège la périphérie, tandis que la limite de privilèges se trouve toujours devant elle.

Un bastion est le point de passage obligé pour les accès privilégiés, il s'authentifie donc en propre

Depuis le segment autorisé, le client atteint un bastion, un saut d'hôte qui se trouve un niveau plus profond et à partir duquel, et uniquement à partir duquel, les systèmes cibles sont atteints. La topologie du bastion suit le modèle de locataire : chaque client plus important a son propre bastion dédié, tandis que les petits clients qui partagent un locataire partagent également un bastion et un pool de ressources commun. Dans un cas comme dans l'autre, le bastion est le point par lequel transitent toutes les sessions privilégiées, c'est pourquoi il n'est jamais exposé directement à Internet (un bastion directement accessible est sondé et attaqué en permanence) et pourquoi la connexion au bastion lui-même est vérifiée à nouveau au lieu de faire confiance au VPN qui l'a précédé. Ce qui est appliqué ici n'est pas seulement un second facteur, mais la politique d'accès du locataire : WebADM évalue la connexion au bastion par rapport aux propres règles de ce client via le même moteur de politique qui régit le reste de la plateforme, de sorte que l'accès au bastion d'un client n'hérite jamais de la politique d'un autre client. Le second facteur est une entrée que la politique prend en compte, aux côtés de qui est l'utilisateur et ce qu'il est autorisé à atteindre.

La connexion au serveur est le dernier barrage, et il doit tenir lorsque le chemin est dégradé

Au bout du chemin se trouvent les serveurs Windows et Linux eux-mêmes. La connexion Windows utilise l'authentification multifacteur (MFA) en ligne et hors ligne via le fournisseur d'informations d'identification OpenOTP, ce qui est important dans un centre de données : un serveur privilégié doit rester accessible à ses administrateurs même lorsque le lien avec le serveur d'authentification est temporairement indisponible, et la connexion capable de fonctionner hors ligne maintient le second facteur en place plutôt que de le supprimer au pire moment. Une information d'identification volée à une couche ne permet pas à un attaquant de passer à la suivante, car chaque connexion protégée par OpenOTP demande à nouveau une authentification.

OpenOTP se branche sur chacun de ces points via les protocoles qu'ils parlent déjà plutôt que de demander au fournisseur de reconfigurer son réseau, ce qui permet au même moteur de politique d'atteindre le VPN, le bastion et le serveur sans exécuter trois projets distincts.

Le schéma présente le modèle de référence générique, dans lequel les services de chaque client sont publiés sur Internet. Ce déploiement est plus restrictif : rien n’est exposé en ligne, à l’exception des points de terminaison nécessaires aux notifications push, qui parviennent au service de push cloud RCDevs. La couche proxy, représentée par un cluster HAProxy et WAProxy, est assurée par des équipements F5 qui gèrent également le pare-feu de première ligne, tandis que les stockages SQL et LDAP, représentés sous forme de clusters distincts, s’exécutent directement sur les deux nœuds WebADM plutôt que sur des couches de stockage dédiées. Chaque client accède à son propre tenant via son propre VPN dédié et sa propre URL, sans jamais transiter par une interface publique partagée.

Mise à l'échelle du même modèle dans plusieurs centres de données

Rien dans cette conception n'est lié à un site unique. Un fournisseur qui exploite plusieurs centres de données place un nœud WebADM dans chacun d'eux : soit un cluster complet par centre de données, soit un nœud d'un cluster global par site. La plateforme les étend sans modifier la manière dont les locataires, les annuaires ou les politiques sont définis. L'ajout d'un centre de données signifie l'ajout d'un nœud, et non la reconstruction du service d'authentification. Un fournisseur peut passer d'un site à plusieurs, ou reprendre une nouvelle région, et le même modèle multi-locataire se transpose inchangé.

Pour un fournisseur dans cette position, le point utile est que le service d'authentification n'a pas à être assemblé à partir d'une installation par client, et il n'a pas à sacrifier l'isolation pour rester gérable. Une plateforme multi-locataires peut héberger un locataire partagé pour les petits clients et des locataires dédiés pour les gros, attacher le propre répertoire de chaque client, déléguer l'administration là où l'isolation le permet, imposer l'authentification multifacteur sur les VPN, les bastions et les connexions aux serveurs, et s'étendre sur autant de centres de données que le fournisseur en exploite.

Pour en savoir plus

• OpenOTP pour Fournisseurs de Services (édition MSSP) : https://www.rcdevs.com/mssp-partners/
• Fonctionnalités et éditions de licence : https://www.rcdevs.com/license-features/
• OpenOTP comparé aux solutions IAM et MFA dans le cloud : https://www.rcdevs.com/compare_cloud_iam_and_mfa_solutions/
• WebADM, la console IAM principale : https://www.rcdevs.com/products/webadm/
• MFA sur VPN et VPN SSL : https://www.rcdevs.com/solutions/vpn/