Bonnes pratiques concernant l'utilisation de Google Groupes

Ce document décrit certaines bonnes pratiques concernant l'utilisation des groupes Google pour gérer l'accès aux ressources Google Cloud avec Identity and Access Management (IAM).

Types de groupes

Les types de groupes listés ici sont une façon de penser, d'utiliser et de gérer les groupes Google. Ces types de groupes ne sont définis par aucun attribut de groupe Google. Toutefois, l'utilisation de ces types de groupes dans votre approche globale de la gestion des groupes Google peut vous aider à éviter certains pièges de sécurité courants.

Ce document utilise les types de groupes suivants :

  • Groupes organisationnels

    Les groupes organisationnels représentent des sous-ensembles de la structure d'une organisation et proviennent généralement des données des ressources humaines. Ils peuvent être basés sur le service, la structure hiérarchique, l'emplacement géographique ou d'autres regroupements organisationnels.

    Les membres d'un groupe organisationnel changent lorsqu'un employé rejoint l'organisation, change de service ou quitte l'organisation.

    La structure globale des groupes d'organisations peut changer lorsque l'entreprise se réorganise. Une réorganisation peut entraîner la création de groupes ou la suppression de groupes existants.

    Voici quelques exemples de groupes organisationnels : org.marketing-fte, org.finance-all, org.msmith-reports, org.apac-all et org.summer-interns.

    Les groupes de l'organisation sont généralement utilisés pour la communication par e-mail.

  • Groupes de collaboration

    Les groupes de collaboration représentent des groupes de travail, des membres de projet ou des utilisateurs qui souhaitent collaborer sur un projet ou discuter d'un sujet spécifique.

    La structure des groupes de collaboration n'est associée à aucune structure organisationnelle. Elles sont souvent créées de manière ponctuelle et en libre-service.

    L'accès aux groupes de collaboration peut être illimité, ce qui permet à tous les membres de l'organisation de les rejoindre. Un groupe de collaboration peut également être autogéré, ce qui signifie que certains membres peuvent décider qui inclure dans le groupe.

    Voici quelques exemples de groupes de collaboration : collab.security-discuss et collab.website-relaunch.

    Les groupes de collaboration sont généralement utilisés pour communiquer par e-mail.

  • Groupes d'accès

    Les groupes d'accès sont utilisés dans le seul but de fournir un accès. Ils représentent des fonctions de poste et sont utilisés pour simplifier l'attribution des rôles requis pour effectuer ces fonctions. Au lieu d'attribuer des rôles à des comptes principaux individuels, vous les attribuez au groupe, puis vous gérez les membres du groupe.

    La structure des groupes d'accès est influencée par celle des ressources ou des charges de travail de votre organisation. Le déploiement d'une nouvelle ressource ou charge de travail peut nécessiter la création de groupes d'accès.

    L'appartenance à des groupes d'accès est généralement contrôlée par un ou plusieurs propriétaires de groupe, qui invitent les utilisateurs à rejoindre le groupe ou approuvent leurs demandes d'adhésion.

    Voici quelques exemples de groupes d'accès : access.prod-firewall-admins, access.finance-datamart-viewers et access.billing-dashboard-users.

    Les groupes d'accès ne sont utilisés que pour fournir l'accès. Elles ne sont pas utilisées à des fins de communication.

  • Groupes chargés de l'application du règlement

    Les groupes d'application sont semblables aux groupes d'accès, sauf qu'ils servent à appliquer des règles de restriction d'accès plutôt qu'à fournir un accès.

    La structure des groupes chargés de l'application des règles est généralement influencée par une combinaison d'exigences de conformité et de structure organisationnelle.

    L'appartenance à un groupe d'application des règles est généralement déterminée par un ensemble de règles prédéfinies qui examinent le niveau d'habilitation, l'emplacement ou le rôle d'un utilisateur dans l'organisation.

    Voici quelques exemples de groupes d'application : enforcement.users-in-restricted-locations, enforcement.fedramp-low et enforcement.sso-users.

    Les groupes d'application ne sont utilisés que pour appliquer les règles de restriction d'accès. Elles ne sont pas utilisées à des fins de communication.

Nommez vos groupes en fonction de leur type.

Pour vous aider à suivre les bonnes pratiques décrites dans le reste de ce document, utilisez des noms de groupes qui vous permettent de déterminer le type d'un groupe à partir de son nom. Vous pouvez utiliser une convention de dénomination ou des domaines secondaires.

Convention d'attribution de noms

Voici un exemple de convention de nommage permettant de rendre le type de groupe visible :

  • Groupes organisationnels : org.GROUP_NAME@example.com. Exemple :org.finance-all@example.com

  • Groupes de collaboration : collab.TEAM_NAME@example.com. Exemple :collab.msmiths-team@example.com

  • Groupes d'accès : access.JOB_FUNCTION@example.com. Exemple : access.billing-dashboard-users@example.com.

  • Groupes de mesures d'application : enforcement.GROUP_DESCRIPTION@example.com. Exemple :enforcement.sso-users@example.com

Adoptez la convention qui convient à votre organisation et qui est compatible avec votre logiciel de gestion des groupes. L'utilisation d'un préfixe permet d'alphabétiser vos groupes par fonction, mais certains systèmes de gestion de groupes, tels que Groups for Business, n'acceptent que les suffixes. Si vous ne pouvez pas utiliser de préfixes, vous pouvez utiliser des suffixes ou des domaines secondaires.

Domaines secondaires

Au lieu d'utiliser des conventions de nommage, vous pouvez utiliser des domaines secondaires pour intégrer le type de groupe dans le nom (par exemple, access.example.com). Les domaines secondaires qui sont des sous-domaines d'un domaine validé n'ont pas besoin d'être validés ni d'exister dans le DNS. De plus, en ne créant pas d'enregistrements DNS Mail Exchange (MX) pour les domaines secondaires, vous pouvez empêcher les e-mails entrants d'arriver dans des groupes qui ne sont pas destinés à la communication.

Règles d'imbrication

Les règles concernant l'imbrication (l'acceptation d'un groupe en tant que membre) varient selon le type de groupe.

Règles d'imbrication pour les groupes organisationnels

Il est recommandé d'imbriquer les groupes d'organisation pour refléter votre organigramme. Cette approche signifie que chaque employé est inclus dans un groupe, puis que les groupes s'incluent mutuellement. Par exemple, le groupe org.finance-all peut contenir les groupes org.finance-us, org.finance-germany et org.finance-australia en tant que membres.

Vous pouvez ajouter des groupes organisationnels à n'importe quel autre type de groupe en tant que membres. Cela peut être beaucoup plus simple que d'avoir à ajouter tous les membres d'un groupe d'organisation à un autre groupe.

N'ajoutez aucun autre type de groupe à un groupe organisationnel en tant que membre. N'utilisez pas de groupes d'accès, d'application ou de collaboration dans une hiérarchie organisationnelle.

Règles d'imbrication pour les groupes de collaboration

Chaque groupe de collaboration doit disposer d'un ensemble de règles bien défini qui détermine comment les membres sont ajoutés. Si deux groupes de collaboration suivent les mêmes règles d'appartenance, ils peuvent être imbriqués. Toutefois, l'imbrication de groupes de collaboration avec des règles d'appartenance différentes peut permettre à des membres qui ne respectent pas les règles d'appartenance d'un groupe de devenir membres. Examinez attentivement les règles relatives aux membres avant d'imbriquer des groupes de collaboration.

Les groupes de collaboration peuvent avoir des groupes organisationnels comme membres.

Règles d'imbrication pour les groupes d'accès

En règle générale, vous ne devez pas imbriquer les groupes d'accès. Il peut être difficile de déterminer qui a accès à quelles ressources lorsque les groupes d'accès sont imbriqués. De plus, l'imbrication de groupes d'accès avec des règles d'accès différentes peut permettre aux principaux de contourner les règles strictes d'appartenance à un groupe d'accès.

Les groupes d'accès peuvent inclure des groupes organisationnels en tant que membres.

Règles d'imbrication pour les groupes d'application

N'imbriquez pas les groupes d'application. L'imbrication de groupes d'application peut rendre difficile la détermination de la raison pour laquelle l'accès est refusé à un compte principal. En outre, l'imbrication de groupes d'application avec des règles d'appartenance différentes peut entraîner l'application de restrictions non souhaitées à certains principaux.

Les groupes d'application peuvent avoir des groupes organisationnels comme membres.

Gérer les groupes organisationnels

Suivez les bonnes pratiques ci-dessous pour gérer vos groupes organisationnels.

Provisionner à partir d'une source de vérité unique

Étant donné que les groupes organisationnels sont basés sur des données de ressources humaines, il est préférable de les provisionner exclusivement à partir d'un système d'information sur les ressources humaines ou d'une source de vérité externe, par exemple un fournisseur d'identité externe (IdP) ou un système de gouvernance des identités tel que Sailpoint, Okta ou Entra ID.

Ne pas autoriser les modifications de groupe

N'ajoutez ni ne supprimez manuellement des utilisateurs d'un groupe organisationnel, et n'autorisez pas les utilisateurs à se retirer eux-mêmes d'un groupe organisationnel.

Éviter d'utiliser des groupes organisationnels pour accorder l'accès aux ressources

Il est rare que tous les utilisateurs d'un groupe organisationnel aient besoin du même niveau d'accès aux ressources. C'octroi d'un accès à un groupe organisationnel risque donc d'entraîner l'attribution d'un accès plus étendu que nécessaire à certains membres du groupe.

De plus, un délai peut s'écouler entre le moment où des modifications sont apportées à un IdP externe et celui où elles sont propagées à Cloud Identity, en fonction de la fréquence de synchronisation de l'IdP externe à Cloud Identity. Ce délai peut entraîner la prolifération d'autorisations excessives. Par exemple, cela peut inciter les propriétaires de ressources à accorder l'accès à des groupes existants au lieu d'en créer un, même si ces groupes existants contiennent des personnes qui n'ont pas besoin d'accéder à la ressource.

Si vous devez accorder l'accès à l'aide d'un groupe de l'organisation, ajoutez-le en tant que membre à un groupe d'accès au lieu d'accorder l'accès directement. N'accordez que des rôles avec des autorisations limitées, comme "Lecteur de l'organisation'organisation". Sinon, utilisez des groupes d'accès pour accorder l'accès aux ressources.

Ne pas autoriser les comptes de service ni les utilisateurs externes dans les groupes de l'organisation

N'incluez pas de comptes de service dans les groupes organisationnels, car ils ne représentent pas des personnes.

Les utilisateurs externes (ceux qui proviennent d'un autre compte Google Workspace ou Cloud Identity) ne font généralement pas partie de votre organisation. Il n'y a donc aucune raison pour qu'ils soient membres d'un groupe de l'organisation. Si vous intégrez votre personnel externe à votre propre compte Google Workspace ou Cloud Identity, il est considéré comme un utilisateur interne et peut être inclus dans vos groupes organisationnels.

Utilisez les groupes de sécurité Cloud Identity et les restrictions de groupe pour appliquer ces règles.

Gérer les groupes de collaboration

Appliquez les bonnes pratiques suivantes pour gérer vos groupes de collaboration.

Utiliser Groups for Business pour gérer les groupes de collaboration

Si vous utilisez Google Workspace, vous pouvez utiliser Groups for Business pour gérer les groupes de collaboration. Cela permet aux utilisateurs d'utiliser Google Groupes pour créer des groupes, les parcourir et les rejoindre. Vous devez configurer Groups for Business pour permettre aux utilisateurs de créer des groupes de collaboration.

Désactiver Groups for Business si vous ne l'utilisez pas

Si vous utilisez Cloud Identity, mais pas Google Workspace, il n'y a aucune raison d'avoir des groupes de collaboration dans Cloud Identity. Il est donc préférable de désactiver Groupes pour les entreprises pour empêcher vos utilisateurs de créer des groupes dans Cloud Identity.

Forcer un suffixe pour les groupes de collaboration

Si vous utilisez Groups for Business, configurez-le pour appliquer un suffixe. C'est particulièrement important si vous autorisez tout le monde à créer de nouveaux groupes Groups for Business.

L'application d'un suffixe empêche les utilisateurs de créer un groupe dont le nom entre en conflit intentionnellement avec un groupe d'accès ou un groupe organisationnel qui est sur le point d'être provisionné à partir d'une source externe. Dans ce scénario, le créateur du groupe de collaboration dont le nom est incorrect pourrait escalader ses droits d'accès.

N'utilisez pas les groupes de collaboration pour contrôle des accès

Les groupes de collaboration sont censés avoir un contrôle des accès souple et ne suivent généralement pas un cycle de vie bien défini. Elles sont donc idéales pour la collaboration, mais pas pour le contrôle des accès.

Si vous avez suivi à la lettre une convention d'attribution de noms pour vos groupes de collaboration, vous pouvez créer une contrainte de règle d'administration personnalisée pour empêcher l'attribution de rôles IAM aux groupes de collaboration.

De même, si vous provisionnez et gérez vos groupes de collaboration en externe, ne les provisionnez pas dans Cloud Identity, car ils pourraient être utilisés à mauvais escient à des fins de contrôle des accès.

Gérer les groupes d'accès

Suivez les bonnes pratiques ci-dessous pour gérer vos groupes d'accès.

Sélectionner le bon outil pour gérer vos groupes d'accès

Étant donné que les groupes d'accès sont gérés par les propriétaires de charges de travail, utilisez un outil adapté au self-service. Votre outil doit permettre aux utilisateurs de trouver les groupes d'accès existants et d'appliquer des mesures de sécurité qui mettent en œuvre les contrôles suivants :

  • Qui (membres de quel groupe organisationnel) peut rejoindre un groupe d'accès ?

  • Quelles sont les conditions à remplir pour qu'un utilisateur puisse rejoindre un groupe ?

    Par exemple, les utilisateurs doivent-ils fournir une justification ?

  • Durée de vie maximale de l'appartenance à un groupe

  • Si l'adhésion doit être approuvée et par qui

  • Compatibilité avec la piste d'audit

Un outil qui répond à ces exigences est JIT Groups.

Utiliser des groupes d'accès pour modéliser les fonctions et accorder l'accès aux ressources

Créez un groupe d'accès pour chaque fonction et accordez-lui l'accès à toutes les ressources dont les utilisateurs de cette fonction ont besoin. Vous pouvez ensuite ajouter des utilisateurs à ce groupe pour leur accorder l'accès dont ils ont besoin, au lieu d'attribuer les mêmes rôles à chaque utilisateur individuel.

Vous pouvez utiliser un seul groupe d'accès pour fournir l'accès à plusieurs ressources, voire à plusieurs projets. Toutefois, assurez-vous que chaque membre du groupe a besoin de l'accès que vous accordez au groupe. Si certains utilisateurs n'ont pas besoin de cet accès supplémentaire, créez un groupe d'accès et accordez-lui cet accès.

Utiliser vos groupes d'accès pour une charge de travail spécifique

La réutilisation de groupes d'accès pour plusieurs charges de travail entraîne une complexité excessive en termes d'autorisations et d'administration.

Supprimer les obstacles à la création de groupes d'accès pour les propriétaires de charges de travail

Pour réduire la tentation de réutiliser un groupe d'accès existant, faites en sorte que les groupes d'accès soient faciles à créer et à gérer. Les propriétaires de charges de travail doivent pouvoir créer des groupes d'accès en libre-service, avec une prise en charge de la dénomination appropriée.

Permettre aux utilisateurs de trouver et de rejoindre des groupes d'accès

Si les utilisateurs peuvent découvrir les groupes d'accès existants et rejoindre ceux dont ils ont besoin, ils seront moins susceptibles d'accumuler des droits inutiles. Si nécessaire, vous pouvez utiliser une invitation ou un processus d'approbation pour contrôler qui peut rejoindre le groupe.

Laisser les abonnements expirer automatiquement par défaut

Exigez des utilisateurs qu'ils rejoignent à nouveau un groupe d'accès ou qu'ils prolongent leur abonnement après un certain temps. Cette pratique ajoute intentionnellement des frictions pour rester membre d'un groupe d'accès et incite à laisser expirer les adhésions inutiles. Cette bonne pratique est essentielle pour atteindre l'objectif de zéro privilège permanent (ZSP, Zero Standing Privileges). Elle est particulièrement importante pour les utilisateurs externes.

N'appliquez toutefois pas cette règle aux comptes de service, car la suppression de comptes de service d'un groupe d'accès peut entraîner des interruptions de service.

Attribuez des propriétaires désignés à chaque groupe.

Chaque groupe d'accès doit comporter un ou plusieurs propriétaires désignés. Cela encourage un sentiment de responsabilité quant à l'appartenance à un groupe. Les propriétaires peuvent être la même personne ou la même équipe que celle qui possède la charge de travail associée au groupe.

Limiter la visibilité des groupes d'accès

Ne rendez pas les groupes d'accès visibles dans l'annuaire des groupes. (Ils devraient être visibles dans votre outil de gestion des groupes d'accès.) De plus, autorisez uniquement les membres du groupe à voir qui d'autre en fait partie. Ces pratiques empêchent les personnes malveillantes d'obtenir des informations précieuses.

Limiter les membres externes

Étant donné que les contraintes liées aux règles de partage restreint au domaine s'appliquent aux groupes, mais pas à leurs membres, les groupes d'accès qui autorisent les membres externes peuvent créer une faille qui compromet le partage restreint au domaine.

Utilisez les groupes de sécurité Cloud Identity et les restrictions de groupe pour autoriser ou interdire les membres externes pour les groupes d'accès. En outre, pensez à utiliser une convention d'attribution de noms spéciale, telle que external.access.GROUP_NAME@example.com, pour les groupes d'accès qui autorisent les membres externes.

Gérer les groupes de mesures d'application

Appliquez les bonnes pratiques suivantes pour gérer vos groupes de mesures d'application.

Sélectionner le bon outil pour gérer vos groupes de mesures d'application

Étant donné que l'appartenance à des groupes d'application est basée sur des règles organisationnelles et utilisée pour appliquer des restrictions de sécurité, ne permettez pas aux membres de se retirer ou de se supprimer d'un groupe d'application.

L'utilisation de groupes dynamiques vous permet d'automatiser le provisionnement des groupes d'application. Si vous utilisez un IdP externe, utilisez les groupes dynamiques fournis par l'IdP, puis provisionnez-les dans Cloud Identity. N'oubliez pas que l'utilisation d'un fournisseur d'identité externe peut entraîner un délai pour les mises à jour des règles.

Si vous ne pouvez pas utiliser de groupes dynamiques, envisagez d'utiliser Terraform ou un autre outil IaC (Infrastructure as Code) pour provisionner vos groupes d'application. Si vous utilisez IaC pour créer des groupes d'application, assurez-vous de ne pas accorder un accès inutilement étendu au pipeline.

Utiliser des groupes d'application pour le contrôle des accès obligatoire et les contrôles d'authentification

Utilisez des groupes d'application pour appliquer le contrôle d'accès obligatoire. Google Cloud est compatible avec le contrôle des accès obligatoire avec un certain nombre de services et d'outils, y compris les suivants :

Les groupes d'application sont également utilisés pour appliquer des contrôles d'authentification tels que l'attribution de profils SAML ou la validation en deux étapes.

Étant donné que ces contrôles restreignent tous des fonctionnalités ou suppriment l'accès, les groupes d'application des règles sont le bon choix.

Ne pas autoriser les utilisateurs à quitter un groupe de mesures d'application

Autoriser les utilisateurs à quitter un groupe d'application des règles va à l'encontre des principes du contrôle des accès obligatoire. Pour empêcher les utilisateurs de quitter le groupe, utilisez l'API Groups Settings pour définir la propriété whoCanLeaveGroup sur NONE_CAN_LEAVE.

Bonnes pratiques pour les IdP externes

Si vous utilisez un IdP externe pour l'authentification, il peut être utile d'utiliser également cet IdP pour provisionner des groupes organisationnels et des groupes d'application.

Éviter d'utiliser une source externe pour les groupes d'accès

Il est possible de gérer les groupes d'accès dans l'IdP externe et de les provisionner dans Cloud Identity, mais cette approche présente plusieurs inconvénients :

  • Retards de provisionnement

    Il peut s'écouler plusieurs heures avant que les modifications apportées au fournisseur d'identité externe ne soient répercutées dans le groupe d'accès.

  • Risque de divergence

    Certains IdP ne prennent pas le contrôle des groupes. Par exemple, il est possible qu'ils ne suppriment pas un groupe dans Cloud Identity après sa suppression en externe, ou qu'ils suppriment activement les membres d'un groupe qui existent dans Cloud Identity, mais pas dans le fournisseur d'identité.

    La divergence peut entraîner la conservation d'accès inutiles pour les utilisateurs et leur fournir des informations incorrectes sur les personnes ayant accès. Cela peut également rendre la création de groupes d'accès plus difficile.

Pour éviter ces pièges, utilisez des IdP externes pour provisionner uniquement les groupes d'application et d'organisation, et utilisez un outil tel que JIT Groups pour gérer les groupes d'accès directement dans Cloud Identity.

Utiliser un domaine secondaire si vous mappez des groupes par nom

Cloud Identity identifie les groupes par adresse e-mail, mais les groupes de votre IdP externe n'en ont peut-être pas.

De nombreux fournisseurs d'identité vous permettent de contourner ce problème en vous laissant dériver une pseudo adresse e-mail à partir du nom du groupe, par exemple en utilisant my-group@example.com. Cette méthode fonctionne, mais peut entraîner des conflits si cette adresse e-mail est déjà utilisée par un autre groupe ou un autre utilisateur. Dans le pire des cas, cette collision de noms pourrait être exploitée par un acteur malveillant pour créer des groupes de sécurité qui se font passer pour un autre type de groupe moins examiné.

Pour éviter tout risque de conflit, utilisez un domaine secondaire dédié pour les groupes que vous provisionnez à partir de la source externe, comme groups.example.com.

Éviter d'attribuer le rôle d'administrateur de groupes aux pipelines de déploiement

Si vous utilisez l'IaC pour gérer les groupes (par exemple, Terraform), votre pipeline de déploiement doit disposer des autorisations requises pour accomplir sa tâche. Le rôle d'administrateur des groupes autorise la création de groupes, mais il permet également à tout compte principal disposant de ce rôle de gérer tous les groupes du compte Cloud Identity.

Vous pouvez limiter l'accès accordé à un pipeline en créant un compte de service avec une seule autorisation (la possibilité de créer un groupe), puis en faisant du pipeline le propriétaire de tout groupe qu'il crée. Cela permet à ce pipeline de gérer tous les groupes qu'il crée et d'en créer d'autres, sans l'autoriser à gérer les groupes qu'il n'a pas créés.

Voici l'approche à suivre :

  1. Créez un rôle d'administrateur personnalisé qui n'inclut que l'autorisation de création de groupes de l'API Admin.

    Attribuez un nom descriptif à ce rôle, par exemple "Créateur de groupe".

  2. Créez un compte de service et attribuez-lui le rôle "Créateur de groupes".

  3. Utilisez le compte de service pour votre pipeline et transmettez l'indicateur WITH_INITIAL_OWNER lors de la création du groupe.

Utilisez Cloud Logging pour auditer et surveiller vos groupes.

La journalisation vous permet de collecter, de surveiller et d'analyser l'activité des groupes.

Auditer les modifications apportées aux membres

L'ajout ou la suppression d'un membre d'un groupe organisationnel, d'un groupe d'accès ou d'un groupe d'application des règles peut avoir une incidence sur les ressources auxquelles le membre a accès. Il est donc important de conserver un journal d'audit qui suit ces modifications.

Exiger des justifications pour rejoindre des groupes d'accès

Pour rendre vos données de surveillance plus utiles, demandez aux utilisateurs de fournir une justification lorsqu'ils rejoignent un groupe ou demandent à le rejoindre, et enregistrez cette justification. S'il existe un processus d'approbation, enregistrez des informations sur la personne qui a approuvé la demande.

Ces métadonnées supplémentaires peuvent vous aider à analyser pourquoi une personne a été ajoutée à un groupe et, par extension, pourquoi elle a eu accès à certaines ressources.

Activer le partage des journaux d'audit Cloud Identity

Configurez Cloud Identity pour router les journaux vers Cloud Logging afin de pouvoir gérer ces journaux d'audit de la même manière que les autres journaux Google Cloud , y compris en configurant des alertes ou en utilisant un système externe de gestion des informations et événements de sécurité (SIEM).