Authentifier les utilisateurs d'entreprise dans un environnement hybride

Last reviewed 2024-06-26 UTC

Ce document est le premier d'une série de plusieurs articles expliquant comment étendre une solution existante de gestion des identités à Google Cloud, afin de permettre à vos équipes de s'authentifier et de consommer des services dans un environnement informatique hybride.

La série comprend les éléments suivants :

Introduction

La gestion des comptes utilisateur et le contrôle de l'accès aux applications et aux ressources informatiques font partie des principales responsabilités des services informatiques des entreprises. Pour assurer la cohérence et l'efficacité au niveau de l'administration, la plupart des entreprises considèrent la gestion des identités comme une fonction centrale, pour laquelle elles utilisent un système unifié. Le plus souvent, les entreprises s'appuient pour cela sur les services Microsoft Active Directory Domain Services (AD DS).

Lorsque vous étendez un environnement informatique vers Google Cloud dans le cadre d'une stratégie hybride, il est souhaitable de mettre en place un point unique de gestion des identités. Un système unifié de gestion des identités minimise les tâches d'administration liées à la gestion des comptes et au contrôle des accès. Un tel système permet également de garantir que les utilisateurs et les applications peuvent s’authentifier de manière sécurisée dans un environnement hybride.

Ce document examine les moyens d’intégrer Google Cloud à votre système de gestion des identités. Il vous aidera à choisir l'approche qui répond le mieux à vos besoins.

Bien que la majeure partie des concepts s'appliquent également à Google Workspace, ce document est exclusivement consacré à Cloud Identity.

Évaluer les besoins en matière de gestion hybride des identités

La meilleure solution pour étendre votre système de gestion des identités à Google Cloud dépend de plusieurs facteurs :

  • Les pools d'identités existant dans votre organisation
  • Les fournisseurs d'identité assurant les services d'authentification pour vos identités d'entreprise
  • Les ressources et applications auxquelles les utilisateurs de l'entreprise doivent pouvoir accéder via Google Cloud
  • Vos exigences de continuité d'activité

Les sections suivantes abordent chacun de ces facteurs.

Identités

Le premier facteur à prendre en compte lors de l'intégration de Google Cloud et de votre système de gestion des identités est la manière dont vous gérez et différenciez les types d'identités. La plupart des organisations utilisent les types d'identités suivants :

  1. Les identités d'entreprise sont les identités que vous gérez pour les employés de votre organisation. Ceux-ci utilisent ces identités pour se connecter à leur poste de travail, accéder à leurs e-mails ou utiliser des applications d'entreprise.
  2. Les identités externes sont les identités que vous gérez pour les utilisateurs ne faisant pas partie de l'entreprise, tels que les sous-traitants ou les partenaires, qui doivent avoir accès aux ressources de l'entreprise.
  3. Les identités d'invité sont des identités gérées par une tierce partie, telle qu'un client ou un partenaire qui a besoin d'accéder aux ressources de l'entreprise.
  4. Les identités client sont les identités que vous gérez pour les utilisateurs qui interagissent avec votre site Web ou avec vos applications destinées aux clients.
  5. Les identités de charge de travail sont les identités que vous gérez pour permettre aux applications d'interagir avec d'autres applications ou avec la plate-forme sous-jacente.

Souvent, les identités d'entreprise constituent un pool d'identités unique, chaque employé ayant une identité unique et toutes les identités étant gérées de la même manière, en utilisant les mêmes systèmes. Ce n'est toutefois pas une obligation : suite à une fusion ou une acquisition, par exemple, vous pouvez vous retrouver avec plusieurs pools d'identités d'entreprise, chacun étant géré de manière distincte à l'aide de systèmes différents. Au niveau technique, cela se traduit par la nécessité d'intégrer à Google Cloud plusieurs sources LDAP, forêts Active Directory ou locataires Azure AD.

L'intégration de plusieurs pools complexifie l'intégration à Google Cloud. Par conséquent, vous devez évaluer les points suivants :

  • Tous les pools d'identités, ou un sous-ensemble seulement, ont-ils besoin d'accéder à Google Cloud ?
  • Tous les pools d'identités doivent-ils avoir accès à la même organisation dans Google Cloud ou chacun à une organisation propre ?
  • Existe-t-il des solutions permettant de réduire le nombre de pools, par exemple en créant des approbations interforêts entre les forêts Active Directory ?

Les identités externes sont souvent traitées de la même manière que les identités d'entreprise, à quelques exceptions près :

  • Les comptes associés peuvent avoir une durée de validité limitée.
  • Ils peuvent se voir attribuer des droits réduits par défaut.
  • Ils peuvent être gérés par un annuaire LDAP, une forêt Active Directory ou un locataire Azure AD distinct.

Contrairement aux identités externes, les identités d'invité ne sont pas gérées par vos soins mais par une tierce partie. Dans les applications SaaS telles que l'espace de travail Google, les identités d'invité peuvent abroger la nécessité de maintenir des identités externes pour les clients ou les partenaires. Vous rencontrez rarement des identités d'invité dans des environnements sur site.

Ce document porte sur les identités d'entreprise et les identités externes.

Si vous avez utilisé des services tels que Google Ads, certains de vos employés peuvent déjà disposer d'un compte Google qui n'est pas connecté à leur identité d'entreprise, ce qui signifie qu'ils possèdent deux identités. Si tel est le cas, envisagez de consolider ces identités.

Fournisseurs d'identité

Le deuxième facteur à prendre en compte est votre fournisseur d'identité. Un fournisseur d'identité (IdP) est un système qui fournit des services d'authentification pour vos charges de travail et qui, finalement, décide d'authentifier ou non un utilisateur.

En plus de fournir des services d'authentification, les IdP sont fréquemment chargés de la gestion du cycle de vie des identités. Ce n'est toutefois pas systématiquement le cas, car les identités peuvent aussi être gérées à partir d'un système de ressources humaines distinct.

Parmi les fournisseurs d'identité courants, citons :

  • Active Directory (AD DS)
  • Azure Active Directory (Azure AD)
  • Les fournisseurs IDaaS tels que ForgeRock, Okta ou Ping Identity
  • D'autres annuaires LDAP, y compris les services AD LDS (Active Directory Lightweight Directory Services)

Au lieu d'utiliser un système unique, vous pouvez utiliser conjointement plusieurs systèmes, par exemple pour gérer différents groupes d'utilisateurs, gérer des comptes externes ou fournir des services d'authentification différents pour les mêmes groupes d'utilisateurs. Voici quelques exemples d'utilisation conjointe de plusieurs fournisseurs d'identité pour gérer les mêmes pools :

  • Active Directory fédéré avec Azure AD
  • Active Directory fédéré avec un fournisseur IDaaS tel que ForgeRock, Okta ou Ping Identity
  • Active Directory avec des instances dupliquées AD LDS

Pour utiliser votre IdP sur Google Cloud, vous pouvez adopter l'une de ces deux approches de base :

  • Fédérer votre fournisseur d'identité avec Cloud Identity : en fédérant votre IdP avec Cloud Identity, vous permettez à Google de devenir un fournisseur d'identité supplémentaire utilisable par vos utilisateurs d'entreprise et pouvant servir d'appui aux applications déployées sur Google Cloud. Au lieu de gérer les identités Google de chacun de vos utilisateurs, vous pouvez vous reposer sur la relation de fédération pour gérer les identités de manière automatisée. Cette relation contribue également à garantir que votre fournisseur d'identité reste la source de vérité.
  • Étendre votre fournisseur d'identité à Google Cloud : vous pouvez autoriser les applications déployées sur Google Cloud à réutiliser votre IdP, soit en s'y connectant directement, soit en conservant une instance répliquée de votre IdP sur Google Cloud.

Les autres facteurs relatifs à la gestion des identités peuvent vous amener à combiner ces deux approches pour répondre à vos scénarios d'utilisation hybride.

Ressources

Le troisième facteur consiste à déterminer à quelles ressources Google Cloud vous souhaitez accorder l'accès à vos utilisateurs d'entreprise. Ce facteur inclut Google Cloud proprement dit : vous devez autoriser les équipes responsables à gérer Google Cloud à travers la console Google Cloud, gcloud CLI ou les API.

Les ressources supplémentaires peuvent inclure :

Ces ressources diffèrent selon qu'elles doivent, peuvent ou ne peuvent pas utiliser Google en tant que fournisseur d'identité. Les sections suivantes abordent chacun de ces cas de figure.

Ressources devant utiliser Google comme IdP

Les ressources qui doivent utiliser Google comme IdP incluent la console Google Cloud, gcloud CLI, les applications protégées par Cloud IAP, ainsi que d'autres outils et services Google. Pour permettre à vos utilisateurs d'entreprise d'accéder à ces ressources, vous devez configurer une identité Google pour chacun d'eux.

Maintenir des identités Google distinctes va à l'encontre de l'idée de gestion unifiée des identités. Par conséquent, si vous accordez aux utilisateurs l’accès à l’une de ces ressources, cela implique de fédérer votre IdP avec Google Cloud.

Une fois que vous avez fédéré votre IdP avec Google Cloud, vous pouvez envisager d'utiliser Google comme IdP pour d'autres ressources, en particulier les applications utilisant d'autres solutions pour l'authentification des utilisateurs.

Ressources pouvant utiliser Google comme IdP

Les ressources qui pourraient utiliser Google comme IdP, mais pour lesquelles ce n'est actuellement pas le cas, comprennent :

  • les applications nouvelles, destinées aux utilisateurs professionnels, que vous envisagez de déployer sur Google Cloud ;
  • les applications existantes, destinées aux utilisateurs professionnels, que vous prévoyez de migrer par migration Lift and Shift ou d'améliorer et de déplacer vers Google Cloud.

La capacité de ces applications à utiliser Google comme IdP dépend des protocoles que vous utilisez pour l'authentification et l'autorisation.

Protocoles Web d'authentification unique

Google est compatible avec plusieurs protocoles standards du secteur pour la gestion de l'authentification, de l'autorisation et l'authentification unique. Les protocoles suivants sont compatibles :

  • OAuth 2.0, qui s’applique aux clients mobiles, aux clients lourds et aux applications autres que les navigateurs ;
  • OpenID Connect 1.0 (OIDC), qui s’applique aux applications basées sur un navigateur.
  • SAML 2.0, qui s'applique à l'intégration d'applications tierces.

OAuth 2.0 ou OIDC sont les solutions à privilégier pour les applications que vous envisagez de développer. Ces protocoles sont couramment utilisés et vous pouvez tirer parti de nombreux outils et bibliothèques bien testés. En outre, l'utilisation de ces protocoles implique que vous pouvez éventuellement utiliser Google comme IdP, tout en conservant la possibilité de changer de fournisseur d'identité suivant vos besoins.

Si vous exploitez des applications utilisant SAML, OAuth 2.0 ou OIDC, il est possible de les basculer vers Google en tant que fournisseur d'identité avec peu ou pas de modifications dans le code.

LDAP

Le protocole LDAP (Lightweight Directory Access Protocol) est l’un des protocoles les plus polyvalents et les plus fiables pour l’authentification et l’autorisation. Une application peut utiliser LDAP de plusieurs manières pour l’authentification et l’autorisation. Les deux scénarios les plus courants sont les suivants :

  1. Utilisation de LDAP pour l'authentification et l'obtention des informations utilisateur : dans ce scénario, une application n'utilise pas l'authentification unique. Au lieu de cela, elle fournit à l'utilisateur un formulaire de connexion demandant son nom d'utilisateur et son mot de passe, puis utilise les identifiants fournis pour tenter une opération LDAP bind. Si la tentative réussit, les identifiants sont considérés comme valides. Toute information supplémentaire concernant l'utilisateur, comme son nom et son appartenance à des groupes, peut être obtenue à partir de l'annuaire et utilisée pour autoriser l'accès.

  2. Utilisation de SAML pour l'authentification et de LDAP pour l'obtention des informations utilisateur : dans ce scénario, l'application authentifie l'utilisateur à l'aide d'un protocole d'authentification unique. Le plus souvent, les applications utilisent SAML à cette fin. Une fois l'utilisateur authentifié, l'application utilise le serveur LDAP pour obtenir des informations supplémentaires à son sujet, comme son nom ou son appartenance à des groupes.

Il existe une différence essentielle entre ces deux scénarios. Le premier scénario nécessite que l'application et le serveur LDAP aient tous deux accès au mot de passe de l'utilisateur pour vérifier les informations d'identification. Dans le second scénario, l'application et le serveur n'ont pas besoin d'accéder au mot de passe de l'utilisateur. L'application peut effectuer ses requêtes LDAP grâce à un utilisateur de service dédié.

Avec le protocole LDAP sécurisé, vous pouvez accéder aux informations relatives aux utilisateurs et aux groupes dans Cloud Identity à l’aide du protocole LDAP. Si Google est votre fournisseur d'identité principal, le protocole LDAP sécurisé vous permet de gérer les deux scénarios. Toutefois, si vous intégrez Cloud Identity à un IdP externe, Cloud Identity ne conserve pas de copie propre des mots de passe des utilisateurs. Par conséquent, seul le second scénario peut être mis en œuvre avec le protocole LDAP sécurisé.

Kerberos et NTLM

Si vous envisagez de migrer des charges de travail Windows vers Google Cloud, certaines de ces applications sont susceptibles de s'appuyer sur l'authentification Windows intégrée (IWA) au lieu d'utiliser des protocoles standards. IWA est un choix courant pour les applications ASP.NET exécutées sur Microsoft IIS. IWA est populaire car il permet une expérience d'authentification unique parfaitement fluide pour les utilisateurs qui se sont connectés à leur poste de travail Windows à l'aide de leurs identifiants de domaine.

IWA s'appuie sur NTLM ou sur Kerberos. Cette authentification nécessite que le poste de travail de l'utilisateur et le serveur exécutant l'application soient joints au même domaine Active Directory ou à des domaines en relation d'approbation.

S'appuyer sur NTLM et Kerberos a pour conséquence qu'une application utilisant IWA ne peut pas utiliser Google comme IdP. Cependant, il peut être envisageable de refactoriser l'application pour qu'elle utilise OIDC. OIDC n'exige pas que le poste de travail de l'utilisateur ou le serveur soient associés à un domaine. La refactorisation peut donc simplifier le déploiement et vous aider à exploiter d'autres options de déploiement.

Au vu de l'expérience d'authentification unique fluide assurée par IWA, opter pour OIDC au lieu d'IWA peut sembler être une régression en termes d'expérience utilisateur. Toutefois, ce n'est pas nécessairement le cas si vous vous assurez que les utilisateurs peuvent se connecter de manière transparente à AD FS ou Azure AD :

  • Si vous fédérez Google Cloud avec Active Directory et AD FS, toutes les méthodes d'authentification configurées dans AD FS s'appliquent. Si vous configurez AD FS pour autoriser IWA, les utilisateurs connectés à leur poste de travail Windows à l'aide de leurs identifiants de domaine peuvent être authentifiés de manière transparente auprès de toute application utilisant Google en tant que fournisseur d'identité.
  • Si vous fédérez Google Cloud avec Azure AD, vous pouvez activer l'authentification unique transparente Azure AD dans le même sens.

Le diagramme suivant présente un exemple simplifié d'utilisation de Cloud Identity, AD FS et IWA pour la mise en œuvre de l'authentification unique transparente pour une application Web :

Utiliser Cloud Identity, AD FS et IWA afin de mettre en place une authentification unique transparente pour une application Web

  1. L'utilisateur demande une page protégée à travers un navigateur Web.
  2. L'application Web initie une connexion à l'aide d'OIDC (flux d'authentification OIDC). Ce flux redirige le navigateur vers le point de terminaison Google Sign-In.
  3. Le point de terminaison Google Sign-In renvoie la page de connexion Google Sign-In à l'utilisateur, en lui demandant de saisir son adresse e-mail.
  4. L'utilisateur saisit son adresse e-mail.
  5. Sur la base de l'adresse e-mail, le point de terminaison Google Sign-In identifie le compte Cloud Identity et reconnaît qu'il est configuré pour utiliser l'authentification unique. Le point de terminaison initie ensuite une connexion SAML avec AD FS.
  6. AD FS, configuré pour utiliser IWA, demande au navigateur de présenter un ticket Kerberos, ce qui déclenche une demande de ticket de la part du navigateur auprès du système d'exploitation Windows sous-jacent.
  7. À moins qu'un ticket adéquat ait été mis en cache, Windows contacte le centre de distribution de clés (KDC) Active Directory et demande l'émission d'un ticket de service approprié correspondant au ticket d'octroi de ticket (TGT) obtenu lorsque l'utilisateur s'est connecté à Windows.
  8. Le navigateur présente le ticket ainsi obtenu à AD FS.
  9. AD FS valide le ticket en vérifiant sa signature chiffrée, en extrait l'identité de l'utilisateur et envoie un jeton SAML au point de terminaison Google Sign-In.
  10. À l'aide des informations d'authentification contenues dans le jeton SAML, le point de terminaison Sign-In réalise la connexion OIDC et émet des jetons OpenID Connect à destination de l'application Web.
  11. Une fois l'utilisateur authentifié, la page protégée peut être renvoyée à l'utilisateur.

Authentification par clé publique SSH

Si vous envisagez d'exécuter des machines virtuelles (VM) Linux sur Google Cloud, vous aurez probablement besoin d'un accès SSH à ces machines. La méthode d'authentification la plus courante pour SSH est l'authentification par clé publique.

Contrairement aux protocoles d'authentification unique décrits précédemment, l'authentification par clé publique SSH ne repose pas sur un fournisseur d'identité centralisé pour prendre des décisions d'authentification. Au lieu de cela, les décisions d'authentification sont décentralisées : chaque ordinateur gère l'authentification en fonction d'un ensemble local de clés publiques autorisées.

Vous pouvez combler l'écart qui existe entre l'authentification par clé publique SSH décentralisée et la gestion centralisée des identités en utilisant OS Login. OS Login lie le cycle de vie des clés SSH au cycle de vie des comptes utilisateur grâce à :

  • la publication d'une clé publique SSH lorsqu'un utilisateur est créé ou tente d'utiliser SSH pour la première fois ;
  • la transmission de la clé publique de l'utilisateur aux machines auxquelles il est autorisé à accéder ;
  • la désactivation de la clé publique de l'utilisateur lorsque le compte est révoqué, désactivé ou supprimé.

L'utilisation d'OS Login fait de Cloud Identity le fournisseur d'identité pour vos instances Linux.

Ressources ne pouvant pas utiliser Google comme IdP

Certaines ressources ne peuvent pas utiliser directement Google en tant que fournisseur d'identité. Vous pouvez néanmoins intégrer ces ressources à Google Cloud en combinant deux approches :

Si une ressource repose sur des protocoles non compatibles avec l'IdP Google, cette ressource ne peut pas utiliser Google comme IdP. Ces protocoles incluent :

  • LDAP pour l'authentification : bien que vous puissiez utiliser le protocole LDAP sécurisé pour faciliter l'interrogation des informations utilisateur à partir de Cloud Identity via LDAP, Cloud Identity ne permet pas de passer par LDAP pour l'authentification lorsqu'il y a fédération avec un IdP externe.

    Pour permettre aux applications d'utiliser LDAP pour l'authentification, vous pouvez exposer ou répliquer un annuaire LDAP sur site ou vous pouvez étendre Active Directory à Google Cloud.

  • WS-Trust, WS-Federation : si vous utilisez AD FS en particulier, vous pouvez toujours devoir faire appel à WS-Trust ou à WS-Federation pour gérer l'authentification par jeton. À moins de pouvoir modifier les applications concernées pour qu'elles utilisent SAML ou OpenID Connect, il est préférable d'exposer vos services AD FS sur site à Google Cloud et de faire en sorte que les applications utilisent directement AD FS.

  • OpenID Connect avec des revendications spécifiques à AD FS : AD FS et Google sont compatibles avec OpenID Connect. Si vous utilisez AD FS en tant que fournisseur OpenID Connect, il est possible que vous vous appuyiez sur certaines revendications spécifiques à AD FS non compatibles avec Google. Si tel est le cas, envisagez d'exposer vos services AD FS sur site à Google Cloud et faites en sorte que les applications concernées utilisent directement AD FS.

  • Kerberos, NTLM : si certaines de vos applications utilisent Kerberos ou NTLM pour l'authentification, il est éventuellement possible de les modifier pour utiliser plutôt OpenID Connect ou SAML. Si ce n'est pas le cas, vous pouvez déployer ces applications sur des serveurs Windows appartenant à un domaine et exposer ou répliquer votre annuaire Active Directory sur site vers Google Cloud.

  • Machines virtuelles Windows : si vous exécutez des charges de travail Windows sur Google Cloud, vous devez pouvoir vous connecter à ces VM via le protocole RDP (Remote Desktop Protocol), via une passerelle de bureau à distance ou par d'autres moyens. Si un utilisateur possède l'accès en écriture au projet Google Cloud hébergeant la VM, Google Cloud lui permet de créer un utilisateur et un mot de passe, ce qui génère un compte dans la base de données SAM (Security Account Manager) locale de la VM. De manière essentielle, le compte Windows SAM résultant n'est pas connecté au compte Google de l'utilisateur et n'est pas soumis au même cycle de vie. Si vous suspendez ou supprimez le compte Google de l'utilisateur, le compte Windows SAM n'est pas affecté et peut continuer à fournir un accès à la VM.

    Si vous avez un nombre modéré de VM Windows et d'utilisateurs devant pouvoir se connecter à ces machines, laisser les utilisateurs générer des comptes et mots de passe d'utilisateur Windows peut être une approche viable. Toutefois, dans le cadre de parcs de serveurs Windows plus importants, il peut être préférable d’étendre Active Directory sur site à Google Cloud et de joindre les serveurs respectifs à des domaines. Joindre les serveurs à des domaines est également une obligation si vous utilisez l'authentification au niveau du réseau.

Disponibilité

Le dernier facteur à prendre en considération est la disponibilité. Être en mesure d'authentifier des utilisateurs est probablement critique pour bon nombre de vos charges de travail, et une panne de fournisseur d'identité peut avoir de lourdes conséquences. La bonne approche pour garantir une disponibilité adaptée dépend de la manière dont vous envisagez d’utiliser Google Cloud et de son intégration dans votre stratégie hybride.

Charges de travail distribuées

Pour tirer parti des fonctionnalités uniques offertes par chaque environnement informatique, vous pouvez utiliser une approche hybride multicloud pour répartir les charges de travail entre ces environnements. Ces environnements peuvent comporter des dépendances croisées qui se révèlent critiques pour la disponibilité de vos charges de travail. Les dépendances peuvent inclure des tunnels VPN ou des interconnexions, des communications entre applications ou encore l'accès aux données entre plusieurs des environnements informatiques.

Lorsque vous fédérez ou étendez votre fournisseur d'identité externe à Google Cloud, assurez-vous que la disponibilité de votre IdP externe et des autres systèmes requis pour l'authentification est égale ou supérieure à la disponibilité des autres dépendances critiques. Cette exigence signifie que vous pouvez être amené à déployer de manière redondante l'IdP externe ainsi que ses dépendances, et assurer la redondance de la connectivité réseau.

Charges de travail redondantes

Si vous utilisez Google Cloud pour assurer la continuité des activités, vos charges de travail sur Google Cloud reflètent certaines charges de travail de votre environnement informatique. Le but d’une telle configuration est de permettre à l'un des environnements de reprendre le rôle de l'autre environnement en cas de défaillance. Ainsi, vous devez examiner chaque dépendance entre ces environnements.

Lorsque vous configurez Google Cloud pour s'appuyer sur un fournisseur d'identité externe s'exécutant sur site, vous créez une dépendance. Cette dépendance peut aller à l'encontre de l'objectif visé par l'utilisation de Google Cloud en tant que copie indépendante de votre environnement informatique.

Essayez de dupliquer votre IdP vers Google Cloud de manière à ce qu'aucune des charges de travail sur Google Cloud ne soit affectée par une panne de votre environnement informatique sur site ou de la connectivité entre Google Cloud et votre réseau local.

Étapes suivantes