Fédérer Google Cloud avec Azure Active Directory

Cet article explique comment étendre à Google Cloud une solution existante de gestion des identités basée sur Microsoft Azure Active Directory, afin de définir des mécanismes d'authentification et d'autorisation cohérents dans un environnement informatique hybride.

Présentation

La gestion des comptes utilisateur et le contrôle de l'accès aux applications et aux ressources informatiques font partie des principales responsabilités des services informatiques des entreprises. Dans le passé, les entreprises utilisaient souvent exclusivement Active Directory (AD) sur site, ce qui en faisait la pierre angulaire de leur paysage informatique et de leur infrastructure sur site.

Aujourd'hui, les entreprises associent souvent Active Directory sur site et Azure Active Directory (Azure AD) pour gérer l'authentification et l'autorisation. Active Directory sur site peut être utilisé pour gérer des ressources sur site et peut être considéré comme le système d'enregistrement pour la gestion des comptes et des groupes d'utilisateurs. Toutefois, Azure AD est souvent utilisé pour gérer l'authentification et l'autorisation pour les déploiements dans le cloud.

Cet article explique comment étendre à Google Cloud votre solution existante de gestion des identités basée sur Active Directory et Azure AD, à l'aide de Cloud Identity ; toutefois, ces principes s'appliquent également à G Suite.

L'article suppose que vous connaissez Active Directory et Azure AD.

Fédérer Active Directory, Azure AD et Google Cloud

Google Cloud utilise les identités Google pour l'authentification et la gestion des accès. Pour accéder aux ressources Google Cloud, un employé doit posséder une identité Google. La gestion manuelle des identités Google pour chaque employé peut s'avérer fastidieuse lorsque tous les employés possèdent déjà un compte dans Active Directory ou Azure AD. En fédérant les identités des utilisateurs entre Cloud Identity et votre système de gestion des identités, vous pouvez automatiser la maintenance des comptes Google et associer leur cycle de vie à des comptes existants.

Si vous utilisez déjà Active Directory et Azure AD, deux options s'offrent à vous pour intégrer Google Cloud :

  1. Vous pouvez fédérer Active Directory directement avec Cloud Identity à l'aide de Google Cloud Directory Sync et des services AD FS (Active Directory Federation Services) :

    Google Cloud Directory Sync

    Bien que cette approche vous permette de contrôler avec précision les éléments à synchroniser entre Active Directory et Cloud Identity ainsi que la méthode à suivre pour effectuer cette synchronisation, elle ne tire pas parti d'Azure AD. De plus, cette approche nécessite que vous exécutiez Google Cloud Directory Sync et AD FS dans votre environnement informatique.

    Pour plus d'informations sur cette approche, reportez-vous au guide dédié.

  2. Vous pouvez fédérer Cloud Identity avec Azure AD. Ce dernier peut lui-même être fédéré avec une ou plusieurs forêts Active Directory sur site :

    Fédérer Cloud Identity avec Azure AD

    L'un des avantages de cette approche est qu'il n'est pas nécessaire d'installer de logiciel supplémentaire dans votre environnement sur site. Les mécanismes d'authentification compatibles avec Azure AD (y compris l'authentification directe et la synchronisation de hachage de mot de passe) peuvent également être utilisés pour Google Cloud.

Le reste de cet article se concentre sur la deuxième approche.

La fédération d'Azure AD avec Cloud Identity garantit les éléments suivants :

  • Active Directory et Azure AD restent la source unique de vérité pour la gestion des identités.
  • Un compte Google est créé automatiquement pour tous les comptes utilisateur ou pour un sous-ensemble sélectionné dans Azure AD.
  • Si un compte est désactivé ou supprimé dans Azure AD, le compte Google correspondant est également suspendu ou supprimé. En revanche, la suspension ou la suppression d'un compte Google n'a aucun effet sur Active Directory, car le compte Google est recréé automatiquement lors de la synchronisation suivante.
  • Azure AD gère l'authentification des utilisateurs. Ainsi, vous n'avez pas besoin de synchroniser les mots de passe avec Google Cloud.

La configuration de la fédération entre Azure AD et Cloud Identity implique deux tâches :

  • Provisionnement de comptes : les comptes utilisateur et les groupes concernés sont synchronisés périodiquement entre Azure AD et Cloud Identity. Lorsque vous créez un compte dans Azure AD ou synchronisez un nouveau compte Active Directory avec Azure AD, celui-ci devient également disponible dans Google Cloud. Il peut alors être référencé dans Google Cloud avant même que l'utilisateur associé ne se connecte pour la première fois. Ce processus garantit également la propagation des suppressions de comptes.

    Le provisionnement est à sens unique, ce qui signifie que toute modification dans Azure AD est répliquée dans Cloud Identity, mais pas l'inverse. De plus, le provisionnement n'inclut pas les mots de passe.

  • Authentification unique : chaque fois qu'un utilisateur doit s'authentifier dans Google Cloud, Cloud Identity délègue l'authentification à Azure AD à l'aide du protocole SAML (Security Assertion Markup Language). Selon votre configuration Azure AD, ce dernier peut effectuer l'une des opérations suivantes :

    • effectuer lui-même l'authentification ;
    • utiliser l'authentification directe ou la synchronisation de hachage de mot de passe ;
    • déléguer l'authentification à un serveur AD FS sur site.

Donner à Cloud Identity la possibilité de déléguer l'authentification à Azure AD évite non seulement d'avoir à synchroniser les mots de passe avec Google Cloud, mais garantit également l'application des règles ou des mécanismes d'authentification multifacteur (MFA, Multi-Factor Authentication) en vigueur configurés dans Azure AD ou AD FS.

Structure logique d'Azure AD

Lorsque vous utilisez Azure, vous utilisez un ou plusieurs locataires Azure AD (également appelés annuaires). Les locataires Azure AD constituent une structure de niveau supérieur. Ils sont considérés comme des limites administratives et servent de conteneurs pour les utilisateurs, les groupes, ainsi que les ressources et les groupes de ressources.

Chaque locataire Azure AD est associé à au moins un domaine DNS. Ce domaine DNS figure dans les noms d'utilisateur (également appelés noms d'utilisateur principaux ou UPN, User Principal Names), qui prennent la forme [name]@[domain], où [domain] est l'un des domaines DNS associés au locataire correspondant.

Structure logique d'Azure AD

Une entreprise peut gérer plusieurs locataires Azure AD. Cette approche est fréquemment utilisée pour faire la distinction entre différentes parties de l'organisation, séparer les ressources de production des ressources de développement et de test, ou encore pour utiliser des locataires distincts pour intégrer plusieurs forêts à partir d'Active Directory sur site.

Structure logique de Google Cloud

Dans Google Cloud, les organisations servent de conteneurs pour toutes les ressources et peuvent être segmentées à l'aide de dossiers et de projets. Toutefois, à l'exception des comptes de service, les organisations ne servent pas à gérer des comptes et groupes d'utilisateurs, ce qui les différencie des locataires Azure AD.

Pour gérer les utilisateurs et les groupes, Google Cloud s'appuie sur des comptes Cloud Identity (ou des comptes G Suite, non évoqués dans ce document).

Structure logique de GCP

Cloud Identity vous permet de créer et gérer des annuaires privés pour des comptes et groupes d'utilisateurs. Chacun de ces annuaires est géré indépendamment et peut, par exemple, différer au niveau des méthodes d'authentification autorisées ou des stratégies de mot de passe appliquées. Dans Cloud Identity, les annuaires sont désignés par le terme comptes Cloud Identity et sont identifiés par des noms de domaine.

Lorsque vous créez un compte Cloud Identity, une organisation Google Cloud associée à ce compte est créée automatiquement. Le compte Cloud Identity et l'organisation Google Cloud qui lui est associée portent le même nom et sont liés l'un à l'autre. Toutefois, une organisation Google Cloud est autorisée à référencer des utilisateurs et des groupes à partir d'autres comptes Cloud Identity.

Intégrer Azure AD et Google Cloud

Malgré certaines similitudes entre la structure logique d'Azure AD et celle de Google Cloud, il n'existe pas de mappage unique entre les deux structures à même d'assurer des performances similaires dans tous les scénarios possibles. Au lieu de cela, l'approche optimale à adopter pour intégrer les deux systèmes et mapper la structure dépend de plusieurs facteurs :

  • Comment mapper des locataires Azure AD sur des comptes Cloud Identity
  • Comment mapper des domaines DNS
  • Comment mapper des comptes utilisateur
  • Comment mapper des groupes

Les sections suivantes abordent chacun de ces facteurs.

Google Cloud n'interagit qu'avec Azure AD, et non avec votre solution Active Directory sur site. Aussi, la façon dont vous avez mappé les forêts et les domaines de votre solution Active Directory sur site sur Azure AD n'a que peu d'importance.

Mapper des locataires Azure AD

Locataire unique

Si vous utilisez un seul locataire Azure AD, vous pouvez le mapper sur un seul compte Cloud Identity et configurer la fédération entre les deux. Ce compte Cloud Identity constitue ensuite la base d'une seule organisation Google Cloud que vous pouvez utiliser pour gérer toutes les ressources Google Cloud.

Mappage d'un locataire sur un seul compte Cloud Identity

Locataires multiples

Dans les grandes organisations, il n'est pas rare d'avoir plusieurs locataires Azure AD. Des locataires multiples peuvent être utilisés pour différencier les environnements de test et de production ou les différentes parties d'une organisation.

Bien qu'il soit possible de provisionner des utilisateurs et des groupes de plusieurs locataires Azure AD vers un seul compte Cloud Identity, il est actuellement impossible de configurer l'authentification unique de manière à ce qu'elle fonctionne pour les utilisateurs de plusieurs locataires Azure AD. Si vous utilisez plusieurs locataires Azure AD, vous devez créer un compte Cloud Identity distinct pour chacun d'entre eux et configurer la fédération entre chaque paire.

Dans Google Cloud, une organisation distincte est créée pour chaque compte Cloud Identity. Google Cloud permet d'organiser les ressources à l'aide de projets et de dossiers au sein d'une même organisation. Il est donc souvent peu pratique de disposer de plusieurs organisations. Vous pouvez sélectionner l'une des organisations et l'associer aux autres comptes Cloud Identity, pour créer ainsi une organisation fédérée avec plusieurs forêts Active Directory. Les autres organisations restent inutilisées.

Organisation fédérée avec plusieurs forêts Active Directory

Utilisateurs externes

Azure AD B2B vous permet de convier des utilisateurs externes en tant qu'invités sur votre locataire Azure AD. Un utilisateur est créé pour chaque invité, auquel Azure AD attribue automatiquement un UPN. L'UPN généré par Azure AD utilise un préfixe dérivé de l'adresse e-mail de l'invité, associé au domaine initial du locataire : [prefix]#EXT#@[tenant].onmicrosoft.com.

Le provisionnement des utilisateurs invités entre Azure AD et Cloud Identity est soumis à certaines limitations :

  • Vous ne pouvez pas mapper l'UPN des utilisateurs invités avec les adresses e-mail dans Cloud Identity, car le domaine onmicrosoft.com ne peut pas être ajouté et vérifié dans Cloud Identity. Vous devez donc mapper les comptes utilisateur au moyen d'un attribut autre que l'UPN.
  • Si un utilisateur invité est suspendu dans son locataire d'origine, il est possible que l'utilisateur correspondant dans Cloud Identity demeure actif et que l'accès aux ressources Google Cloud ne soit pas correctement révoqué.

Afin de mieux gérer les utilisateurs invités qui proviennent d'un locataire Azure AD différent, il est préférable de créer plusieurs comptes Cloud Identity, comme indiqué dans la section précédente, chacun étant fédéré avec un locataire Azure AD différent.

Pour que l'accès à certaines ressources Google Cloud puisse être accordé à un utilisateur externe, celui-ci ne doit pas nécessairement disposer d'un compte dans Cloud Identity. Sauf en cas de restriction par des règles, vous pouvez également ajouter directement l'utilisateur externe en tant que membre à l'organisation, aux projets ou aux dossiers correspondants, à condition que cet utilisateur dispose d'un compte Google.

Mapper des domaines DNS

Le DNS joue un rôle crucial à la fois pour Azure AD et pour Cloud Identity. Lorsque vous envisagez de fédérer Azure AD et Google Cloud, le deuxième facteur à prendre en compte est le mode de partage ou de mappage des domaines DNS entre Active Directory et Google Cloud.

Utiliser des domaines DNS dans Google Cloud

Google Sign-In, sur lequel Google Cloud s'appuie pour l'authentification, utilise des adresses e-mail pour identifier les utilisateurs. L'utilisation d'adresses e-mail garantit non seulement que chaque utilisateur est unique, mais permet également à Google Cloud d'envoyer des messages de notification à ces adresses.

Google Sign-In définit l'annuaire de comptes ou le fournisseur d'identité à utiliser pour authentifier un utilisateur en fonction de la partie domaine des adresses e-mail, qui suit le caractère @. Par exemple, dans le cas d'une adresse e-mail basée sur le domaine gmail.com, Google Sign-In utilise l'annuaire des comptes utilisateur Gmail pour procéder à l'authentification.

Utiliser des domaines DNS dans GCP

Créer un compte G Suite ou Cloud Identity revient à créer un annuaire privé que Google Identity Platform peut exploiter à des fins d'authentification. De la même manière que l'annuaire Gmail est associé au domaine gmail.com, les comptes G Suite et Cloud Identity doivent être associés à un domaine personnalisé. Trois types de domaines sont utilisés :

  • Domaine principal : ce domaine identifie le compte Cloud Identity et sert également de nom d'organisation dans Google Cloud. Vous devez spécifier ce nom de domaine lors de votre inscription à Cloud Identity.
  • Domaine secondaire : en plus du domaine principal, vous pouvez associer des domaines secondaires à un annuaire Cloud Identity. Chaque compte de l'annuaire est associé soit au domaine principal, soit à l'un des domaines secondaires. Deux comptes tels que johndoe@example.com et johndoe@secondary.example.com sont donc considérés comme des comptes distincts si example.com est le domaine principal et secondary.example.com le domaine secondaire d'un annuaire.
  • Domaine d'alias : un domaine d'alias est un domaine alternatif pour le domaine principal. Cela signifie que johndoe@example.com et johndoe@alias.example.com font référence au même compte si alias.example.com est configuré en tant que domaine d'alias. Un domaine d'alias ne peut fournir un nom alternatif qu'au domaine principal : il n'est pas possible d'ajouter des domaines d'alias pour les domaines secondaires.

Tous les domaines doivent répondre aux exigences suivantes :

  • Il doit s'agir de noms de domaine DNS globaux et valides. Durant la mise en place, vous aurez sans doute besoin d'un accès administrateur aux zones DNS correspondantes afin de valider la propriété du domaine.
  • Un domaine tel que example.com ne peut faire référence qu'à un seul annuaire. Toutefois, vous pouvez utiliser différents sous-domaines, par exemple subdomain.example.com, pour faire référence à différents annuaires.
  • Le domaine principal et les domaines secondaires doivent posséder un enregistrement MX valide pour que les messages envoyés aux adresses e-mail formées à partir de ce nom de domaine puissent être correctement remis.

Utiliser des domaines DNS dans Azure AD

La manière dont Cloud Identity utilise le DNS est semblable à la manière dont Azure AD s'appuie sur le DNS pour distinguer les locataires Azure AD et associer des noms d'utilisateur aux locataires. Toutefois, veuillez tenir compte des deux différences notables suivantes :

  1. Domaines initiaux : lorsque vous créez un locataire Azure AD, le locataire est associé à un domaine initial, qui est un sous-domaine de onmicrosoft.com. Ce domaine est différent de tout nom de domaine personnalisé que vous pourriez enregistrer, car vous ne possédez pas le domaine et vous ne disposez pas d'un accès administrateur à la zone DNS correspondante.

    Cloud Identity n'a pas d'équivalent au concept de domaine initial. Vous devez donc posséder tous les domaines que vous associez à un compte Cloud Identity. Cette condition signifie que vous ne pouvez pas enregistrer un sous-domaine onmicrosoft.com en tant que domaine Cloud Identity.

  2. Domaines utilisés dans les identifiants d'utilisateur : Azure AD fait la distinction entre les adresses e-mail MOERA (Microsoft Online Email Routing Addresses, adresses de routage des e-mails en ligne Microsoft) et les UPN. Tous deux respectent le format RFC 822 (user@domain), mais ils servent des objectifs différents : les UPN servent à identifier les utilisateurs et sont utilisés dans le formulaire d'inscription, alors que seules les adresses MOERA sont utilisées pour la remise des e-mails.

    Le suffixe de domaine utilisé par les UPN doit correspondre à l'un des domaines enregistrés de votre locataire Azure AD. Cette exigence ne s'applique pas aux adresses e-mail.

    Cloud Identity ne s'appuie pas sur le concept d'UPN, mais utilise l'adresse e-mail d'un utilisateur comme identifiant. Ainsi, le domaine utilisé par l'adresse e-mail doit correspondre à l'un des domaines enregistrés du compte Cloud Identity.

Azure AD et Cloud Identity peuvent utiliser les mêmes domaines DNS. Compte tenu des deux différences décrites ci-dessus, vous devez baser votre mappage de domaine sur la manière dont vous envisagez de mapper les comptes utilisateur entre Azure AD et Cloud Identity.

Mapper des comptes utilisateur

Le troisième facteur à prendre en compte lorsque vous envisagez de fédérer Active Directory avec Google Cloud est le mappage des comptes utilisateur entre Azure AD et Cloud Identity.

Le mappage de comptes Azure AD et de comptes Cloud Identity requiert deux informations pour chaque compte utilisateur :

  1. Un identifiant unique et stable que vous pouvez utiliser lors de la synchronisation pour déterminer quel compte Azure AD correspond à quel compte Cloud Identity.
  2. Une adresse e-mail dont la partie "domaine" correspond à un domaine principal, secondaire ou d'alias dans Cloud Identity. Cette adresse e-mail doit être lisible, car elle sera utilisée partout dans Google Cloud.

En interne, Azure AD identifie les utilisateurs à l'aide d'ObjectId, un ID unique généré de manière aléatoire. Bien que cet ID soit stable et corresponde donc à la première condition, il est dénué de sens pour l'humain et ne respecte pas le format d'une adresse e-mail. Pour mapper des utilisateurs, les seules options pratiques consistent à effectuer un mappage par UPN ou par adresse e-mail.

Mapper des comptes utilisateur par adresse e-mail

Si l'utilisateur saisit une adresse e-mail appartenant à un compte Cloud Identity configuré pour utiliser l'authentification unique avec Azure AD, il est alors redirigé vers l'écran de connexion d'Azure AD.

Azure AD utilise des UPN, et non des adresses e-mail, pour identifier les utilisateurs. L'écran de connexion invite l'utilisateur à fournir un UPN.

Écran de connexion demandant un UPN

Si le locataire Azure AD est configuré pour utiliser AD FS pour l'authentification, l'utilisateur est redirigé vers l'écran de connexion d'AD FS. Les utilisateurs peuvent se connecter aux services AD FS à l'aide de leur UPN Active Directory ou de leur nom de connexion antérieur à Windows 2000 (domain\user).

Écran de connexion d'AD FS

Si l'adresse e-mail utilisée pour Cloud Identity, l'UPN utilisé par Azure AD et l'UPN utilisé par Active Directory sont tous différents, les différents écrans de connexion peuvent vite devenir confus pour les utilisateurs finaux. En revanche, si les trois identifiants sont les mêmes, comme c'est le cas dans les captures d'écran données à titre d'exemple (johndoe@example.com), les utilisateurs ne sont pas confrontés aux différences techniques entre les UPN et les adresses e-mail, ce qui minimise les risques de confusion.

Mapper des utilisateurs par UPN

Du point de vue de l'expérience utilisateur, le mappage des UPN Azure AD à des adresses e-mail Cloud Identity peut être considéré comme la meilleure option. Le fait de s'appuyer sur les UPN présente un autre avantage : Azure AD garantit l'unicité et vous permet ainsi d'éviter les risques de conflits de noms.

Pour mapper des UPN Azure AD à des adresses e-mail Cloud Identity, vous devez toutefois répondre aux exigences suivantes :

  • Les UPN Azure AD doivent être des adresses e-mail valides afin que tous les e-mails de notification envoyés par Google Cloud soient correctement remis dans la boîte aux lettres de l'utilisateur. Dans le cas contraire, vous pouvez configurer des adresses e-mail d'alias pour vous assurer que l'utilisateur reçoit ces e-mails.
  • Les UPN de tous les utilisateurs concernés dans Azure AD doivent comporter un domaine personnalisé comme suffixe ([user]@[custom-domain]). Les UPN utilisant le domaine initial Azure AD ([user]@[tenant].onmicrosoft.com) ne peuvent pas être mappés à des adresses e-mail dans Cloud Identity, car le domaine initial n'est pas détenu par vous, mais par Microsoft.
  • Tous les domaines personnalisés utilisés par Azure AD pour les UPN doivent également être enregistrés dans Cloud Identity. Cela signifie que vous devez avoir accès aux zones DNS correspondantes pour pouvoir effectuer la validation de domaine. Afin d'éviter de remplacer les enregistrements DNS TXT existants que vous avez éventuellement créés pour valider la propriété du domaine dans Azure AD, vous pouvez utiliser un enregistrement CNAME pour valider la propriété du domaine dans Cloud Identity.

Pour Cloud Identity, les UPN n'ont pas besoin d'être identiques dans Active Directory et dans Azure AD. Toutefois, si vous utilisez AD FS, les utilisateurs profiteront d'une meilleure expérience si l'UPN dans Active Directory est identique à l'UPN dans Azure AD.

Mapper des utilisateurs par adresse e-mail

Si le mappage des UPN Azure AD aux adresses e-mail Cloud Identity n'est pas possible dans votre cas, vous pouvez mapper les comptes par adresse e-mail.

Lorsque vous spécifiez une adresse e-mail dans Active Directory, elle est stockée dans l'attribut mail de l'objet user correspondant. Azure AD Connect synchronise ensuite cette valeur avec l'attribut Mail dans Azure AD. Azure AD rend également l'attribut disponible pour le provisionnement des utilisateurs, afin que vous puissiez le mapper à l'adresse e-mail dans Cloud Identity.

L'attribut Azure AD Mail n'est actuellement pas affiché sur le portail Azure et ne peut être affiché et modifié que via des API ou PowerShell. Bien que l'interface utilisateur vous permette de spécifier une adresse e-mail et une adresse e-mail secondaire, aucune de ces valeurs n'est stockée dans l'attribut Mail. Elles ne peuvent donc pas être utilisées pour le provisionnement vers Cloud Identity. Ainsi, le mappage des utilisateurs d'une adresse e-mail n'est intéressant que lorsque vous créez et modifiez la plupart de vos utilisateurs dans Active Directory, et non dans Azure AD.

Pour mapper des utilisateurs par adresse e-mail, vous devez répondre aux exigences supplémentaires suivantes :

  • Les affectations des adresses e-mail doivent être exhaustives. Une adresse e-mail doit être attribuée à chacun des comptes utilisateur soumis à la synchronisation. Il se peut que ce ne soit pas le cas, en particulier lorsque les utilisateurs sont synchronisés à partir d'un annuaire Active Directory sur site, car mail est un attribut utilisateur facultatif dans Active Directory. Les utilisateurs dépourvus d'adresse e-mail dans l'attribut Azure AD Mail sont ignorés sans notification pendant la synchronisation.
  • Les adresses e-mail doivent être uniques au sein du locataire Azure AD. Bien qu'Active Directory ne vérifie pas l'unicité lors de la création du compte, Azure AD Connect détecte les collisions par défaut, ce qui peut entraîner l'échec de la synchronisation des comptes utilisateur affectés.
  • Les domaines utilisés par les adresses e-mail n'ont pas besoin d'être enregistrés dans Azure AD, mais ils doivent l'être dans Cloud Identity. Cette condition signifie que vous devez avoir accès aux zones DNS respectives pour effectuer la validation du domaine, ce qui exclut l'utilisation d'adresses e-mail de domaines qui ne vous appartiennent pas (comme gmail.com).

Mapper des groupes

Le quatrième facteur à prendre en compte lorsque vous envisagez de fédérer Active Directory et Google Cloud est la synchronisation et le mode de mappage des groupes entre Active Directory et Google Cloud.

Dans Google Cloud, les groupes sont couramment utilisés pour gérer efficacement l'accès entre projets. Plutôt que d'affecter des utilisateurs individuels aux rôles Cloud IAM (Cloud Identity and Access Management) dans chaque projet, vous définissez un ensemble de groupes modélisant les rôles courants au sein de votre organisation. Vous affectez ensuite ces groupes à un ensemble de rôles Cloud IAM. Modifier l'appartenance aux groupes vous permet de contrôler l'accès des utilisateurs à un ensemble complet de ressources.

Le mappage de groupes entre Azure AD et Google Cloud est facultatif. Une fois les comptes utilisateur fédérés, vous pouvez créer et gérer des groupes directement dans Cloud Identity, ce qui signifie qu'Active Directory ou Azure AD reste le système central pour la gestion des identités, mais pas pour la gestion des accès Google Cloud.

Pour préserver le rôle central d'Active Directory ou d'Azure AD pour la gestion des identités et des accès, nous vous recommandons de synchroniser les groupes à partir d'Azure AD plutôt que de les gérer dans Cloud Identity. Cette approche vous permet de configurer Cloud IAM afin d'exploiter l'appartenance à des groupes dans Active Directory ou Azure AD pour contrôler qui a accès aux ressources dans Google Cloud.

Groupes dans Cloud Identity

Dans Cloud Identity, il n'existe qu'un seul type de groupe. Les groupes dans Cloud Identity ne se limitent pas au champ d'application du compte Cloud Identity dans lequel ils ont été définis. Ils peuvent inclure des comptes utilisateur issus de différents comptes Cloud Identity, être référencés et imbriqués dans d'autres comptes Cloud Identity, et être utilisés dans toute organisation Google Cloud.

Comme pour les comptes utilisateur, Cloud Identity identifie les groupes par adresse e-mail. L'adresse e-mail ne doit pas nécessairement correspondre à une boîte aux lettres réelle, mais elle doit utiliser l'un des domaines enregistrés pour le compte Cloud Identity correspondant.

Lorsque vous travaillez avec des groupes dans Cloud IAM, vous devez souvent spécifier des groupes par adresse e-mail plutôt que par nom. Il est donc préférable que les groupes aient non seulement un nom significatif, mais également une adresse e-mail pertinente et reconnaissable.

Groupes dans Azure AD

Azure AD accepte plusieurs types de groupes, chacun correspondant à différents cas d'utilisation. Les groupes sont limités à un seul locataire et sont identifiés par un ID d'objet, qui est un identifiant unique généré de manière aléatoire. Les groupes peuvent être imbriqués et peuvent contenir soit des utilisateurs du même locataire, soit des utilisateurs invités depuis d'autres locataires utilisant Azure B2B. Azure AD est également compatible avec les groupes dynamiques, dont les membres sont définis automatiquement en fonction d'une requête.

Dans le contexte de l'intégration d'Azure AD à Cloud Identity, deux propriétés de groupe sont particulièrement intéressantes, à savoir l'extension messagerie et la sécurité :

  • Un groupe sécurisé peut être utilisé pour gérer l'accès aux ressources dans Azure AD. Tout groupe dont la sécurité est activée est donc potentiellement pertinent dans le contexte de Google Cloud.
  • Un groupe à extension messagerie possède une adresse e-mail, ce qui est intéressant puisque Cloud Identity exige que les groupes soient identifiés par une adresse e-mail.

Dans Azure AD, vous pouvez créer des groupes de type Sécurité ou Office 365 (parfois appelés groupes unifiés). Lors de la synchronisation de groupes à partir d'Active Directory sur site ou lors de l'utilisation du type Office 365, vous pouvez également créer des groupes de type Liste de distribution.

Le tableau suivant récapitule les différences entre ces différents types de groupes en ce qui concerne l'extension messagerie ou la sécurité, ainsi que la manière dont ils sont mappés aux types de groupe Active Directory, en se basant sur une configuration Azure AD Connect par défaut :

Source Type de groupe Active Directory Type de groupe Azure AD Extension messagerie Sécurité
Azure AD - Groupe Office 365 Toujours Facultatif
Azure AD - Groupe de sécurité Facultatif Toujours
sur site Groupe de sécurité (avec e-mail) Groupe de sécurité Oui Oui
sur site Groupe de sécurité (sans e-mail) Groupe de sécurité Non Oui
sur site Liste de distribution (avec e-mail) Liste de distribution Oui Non
sur site Liste de distribution (sans e-mail) (ignoré par Azure AD Connect)

Contrairement aux utilisateurs, Azure AD requiert que les adresses e-mail affectées à des groupes utilisent un domaine qui a été enregistré en tant que domaine personnalisé dans Azure AD. Cette condition entraîne le comportement par défaut suivant :

  • Si un groupe dans Active Directory utilise une adresse e-mail basée sur un domaine précédemment enregistré dans Azure AD, l'adresse e-mail est correctement conservée lors de la synchronisation avec Azure AD.
  • Si un groupe dans Active Directory utilise une adresse e-mail qui n'a pas été enregistrée dans Azure AD, Azure AD génère automatiquement une nouvelle adresse e-mail lors de la synchronisation. Cette adresse e-mail utilise le domaine par défaut du locataire. Si votre locataire utilise le domaine initial comme domaine par défaut, l'adresse e-mail obtenue sera au format [name]@[tenant].onmicrosoft.com.
  • Si vous créez un groupe Office 365 dans Azure AD, Azure AD génère également automatiquement une adresse e-mail qui utilise le domaine par défaut du locataire.

Mapper des identités de groupe

Le mappage des groupes Azure AD avec les groupes Cloud Identity requiert un identifiant commun, et Cloud Identity requiert que cet identifiant soit une adresse e-mail. Du côté d'Azure AD, cette exigence vous laisse deux options :

  • Vous pouvez utiliser l'adresse e-mail d'un groupe dans Azure AD et la mapper avec une adresse e-mail Cloud Identity.
  • Vous pouvez générer une adresse e-mail à partir du nom du groupe dans Azure AD et mapper l'adresse résultante avec une adresse e-mail dans Cloud Identity.

Mappage par adresse e-mail

Le mappage de groupes par adresse e-mail est le choix le plus évident, mais il implique de respecter plusieurs exigences :

  • Tous les groupes soumis à la synchronisation doivent posséder une adresse e-mail. En pratique, cela signifie que vous ne pouvez synchroniser que des groupes à extension messagerie. Les groupes sans adresse e-mail sont ignorés lors du provisionnement.
  • Les adresses e-mail doivent être uniques au sein du locataire. Comme Azure AD n'impose pas l'unicité des adresses, vous devrez peut-être mettre en œuvre des stratégies ou des contrôles personnalisés.
  • Les domaines utilisés par les adresses e-mail doivent être enregistrés à la fois dans Azure AD et dans Cloud Identity. La synchronisation échouera pour tous les groupes dont les adresses e-mail utilisent des domaines non enregistrés dans Cloud Identity, y compris le domaine [tenant].onmicrosoft.com.

Si tous les groupes concernés répondent à ces critères, identifiez les domaines utilisés par ces adresses e-mail et vérifiez qu'ils font bien partie de la liste des domaines DNS enregistrés dans Cloud Identity.

Mappage par nom

Répondre aux critères requis pour mapper des groupes par adresse e-mail peut s'avérer difficile, en particulier si un grand nombre des groupes de sécurité que vous souhaitez provisionner dans Cloud Identity ne sont pas à extension messagerie. Dans ce cas, il peut être préférable de générer automatiquement une adresse e-mail à partir du nom complet du groupe.

La génération d'une adresse e-mail présente deux difficultés :

  1. Une adresse e-mail dérivée du nom d'un groupe peut entrer en conflit avec l'adresse e-mail d'un utilisateur.
  2. Azure AD n'impose pas l'unicité des noms de groupe. Si plusieurs groupes de votre locataire Azure AD partagent le même nom, les adresses e-mail dérivées de ce nom entreront en conflit, et un seul groupe sera donc synchronisé correctement.

Vous pouvez résoudre la première difficulté en utilisant pour l'adresse e-mail générée un domaine différent de tous les domaines utilisés par les utilisateurs. Par exemple, si tous vos utilisateurs utilisent des adresses e-mail du domaine example.com, vous pouvez choisir groups.example.com pour tous les groupes. L'enregistrement de sous-domaines dans Cloud Identity ne nécessite pas de validation de domaine. La zone DNS groups.example.com n'a donc pas besoin d'exister.

La deuxième difficulté, qui concerne la duplication des noms de groupe, ne peut se résoudre que techniquement, en générant l'adresse e-mail du groupe à partir de l'ID d'objet. Comme les noms de groupe résultants sont plutôt difficiles à lire et à manipuler, il est préférable d'identifier et de renommer les noms de groupe en double dans Azure AD avant de configurer le provisionnement vers Cloud Identity.

Gérer le cycle de vie des comptes utilisateur

L'identification du bon mappage entre les locataires, les domaines, les utilisateurs et les groupes vous permet d'automatiser la gestion des comptes utilisateur et des groupes dans Cloud Identity. Mais comment faire pour savoir quels comptes et groupes d'utilisateurs provisionner et pour définir ceux pour lesquels vous devez activer l'authentification unique ?

Gérer les arrivées

Selon la façon dont vous envisagez d'utiliser Google Cloud, tous les utilisateurs disposant d'un compte dans Azure AD ou pour lesquels vous créez un compte pourraient également bénéficier de l'autorisation d'accéder à Google Cloud. Toutefois, il est plus probable que seul un sous-ensemble de vos utilisateurs aient besoin d'accéder à Google Cloud. Il est donc intéressant de distinguer quatre ensembles de comptes utilisateur dans Azure AD :

  • Accounts in Azure AD (Comptes dans Azure AD) : indique le nombre total de comptes dans Azure AD.
  • Accounts provisioned to Cloud Identity (Comptes provisionnés vers Cloud Identity) : sous-ensemble de comptes Azure AD affectés pour le provisionnement vers Cloud Identity.
  • Accounts enabled for SSO (Comptes pour lesquels SSO est activé) : sous-ensemble de comptes Azure AD affectés pour l'authentification unique.
  • Accounts granted access in Cloud IAM (Comptes disposant d'un accès dans Cloud IAM) : sous-ensemble de comptes Azure AD provisionnés vers Cloud Identity et autorisés à accéder à toutes les ressources Google Cloud.

Pour pouvoir utiliser les ressources Google Cloud, un compte doit être configuré sur Cloud Identity, pouvoir utiliser l'authentification unique et bénéficier d'un accès dans Cloud IAM.

Un compte provisionné vers Cloud Identity et pour lequel l'authentification unique est activée, mais n'ayant pas accès à Cloud IAM, ne pourra pas utiliser Google Cloud, mais pourra toujours utiliser d'autres outils Google tels que Data Studio.

Un compte qui a été provisionné dans Cloud Identity mais pour lequel l'authentification unique n'est pas activée n'est pas très intéressant pour l'utilisateur, car il ne lui permet pas de se connecter. En revanche, l'existence du compte dans Cloud Identity empêche l'utilisateur d'utiliser son adresse e-mail professionnelle pour créer un compte personnel sur YouTube, la recherche Google ou sur d'autres sites Google. Autoriser les employés à utiliser des comptes personnels à des fins professionnelles peut être risqué, car votre entreprise ne contrôle pas les comptes, leur cycle de vie et leur sécurité. Par conséquent, il peut être préférable de bloquer l'inscription.

Il peut être utile d'activer l'authentification unique pour un compte sans provisionner ce dernier dans Cloud Identity en cas de migration de comptes personnels existants vers Cloud Identity. En dehors d'une migration, peu de raisons peuvent vous inciter à activer l'authentification unique pour un compte qui n'est pas également provisionné dans Cloud Identity.

Provisionnement et activation de l'authentification unique pour tous les comptes

Compte tenu de l'interaction entre ces quatre ensembles d'utilisateurs, l'approche la plus simple consiste à provisionner tous les comptes Azure AD vers Cloud Identity et à activer l'authentification unique pour tous les comptes, tout en n'accordant l'accès aux ressources qu'à un sous-ensemble d'utilisateurs approprié :

Provisionnement et activation de l'authentification unique pour tous les comptes

Dans les grandes organisations, il est recommandé d'accorder des autorisations en fonction de groupes, et non en fonction des individus. Les groupes que vous utilisez à cette fin peuvent être des groupes créés dans Cloud Identity ou des groupes provisionnés à partir d'Azure AD.

Vous pouvez décider d'utiliser Cloud Identity pour créer et gérer les groupes pour contrôler l'accès aux ressources Google Cloud. Cette approche présente l'avantage de faciliter la mise à disposition de tous les comptes utilisateur dans Cloud Identity lorsque vous décidez d'accorder l'accès à un groupe à davantage d'utilisateurs. Sinon, pour accorder un accès utilisateur à Google Cloud, vous devrez d'abord effectuer des modifications dans Azure AD, attendre la synchronisation du compte utilisateur, puis effectuer d'autres actions dans Cloud Identity.

Provisionnement et activation de l'authentification unique pour le plus petit ensemble de comptes

Le provisionnement de tous les comptes Azure AD vers Cloud Identity et l'activation de l'authentification unique impliquent que tous les utilisateurs puissent accéder aux outils extérieurs à Google Cloud, tels que Data Studio, ce qui peut sembler superflu. Une autre approche consiste à ne provisionner que le plus petit ensemble possible de comptes vers Cloud Identity. Idéalement, cet ensemble ne comprend que les comptes disposant également d'un accès à Cloud IAM.

Provisionnement et activation de l'authentification unique pour le plus petit ensemble de comptes

Si vous utilisez des groupes pour gérer les accès, mais décidez de gérer ces groupes dans Azure AD au lieu de Cloud Identity, vous pouvez vous assurer que seuls les comptes pertinents sont provisionnés en utilisant les mêmes groupes pour contrôler l'affectation à l'application d'entreprise correspondante. Une autre solution consiste à créer un groupe dynamique dans Azure AD pour estimer l'ensemble des comptes pouvant nécessiter l'accès à Google Cloud.

L'un des inconvénients de cette approche est que les utilisateurs dont les comptes ne sont pas provisionnés peuvent toujours créer un compte personnel à l'aide de leur adresse e-mail professionnelle.

Provisionnement de tous les utilisateurs et activation de l'authentification unique pour le plus petit ensemble de comptes

Vous pouvez remédier à l'inconvénient de l'approche précédente en provisionnant tous les comptes vers Cloud Identity, tout en n'activant l'authentification unique que pour les utilisateurs pour lesquels vous envisagez également d'accorder l'accès dans Cloud IAM.

Provisionnement de tous les utilisateurs et activation de l'authentification unique pour le plus petit ensemble de comptes

Cette approche empêche la création de comptes personnels et permet d'éviter qu'un trop grand nombre d'utilisateurs puissent se connecter aux services Google.

Gérer les départs

Accorder aux utilisateurs l'accès à Google Cloud au moment opportun est aussi important que de révoquer cet accès lorsqu'ils quittent ces rôles ou en changent. Lorsqu'un utilisateur est supprimé dans Azure AD, les tentatives d'authentification unique ultérieures pour cet utilisateur échouent. En outre, le compte utilisateur correspondant dans Cloud Identity est suspendu.

De même, si vous supprimez un utilisateur d'un groupe en cours de synchronisation avec Cloud Identity, cette suppression d'appartenance sera reflétée dans Cloud Identity, ce qui fera perdre à l'utilisateur toutes les autorisations associées au groupe.

Étapes suivantes