Modèles pour authentifier les utilisateurs d'entreprise dans un environnement hybride

Last reviewed 2024-06-26 UTC

Ce document est la deuxième partie d'une série de plusieurs articles expliquant comment étendre votre solution de gestion des identités à Google Cloud pour permettre aux utilisateurs de l'entreprise de s'authentifier et d'utiliser des services dans un environnement informatique hybride.

La série comprend les documents suivants :

Présentation

Lorsque vous étendez votre environnement informatique à Google Cloud dans le cadre d'une stratégie hybride, nous vous recommandons d'adopter une approche cohérente pour gérer les identités d'un environnement à un autre. Lorsque vous concevez et adaptez votre architecture pour répondre à ces contraintes et exigences, vous pouvez aussi vous appuyer sur certains modèles courants. Ces modèles entrent dans deux catégories :

  • Modèles permettant de fédérer un fournisseur d'identité externe (IdP) avec Google Cloud L'objectif de ces modèles est de permettre à Google de devenir un fournisseur d'identité pour les utilisateurs de votre entreprise, de sorte que les identités Google soient gérées automatiquement et que votre fournisseur d'identité reste la source unique de vérité.
  • Modèles visant à étendre un IdP vers Google Cloud. Dans ces modèles, vous permettez aux applications déployées sur Google Cloud de réutiliser votre IdP soit en vous y connectant directement, soit en gérant une instance dupliquée de votre IdP sur Google Cloud.

Modèles permettant de fédérer un IdP externe avec Google Cloud

Pour autoriser l'accès à la console Google Cloud, à Google Cloud CLI ou à toute autre ressource utilisant Google comme IdP, un utilisateur de l'entreprise doit posséder une identité Google. La gestion des identités Google pour chaque employé peut s'avérer fastidieuse lorsque tous les employés disposent déjà d'un compte auprès d'un IdP. En fédérant les identités des utilisateurs entre votre IdP et Google Cloud, vous pouvez automatiser la gestion des comptes Google et lier leur cycle de vie aux comptes existants. La fédération contribue à garantir les éléments suivants :

  • Votre IdP reste la source unique de vérité pour la gestion des identités.
  • Un compte Google est créé automatiquement pour chacun des comptes utilisateur gérés par votre IdP ou pour un sous-ensemble de ces comptes.
  • Si un compte est désactivé ou supprimé dans votre IdP, le compte Google correspondant est également suspendu ou supprimé.
  • Pour empêcher la copie des mots de passe et autres informations d'identification, l'acte d'authentification d'un utilisateur est délégué à votre IdP.

Fédérer Active Directory avec Cloud Identity à l'aide de Google Cloud Directory Sync et AD FS

Si vous utilisez Active Directory en tant qu'IdP, vous pouvez fédérer Active Directory avec Cloud Identity à l'aide de Google Cloud Directory Sync (GCDS) et des services AD FS (Active Directory Federation Services):

  • GCDS est un outil gratuit fourni par Google qui met en œuvre le processus de synchronisation. GCDS communique avec Identity Platform via SSL (Secure Sockets Layer) et s'exécute généralement dans l'environnement informatique existant.
  • AD FS est fourni par Microsoft dans le cadre de Windows Server. AD FS vous permet d'utiliser Active Directory pour l'authentification fédérée. AD FS s'exécute généralement dans l'environnement informatique existant.

Pour en savoir plus sur cette approche, consultez la page Fédérer Google Cloud avec Active Directory.

Modèle: Fédérer Active Directory avec Cloud Identity à l'aide de GCDS et AD FS

Une variante de ce modèle consiste à utiliser les services AD LDS (Active Directory Lightweight Directory Services), ou un autre annuaire LDAP associé à AD FS ou à un autre IdP compatible SAML.

Expérience utilisateur

  1. Lorsque vous demandez l'accès à une ressource protégée, vous êtes redirigé vers l'écran de connexion Google, qui vous invite à saisir votre adresse e-mail.
  2. Si l'adresse e-mail est associée à un compte synchronisé à partir d'Active Directory, vous êtes redirigé vers AD FS.
  3. Suivant la configuration d'AD FS, un écran de connexion peut vous demander de saisir votre nom d'utilisateur et votre mot de passe Active Directory. AD FS peut également tenter de vous connecter automatiquement sur la base de vos informations de connexion Windows (IWA).
  4. Une fois qu'AD FS vous a authentifié, vous êtes redirigé vers la ressource protégée.

Avantages

  • Cette approche permet une authentification unique pour toutes les applications sur site et les ressources sur Google Cloud.
  • Si vous avez configuré AD FS pour exiger une authentification à plusieurs facteurs, cette configuration s'applique automatiquement à Google Cloud.
  • Vous n'avez pas besoin de synchroniser les mots de passe et autres identifiants avec Google.
  • L'API Cloud Identity étant accessible au public, il n'est pas nécessaire de configurer une connectivité hybride entre votre réseau sur site et Google Cloud.

Bonnes pratiques

  • Active Directory et Cloud Identity exploitent des structures logiques différentes. Assurez-vous de bien comprendre les différences et de déterminer la méthode qui convient le mieux à votre situation pour mapper les domaines, les identités et les groupes. Pour en savoir plus, consultez notre guide Fédérer Google Cloud avec Active Directory.
  • Synchronisez les groupes en plus des utilisateurs. Cette approche vous permet de configurer IAM afin d'exploiter l'appartenance à des groupes dans Active Directory pour contrôler qui a accès aux ressources dans Google Cloud.
  • Déployez et exposez AD FS afin que les utilisateurs d'entreprise puissent y accéder, mais veillez à ne pas l'exposer plus que nécessaire. Bien que les utilisateurs d'entreprise doivent pouvoir accéder à AD FS, il n'est pas nécessaire que ce composant soit accessible depuis Google ou par les applications déployées sur Google Cloud.
  • Envisagez d'activer l'authentification IWA (Integrated Windows Authentication ou authentification Windows intégrée) dans AD FS pour permettre aux utilisateurs de se connecter automatiquement sur la base de leurs identifiants Windows.
  • Si AD FS devient indisponible, les utilisateurs risquent de ne pas pouvoir utiliser la console Google Cloud ou toute autre ressource utilisant Google comme fournisseur d'identité. Par conséquent, assurez-vous qu'AD FS et les contrôleurs de domaine utilisés sont déployés et dimensionnés pour répondre à vos objectifs de disponibilité.
  • Si vous utilisez Google Cloud en tant que copie indépendante de votre déploiement afin d'assurer la continuité de votre activité, exploiter un service AD FS peut aller à l'encontre de cet objectif. Dans ce cas, envisagez plutôt de déployer des instances dupliquées de tous les systèmes pertinents sur Google Cloud :
    • Répliquez votre Active Directory sur Google Cloud et déployez GCDS pour qu'il s'exécute sur Google Cloud.
    • Exécutez des serveurs AD FS dédiés sur Google Cloud. Ces serveurs utilisent les contrôleurs de domaine Active Directory exécutés sur Google Cloud.
    • Configurez Cloud Identity pour utiliser les serveurs AD FS déployés sur Google Cloud pour l'authentification unique.

Fédérer Azure AD avec Cloud Identity

Si vous êtes un client Microsoft Office 365 ou Azure, vous avez peut-être connecté vos services Active Directory sur site à Azure AD. Si tous les comptes utilisateur susceptibles de nécessiter l'accès à Google Cloud sont déjà synchronisés avec Azure AD, vous pouvez réutiliser cette intégration en fédérant Cloud Identity avec Azure AD, comme illustré par le modèle suivant.

Fédérer Cloud Identity avec Azure AD

Pour en savoir plus sur cette approche, consultez la page Fédérer Google Cloud avec Azure Active Directory.

Expérience utilisateur

  1. Lorsque vous demandez l'accès à une ressource protégée, vous êtes redirigé vers l'écran de connexion Google, qui vous invite à saisir votre adresse e-mail.
  2. Si l'adresse e-mail est associée à un compte synchronisé à partir d'Azure AD, vous êtes redirigé vers Azure AD.
  3. Suivant la manière dont votre annuaire Active Directory sur site est connecté à Azure AD, Azure AD peut vous demander un nom d'utilisateur et un mot de passe. Il peut également vous rediriger vers un service AD FS sur site.
  4. Une fois qu'Azure AD vous a authentifié, vous êtes redirigé vers la ressource protégée.

Avantages

  • Vous n'avez pas besoin d'installer de logiciels supplémentaires sur site.
  • Cette approche permet d'utiliser une authentification unique sur Office 365, Azure et les ressources sur Google Cloud.
  • Si vous avez configuré Azure AD pour exiger une authentification multifacteur (MFA), cette configuration s'applique automatiquement à Google Cloud.
  • Si votre annuaire Active Directory sur site utilise plusieurs domaines ou forêts et que vous avez mis en place une configuration personnalisée Azure AD Connect pour mapper cette structure vers un locataire Azure AD, vous pouvez tirer parti de ce travail d'intégration.
  • Vous n'avez pas besoin de synchroniser les mots de passe et autres identifiants avec Google.
  • L'API Cloud Identity étant accessible au public, il n'est pas nécessaire de configurer une connectivité hybride entre votre réseau sur site ou Azure et Google Cloud.
  • Vous pouvez afficher la console Google Cloud en tant que vignette dans le portail Office 365.

Bonnes pratiques

  • Comme Azure AD et Cloud Identity exploitent des structures logiques différentes, assurez-vous de bien comprendre les différences. Déterminez la méthode de mappage de domaines, d'identités et de groupes la plus adaptée à votre situation. Pour plus de précisions consultez la page Fédérer Google Cloud avec Azure AD.
  • Synchronisez les groupes en plus des utilisateurs. Cette approche vous permet de configurer IAM afin d'exploiter l'appartenance à des groupes dans Azure AD pour contrôler qui a accès aux ressources dans Google Cloud.
  • Si vous utilisez Google Cloud en tant que copie indépendante de votre déploiement existant afin d'assurer la continuité de votre activité, l'exploitation d'Azure AD pour l'authentification peut aller à l'encontre de cet objectif.

Modèles permettant d'étendre un fournisseur d'identité externe vers Google Cloud

Certaines des applications que vous prévoyez de déployer sur Google Cloud peuvent nécessiter l'utilisation de protocoles d'authentification non fournis par Cloud Identity. Pour gérer ces charges de travail, vous devez autoriser ces applications à utiliser votre IdP depuis Google Cloud.

Les sections suivantes décrivent les modèles courants permettant aux charges de travail déployées sur Google Cloud d'utiliser votre IdP :

Exposer un service AD FS sur site à Google Cloud

Si une application nécessite l'utilisation de WS-Trust ou de WS-Federation, ou repose sur des fonctionnalités ou des revendications spécifiques à AD FS pour l'utilisation d'OpenID Connect, vous pouvez autoriser l'application à utiliser directement AD FS pour l'authentification.

Application utilisant directement AD FS pour l'authentification.

Une application peut authentifier un utilisateur à l'aide d'AD FS. Cependant, l'authentification n'étant pas basée sur une identité Google, l'application ne sera pas en mesure d'effectuer des appels d'API authentifiés avec des identifiants utilisateur. Au lieu de cela, tout appel aux API Google Cloud doit être authentifié à l'aide d'un compte de service.

Expérience utilisateur

  1. Lorsque vous demandez l'accès à une ressource protégée, vous êtes redirigé vers l'écran de connexion AD FS, qui vous invite à saisir votre adresse e-mail. Si AD FS n'est pas exposé de manière publique sur Internet, l'accès à AD FS peut nécessiter que vous soyez connecté au réseau de votre entreprise ou à un VPN d'entreprise.
  2. Suivant la configuration d'AD FS, un écran de connexion peut vous demander de saisir votre nom d'utilisateur et votre mot de passe Active Directory. AD FS peut également tenter de vous connecter automatiquement sur la base de vos informations de connexion Windows.
  3. Une fois qu'AD FS vous a authentifié, vous êtes redirigé vers la ressource protégée.

Avantages

  • Vous pouvez utiliser des protocoles d'authentification qui ne sont pas gérés dans Cloud Identity, en particulier WS-Trust et WS-Federation.
  • Si l'application a été développée et testée avec AD FS, vous pouvez ainsi éviter les problèmes susceptibles de survenir suite au passage à Cloud Identity.
  • Il n'est pas nécessaire de configurer une connectivité hybride entre votre réseau sur site et Google Cloud.

Bonnes pratiques

  • Déployez et exposez AD FS afin que les utilisateurs d'entreprise puissent y accéder, mais veillez à ne pas l'exposer plus que nécessaire. Bien que les utilisateurs d'entreprise doivent pouvoir accéder à AD FS, il n'est pas nécessaire que ce composant soit accessible depuis Google ou par les applications déployées sur Google Cloud.
  • En cas d'indisponibilité d'AD FS, les utilisateurs peuvent ne plus être en mesure d'utiliser l'application. Veillez donc à ce que les services AD FS et les contrôleurs de domaine sur lesquels AD FS s'appuie soient déployés et dimensionnés pour répondre à vos objectifs de disponibilité.
  • Envisagez de refactoriser les applications qui s'appuient sur WS-Trust et WS-Federation pour qu'elles utilisent plutôt SAML ou OpenID Connect.
  • Si l'application exploite les informations de groupe exposées sous la forme de revendications dans des jetons IdTokens émis par AD FS, envisagez de récupérer ces informations de groupe depuis une autre source telle que l'API Directory. Interroger l'API Directory est une opération demandant des privilèges, qui nécessite d'utiliser un compte de service activé pour la délégation au niveau du domaine Google Workspace.

Exposer un annuaire LDAP sur site à Google Cloud

Certaines de vos applications peuvent exiger que les utilisateurs fournissent leur nom d'utilisateur et leur mot de passe, afin d'exploiter ces informations d'identification pour tenter une opération de liaison LDAP. Si vous ne pouvez pas modifier ces applications pour utiliser d'autres méthodes (par exemple SAML) pour réaliser l'authentification, vous pouvez leur accorder l'accès à un annuaire LDAP sur site.

Accorder aux utilisateurs l'accès à un annuaire LDAP sur site

Avantages

  • Vous n'avez pas besoin de modifier votre application.

Bonnes pratiques

  • Utilisez Cloud VPN ou Cloud Interconnect pour établir une connectivité hybride entre Google Cloud et votre réseau sur site, sans avoir à exposer l'annuaire LDAP sur Internet.
  • Vérifiez que la latence introduite par l'interrogation d'un annuaire LDAP sur site n'a pas d'impact négatif sur l'expérience utilisateur.
  • Assurez-vous que la communication entre l'application et l'annuaire LDAP est chiffrée. Vous pouvez réaliser ce chiffrement à l'aide de Cloud VPN ou de Cloud Interconnect avec LDAP/S.
  • En cas d'indisponibilité de l'annuaire LDAP ou de la connexion privée entre Google Cloud et votre réseau sur site, les utilisateurs risquent de ne plus pouvoir utiliser une application basée sur LDAP. Par conséquent, assurez-vous que les serveurs respectifs sont déployés et dimensionnés pour répondre à vos objectifs de disponibilité, et envisagez d'utiliser des redondances au niveau des tunnels VPN ou des interconnexions.
  • Si vous utilisez Google Cloud en tant que copie indépendante de votre déploiement existant afin d'assurer la continuité de votre activité, exploiter un annuaire LDAP sur site peut aller à l'encontre de cet objectif. Dans ce cas, envisagez plutôt de dupliquer l'annuaire LDAP vers Google Cloud.
  • Si vous utilisez Active Directory, envisagez plutôt d'exécuter une instance dupliquée sur Google Cloud, en particulier si vous envisagez de joindre au domaine des machines Windows exécutées sur Google Cloud vers Active Directory.

Dupliquer un annuaire LDAP sur site sur Google Cloud

La duplication d'un annuaire LDAP sur site sur Google Cloud utilise le même modèle que celui utilisé pour exposer un annuaire LDAP sur site sur Google Cloud. L'objectif de cette approche est de permettre l'exécution sur Google Cloud des applications qui vérifient les noms d'utilisateur et les mots de passe via LDAP. Au lieu de permettre à ces applications d'interroger votre annuaire LDAP sur site, vous pouvez conserver une instance dupliquée de l'annuaire sur site sur Google Cloud.

Gérer une instance dupliquée d'annuaire sur site sur Google Cloud

Avantages

  • Vous n'avez pas besoin de modifier votre application.
  • La disponibilité des applications LDAP exécutées sur Google Cloud ne dépend pas de la disponibilité de l'annuaire sur site ni de la connectivité au réseau sur site. Ce modèle est particulièrement adapté aux scénarios de continuité d'activité hybride.

Bonnes pratiques

  • Utilisez Cloud VPN ou Cloud Interconnect pour établir une connectivité hybride entre Google Cloud et votre réseau sur site, sans avoir à exposer l'annuaire LDAP sur Internet.
  • Assurez-vous que la réplication de l'annuaire LDAP sur site s'effectue sur un canal chiffré.
  • Déployez plusieurs instances dupliquées de l'annuaire LDAP dans différentes zones ou régions pour répondre à vos objectifs de disponibilité. Vous pouvez utiliser un équilibreur de charge interne pour répartir les connexions LDAP entre les différentes instances dupliquées déployées dans la même région.
  • Utilisez un projet Google Cloud distinct avec un VPC partagé pour déployer les instances LDAP dupliquées et accordez l'accès à ce projet suivant le principe du moindre privilège.

Étendre un service Active Directory sur site à Google Cloud

Certaines des charges de travail que vous prévoyez de déployer sur Google Cloud peuvent dépendre des services de domaine Active Directory, par exemple :

  • des ordinateurs Windows devant être associés à un domaine ;
  • des applications utilisant Kerberos ou NTLM pour l'authentification ;
  • des applications utilisant Active Directory comme annuaire LDAP pour vérifier les noms d'utilisateur et les mots de passe.

Pour gérer ces charges de travail, vous pouvez étendre votre forêt Active Directory locale à Google Cloud en y déployant une forêt de ressources à connecter, ensuite, à votre forêt Active Directory locale.

Associer une forêt de ressources à votre forêt Active Directory sur site

Pour obtenir plus de détails sur cette approche et découvrir d'autres manières de déployer Active Directory dans un environnement hybride, consultez la page Modèles d'utilisation d'Active Directory dans un environnement hybride.

Étendre votre forêt Active Directory sur site à Google Cloud en y déployant des contrôleurs de domaine supplémentaires

Avantages

  • Vos charges de travail peuvent tirer pleinement parti d'Active Directory, y compris la possibilité d'associer des machines Windows au domaine Active Directory.
  • La disponibilité des applications Active Directory s'exécutant sur Google Cloud ne dépend pas de la disponibilité des ressources locales ni de la connectivité au réseau sur site. Ce modèle est particulièrement adapté aux scénarios de continuité d'activité hybride.

Bonnes pratiques

  • Utilisez Cloud VPN ou Cloud Interconnect pour établir une connectivité hybride entre Google Cloud et votre réseau sur site.
  • Pour réduire les communications entre Google Cloud et votre réseau sur site, créez un site Active Directory distinct pour les déploiements Google Cloud. Vous pouvez utiliser un seul site par VPC partagé ou, pour réduire les communications entre régions, un seul site par VPC partagé et par région.
  • Créez un domaine Active Directory distinct dédié aux ressources déployées sur Google Cloud et ajoutez ce domaine à la forêt existante. L'utilisation d'un domaine distinct permet de réduire la charge de duplication et la taille des partitions.
  • Pour augmenter la disponibilité, déployez au moins deux contrôleurs de domaine répartis sur plusieurs zones. Si vous utilisez plusieurs régions, envisagez de déployer des contrôleurs de domaine dans chaque région.
  • Utilisez un projet Google Cloud distinct avec un VPC partagé pour déployer les contrôleurs de domaine, puis accordez l'accès à ce projet suivant le principe du moindre privilège. Des personnes malveillantes au sein de votre projet peuvent compromettre le domaine si elles sont autorisées à générer un mot de passe ou à accéder à la console série des instances de contrôleur de domaine.
  • Envisagez de déployer une ferme de serveurs AD FS et GCDS sur Google Cloud. Cette approche vous permet de fédérer Active Directory avec Cloud Identity sans dépendre de la disponibilité des ressources ou de la connectivité au réseau sur site.

Étape suivante