Bonnes pratiques concernant l'utilisation de Google Groupes

Ce document décrit certaines bonnes pratiques pour utiliser des groupes Google afin de 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 un moyen 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, utiliser ces types de groupes dans votre approche globale de la gestion des groupes Google peut vous aider à éviter certains écueils 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 de données sur les ressources humaines. Ils peuvent être basés sur le service, la structure de reporting, la zone géographique ou d'autres regroupements organisationnels.

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

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

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

    Les groupes organisationnels 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. Ils sont souvent créés de manière ponctuelle et en libre-service.

    L'adhésion aux groupes de collaboration peut être illimitée, 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 d'autre inclure dans le groupe.

    collab.security-discuss et collab.website-relaunch sont des exemples de groupes de collaboration.

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

  • Groupes d'accès

    Les groupes d'accès servent uniquement à fournir un accès. Ils représentent des fonctions et sont utilisés pour simplifier l'attribution des rôles requis pour accomplir ces fonctions. Au lieu d'attribuer des rôles à des comptes principaux individuels, vous attribuez des rôles au groupe, puis gérez l'appartenance au groupe.

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

    L'appartenance aux 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 de participation.

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

    Les groupes d'accès ne servent qu'à fournir un accès. Ils ne sont pas utilisés à des fins de communication.

  • Groupes d'application

    Les groupes d'application sont semblables aux groupes d'accès, à la différence qu'ils sont utilisés pour appliquer des règles de restriction d'accès plutôt que pour fournir un accès.

    La structure des groupes d'application est généralement influencée par une combinaison de exigences de conformité et de structure organisationnelle.

    L'appartenance à un groupe d'application 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.

    enforcement.users-in-restricted-locations, enforcement.fedramp-low et enforcement.sso-users sont des exemples de groupes d'application.

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

Nommer 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 groupe 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 pour 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 d'application: enforcement.GROUP_DESCRIPTION@example.com. Exemple :enforcement.sso-users@example.com

Adoptez la convention qui convient à votre organisation et est compatible avec votre logiciel de gestion de groupe. L'utilisation d'un préfixe permet d'organiser 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 de conventions d'attribution de noms, vous pouvez utiliser des domaines secondaires pour intégrer le type de groupe au nom (par exemple, access.example.com). Les domaines secondaires qui sont un sous-domaine d'un domaine validé ne nécessitent pas de validation et n'ont pas besoin 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'être envoyés à des groupes qui ne sont pas destinés à la communication.

Règles d'imbrication

Les règles d'imbrication (accepter un groupe en tant que membre) varient selon les types de groupes.

Règles d'imbrication pour les groupes organisationnels

Il est recommandé d'imbriquer des groupes organisationnels pour refléter votre organigramme. Cette approche signifie que chaque employé est inclus dans un groupe, puis que les groupes s'incluent les uns les autres. 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 en tant que membres à n'importe quel autre type de groupe. Cela peut être beaucoup plus simple que d'ajouter chaque membre d'un groupe organisationnel à un autre groupe.

N'ajoutez aucun autre type de groupe en tant que membre à un groupe organisationnel. 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éterminent comment les membres sont ajoutés. Si deux groupes de collaboration respectent les mêmes règles d'adhésion, ils peuvent être imbriqués. Toutefois, l'imbrication de groupes de collaboration avec des règles d'appartenance différentes peut permettre aux membres qui ne répondent pas aux règles d'appartenance d'un groupe de devenir membres. Consultez attentivement les règles d'adhésion avant d'imbriquer des groupes de collaboration.

Les groupes de collaboration peuvent comporter des groupes d'organisations parmi leurs membres.

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

En règle générale, vous ne devez pas imbriquer de groupes d'accès. L'imbrication de groupes d'accès peut rendre difficile la détermination de qui a accès à quelles ressources. En outre, 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 aux groupes d'accès.

Les groupes d'accès peuvent comporter des groupes organisationnels parmi leurs membres.

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

N'imbriquez pas de 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 des restrictions involontaires pour certains principaux.

Les groupes d'application peuvent comporter des groupes d'organisation parmi leurs membres.

Gérer les groupes organisationnels

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

Provisionnement à 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 provisionner ces groupes exclusivement à partir d'un système d'information RH ou d'une source de vérité externe, par exemple un fournisseur d'identité (IdP) externe ou un système de gouvernance des identités tel que Sailpoint, Okta ou Entra ID.

Ne pas autoriser les modifications apportées au groupe

N'ajoutez ni ne supprimez manuellement d'utilisateurs d'un groupe organisationnel, et n'autorisez pas les utilisateurs à se retirer d'un groupe organisationnel.

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

Tous les utilisateurs d'un groupe organisationnel n'ont que rarement besoin du même niveau d'accès aux ressources. Pour cette raison, accorder l'accès à un groupe organisationnel entraînera probablement que certains membres du groupe auront plus d'accès qu'ils n'en ont réellement besoin.

De plus, il peut y avoir un délai entre le moment où des modifications sont apportées dans un fournisseur d'identité externe et celui où elles sont propagées vers Cloud Identity, en fonction de la fréquence de synchronisation entre le fournisseur d'identité externe et Cloud Identity. Ce délai peut entraîner la prolifération d'autorisations en excès. Par exemple, cela peut amener 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 organisationnel, ajoutez-le en tant que membre à un groupe d'accès plutôt que d'accorder l'accès directement, et n'accordez que des rôles avec des autorisations limitées, comme Lecteur de l'organisation. Dans le cas contraire, utilisez des groupes d'accès pour accorder l'accès aux ressources.

Ne pas autoriser les comptes de service et les utilisateurs externes dans les groupes organisationnels

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

Les utilisateurs externes (utilisateurs 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 qu'ils soient membres d'un groupe organisationnel. Si vous intégrez votre personnel externe à votre propre compte Google Workspace ou Cloud Identity, il est considéré comme des utilisateurs internes 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

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

Gérer des groupes de collaboration avec Groups for Business

Si vous utilisez Google Workspace, vous pouvez utiliser Groups for Business pour gérer les groupes de collaboration. Les utilisateurs peuvent ainsi utiliser Google Groups pour créer, parcourir et rejoindre des groupes. Vous devez configurer Groups for Business pour autoriser les utilisateurs à 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'est pas nécessaire de créer des groupes de collaboration dans Cloud Identity. Il est donc préférable de désactiver Groups for Business 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 qu'il applique un suffixe. Cela est particulièrement important si vous autorisez tout le monde à créer des groupes Groups for Business.

L'application d'un suffixe empêche les utilisateurs de créer un groupe dont le nom est intentionnellement en conflit avec un groupe d'accès ou un groupe organisationnel sur le point d'être provisionné à partir d'une source externe. Ce scénario pourrait permettre au créateur du groupe de collaboration portant un nom trompeur d'étendre ses droits.

Ne pas utiliser les groupes de collaboration pour le contrôle des accès

Les groupes de collaboration sont censés avoir un contrôle des accès peu strict et ne suivent généralement pas un cycle de vie bien défini. Ils sont donc adaptés à la collaboration, mais pas au contrôle des accès.

Si vous avez strictement suivi 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 de manière abusive à 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 l'outil adapté 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 la charge de travail, utilisez un outil adapté au libre-service. Votre outil doit permettre aux utilisateurs de trouver des groupes d'accès existants et de mettre en place des garde-fous de sécurité qui appliquent les contrôles suivants:

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

  • Conditions requises pour qu'un utilisateur puisse rejoindre un groupe

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

  • Durée de vie maximale de l'adhésion au groupe

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

  • Prise en charge des journaux d'audit

L'un des outils qui répond à ces exigences est les groupes JIT.

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 les utilisateurs de ce poste au groupe pour leur accorder l'accès dont ils ont besoin au lieu d'attribuer les mêmes rôles à chaque utilisateur.

Vous pouvez utiliser un seul groupe d'accès pour accorder 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 supplémentaire à la place.

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, facilitez la création et la gestion des groupes d'accès. Les propriétaires de charges de travail doivent pouvoir créer des groupes d'accès en libre-service, avec la possibilité de nommer correctement les groupes.

Permettre aux utilisateurs de rechercher 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 sont moins susceptibles d'accumuler des droits inutiles. Si nécessaire, vous pouvez utiliser un processus d'invitation ou d'approbation pour contrôler qui peut rejoindre le groupe.

Autoriser les abonnements à expirer automatiquement par défaut

Demander aux utilisateurs de rejoindre à nouveau un groupe d'accès ou de prolonger leur adhésion au bout d'un certain temps Cette pratique ajoute intentionnellement des frictions pour rester membre d'un groupe d'accès et incite à laisser les adhésions inutiles expirer. Cette bonne pratique est essentielle pour atteindre l'objectif de ZSP (Zero Standing Privileges) et est particulièrement importante pour les utilisateurs externes.

Toutefois, n'appliquez pas cette règle aux comptes de service, car supprimer des comptes de service d'un groupe d'accès peut entraîner des interruptions de service.

Attribuez des propriétaires à chaque groupe.

Chaque groupe d'accès doit avoir un ou plusieurs propriétaires désignés. Cela encourage un sentiment de responsabilité pour l'appartenance au groupe. Les propriétaires peuvent être la même personne ou l'équipe qui est propriétaire 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 détectables dans votre outil de gestion des groupes d'accès.) De plus, n'autorisez que les membres du groupe à voir les autres membres. Ces pratiques empêchent les acteurs malintentionnés d'obtenir des informations précieuses.

Limiter les membres externes

Étant donné que les contraintes de règles de partage restreint de domaine (DRS, Domain Restricted Sharing) s'appliquent aux groupes, mais pas aux membres de groupe, les groupes d'accès qui autorisent les membres externes peuvent créer une faille qui compromet le DRS.

Utilisez les groupes de sécurité Cloud Identity et les restrictions de groupe pour autoriser ou non les membres externes aux groupes d'accès. En outre, envisagez d'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 d'application

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

Sélectionner l'outil approprié pour gérer vos groupes d'application

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

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 l'IaC pour créer des groupes d'application, veillez à ne pas accorder un accès trop large au pipeline.

Utiliser des groupes d'application pour le contrôle des accès et l'authentification obligatoires

Utilisez des groupes d'accès 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 commandes limitent toutes les fonctionnalités ou suppriment l'accès, les groupes d'application sont le bon choix.

Ne pas autoriser les utilisateurs à quitter un groupe d'application des règles

Permettre aux utilisateurs de quitter un groupe d'application des règles va à l'encontre des principes du contrôle des accès obligatoire. Pour interdire aux 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 fournisseurs d'identité 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 des groupes d'accès dans le fournisseur d'identité externe et de les provisionner dans Cloud Identity, mais cette approche présente plusieurs inconvénients:

  • Retards de provisionnement

    Les modifications apportées au fournisseur d'identité externe peuvent prendre plusieurs heures avant d'être reflétées dans le groupe d'accès.

  • Risque de divergence

    Certains IdP ne prennent pas le contrôle des groupes. Par exemple, il peut ne pas supprimer un groupe dans Cloud Identity après sa suppression externe, ou supprimer activement des membres de groupe qui existent dans Cloud Identity, mais pas dans l'IDP.

    Les divergences peuvent entraîner le maintien d'un accès dont les utilisateurs n'ont pas besoin et leur fournir des informations incorrectes sur les personnes qui y ont accès. Cela peut également complexifier la création de groupes d'accès.

Pour éviter ces écueils, utilisez des IdP externes pour provisionner uniquement des groupes d'organisation et d'application des règles, et utilisez un outil tel que les groupes JIT 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 peuvent ne pas avoir d'adresse e-mail.

De nombreux IdP vous permettent de contourner ce problème en vous permettant d'obtenir une adresse e-mail pseudo à partir du nom du groupe, par exemple à l'aide de my-group@example.com. Cette méthode fonctionne, mais peut entraîner des conflits lorsque 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 pirate informatique pour créer des groupes de sécurité se faisant passer pour un autre type de groupe moins surveillé.

Pour éviter les risques de collision, 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 "Administrateur des groupes" aux pipelines de déploiement

Si vous utilisez l'IaC pour gérer des groupes (par exemple, Terraform), votre pipeline de déploiement doit disposer des autorisations requises pour accomplir sa tâche. Le rôle "Administrateur des groupes" autorise la création de groupes, mais 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 de créer d'autres groupes, sans l'autoriser à gérer les groupes qu'il n'a pas créés.

Cette approche se compose des étapes suivantes:

  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 à ce rôle un nom descriptif, 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 au moment 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é de groupe.

Auditer les modifications apportées à la liste des 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 une piste d'audit pour suivre 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 à en rejoindre un, et enregistrez la justification. S'il existe un processus d'approbation, consignez les informations sur la personne qui a approuvé la requête.

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

Activer le partage des journaux d'audit Cloud Identity

Configurez Cloud Identity pour acheminer 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 SIEM (Security Information and Event Management) externe.