Ce document fournit des bonnes pratiques et des conseils vous aidant à configurer la fédération de manière cohérente et sécurisée. Les conseils s'appuient sur les bonnes pratiques pour l'utilisation de Cloud Identity ou de Google Workspace avec Google Cloud.
Tous les services Google, y compris Google Cloud, Google Marketing Platform et Google Ads, exploitent Google Sign-In pour authentifier les utilisateurs. Plutôt que de créer et de gérer manuellement des comptes utilisateur dans Cloud Identity ou Google Workspace pour chaque employé, vous pouvez fédérer Cloud Identity ou Google Workspace avec votre fournisseur d'identité externe, tel qu'Active Directory ou Azure Active Directory. La configuration de la fédération implique généralement les opérations suivantes :
- Provisionner automatiquement les comptes utilisateur pertinents depuis une source externe faisant autorité vers Cloud Identity ou Google Workspace
- Permettre aux utilisateurs de recourir à un fournisseur d'identité externe pour s'authentifier auprès des services Google
Mapper des identités
L'identité d'un compte utilisateur géré par Cloud Identity ou Google Workspace est définie par son adresse e-mail principale. Cette adresse est répertoriée comme adresse e-mail du compte Google sur la page du compte Google. Pour être considérée comme valide, l'adresse e-mail principale doit utiliser l'un des domaines que vous avez ajoutés à votre compte Cloud Identity ou Google Workspace.
L'adresse e-mail principale assume également les rôles suivants :
- L'adresse e-mail principale est le nom d'utilisateur à fournir lors de la connexion. Bien que les utilisateurs puissent ajouter des adresses e-mail secondaires ou des alias à leur compte Google, ces adresses ne sont pas considérées comme des identités et ne peuvent pas être employées pour se connecter.
- Lorsqu'un administrateur doit envoyer des notifications aux utilisateurs (par exemple, pour signaler un risque de sécurité potentiel), ces notifications ne sont envoyées qu'à l'adresse e-mail principale.
Pour configurer l'authentification unique et le provisionnement automatique des utilisateurs entre Google et votre fournisseur d'identité externe, vous devez mapper les identités de votre fournisseur d'identité externe aux identités correspondantes dans Cloud Identity ou Google Workspace. Les sections suivantes décrivent les bonnes pratiques liées à l'établissement de ce mappage.
Utiliser la même identité dans tous les systèmes fédérés
Pour établir un mappage, vous devez simplement vérifier que l'assertion SAML accordée à Google par le fournisseur d'identité contient une revendication NameID dont la valeur correspond à l'adresse e-mail principale d'un utilisateur Cloud Identity ou Google Workspace existant. Le fournisseur d'identité est libre d'utiliser tout mappage ou toute logique applicable pour dériver une revendication NameID appropriée pour ses utilisateurs existants.
De nombreux fournisseurs d'identité exploitent des adresses e-mail (ou plus généralement, des noms conformes à la norme RFC 822) pour identifier les utilisateurs. Voici quelques exemples :
- L'attribut
userPrincipalNamedans Active Directory est un nom conforme à la norme RFC 822 qui identifie un utilisateur de manière unique et lui permet de se connecter à Windows ou aux services de fédération Active Directory (AD FS). - Azure Active Directory se sert de l'attribut
UserPrincipalNamepour identifier les utilisateurs et leur permettre de se connecter.
Si les utilisateurs gérés par votre fournisseur d'identité externe utilisent déjà une adresse e-mail comme identité, vous pouvez employer la même identité que l'adresse e-mail principale dans Cloud Identity ou Google Workspace. L'emploi de la même identité utilisateur dans les systèmes fédérés présente plusieurs avantages :
Lorsque les utilisateurs se connectent à un outil Google tel que la console Google Cloud, ils sont d'abord invités à fournir l'adresse e-mail principale de leur compte utilisateur Cloud Identity ou Google Workspace avant d'être redirigés vers votre fournisseur d'identité externe. En fonction de votre fournisseur d'identité, il se peut qu'un autre écran de connexion invite l'utilisateur à saisir son nom d'utilisateur et son mot de passe.
Si les adresses e-mail diffèrent pour ces étapes, les multiples écrans de connexion peuvent facilement dérouter les utilisateurs finaux. En revanche, si les utilisateurs peuvent employer la même identité à chaque étape, ils ne sont pas confrontés aux différences techniques entre les fournisseurs d'identité, ce qui réduit les risques de confusion.
Si vous n'avez pas besoin de mapper les identités utilisateur, vous pouvez plus facilement mettre en corrélation les journaux d'audit de Google Cloud avec les journaux des systèmes sur site.
De même, si les applications déployées sur site et sur Google Cloud doivent échanger des données contenant des identités utilisateur, cette approche vous évite d'avoir à mapper les identifiants utilisateur.
Pour en savoir plus sur le mappage des utilisateurs Active Directory ou Azure AD avec Cloud Identity ou Google Workspace, consultez le guide d'Active Directory ou d'Azure AD.
S'assurer que les identités utilisent des adresses e-mail routables
Google Cloud se sert de l'adresse e-mail principale d'un utilisateur pour envoyer des e-mails de notification. Voici quelques exemples de notifications :
Alertes budgétaires : si vous avez configuré une alerte budgétaire, Google Cloud envoie une notification aux administrateurs et aux utilisateurs du service de facturation lorsqu'un seuil budgétaire est dépassé.
Notifications de paiement : les notifications ou alertes concernant les paiements sont envoyées aux adresses e-mail d'utilisateurs du service de paiement configurées pour le compte de facturation concerné.
Invitations aux projets : si vous attribuez le rôle d'administrateur de projet à un utilisateur faisant partie d'un compte Cloud Identity ou Google Workspace différent de celui auquel l'organisation du projet est associée, une invitation est envoyée à l'utilisateur. Pour que le nouveau rôle prenne effet, l'utilisateur doit accepter l'invitation en cliquant sur un lien dans l'e-mail.
Réponses aux demandes d'assistance et autres notifications de l'assistance.
Si vous utilisez Google Workspace et que vous avez correctement configuré les enregistrements MX DNS nécessaires, tous les e-mails de notification envoyés à l'adresse e-mail principale sont transmis à la boîte de réception Gmail de l'utilisateur correspondant.
Pour les utilisateurs Cloud Identity, Google Cloud tente également de distribuer les e-mails de notification, mais le routage de ces message doit être géré par votre infrastructure de messagerie existante. Pour éviter que vos utilisateurs Cloud Identity ne manquent des notifications, assurez-vous que votre système de messagerie actuel accepte les messages envoyés à leur adresse e-mail principale et qu'il achemine ces e-mails vers les boîtes aux lettres appropriées. Procédez comme suit :
Assurez-vous que tous les domaines ajoutés à Cloud Identity possèdent des enregistrements MX DNS pointant vers votre système de messagerie existant.
Vérifiez que l'adresse e-mail principale d'un utilisateur Cloud Identity correspond bien à une boîte aux lettres existante dans votre système de messagerie. Si l'adresse e-mail principale employée par Cloud Identity et l'adresse e-mail de l'utilisateur diffèrent, configurez un alias dans votre système de messagerie existant pour que les e-mails envoyés à chaque adresse principale soient acheminés vers la boîte aux lettres appropriée.
Si ces solutions ne sont pas envisageables, songez à ajouter Google Workspace à votre compte Cloud Identity existant et à attribuer des licences Google Workspace aux principaux utilisateurs chargés de la facturation ou de l'interaction avec l'assistance, qui sont plus susceptibles de recevoir des notifications.
Évaluer les options de migration pour les comptes personnels existants
Si vos employés utilisaient des services Google tels que Google Ad Manager, Google AdSense ou Google Analytics avant que votre organisation ne s'inscrive à Cloud Identity ou Google Workspace, il est possible qu'ils se soient servis de comptes personnels pour y accéder.
Il peut s'avérer risqué de laisser vos employés utiliser des comptes personnels à des fins professionnelles. Pour en savoir plus sur ces risques et découvrir comment identifier les comptes personnels existants, consultez la page Évaluer vos comptes Google existants.
Vous pouvez gérer les comptes personnels existants des manières suivantes :
- Conservez les comptes personnels tels quels, en acceptant les risques potentiels.
- Migrez les comptes vers Cloud Identity ou Google Workspacee en initiant un transfert.
- Obligez les propriétaires des comptes utilisateur non gérés à modifier leur adresse e-mail pour qu'elle utilise un autre domaine.
Pour découvrir comment consolider les comptes personnels existants, consultez la page Évaluer les options de regroupement des identités.
Votre décision concernant la gestion des comptes personnels détermine de quelle façon et dans quel ordre vous allez configurer la fédération. Évaluez les comptes personnels existants employés par vos utilisateurs avant de créer des comptes utilisateur ou de configurer l'authentification unique dans Cloud Identity ou Google Workspace.
Mapper les ensembles d'identités
Une fois que vous avez défini le mappage des identités individuelles entre votre fournisseur d'identité externe et Cloud Identity ou Google Workspace, vous devez déterminer l'ensemble d'identités pour lequel vous souhaitez activer l'accès aux services Google.
L'ensemble effectif d'identités pouvant s'authentifier auprès des services Google se situe à l'intersection de deux ensembles :
- Identités externes mappées à une identité dans Cloud Identity ou Google Workspace
Identités externes pour lesquelles votre fournisseur d'identité externe autorise l'authentification unique à Cloud Identity ou Google Workspace
Le processus de contrôle des membres autorisés à employer l'authentification unique dépend du fournisseur d'identité que vous utilisez. Par exemple, Azure AD exploite des affectations, tandis qu'AD FS utilise des stratégies de contrôle d'accès.
Limiter l'ensemble d'identités pouvant s'authentifier auprès des services Google
Selon la manière dont vous envisagez d'utiliser Google Cloud, Google Workspace et d'autres outils Google, tous les employés de votre organisation ou seulement certains d'entre eux doivent pouvoir s'authentifier auprès des services Google.
Si vous prévoyez de n'autoriser qu'un sous-ensemble d'employés de votre organisation à accéder aux services Google, il est préférable de restreindre l'authentification à cet ensemble d'utilisateurs. En limitant le nombre d'utilisateurs capables de s'authentifier, vous établissez une couche de défense supplémentaire qui s'avère bénéfique si vous avez accidentellement configuré une règle de contrôle d'accès trop laxiste.
Vous pouvez limiter l'ensemble d'utilisateurs pouvant s'authentifier auprès de Google des manières suivantes :
- Réduisez le nombre de comptes utilisateur dans Cloud Identity ou Google Workspace. Si vous n'avez mappé aucun compte utilisateur, toute tentative d'authentification effectuée par un utilisateur échouera, même si le fournisseur d'identité l'autorise à se connecter à Cloud Identity ou à Google Workspace à l'aide de l'authentification unique.
- Configurez l'authentification unique dans votre fournisseur d'identité pour réduire le nombre d'utilisateurs autorisés à se connecter à Cloud Identity ou Google Workspace.
La meilleure approche pour votre situation varie selon que vous devez ou non migrer des comptes personnels existants.
Limiter l'ensemble d'identités provisionnées si vous devez encore migrer des comptes personnels
Vous ne pouvez migrer un compte personnel vers Cloud Identity ou Google Workspace que si vous n'avez pas créé de compte utilisateur avec la même identité dans Cloud Identity ou Google Workspace.
S'il vous reste des comptes personnels existants que vous envisagez de migrer, veillez à ne pas créer accidentellement des comptes utilisateur en conflit. Suivez les instructions ci-dessous :
- Limitez l'authentification en ne créant des comptes utilisateur Cloud Identity ou Google Workspace que pour les utilisateurs qui en ont besoin et qui ne disposent pas de compte personnel.
- Évitez de verrouiller accidentellement les comptes migrés en configurant l'authentification unique non seulement pour les utilisateurs pour lesquels vous créez des comptes dans Cloud Identity ou Google Workspace, mais aussi pour tous les comptes personnels devant encore être migrés.
Le schéma suivant montre comment différents types d'identités se chevauchent et sont corrélés.
Dans le schéma, les identités associées à un compte utilisateur dans Cloud Identity ou Google Workspace se situent dans la plus petite ellipse (jaune). Cette ellipse est contenue dans la deuxième ellipse (bleue), qui comprend les identités capables de s'authentifier. La troisième et plus grande ellipse (grise) contient le reste des identités, soit celles qui possèdent un compte utilisateur dans votre fournisseur d'identité. Pour en savoir plus sur la configuration d'Active Directory, d'Azure AD ou d'Okta, consultez notre guide des bonnes pratiques (document distinct).
Empêcher la création de comptes personnels
L'ajout d'un domaine tel que example.com à votre compte Cloud Identity ou Google Workspace n'empêche pas les employés de créer des comptes personnels utilisant le même domaine. Ces nouveaux comptes personnels apparaissent comme des utilisateurs non gérés dans votre compte Cloud Identity ou Google Workspace. Ils ne sont pas autorisés à utiliser l'authentification unique, ni aucune autre configuration appliquée à votre compte Cloud Identity ou Google Workspace.
Une manière de bloquer la création d'un compte personnel consiste à créer un compte utilisateur dans Cloud Identity ou Google Workspace avec la même adresse e-mail. Par exemple, si vous avez créé un utilisateur alice@example.com dans votre compte Cloud Identity ou Google Workspace, toute tentative de création d'un compte personnel avec la même identité échouera. Toutefois, si aucun utilisateur correspondant n'existe dans Cloud Identity ou Google Workspace, la création d'un compte personnel aboutira.
Une fois la migration des comptes personnels vers Cloud Identity ou G Suite terminée, empêchez la création d'autres comptes en appliquant la configuration suivante :
Limitez l'authentification en n'autorisant que les utilisateurs appropriés à employer l'authentification unique pour Cloud Identity ou Google Workspace.
Provisionnez des utilisateurs Cloud Identity ou Google Workspace pour tous les employés. Assurez-vous que les comptes utilisateur se servent de l'adresse e-mail professionnelle de l'employé en tant qu'adresse e-mail principale ou d'alias pour éviter qu'un compte personnel ne soit créé avec la même adresse e-mail. Si possible, conservez à l'état "suspendu" les comptes utilisateur pour lesquels l'authentification unique n'est pas activée.
Le schéma suivant présente cette configuration.
Si vous n'avez pas fini de migrer des comptes personnels, vous pouvez surveiller temporairement la création de comptes personnels en capturant les e-mails de validation envoyés lors du processus de création. Les e-mails de validation utilisent une adresse d'expéditeur d'enveloppe correspondant à *@idverification.bounces.google.com.
Configurez un filtre dans votre système de messagerie afin d'identifier les e-mails contenant cette adresse et de les conserver pour examen interne.
Définir les identités Cloud Identity ou Google Workspace en tant que sous-ensemble des identités de votre fournisseur d'identité externe
Votre compte Cloud Identity ou Google Workspace peut inclure des comptes utilisateur dont les identités ne sont mappées à aucun utilisateur de votre fournisseur d'identité externe. Deux scénarios types peuvent être à l'origine de ces comptes utilisateur :
- Vous créez un compte utilisateur dans Cloud Identity ou Google Workspace à l'aide d'une adresse e-mail principale qui n'est mappée à aucun utilisateur de votre fournisseur d'identité externe.
- Vous disposez d'un compte utilisateur dans Cloud Identity ou Google Workspace qui est mappé à une identité de votre fournisseur d'identité externe, mais supprimez ensuite l'identité dans le fournisseur d'identité externe. Par exemple, il est possible que vous supprimiez l'identité si l'employé quitte l'entreprise.
Lorsque vous activez l'authentification unique dans Cloud Identity ou Google Workspace, tous les utilisateurs (à l'exception des super-administrateurs) sont forcés de recourir à l'authentification unique. Pour un compte utilisateur Cloud Identity ou Google Workspace qui n'est pas mappé à une identité de votre fournisseur d'identité externe, toute tentative d'utilisation de l'authentification unique échouera. Bien qu'un compte utilisateur dépourvu d'homologue soit en réalité inutilisable, il peut tout de même présenter un risque, comme dans les situations suivantes :
Si, à un moment donné, l'authentification unique est temporairement ou définitivement désactivée, le compte utilisateur peut être réutilisé. Cela peut permettre à un ancien employé de se connecter et d'accéder aux ressources de l'entreprise.
Le nom du compte utilisateur supprimé peut être réutilisé. Par exemple, un employé rejoignant l'entreprise peut partager le même nom qu'un autre employé l'ayant quittée quelques mois ou quelques années plus tôt. Si, entre-temps, le compte utilisateur de l'ancien employé a été supprimé, vous pouvez attribuer au nouvel employé le nom d'utilisateur précédemment utilisé par l'ancien employé.
Le compte utilisateur du nouvel employé peut avoir un ID interne différent de celui de l'ancien employé. Toutefois, du point de vue de la fédération, les deux comptes utilisateur sont considérés comme identiques s'ils sont mappés à la même adresse e-mail principale dans Cloud Identity ou Google Workspace. Par conséquent, lorsque le nouvel employé se connecte à Google, il peut "hériter" des données, paramètres et autorisations de l'ancien employé.
Les utilisateurs super-administrateur Cloud Identity et Google Workspace ne sont pas tenus de recourir à l'authentification unique, mais peuvent toujours le faire lorsque l'authentification est initiée par le fournisseur d'identité. La possibilité d'utiliser l'authentification unique initiée par le fournisseur d'identité rend les utilisateurs super-administrateur sensibles au "name squatting" (squat de nom) s'ils n'ont pas d'homologue dans votre fournisseur d'identité externe.
Prenons l'exemple suivant : Alice dispose d'un compte utilisateur super-administrateur alice-admin@example.com dans Cloud Identity ou Google Workspace et n'utilise pas la validation en deux étapes. Mallory, qui ne connaît pas le mot de passe d'Alice, trouve un moyen de créer dans le fournisseur d'identité externe un utilisateur mappé à alice-admin@example.com. Bien que ce nouveau compte utilisateur ne possède aucun privilège particulier ni aucun lien avec le compte utilisateur d'Alice, le fait qu'il partage une identité commune avec le compte super-administrateur d'Alice permet désormais à Mallory d'utiliser l'authentification unique initiée par le fournisseur d'identité et de s'authentifier en tant que alice-admin@example.com.
Pour limiter ce risque de "name squatting", assurez-vous que vos identités Cloud Identity ou Google Workspace correspondent à un sous-ensemble des identités de votre fournisseur d'identité externe. La meilleure façon d'obtenir ce résultat consiste à mapper l'intégralité du cycle de vie des comptes utilisateur tel que mis en œuvre par votre fournisseur d'identité externe au cycle de vie des comptes utilisateur dans Cloud Identity ou Google Workspace.
Utiliser des utilisateurs super-administrateur dédiés
Les comptes super-administrateur Google Workspace et Cloud Identity sont associés à un puissant ensemble d'autorisations qui s'appliquent non seulement au compte Cloud Identity ou Google Workspace, mais également à une organisation Google Cloud associée. Comme seul un faible nombre d'activités requiert des droits de super-administrateur, il est préférable de limiter autant que possible le nombre d'administrateurs disposant d'un accès super-administrateur, et d'utiliser des comptes utilisateur disposant de privilèges moindres pour l'administration quotidienne de votre compte ou de votre organisation Google Cloud.
Une fois que vous avez identifié les administrateurs qui nécessitent un accès super-administrateur, créez des comptes utilisateur super-administrateur dédiés. Par exemple :
- Créez un compte utilisateur associé à l'identité
alice@example.comet attribuez-lui des autorisations standards. Ce compte doit être utilisé quotidiennement pour les activités de routine. Créez un deuxième compte utilisateur associé à l'identité
alice-admin@example.comet attribuez-lui des droits de super-utilisateur. Alice ne devrait utiliser ce compte que lorsque des droits de super-administrateur sont requis.Pour garantir que les e-mails de notification envoyés à cette adresse e-mail seront bien reçus dans la boîte aux lettres de l'utilisateur, configurez Google Workspace ou votre système de messagerie existant de sorte que l'adresse e-mail
alice-admin@example.comsoit employée en tant qu'alias ou que les e-mails soient transférés àalice@example.com.
Assurez-vous que les deux identités sont reconnues par votre fournisseur d'identité externe afin que l'ensemble d'identités dans Cloud Identity ou Google Workspace reste un sous-ensemble des identités de votre fournisseur d'identité externe.
Nous vous recommandons de suivre un schéma de nommage pour ces comptes super-administrateur dédiés pour pouvoir surveiller leur utilisation dans les journaux d'audit. Par exemple, ajoutez -admin au nom d'utilisateur, comme dans l'exemple précédent.
Limiter le nombre d'utilisateurs de service dans Google Workspace et Cloud Identity
Votre fournisseur d'identité externe peut contenir non seulement des comptes utilisateur pour les employés, mais aussi des comptes utilisateur destinés aux utilisateurs machine tels que des applications, des outils ou des tâches en arrière-plan.
Notez que la méthode recommandée sur Google Cloud pour permettre à une application de s'authentifier et d'accéder aux API Google consiste à mettre en œuvre l'une des approches suivantes :
Un outil ou une application Web ayant besoin d'accéder aux services ou API Google pour le compte d'un utilisateur final doit utiliser OAuth 2.0 ou OpenID Connect. Avec ces protocoles, l'application sollicite d'abord le consentement de l'utilisateur final pour accéder à ses données puis, une fois l'autorisation reçue, peut effectuer l'accès au nom de l'utilisateur final.
Si l'accès aux API ou aux services ne doit pas être effectué au nom d'un utilisateur final, mais de l'application elle-même, il est préférable d'utiliser des comptes de service Google Cloud pour l'authentification, puis de leur accorder un accès aux ressources à l'aide d'IAM.
Si les comptes de service Google Cloud disposent des rôles appropriés dans IAM, ils permettent l'authentification et peuvent utiliser n'importe quelle API Cloud. Si vous devez autoriser un compte de service à accéder à des API situées en dehors de Google Cloud, telles que l'API Directory ou l'API Drive, vous pouvez utiliser la délégation au niveau du domaine Google Workspace.
Cette fonctionnalité permet d'autoriser un compte de service à agir pour le compte d'un utilisateur Cloud Identity ou Google Workspace. La délégation étant un privilège puissant, nous vous recommandons de n'utiliser la délégation au niveau du domaine Google Workspace que lorsque vous ne pouvez pas mettre en œuvre l'approche OAuth.
Employez un utilisateur Cloud Identity ou Google Workspace dédié pour chaque compte de service Google Cloud pour lequel la délégation au niveau du domaine Google Workspace est activée. Créez cet utilisateur dans votre fournisseur d'identité externe, puis provisionnez-le dans Cloud Identity ou Google Workspace pour que l'ensemble d'utilisateurs dans Cloud Identity ou Google Workspace reste un sous-ensemble des utilisateurs de votre fournisseur d'identité externe.
Évitez de créer dans Cloud Identity et Google Workspace des utilisateurs de service que vous ne prévoyez pas d'employer pour la délégation au niveau du domaine Google Workspace.
Mapper les cycles de vie des comptes utilisateur
Les comptes utilisateur de votre fournisseur d'identité externe suivent un certain cycle de vie. Généralement, ce cycle de vie reflète la relation de travail entre l'employé et l'entreprise :
- Un compte utilisateur est créé pour un employé rejoignant l'organisation.
- Le compte utilisateur peut être temporairement suspendu et réactivé ultérieurement, par exemple lorsque le collaborateur part en congé.
- Lorsque l'utilisateur quitte l'entreprise, le compte utilisateur est soit supprimé, soit suspendu pendant une certaine période de conservation avant d'être définitivement supprimé.
Le schéma suivant illustre ce cycle de vie.
Cette section répertorie les bonnes pratiques à adopter pour s'assurer que le cycle de vie des comptes utilisateur dans Cloud Identity ou Google Workspace suit le cycle de vie des comptes utilisateur correspondants dans votre fournisseur d'identité externe.
Désigner le fournisseur d'identité externe comme source fiable
De nombreux systèmes d'information de gestion des ressources humaines (SIRH), fournisseurs d'identité et adaptateurs ne permettent qu'un provisionnement à sens unique des utilisateurs. Cela signifie que les modifications effectuées dans le SIRH ou dans le fournisseur d'identité sont propagées dans Cloud Identity ou Google Workspace, mais que les modifications effectuées dans Cloud Identity ou Google Workspace ne sont pas répercutées.
Pour éviter les incohérences causées par le provisionnement à sens unique, désignez votre fournisseur d'identité externe comme source fiable. Utilisez exclusivement votre fournisseur d'identité externe (ou SIRH) pour créer, modifier ou supprimer des utilisateurs, et exploitez le provisionnement automatisé pour propager les modifications dans Google Workspace et Cloud Identity. En désignant votre fournisseur d'identité externe comme source fiable, vous limitez le risque d'incohérences et la possibilité que vos modifications manuelles soient ignorées par le fournisseur d'identité.
Automatiser le provisionnement des utilisateurs dans Cloud Identity ou Google Workspace
Pour permettre à un employé de s'authentifier auprès de Google à l'aide de l'authentification unique, vous devez d'abord lui créer un compte utilisateur dans Cloud Identity ou Google Workspace. Afin d'assurer la cohérence avec votre fournisseur d'identité externe, il est préférable d'automatiser le processus de provisionnement de ces comptes utilisateur dans Cloud Identity ou Google Workspace :
- En automatisant le provisionnement, vous pouvez garantir que les identités Cloud Identity ou Google Workspace correspondront toujours à un sous-ensemble des identités de votre fournisseur d'identité externe.
- Vous réduisez le risque d'introduction accidentelle d'une incohérence entre une identité dans Cloud Identity ou Google Workspace et l'identité correspondante dans votre fournisseur d'identité externe. En cas d'incohérence (causée par une erreur de saisie de l'adresse e-mail, par exemple), les employés peuvent rencontrer des problèmes de connexion.
- Vous réduisez l'effort manuel d'administration.
Si vous gérez le processus d'intégration à l'aide d'un SIRH, vous pouvez automatiser le provisionnement des utilisateurs en configurant le SIRH pour qu'il provisionne les comptes utilisateur à la fois dans votre fournisseur d'identité externe et dans Cloud Identity ou Google Workspace, comme illustré dans le schéma suivant.
Pour que cette configuration fonctionne correctement, vous devez vous assurer que votre SIRH provisionne les comptes utilisateur en les mappant les uns aux autres. En outre, le SIRH doit décider quels comptes utilisateur doivent être provisionnés pour Cloud Identity ou Google Workspace.
Une autre méthode pour automatiser le provisionnement des utilisateurs, fonctionnant indépendamment d'un SIRH, consiste à employer votre fournisseur d'identité externe comme source fiable pour le provisionnement dans Cloud Identity ou Google Workspace. Avec cette approche, la configuration du mappage des comptes utilisateur et des ensembles de comptes utilisateur est gérée dans le fournisseur d'identité ou par l'adaptateur, comme le montre le schéma suivant.
Si vous utilisez Active Directory en tant que fournisseur d'identité, vous pouvez dupliquer cette configuration à l'aide de Google Cloud Directory Sync. D'autres fournisseurs d'identité, tels qu'Azure AD ou Okta, disposent d'adaptateurs intégrés pour le provisionnement des utilisateurs dans Google Workspace. Dans la mesure où Google Workspace et Cloud Identity sont basés sur la même plate-forme et exploitent les mêmes API, ces adaptateurs peuvent également être utilisés pour Cloud Identity.
Propager des événements de suspension dans Cloud Identity ou Google Workspace
Lorsqu'un employé quitte l'organisation de manière temporaire ou définitive, nous vous recommandons de révoquer son accès aux services Google. En suspendant le compte utilisateur de l'employé dans votre fournisseur d'identité externe, vous l'empêchez de s'authentifier auprès de Google à l'aide de l'authentification unique, mais cette opération peut ne pas complètement supprimer l'accès à tous les services Google. Les événements suivants peuvent toujours se produire :
- Si l'utilisateur Cloud Identity ou Google Workspace dispose d'une session de navigateur active, la session continue de fonctionner. Tous les jetons OAuth déjà obtenus restent également valides.
- Si l'utilisateur dispose de droits de super-administrateur ou si vous avez configuré des masques de réseau, il est possible que l'employé puisse toujours se connecter à l'aide d'un mot de passe.
- Le compte utilisateur peut toujours recevoir des notifications de Google Cloud, y compris des alertes budgétaires.
- Si une licence Google Workspace est attribuée à l'utilisateur, celui-ci continuera à recevoir des e-mails dans sa boîte aux lettres. De plus, il apparaîtra toujours dans le carnet d'adresses et pourra être répertorié comme disponible dans Google Agenda.
- Si vous autorisez les utilisateurs à employer des applications moins sécurisées, l'utilisateur pourra toujours accéder à Gmail, à Google Agenda et à d'autres données à l'aide de mots de passe d'application.
Pour révoquer complètement l'accès aux services Google, vous pouvez propager les événements de suspension dans Cloud Identity ou Google Workspace des manières suivantes :
Assurez-vous que chaque fois qu'un compte utilisateur est suspendu dans votre fournisseur d'identité externe, le compte utilisateur correspondant dans Cloud Identity ou Google Workspace est également suspendu. La suspension d'un utilisateur dans Cloud Identity ou Google Workspace met fin aux sessions de navigateur actives, invalide les jetons et révoque tous les autres accès.
De même, lorsque vous réactivez un compte utilisateur dans votre fournisseur d'identité externe, veillez également à réactiver le compte utilisateur correspondant dans Cloud Identity ou Google Workspace.
La suspension d'un compte utilisateur dans Cloud Identity ou Google Workspace n'est pas une opération destructrice. Lorsque le compte utilisateur est suspendu, les données de l'utilisateur sont conservées, les licences Google Workspace restent associées et les rôles attribués dans Google Cloud restent inchangés.
Propager des événements de suppression dans Cloud Identity ou Google Workspace
Lorsqu'un employé quitte définitivement l'organisation, vous pouvez décider de non seulement suspendre son compte utilisateur dans votre fournisseur d'identité externe, mais également de le supprimer.
Si vous supprimez un compte utilisateur dans votre fournisseur d'identité externe, mais que vous ne supprimez pas l'utilisateur Cloud Identity ou Google Workspace correspondant, l'ensemble d'utilisateurs dans Cloud Identity et Google Workspace ne correspond plus à un sous-ensemble des utilisateurs de votre fournisseur d'identité externe. Cela peut se révéler problématique à l'avenir si un nouvel employé portant le même nom que celui qui a quitté l'entreprise rejoint votre organisation. Si vous créez un compte utilisateur dans votre fournisseur d'identité pour le nouvel employé, il se peut que vous réutilisiez le nom d'utilisateur de l'ancien employé, ce qui mappe le nouveau compte utilisateur à l'ancien dans Cloud Identity ou Google Workspace. En ce cas, il est possible que le nouvel employé ait accès aux données et aux paramètres de l'ancien employé.
Vous pouvez éviter les risques associés aux comptes utilisateur orphelins Cloud Identity ou Google Workspace en supprimant un utilisateur Cloud Identity ou Google Workspace dès que le compte utilisateur correspondant dans votre fournisseur d'identité est supprimé.
La suppression d'un utilisateur Cloud Identity ou Google Workspace est une opération destructrice qui ne peut être annulée que pendant une certaine période. En fonction des services Google exploités par l'utilisateur, la suppression de l'utilisateur peut entraîner la suppression définitive des données associées et, par conséquent, le non-respect de vos exigences de conformité.
Pour conserver les paramètres et les données de l'utilisateur pendant une certaine période avant de les supprimer définitivement, mettez en œuvre l'une des approches suivantes :
Retardez la suppression du compte utilisateur dans votre fournisseur d'identité externe en maintenant le compte utilisateur à l'état suspendu pendant une période de conservation donnée. Supprimez l'utilisateur à la fois dans votre fournisseur d'identité et dans Cloud Identity ou Google Workspace une fois la période de conservation écoulée.
Lorsque vous supprimez un compte utilisateur dans votre fournisseur d'identité externe, suspendez l'utilisateur Cloud Identity ou Google Workspace correspondant et remplacez son adresse e-mail principale par un nom peu susceptible de provoquer un conflit. Par exemple, renommez
alice@example.comenobsolete-yyyymmdd-alice@example.com, oùyyyymmddreflète la date de la suppression dans votre fournisseur d'identité externe. Conservez le compte utilisateur renommé à l'état suspendu pendant la période de conservation définie, puis supprimez-le une fois cette période écoulée.
Pour préserver les données Google Workspace des comptes utilisateur suspendus, conservez la licence Google Workspace attribuée à l'utilisateur ou basculez vers une licence Utilisateur archivé pour que les règles de conservation Google Workspace Vault continuent de s'appliquer et que les données de l'utilisateur soient préservées.
Authentification unique
Tous les produits Google, y compris les services tels que Google Cloud, Google Ads et YouTube, exploitent Google Sign-In pour authentifier les utilisateurs. Un service initie le processus d'authentification en redirigeant l'utilisateur vers accounts.google.com, où l'écran de connexion Google l'invite à saisir son adresse e-mail. En fonction du domaine de l'adresse e-mail fournie, le compte utilisateur est ensuite recherché dans Gmail, dans l'annuaire des comptes personnels ou, si le domaine correspond à son domaine principal, secondaire ou alias, dans un compte Cloud Identity ou Google Workspace.
Le schéma suivant illustre ce processus d'authentification.
Si vous configurez un compte Cloud Identity ou Google Workspace pour qu'il exploite l'authentification unique, les utilisateurs sont redirigés vers un fournisseur d'identité externe pour s'authentifier. Une fois que le fournisseur d'identité externe a terminé l'authentification, le résultat est renvoyé à Google Sign-In au moyen d'une assertion SAML. Cette assertion SAML sert de preuve d'une authentification réussie. Elle contient l'adresse e-mail de l'utilisateur et est signée par le certificat du fournisseur d'identité externe afin que Google Sign-In puisse vérifier son authenticité.
Ce processus, appelé authentification unique initiée par le fournisseur de services, s'applique à tous les utilisateurs, à l'exception des super-administrateurs. Les super-administrateurs ne sont jamais redirigés vers un fournisseur d'identité externe et sont invités à saisir un mot de passe.
Certains fournisseurs d'identité sont également compatibles avec l'authentification unique initiée par le fournisseur d'identité. Dans ce modèle, l'utilisateur s'authentifie auprès du fournisseur d'identité externe, puis suit un lien pointant vers un service Google tel que Google Cloud ou Google Ads. Si l'authentification unique a été activée pour un compte Cloud Identity ou Google Workspace, tous les utilisateurs de ce compte sont autorisés à employer l'authentification unique initiée par le fournisseur d'identité, y compris les super-administrateurs.
Réduire l'ensemble d'attributs transmis dans les assertions SAML
Une fois qu'un utilisateur s'est authentifié auprès du fournisseur d'identité externe, Cloud Identity ou Google Workspace utilise l'assertion SAML transmise par le fournisseur d'identité externe pour établir une session. En plus de valider l'authenticité de l'assertion SAML, ce processus identifie le compte utilisateur Cloud Identity ou Google Workspace correspondant à la valeur NameID de l'assertion.
La valeur NameID doit contenir l'adresse e-mail principale du compte utilisateur à authentifier. L'adresse e-mail est sensible à la casse. Les adresses e-mail secondaires et les alias ne sont pas pris en compte.
Pour éviter les erreurs de saisie ou de casse, il est préférable de provisionner automatiquement les comptes utilisateur.
Les assertions SAML peuvent inclure des attributs supplémentaires, mais ceux-ci ne sont pas pris en compte lors de l'authentification. Les attributs contenant des informations telles que le nom, le prénom ou l'appartenance à un groupe sont ignorés, car le compte de l'utilisateur dans Cloud Identity ou Google Workspace est considéré comme la seule source de ces informations utilisateur.
Pour réduire la taille des assertions SAML, configurez votre fournisseur d'identité de manière à n'inclure aucun attribut non requis par Google Sign-In.
Utiliser google.com en tant qu'émetteur
Les sessions Google Sign-In ne sont pas limitées à un seul outil ou domaine. En effet, une fois une session établie, celle-ci reste valide pour tous les services Google auxquels l'utilisateur a accès. Cette liste de services peut inclure des services tels que Google Cloud et Google Ads, ainsi que des services tels que la recherche Google et YouTube.
La nature globale d'une session est reflétée dans l'échange de protocole SAML : par défaut, Google utilise google.com en tant qu'émetteur (l'élément Issuer de la requête SAML) dans les requêtes SAML et attend des assertions SAML pour spécifier google.com en tant qu'audience (l'élément Audience de la réponse SAML).
Vous pouvez modifier cette valeur par défaut en activant l'option Utiliser un émetteur spécifique au domaine lorsque vous configurez l'authentification unique dans Cloud Identity ou Google Workspace. N'activez l'option d'émetteur spécifique au domaine que si vous possédez plusieurs comptes Cloud Identity ou Google Workspace (et donc plusieurs domaines) et que votre fournisseur d'identité doit pouvoir distinguer les connexions initiées par un compte Cloud Identity ou Google Workspace de celles initiées par un autre compte. Lorsque vous activez cette option, les requêtes SAML utilisent google.com/a/DOMAIN en tant qu'émetteur et attendent google.com/a/DOMAIN en tant qu'audience, où DOMAIN est le domaine principal du compte Cloud Identity ou Google Workspace.
Dans tous les autres cas, conservez le paramètre par défaut pour utiliser google.com en tant qu'émetteur et configurez votre fournisseur d'identité externe pour spécifier google.com en tant qu'audience dans les assertions SAML. Selon votre fournisseur d'identité, ce paramètre peut également être appelé émetteur, identificateur d'approbation de partie de confiance ou ID d'entité.
Aligner la durée des sessions Google sur la durée des sessions du fournisseur d'identité
Une fois qu'un utilisateur a terminé le processus d'authentification unique et qu'une session a été établie, la session Google Sign-In reste active pendant un certain temps. Au terme de cette période ou en cas de déconnexion de l'utilisateur, celui-ci est invité à se réauthentifier en répétant le processus d'authentification unique.
Par défaut, la durée d'une session pour les services Google est de 14 jours. Pour les utilisateurs disposant d'une licence Cloud Identity Premium ou Google Workspace Business, vous pouvez définir la durée de session par défaut sur une autre période (huit heures, par exemple).
Vous pouvez contrôler la durée de session utilisée par Google Cloud. La session Google Cloud s'applique à la console Google Cloud, à Google Cloud CLI ainsi qu'aux autres clients API. Vous pouvez définir la durée de session Google Cloud dans tous les types de comptes Cloud Identity et Google Workspace.
La plupart des fournisseurs d'identité externes gèrent également une session pour les utilisateurs authentifiés. Si la durée de la session du fournisseur d'identité est supérieure à celle de la session Google, la réauthentification peut se produire silencieusement. Autrement dit, l'utilisateur est redirigé vers le fournisseur d'identité, mais il est possible qu'il n'ait pas besoin de saisir à nouveau ses identifiants. La réauthentification silencieuse peut aller à l'encontre de la volonté de raccourcir la durée de session Google.
Pour vous assurer que les utilisateurs doivent saisir à nouveau leurs identifiants après l'expiration d'une session Google, configurez la durée de session Google et la durée de session du fournisseur d'identité de sorte que la durée de session du fournisseur d'identité soit inférieure à la durée de session Google.
Désactiver l'authentification unique pour les comptes de super-administrateur
Pour les comptes de super-administrateur, la SSO est facultative. Ils peuvent utiliser la SSO lorsque l'authentification est initiée par le fournisseur d'identité, mais ils peuvent également se connecter à l'aide d'un nom d'utilisateur et d'un mot de passe.
Si vous ne prévoyez pas d'utiliser l'authentification unique initiée par le fournisseur d'identité pour les comptes de super-administrateur, vous pouvez réduire le risque en procédant comme suit :
- Ajoutez une unité organisationnelle dédiée aux super-administrateurs.
- Attribuez un profil SSO à l'unité organisationnelle qui désactive l'authentification unique.
Sinon, si vous prévoyez d'utiliser l'authentification unique initiée par le fournisseur d'identité, assurez-vous d'appliquer la validation post-SSO pour les comptes de super-administrateur.
Authentification multifacteur
L'activation de l'authentification unique entre Cloud Identity ou Google Workspace et votre fournisseur d'identité externe améliore l'expérience utilisateur pour les employés. Les utilisateurs doivent s'authentifier moins fréquemment et n'ont pas besoin de mémoriser des identifiants distincts pour accéder aux services Google.
Toutefois, le fait d'autoriser les utilisateurs à s'authentifier de manière fluide auprès des différents services et environnements signifie également que l'impact potentiel des identifiants utilisateur compromis augmente. Si le nom d'utilisateur et le mot de passe d'un utilisateur sont perdus ou volés, un pirate informatique peut exploiter ces identifiants pour accéder non seulement aux ressources de votre environnement existant, mais également à celles d'un ou de plusieurs services Google.
Pour réduire le risque de vol d'identifiants, il est préférable d'utiliser l'authentification multifacteur pour tous les comptes utilisateur.
Appliquer l'authentification multifacteur pour les utilisateurs
Une fois que vous avez configuré l'authentification unique pour votre compte Cloud Identity ou Google Workspace, les utilisateurs ne disposant pas de droits de super-administrateur doivent s'authentifier via votre fournisseur d'identité externe.
Configurez votre fournisseur d'identité pour qu'il exige un deuxième facteur (un code à usage unique ou une clé USB, par exemple), et ainsi imposer l'authentification multifacteur chaque fois que l'authentification unique à Google est utilisée.
Si votre fournisseur d'identité externe n'est pas compatible avec l'authentification multifacteur, songez à activer la validation post-authentification unique pour que Google procède à une validation supplémentaire une fois que l'utilisateur s'est authentifié auprès de votre fournisseur d'identité externe.
Évitez d'utiliser des masques de réseau, car ils pourraient faire l'objet d'un usage abusif visant à contourner l'authentification multifacteur pour les utilisateurs.
Appliquer l'authentification en deux étapes de Google pour les super-administrateurs
Les super-administrateurs ne sont pas redirigés vers votre fournisseur d'identité (IdP) externe lorsqu'ils tentent de se connecter à la console Google Cloud ou à d'autres sites Google. Ils sont invités à s'authentifier à l'aide d'un nom d'utilisateur et d'un mot de passe.
Étant donné que les super-administrateurs peuvent s'authentifier à l'aide d'un nom d'utilisateur et d'un mot de passe, ils ne sont soumis à aucune règle d'authentification multifacteur applicable par votre IdP. Pour protéger les super-administrateurs, appliquez la validation en deux étapes de Google.
Les utilisateurs super-administrateur appartiennent généralement à l'une des deux catégories suivantes :
Utilisateurs super-administrateur personnalisés : ces utilisateurs sont personnalisés et destinés à être utilisés par un seul administrateur. Nous vous recommandons d'appliquer la validation en deux étapes pour tous les utilisateurs super-administrateur personnalisés.
Utilisateurs super-administrateur machine : bien qu'il soit préférable d'éviter ces comptes utilisateur, ils sont parfois nécessaires pour activer des outils tels que Cloud Directory Sync ou l'application de galerie Azure AD afin de gérer les utilisateurs et les groupes dans Cloud Identity ou Google Workspace.
Limitez le nombre d'utilisateurs super-administrateur machine et essayez d'activer la validation en deux étapes partout où c'est possible.
Pour les utilisateurs qui n'utilisent pas l'authentification unique, vous pouvez appliquer l'authentification en deux étapes sur un compte de façon globale, par unité organisationnelle ou par groupe :
Si aucun utilisateur super-administrateur machine ne peut utiliser la validation en deux étapes, il est préférable d'activer l'application forcée pour tous les utilisateurs. En appliquant la validation en deux étapes pour tous les utilisateurs, vous évitez de manquer accidentellement des utilisateurs.
Si certains utilisateurs super-administrateur machine ne peuvent pas employer la validation en deux étapes, utilisez un groupe dédié pour contrôler la validation en deux étapes. Créez un groupe, activez l'application forcée pour le groupe et ajoutez-y tous les super-utilisateurs concernés.
Pour découvrir comment sécuriser les super-administrateurs à l'aide de l'authentification en deux étapes, consultez nos bonnes pratiques de sécurité concernant les comptes administrateur.
Appliquer la validation post-authentification unique pour les super-administrateurs
Bien que les super-administrateurs ne soient pas tenus de recourir à l'authentification unique, ils peuvent toujours le faire lorsque l'authentification est initiée par le fournisseur d'identité. Pour vous assurer que les super-administrateurs sont toujours soumis à la validation en deux étapes, même s'ils s'authentifient via une connexion initiée par le fournisseur d'identité, activez d'autres validations SSO et la validation en deux étapes pour tous les super-administrateurs.
Ces validations supplémentaires peuvent sembler redondantes si votre IdP applique déjà l'authentification multifacteur, mais ce paramètre peut aider à protéger les super-administrateurs en cas de piratage de votre fournisseur d'identité.
Ne pas limiter l'authentification unique par masque de réseau
Lorsque vous configurez l'authentification unique dans Cloud Identity ou Google Workspace, vous pouvez éventuellement spécifier un masque de réseau. Si vous spécifiez un masque, seuls les utilisateurs dont l'adresse IP correspond au masque sont soumis à l'authentification unique. Les autres utilisateurs sont invités à saisir un mot de passe lorsqu'ils se connectent.
Si vous utilisez des masques de réseau, vous risquez de compromettre l'authentification multifacteur appliquée par votre fournisseur d'identité externe. Par exemple, en modifiant les emplacements ou en recourant à un VPN, un utilisateur peut être en mesure de contrôler si le masque de réseau s'applique ou non. Si vous appliquez l'authentification multifacteur au fournisseur d'identité externe, cette tactique peut permettre à un utilisateur ou à un pirate informatique de contourner les règles d'authentification multifacteur configurées sur votre fournisseur d'identité externe.
Pour garantir que l'authentification multifacteur s'applique de manière cohérente, indépendamment de l'emplacement ou de l'adresse IP d'un utilisateur, évitez de limiter l'authentification unique par masque de réseau.
Pour limiter l'accès aux ressources par adresse IP, configurez une liste blanche d'adresses IP autorisées au niveau de votre fournisseur d'identité externe ou utilisez l'accès contextuel pour Google Cloud et Google Workspace.
Étape suivante
- Découvrez d'autres bonnes pratiques :
- Comparez les modèles permettant de fédérer un fournisseur d'identité externe avec Google Cloud.