Si vous envisagez de fédérer Cloud Identity ou Google Workspace avec un fournisseur d'identité externe, mais que vous devez malgré tout consolider des comptes personnels, ce document vous aide à comprendre et à évaluer l'interaction entre la fédération et la consolidation. Il vous explique également comment configurer la fédération sans gêner votre capacité à regrouper les comptes personnels existants.
Interaction entre la fédération et le regroupement des comptes utilisateur
Dans une configuration fédérée, vous connectez Cloud Identity ou Google Workspace à une source externe faisant autorité afin que celle-ci puisse provisionner automatiquement des comptes utilisateur dans Cloud Identity ou Google Workspace.
Les règles invariantes suivantes s'appliquent généralement à une configuration fédérée :
- La source faisant autorité est la seule source pour les identités.
- Il n'existe aucun compte utilisateur dans Cloud Identity ou Google Workspace autre que ceux provisionnés par la source faisant autorité.
- Le fournisseur d'identité SAML ne permet pas aux identités pour lesquelles la source faisant autorité n'a pas provisionné les comptes utilisateur d'employer l'authentification unique Google.
Bien que ces règles invariantes reflètent les bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe, elles s'avèrent problématiques lorsque vous souhaitez migrer des comptes personnels existants :
- Les comptes personnels existants ne proviennent pas de la source faisant autorité. Ces comptes existent déjà et doivent être associés à une identité connue de la source faisant autorité.
- Une fois migrés vers Cloud Identity ou Google Workspace, les comptes personnels existants sont identifiés comme des comptes utilisateur qui n'ont pas été provisionnés par la source faisant autorité. La source faisant autorité doit reconnaître et "adopter" ces comptes migrés.
- Les identités des comptes personnels existants peuvent être inconnues du fournisseur d'identité SAML, mais elles doivent tout de même être autorisées à utiliser l'authentification unique.
Pour pouvoir regrouper les comptes personnels existants, vous devez configurer temporairement la fédération de manière sécurisée pour le regroupement des comptes.
Sécuriser la fédération pour le regroupement des comptes
Le tableau suivant répertorie les exigences à prendre en compte afin de sécuriser la fédération pour le regroupement des comptes. Si vous prévoyez d'utiliser un fournisseur d'identité externe, mais que vous devez encore regrouper les comptes personnels existants, assurez-vous que votre configuration répond initialement à ces exigences. Une fois la migration des comptes personnels existants terminée, vous êtes libre de modifier la configuration, car les exigences ne s'appliquent plus.
| Exigence | Justification |
|---|---|
| Autoriser l'authentification unique pour les identités avec des comptes personnels | La migration d'un compte personnel nécessite un transfert de compte. Un administrateur Cloud Identity ou Google Workspace peut initier ce transfert, mais le propriétaire du compte personnel doit donner son accord pour que le transfert de compte soit effectué. En tant qu'administrateur, vous disposez d'un contrôle limité sur le moment où le consentement sera exprimé et, par conséquent, sur le moment du transfert.
Une fois que le propriétaire a donné son accord et que le transfert s'est achevé, toutes les connexions sont soumises à une authentification unique via votre fournisseur d'identité externe. Quel que soit le moment où le transfert se termine, pour que l'authentification unique réussisse, vous devez vous assurer que votre fournisseur d'identité externe autorise l'authentification unique pour les identités de tous les comptes personnels que vous prévoyez de migrer. |
| Empêcher le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels | Si vous provisionnez un compte utilisateur pour une identité qui possède déjà un compte personnel, vous créez un compte en conflit. Un compte en conflit vous empêche de transférer la propriété du compte personnel, sa configuration, ainsi que les données associées à Cloud Identity ou Google Workspace.
Le comportement par défaut de nombreux fournisseurs d'identité externes consiste à créer des comptes utilisateur de manière proactive dans Cloud Identity ou Google Workspace. Ce comportement peut entraîner la création accidentelle de comptes en conflit. En empêchant le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels existants, vous évitez de créer accidentellement des comptes en conflit et vous vous assurez que les comptes personnels peuvent être transférés correctement. |
Si vous avez identifié des comptes personnels sans identité correspondante dans le fournisseur d'identité externe, mais que vous les considérez légitimes et souhaitez les migrer vers Cloud Identity ou Google Workspace, vous devez vous assurer que votre configuration de la fédération ne gêne pas votre capacité à migrer ces comptes personnels.
| Exigence | Justification |
|---|---|
| Empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe | Si vous disposez d'un compte utilisateur dans Cloud Identity ou Google Workspace pour lequel aucune identité correspondante n'existe dans votre fournisseur d'identité externe, celui-ci peut considérer ce compte utilisateur comme orphelin et peut le suspendre ou le supprimer. En empêchant votre fournisseur d'identité externe de suspendre ou de supprimer les comptes migrés sans identité correspondante, vous évitez de perdre la configuration et les données associées aux comptes concernés, et vous vous assurez que vous pourrez rapprocher les comptes manuellement. |
Rendre la fédération Microsoft Entra ID (anciennement Azure AD) sécurisée pour le regroupement des comptes
Si vous envisagez de fédérer Cloud Identity ou Google Workspace avec Microsoft Entra ID (anciennement Azure AD), vous pouvez utiliser l'application de galerie Google Workspace.
Lorsque vous activez le provisionnement, Microsoft Entra ID ignore les comptes existants dans Cloud Identity ou Google Workspace qui n'ont pas d'homologue dans Microsoft Entra ID. Par conséquent, la condition pour empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe est toujours satisfaite.
Selon la façon dont vous configurez l'application de galerie, vous devez toujours veiller à effectuer les opérations suivantes :
- Autorisez l'authentification unique pour les identités avec des comptes personnels.
- Empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Il existe plusieurs façons de répondre à ces exigences, chacune présente des avantages et des inconvénients.
Méthode 1 : ne pas configurer la gestion des comptes
Avec cette méthode, vous configurez l'application de galerie pour traiter l'authentification unique, mais vous ne configurez pas le provisionnement automatique des utilisateurs. Ainsi, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Pour autoriser l'authentification unique pour les identités avec des comptes personnels, attribuez l'application à toutes les identités qui pourraient avoir besoin d'accéder aux services Google, même si leurs comptes personnels existants sont toujours susceptibles d'être migrés.
Pour un utilisateur disposant d'un compte personnel existant, le compte utilisateur Cloud Identity ou Google Workspace correspondant est créé automatiquement lorsque la demande de transfert est acceptée. Cet utilisateur peut alors utiliser immédiatement l'authentification unique.
Pour un utilisateur qui ne dispose pas de compte utilisateur dans Cloud Identity ou Google Workspace, vous devez en créer un manuellement.
Bien que cette méthode remplisse les conditions requises et soit la moins complexe à configurer, elle implique toutefois que les modifications d'attributs ou les suspensions d'utilisateurs effectuées dans Microsoft Entra ID ne seront pas répercutées dans Cloud Identity ou Google Workspace.
Méthode 2 : deux applications avec attribution manuelle
Cette méthode vous permet de contourner les limites liées à la création manuelle de comptes utilisateur dans Google Workspace ou Cloud Identity pour les utilisateurs qui n'en disposent pas. Elle consiste à utiliser deux applications de galerie, une pour la gestion des comptes et l'autre pour l'authentification unique :
- La première application sert exclusivement au provisionnement des utilisateurs et des groupes ; l'authentification unique est désactivée. En attribuant des utilisateurs à cette application, vous contrôlez les comptes provisionnés pour Cloud Identity ou Google Workspace.
- La deuxième application sert exclusivement à l'authentification unique et n'est pas autorisée à provisionner les utilisateurs. En lui attribuant des utilisateurs, vous contrôlez les utilisateurs autorisés à se connecter.
Pour attribuer des utilisateurs à l'aide de ces deux applications, procédez comme suit :
- Attribuez à l'application d'authentification unique toutes les identités qui auront besoin d'accéder aux services Google. Incluez les identités avec des comptes personnels existants afin d'autoriser l'authentification unique pour les identités avec des comptes personnels.
- Lors de l'attribution d'identités à l'application de gestion des comptes, incluez celles qui auront besoin d'accéder aux services Google, mais excluez toutes les identités qui possèdent un compte personnel existant. De cette façon, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Méthode 3 : deux applications avec création d'utilisateurs désactivée
Lorsque vous configurez le provisionnement, vous devez autoriser Microsoft Entra ID à accéder à Cloud Identity ou Google Workspace à l'aide d'un compte Cloud Identity ou Google Workspace. Normalement, il est préférable d'utiliser un compte super-administrateur dédié, car ces comptes sont exemptés de l'authentification unique. Comme ils ne sont pas concernés par la configuration SSO, ils continueront de se connecter à l'aide d'un mot de passe.
Toutefois, dans ce scénario, vous pouvez faire en sorte que Microsoft Entra ID utilise pour la migration un compte plus limité qui ne l'autorise pas à créer des utilisateurs. De cette façon, vous empêchez Azure de provisionner automatiquement des comptes utilisateur pour les identités avec des comptes personnels, quels que soient les utilisateurs affectés à l'application de gestion des comptes.
Un compte administrateur limité dans Cloud Identity ou Google Workspace ne doit disposer que des droits suivants :
- Unités organisationnelles > Lire
- Utilisateurs > Lire
- Utilisateurs > Mettre à jour
- Groupes
Un inconvénient de cette méthode est que vous devrez créer manuellement des comptes dans Cloud Identity ou Google Workspace pour les utilisateurs sans comptes non gérés.
Fédérer avec Microsoft Entra ID : comparaison
Le tableau suivant récapitule les différentes méthodes.
| Autoriser l'authentification unique pour les identités avec des comptes personnels | Empêcher le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels | Empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe | Provisionner automatiquement de nouveaux comptes | Mettre à jour automatiquement les comptes migrés | |
|---|---|---|---|---|---|
| Méthode 1 : sans la gestion des comptes | ✅ | ✅ | ✅ | X | X |
| Méthode 2 : deux applications avec attribution manuelle | ✅ | Sujet à des erreurs manuelles | ✅ | ✅ | ✅ |
| Méthode 3 : deux applications avec création d'utilisateurs désactivée | ✅ | ✅ | ✅ | X | ✅ |
Sécuriser la fédération Active Directory pour le compte
Si vous envisagez de fédérer Cloud Identity ou Google Workspace avec Active Directory, vous pouvez utiliser Google Cloud Directory Sync (GCDS) et des services AD FS (Active Directory Federation Services). Lorsque vous configurez GCDS et AD FS, vous devez effectuer les opérations suivantes :
- Autorisez l'authentification unique pour les identités avec des comptes personnels.
- Empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
- Empêchez la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe.
Il existe plusieurs façons de répondre à ces exigences, chacune présente des avantages et des inconvénients.
Méthode 1 : désactiver GCDS
Dans cette méthode, vous configurez l'authentification unique avec AD FS, mais vous n'activez pas GCDS tant que la migration des comptes utilisateur non gérés n'est pas terminée. En désactivant GCDS, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Pour autoriser l'authentification unique pour les identités avec des comptes personnels, créez une stratégie de contrôle d'accès personnalisée dans AD FS et attribuez-lui toutes les identités qui pourraient avoir besoin d'accéder aux services Google, même si leurs comptes personnels existants sont toujours susceptibles d'être migrés.
Pour un utilisateur disposant d'un compte personnel existant, le compte utilisateur Cloud Identity ou Google Workspace correspondant est créé automatiquement lorsque la demande de transfert est acceptée. Grâce à la stratégie de contrôle d'accès personnalisée, vous vous assurez que l'utilisateur peut immédiatement utiliser l'authentification unique.
Pour un utilisateur qui ne dispose pas de compte utilisateur dans Cloud Identity ou Google Workspace, vous devez en créer un manuellement.
Bien que cette méthode remplisse les conditions requises et soit la moins complexe à configurer, elle implique toutefois que les modifications d'attributs ou suspensions d'utilisateurs effectuées dans Active Directory ne seront pas répercutées dans Cloud Identity ou Google Workspace.
Méthode 2 : GCDS avec attribution manuelle
Cette méthode vous permet de contourner les limites liées à la création manuelle de comptes utilisateur dans Google Workspace ou Cloud Identity pour les utilisateurs qui n'en disposent pas :
À l'instar de la méthode 1, vous autorisez l'authentification unique pour les identités avec des comptes personnels en créant une stratégie de contrôle d'accès personnalisée dans AD FS et en lui attribuant toutes les identités qui pourraient avoir besoin d'accéder aux services Google, même si leurs comptes personnels existants sont toujours susceptibles d'être migrés.
Créez dans Active Directory un groupe qui reflète les comptes utilisateur que vous souhaitez provisionner automatiquement dans GCDS. Dans la liste des membres, incluez les identités qui auront besoin d'accéder aux services Google, mais excluez toutes celles possédant un compte personnel existant.
Configurez GCDS de façon à ne provisionner des comptes utilisateur que pour les identités membres de ce groupe. De cette façon, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Une limite importante de cette méthode est que vous ne pouvez pas empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe. Cette approche ne s'applique donc que si vous n'avez pas de comptes personnels sans identité correspondante dans le fournisseur d'identité externe.
Méthode 3 : empêcher GCDS de créer des utilisateurs
Lorsque vous configurez le provisionnement, vous devez autoriser GCDS à accéder à Cloud Identity ou à Google Workspace. En règle générale, il est préférable d'utiliser un compte super-administrateur dédié, car ces comptes sont exemptés de l'authentification unique. Comme ils ne sont pas concernés par la configuration SSO, ils continueront de se connecter à l'aide d'un mot de passe.
Toutefois, dans ce scénario, vous pouvez faire en sorte que GCDS utilise pour la migration un compte plus limité qui ne l'autorise pas à créer des utilisateurs. De cette façon, vous empêchez GCDS de provisionner automatiquement des comptes utilisateur pour les identités avec des comptes personnels et de supprimer les comptes migrés sans identité correspondante dans le fournisseur d'identité externe.
Un compte administrateur limité dans Cloud Identity ou Google Workspace ne doit disposer que des droits suivants :
- Unités organisationnelles
- Utilisateurs > Lire
- Utilisateurs > Mettre à jour
- Groupes
- Gestion des schémas
- Gestion de domaine
Un inconvénient de cette méthode est que vous devrez créer manuellement des comptes dans Cloud Identity ou Google Workspace pour les utilisateurs sans comptes non gérés.
Fédérer avec Active Directory : comparaison
Le tableau suivant récapitule les différentes méthodes.
| Autoriser l'authentification unique pour les identités avec des comptes personnels | Empêcher le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels | Empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe | Provisionner automatiquement de nouveaux comptes | Mettre à jour automatiquement les comptes migrés | |
|---|---|---|---|---|---|
| Méthode 1 : ne pas configurer la gestion des comptes | ✅ | ✅ | ✅ | X | X |
| Méthode 2 : GCDS avec attribution manuelle | ✅ | Sujet à des erreurs manuelles | X | ✅ | ✅ |
| Méthode 3 : empêcher GCDS de créer des utilisateurs | ✅ | ✅ | ✅ | X | ✅ |
Sécuriser la fédération Okta pour le regroupement des comptes
Pour fédérer Cloud Identity ou Google Workspace avec Okta, vous pouvez utiliser l'application Google Workspace à partir du catalogue d'applications Okta. Cette application peut gérer l'authentification unique et provisionner les utilisateurs et les groupes dans Cloud Identity ou Google Workspace.
Lorsque vous utilisez l'application Google Workspace pour le provisionnement, Okta ignore les utilisateurs existants dans Cloud Identity ou Google Workspace qui n'ont pas d'homologue dans Okta. Par conséquent, l'obligation d'empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe est toujours respectée.
Selon la façon dont vous configurez Okta, vous devez toujours effectuer les opérations suivantes :
- Autorisez l'authentification unique pour les identités avec des comptes personnels.
- Empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Il existe plusieurs façons de répondre à ces exigences, chacune présente des avantages et des inconvénients.
Méthode 1 : ne pas configurer la gestion des comptes
Cette méthode vous permet de configurer l'application Google Workspace pour permettre l'authentification unique, mais pas de configurer le provisionnement. Ainsi, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Pour autoriser l'authentification unique pour les identités avec des comptes personnels, attribuez l'application à toutes les identités qui pourraient avoir besoin d'accéder aux services Google, même si leurs comptes personnels existants sont toujours susceptibles d'être migrés. Les icônes Google Workspace ou Google Cloud apparaissent sur la page d'accueil Okta de toutes les identités attribuées à l'application. Toutefois, la connexion échouera sauf si un compte utilisateur correspondant existe du côté de Google.
Pour un utilisateur disposant d'un compte personnel existant, le compte utilisateur Cloud Identity ou Google Workspace correspondant est créé automatiquement lorsque la demande de transfert est acceptée. Cet utilisateur peut alors utiliser immédiatement l'authentification unique.
Bien que cette méthode remplisse les conditions requises et soit la moins complexe à configurer, elle implique toutefois que les modifications d'attributs ou suspensions d'utilisateurs effectuées dans Okta ne seront pas répercutées dans Cloud Identity ou Google Workspace. Un autre inconvénient est que, si des utilisateurs ne disposent pas de comptes personnels, vous devrez créer ces comptes manuellement dans Cloud Identity ou Google Workspace.
Méthode 2 : gestion de comptes avec attribution manuelle
Avec cette méthode, vous configurez l'application Google Workspace pour permettre l'authentification unique et le provisionnement, mais n'activez que les fonctionnalités de provisionnement suivantes :
- Créer des utilisateurs
- Mettre à jour les attributs utilisateur
- Désactiver des utilisateurs
Lorsque vous attribuez des identités à l'application, incluez celles qui auront besoin d'accéder aux services Google, mais excluez toutes celles possédant un compte personnel existant. De cette façon, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Dès qu'un utilisateur accepte une demande de transfert, vous attribuez cet utilisateur à l'application et lui permettez ainsi d'utiliser l'authentification unique et d'accéder à Google Workspace ou à Google Cloud.
Un inconvénient de cette méthode est que toute erreur d'attribution peut immédiatement entraîner la création de comptes en conflit, ce qui la rend sensiblement plus risquée que certaines des autres méthodes.
Un autre inconvénient de cette méthode est qu'elle provoque le verrouillage temporaire des comptes migrés. Après avoir accepté une demande de transfert, l'utilisateur doit effectuer toutes les connexions via Okta. Ces tentatives de connexion échoueront tant que vous n'aurez pas attribué l'utilisateur à l'application dans Okta.
Méthode 3 : gestion de comptes avec création d'utilisateurs désactivée
Avec cette méthode, vous configurez l'application Google Workspace pour permettre l'authentification unique et le provisionnement, mais n'activez que les fonctionnalités de provisionnement suivantes :
- Mettre à jour les attributs utilisateur
- Désactiver des utilisateurs
Laissez l'option Créer des utilisateurs désactivée et attribuez toutes les identités qui auront besoin d'accéder aux services Google à l'application. Incluez les identités avec des comptes personnels existants afin d'autoriser l'authentification unique pour les identités avec des comptes personnels.
En empêchant Okta de créer des comptes, vous empêchez Okta de provisionner automatiquement des comptes utilisateur pour les identités avec des comptes personnels. De plus, cette configuration permet quand-même à Okta de propager les modifications d'attributs et les suspensions d'utilisateurs dans Cloud Identity ou Google Workspace pour les utilisateurs disposant d'un compte Google correspondant.
Pour les identités ne disposant pas de compte utilisateur correspondant dans Cloud Identity ou Google Workspace, Okta peut afficher le message d'erreur suivant dans la console d'administration Okta :
Pour un utilisateur disposant d'un compte personnel existant, le compte utilisateur Cloud Identity ou Google Workspace correspondant est créé automatiquement lorsque la demande de transfert est acceptée. Cet utilisateur peut alors utiliser immédiatement l'authentification unique. Bien que le compte utilisateur soit fonctionnel à ce stade, il est possible qu'Okta n'affiche pas encore d'icône sur la page d'accueil de l'utilisateur et continue d'afficher le message d'erreur dans l'interface administrateur. Pour résoudre ce problème, réessayez d'exécuter la tâche d'attribution dans le tableau de bord d'administrateur Okta :
Cette méthode empêche Okta de provisionner automatiquement des comptes utilisateur pour les identités avec des comptes personnels, mais autorise l'authentification unique pour les identités avec des comptes personnels. Elle est en outre moins sujette aux erreurs de configuration que la deuxième méthode. Toutefois, pour les utilisateurs sans compte personnel existant, l'inconvénient est que vous devez créer manuellement des comptes utilisateur dans Cloud Identity ou Google Workspace.
Méthode 4 : deux applications avec attribution manuelle
Vous pouvez remédier à certains des inconvénients des méthodes précédentes en utilisant deux applications, l'une pour la gestion des comptes et l'autre pour l'authentification unique, en procédant comme suit :
- Configurez une seule instance de l'application Google Workspace pour ne permettre que le provisionnement. La fonctionnalité d'authentification unique de l'application n'est pas utilisée. En attribuant des utilisateurs à cette application, vous contrôlez les comptes provisionnés pour Cloud Identity ou Google Workspace. Pour masquer cette application pour vos utilisateurs, il vous suffit d'activer l'option Do not display application icon to users (Ne pas afficher l'icône de l'application pour les utilisateurs).
- Configurez une autre instance de l'application Google Workspace uniquement pour permettre l'authentification unique. En attribuant des utilisateurs à cette application, vous contrôlez qui est autorisé à se connecter.
Pour attribuer des utilisateurs à l'aide de ces deux applications, procédez comme suit :
- Attribuez à l'application d'authentification unique toutes les identités qui auront besoin d'accéder aux services Google. Incluez les identités avec des comptes personnels existants afin d'autoriser l'authentification unique pour les identités avec des comptes personnels.
Lors de l'attribution d'identités à l'application de gestion des comptes, incluez celles qui auront besoin d'accéder aux services Google, mais excluez toutes les identités qui possèdent un compte personnel existant. De cette façon, vous empêchez le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels.
Lorsqu'un utilisateur accepte une demande de transfert, attribuez-le également à l'application.
Fédérer avec Okta : comparaison
Le tableau suivant récapitule les différentes méthodes.
| Autoriser l'authentification unique pour les identités avec des comptes personnels | Empêcher le provisionnement automatique des utilisateurs pour les identités avec des comptes personnels | Empêcher la suppression des comptes migrés sans identité correspondante dans le fournisseur d'identité externe | Provisionner automatiquement de nouveaux comptes | Mettre à jour automatiquement les comptes migrés | |
|---|---|---|---|---|---|
| Méthode 1 : sans la gestion des comptes | ✅ | ✅ | ✅ | X | X |
| Méthode 2 : gestion des comptes avec attribution manuelle | X | Risky | ✅ | ✅ | ✅ |
| Méthode 3 : gestion des comptes avec création d'utilisateurs désactivée | ✅ | ✅ | ✅ | X | ✅ |
| Méthode 4 : deux applications avec attribution manuelle | ✅ | Risky | ✅ | ✅ | ✅ |
Étape suivante
- Découvrez comment configurer la fédération avec Active Directory ou Microsoft Entra ID.
- Démarrez votre processus d'intégration en préparant des comptes Cloud Identity ou Google Workspace.