Ce document présente des architectures types que vous pouvez utiliser comme référence pour gérer des identités d'entreprise. Les deux principes fondamentaux de la gestion des identités d'entreprise sont les suivants :
Une source faisant autorité pour les identités qui est le seul système que vous utilisez pour créer, gérer et supprimer les identités de vos employés. Les identités gérées dans le système source faisant autorité peuvent être propagées dans d'autres systèmes.
Un fournisseur d'identité (IdP) central qui est le seul système d'authentification et qui offre à vos employés une expérience d'authentification unique couvrant l'ensemble des applications.
Lorsque vous utilisez Google Cloud ou d'autres services Google, vous devez choisir le système à utiliser en tant que fournisseur d'identité et le système à utiliser en tant que source fiable.
Utiliser Google comme fournisseur d'identité
En utilisant Cloud Identity Premium ou Google Workspace, vous pouvez définir Google comme fournisseur d'identité principal. Google propose une large gamme d'intégrations prêtes à être utilisées pour les applications tierces populaires. Vous pouvez également utiliser des protocoles standards tels que SAML, OAuth et OpenID Connect pour intégrer vos applications personnalisées.
Google en tant que fournisseur d'identité et source faisant autorité
Vous pouvez utiliser Cloud Identity Premium ou Google Workspace comme fournisseur d'identité et source faisant autorité, comme le montre le schéma suivant.
- Vous utilisez Cloud Identity Premium ou Google Workspace pour gérer les utilisateurs et les groupes.
- Tous les services Google utilisent Cloud Identity Premium ou Google Workspace comme fournisseur d'identité.
- Vous configurez des applications d'entreprise et d'autres services SaaS pour utiliser Google en tant que fournisseur d'identité.
Expérience utilisateur
Dans cette configuration, pour un employé, l'expérience utilisateur de connexion ressemble à ce qui suit :
- Lorsqu'il demande une ressource protégée ou un accès à une application d'entreprise, l'employé est redirigé vers l'écran Google Sign-In, qui lui demande son adresse e-mail et son mot de passe.
- Si la validation en deux étapes est activée, l'employé est invité à fournir un deuxième facteur, tel qu'un code ou une clé USB.
- Lorsque l'employé est authentifié, il est redirigé vers la ressource protégée.
Avantages
L'utilisation de Google comme fournisseur d'identité et source faisant autorité présente les avantages suivants :
- Vous pouvez tirer pleinement parti des fonctionnalités d'authentification multifacteur et de gestion des appareils mobiles de Google.
- Vous n'avez pas besoin d'un fournisseur d'identité supplémentaire, ce qui peut vous faire économiser de l'argent.
Quand utiliser cette architecture
Envisagez d'utiliser Google comme fournisseur d'identité et comme source fiable dans les scénarios suivants :
- Vous utilisez déjà Google Workspace comme solution de collaboration et de productivité.
- Il n'y a pas d'infrastructure sur site ou de fournisseur d'identité que vous devez intégrer ou séparer de toutes vos ressources sur Google (dans Google Cloud, Google Ads, etc.).
- Vous n'avez pas besoin d'une intégration à un système d'information de gestion des ressources humaines (SIRH) pour gérer les identités.
Google en tant que fournisseur d'identité avec un SIRH comme source faisant autorité
Si vous utilisez un système d'information de gestion des ressources humaines (SIRH) pour gérer le processus d'intégration et de départ de vos employés, vous pouvez tout de même utiliser Google comme fournisseur d'identité. Cloud Identity et Google Workspace fournissent des API qui permettent au SIRH et à d'autres systèmes de prendre le contrôle de la gestion des utilisateurs et des groupes, comme illustré dans le schéma suivant.
- Vous utilisez votre SIRH existant pour gérer les utilisateurs et éventuellement les groupes. Le SIRH reste la source fiable unique pour la gestion des identités et gère automatiquement les utilisateurs pour Cloud Identity ou Google Workspace.
- Tous les services Google utilisent Cloud Identity Premium ou Google Workspace comme fournisseur d'identité.
- Vous configurez des applications d'entreprise et d'autres services SaaS pour utiliser Google en tant que fournisseur d'identité.
Expérience utilisateur
Pour un employé, l'expérience de connexion équivaut à utiliser Google en tant que fournisseur d'identité et source faisant autorité.
Avantages
L'utilisation de Google comme fournisseur d'identité et source faisant autorité présente les avantages suivants :
- Vous pouvez réduire la charge administrative en réutilisant vos flux de travail SIRH existants.
- Vous pouvez tirer pleinement parti des fonctionnalités d'authentification multifacteur et de gestion des appareils mobiles de Google.
- Vous n'avez pas besoin d'un fournisseur d'identité supplémentaire, ce qui peut vous faire économiser de l'argent.
Quand utiliser cette architecture
Envisagez d'utiliser Google en tant que fournisseur d'identité avec un SIRH comme source faisant autorité dans les scénarios suivants :
- Vous disposez d'un système SIRH ou d'un autre système qui sert de source faisant autorité pour les identités.
- Vous utilisez déjà Google Workspace comme solution de collaboration et de productivité.
- Il n'y a pas d'infrastructure sur site ou fournisseur d'identité que vous devez intégrer ou séparer de votre domaine Google.
Utiliser un fournisseur d'identité externe
Si votre organisation utilise déjà un fournisseur d'identité tel qu'Active Directory, Azure AD, ForgeRock, Okta ou Ping Identity, vous pouvez intégrer Google Cloud à ce fournisseur d'identité externe via la fédération.
En fédérant un compte Cloud Identity ou Google Workspace avec un fournisseur d'identité externe, vous pouvez permettre aux employés d'utiliser leur identité et leurs identifiants existants pour se connecter aux services Google tels que Google Cloud, Google Marketing Platform et Google Ads.
IDaaS externe en tant que fournisseur d'identité et source faisant autorité
Si vous utilisez un fournisseur IDaaS (Identity as a Service) tel que ForgeRock, Okta ou Ping Identity, vous pouvez configurer la fédération comme illustré dans le schéma suivant.
- Cloud Identity ou Google Workspace utilise votre IDaaS comme fournisseur d'identité pour l'authentification unique.
- L'IDaaS provisionne automatiquement les utilisateurs et les groupes pour Cloud Identity ou Google Workspace.
- Les applications d'entreprise existantes et les autres services SaaS peuvent continuer à utiliser votre IDaaS en tant que fournisseur d'identité.
Pour en savoir plus sur la fédération de Cloud Identity ou de Google Workspace avec Okta, consultez la page Provisionnement des utilisateurs et authentification unique Okta.
Expérience utilisateur
Pour un employé, l'expérience de connexion ressemble à ceci :
- Lorsqu'il demande une ressource protégée, il est redirigé vers l'écran Google Sign-In, qui lui demande son adresse e-mail et son mot de passe.
- Google Sign-In vous redirige vers la page de connexion de votre IDaaS.
- Vous vous authentifiez avec votre IDaaS. Selon votre IDaaS, vous devrez peut-être fournir un deuxième facteur, tel qu'un code.
- Une fois authentifié, vous êtes redirigé vers la ressource protégée.
Avantages
L'utilisation d'un IDaaS externe comme fournisseur d'identité et source faisant autorité présente les avantages suivants :
- Vous offrez à vos employés une expérience d'authentification unique, qui s'applique aux services Google et aux autres applications intégrées à votre IDaaS.
- Si vous avez configuré votre IDaaS pour exiger une authentification multifacteur, cette configuration s'applique automatiquement à Google Cloud.
- Vous n'avez pas besoin de synchroniser vos mots de passe ni vos autres identifiants avec Google.
- Vous pouvez utiliser la version gratuite de Cloud Identity.
Quand utiliser cette architecture
Envisagez d'utiliser un IDaaS externe comme fournisseur d'identité et source faisant autorité dans les scénarios suivants :
- Vous utilisez déjà un fournisseur IDaaS tel que ForgeRock, Okta ou Ping Identity comme fournisseur d'identité.
Bonnes pratiques
Consultez les bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.
Active Directory en tant que fournisseur d'identité et source faisant autorité
Si vous utilisez Active Directory en tant que source fiable pour la gestion des identités, vous pouvez configurer la fédération comme illustré dans le schéma suivant.
- Vous utilisez Google Cloud Directory Sync (GCDS) pour gérer automatiquement les utilisateurs et les groupes depuis Active Directory pour Cloud Identity ou Google Workspace. Google Cloud Directory Sync est un outil gratuit fourni par Google qui met en œuvre le processus de synchronisation et peut être exécuté sur Google Cloud ou dans votre environnement sur site. La synchronisation est à sens unique, de sorte qu'Active Directory reste la source fiable.
- Cloud Identity ou Google Workspace utilisent les services AD FS (Active Directory Federation Services) pour l'authentification unique.
- Les applications d'entreprise existantes et les autres services SaaS peuvent continuer à utiliser votre AD FS en tant que fournisseur d'identité.
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 fournisseur d'identité compatible SAML.
Pour en savoir plus sur cette approche, consultez la page Fédérer Google Cloud avec Active Directory.
Expérience utilisateur
- Lorsqu'il demande une ressource protégée, l'employé est redirigé vers l'écran Google Sign-In, qui lui demande son adresse e-mail.
- Google Sign-In redirige l'employé vers la page de connexion d'AD FS.
- Selon la configuration d'AD FS, l'employé peut voir un écran de connexion lui demandant son nom d'utilisateur et son mot de passe Active Directory. AD FS peut également tenter de connecter l'employé automatiquement sur la base de ses identifiants Windows.
- Une fois qu'AD FS a authentifié l'employé, il est redirigé vers la ressource protégée.
Avantages
L'utilisation d'Active Directory en tant que fournisseur d'identité et source faisant autorité présente les avantages suivants :
- Vous offrez à vos employés une expérience d'authentification unique, qui s'applique aux services Google et à votre environnement sur site.
- Si vous avez configuré AD FS pour exiger une authentification multifacteur, cette configuration s'applique automatiquement à Google Cloud.
- Vous n'avez pas besoin de synchroniser les mots de passe et autres identifiants avec Google.
- Vous pouvez utiliser la version gratuite de Cloud Identity.
- Étant donné que les API utilisées par GCDS sont accessibles au public, il n'est pas nécessaire de configurer une connectivité hybride entre votre réseau sur site et Google Cloud.
Quand utiliser cette architecture
Envisagez d'utiliser Active Directory en tant que fournisseur d'identité et source faisant autorité dans les scénarios suivants :
- Vous disposez déjà d'une infrastructure Active Directory.
- Vous souhaitez offrir une expérience de connexion fluide aux utilisateurs de Windows.
Bonnes pratiques
Tenez compte des bonnes pratiques suivantes :
- Active Directory et Cloud Identity exploitent des structures logiques différentes. Assurez-vous de bien comprendre les différences et déterminez la méthode de mappage des domaines, des identités et des groupes la mieux adaptée à votre situation. Pour en savoir plus, consultez notre guide sur la fédération de 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 à des ressources spécifiques 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 aux services AD FS, rien n'oblige ces services à être accessibles depuis Cloud Identity ou Google Workspace, ou même depuis toute application déployée 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 Google Cloud Console 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 de déployer des instances dupliquées de tous les systèmes pertinents sur Google Cloud de l'une des manières suivantes :
- Étendez votre domaine Active Directory existant à 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 qui s'exécutent sur Google Cloud.
- Configurez Cloud Identity pour utiliser les serveurs AD FS déployés sur Google Cloud pour l'authentification unique.
Pour en savoir plus, consultez la page Bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.
Azure AD en tant que fournisseur d'identité avec Active Directory comme source faisant autorité
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 l'illustre le schéma suivant.
- Vous utilisez Azure AD pour gérer automatiquement les utilisateurs et les groupes dans Cloud Identity ou Google Workspace. Azure AD lui-même peut être intégré à Active Directory sur site.
- Cloud Identity ou Google Workspace utilise Azure AD pour l'authentification unique.
- Les applications d'entreprise existantes et les autres services SaaS peuvent continuer à utiliser Azure AD en tant que fournisseur d'identité.
Pour en savoir plus sur cette approche, consultez la page Fédérer Google Cloud avec Azure Active Directory.
Expérience utilisateur
- Lorsqu'il demande une ressource protégée, l'employé est redirigé vers l'écran Google Sign-In, qui lui demande son adresse e-mail.
- Google Sign-In le redirige vers la page de connexion d'AD FS.
- Suivant la manière dont son annuaire Active Directory sur site est connecté à Azure AD, Azure AD peut lui demander un nom d'utilisateur et un mot de passe, ou le rediriger vers un AD FS sur site.
- Une fois authentifié, l'employé est redirigé vers la ressource protégée.
Avantages
L'utilisation d'Azure AD en tant que fournisseur d'identité avec Active Directory comme source faisant autorité présente plusieurs avantages :
- Vous offrez à vos employés une expérience d'authentification unique, qui s'applique aux services Google, à Azure et à votre environnement sur site.
- Si vous avez configuré Azure AD pour exiger une authentification multifacteur, cette configuration s'applique automatiquement à Google Cloud.
- Vous n'avez pas besoin d'installer de logiciels supplémentaires sur site.
- 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.
- Vous pouvez utiliser la version gratuite de Cloud Identity.
- Vous pouvez afficher la console Google Cloud en tant que vignette dans le portail Office 365.
- Étant donné que les API utilisées par Azure AD sont accessibles au public, il n'est pas nécessaire de configurer une connectivité hybride entre Azure et Google Cloud.
Quand utiliser cette architecture
Envisagez d'utiliser Azure AD en tant que fournisseur d'identité avec Active Directory comme source faisant autorité dans les scénarios suivants :
- Vous utilisez déjà Azure AD et l'avez intégré à une infrastructure Active Directory existante.
- Vous souhaitez offrir une expérience de connexion fluide aux utilisateurs d'Azure et de Google Cloud.
Bonnes pratiques
Appliquez les bonnes pratiques suivantes :
- 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 à des ressources spécifiques 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.
Pour en savoir plus, consultez la page Bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.
Étape suivante
- En savoir plus sur la fédération avec Active Directory
- Découvrez comment configurer la fédération avec Azure AD.
- Consultez les bonnes pratiques pour planifier des comptes et des organisations ainsi que les bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.