Stratégies de limite d'accès des comptes principaux

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Les stratégies de limite d'accès des comptes principaux (PAB, Principal Access Boundary) vous permettent de limiter les ressources auxquelles les comptes principaux peuvent accéder.

Par exemple, vous pouvez utiliser des règles de limite d'accès des comptes principaux pour empêcher vos comptes principaux d'accéder aux ressources d'autres organisations. Cela peut vous aider à prévenir les attaques par hameçonnage ou l'exfiltration de données.

Pour en savoir plus sur les autres types de stratégies de contrôle des accès proposés par Identity and Access Management (IAM), consultez la section Types de stratégies.

Fonctionnement des stratégies de limite d'accès des comptes principaux

Par défaut, les comptes principaux peuvent accéder à n'importe quelle ressource Google Cloud. Cela signifie que si un compte principal dispose d'une autorisation sur la ressource et qu'elle ne lui est pas refusée, il peut l'utiliser pour accéder à la ressource.

Les stratégies de limite d'accès des comptes principaux vous permettent de limiter les ressources auxquelles un compte principal est autorisé à accéder. Si une stratégie de limite d'accès des comptes principaux empêche un compte principal d'accéder à une ressource, son accès à cette ressource est limité, quels que soient les rôles qui lui sont attribués.

Lorsque des comptes principaux tentent d'accéder à des ressources auxquelles ils ne sont pas autorisés, les stratégies de limite d'accès des comptes principaux peuvent bloquer certaines autorisations IAM (Identity and Access Management), mais pas toutes. Pour en savoir plus sur les autorisations bloquées, consultez la section Autorisations que la limite d'accès des comptes principaux peut bloquer.

Les stratégies de limite d'accès des comptes principaux sont composées de règles de limite d'accès des comptes principaux. Chaque règle de limite d'accès des comptes principaux définit un ensemble de ressources auxquelles les comptes principaux concernés peuvent accéder. Vous pouvez créer jusqu'à 1 000 stratégies de limite d'accès des comptes principaux dans votre organisation.

Une fois que vous avez créé une stratégie de limite d'accès des comptes principaux, vous devez créer une liaison de règles pour l'appliquer à un ensemble de comptes principaux.

Un principal peut être soumis à une ou plusieurs stratégies de limite d'accès des comptes principaux. Chaque principal n'est autorisé à accéder qu'aux ressources listées dans ces stratégies. Pour toutes les autres ressources, l'accès du compte principal à cette ressource est limité, même si vous lui accordez des rôles sur cette ressource.

Étant donné que les stratégies de limite d'accès des comptes principaux sont associées aux comptes principaux et non aux ressources, vous pouvez les utiliser pour empêcher les comptes principaux d'accéder aux ressources que vous ne possédez pas. Prenons les exemples suivants :

• Le principal Tal ([e-mail]) fait partie de l'organisation Google Workspace altostrat.com.
• Tal se voit attribuer le rôle Administrateur de l'espace de stockage (roles/storage.admin) sur un bucket Cloud Storage dans une autre organisation, cymbalgroup.com. Ce rôle contient l'autorisation storage.objects.get, qui est nécessaire pour afficher les objets du bucket.
• Aucune règle de refus dans cymbalgroup.com n'empêche Tal d'utiliser l'autorisation storage.objects.get.

Avec des stratégies d'autorisation et de refus uniquement, altostrat.com ne peut pas empêcher Tal de consulter les objets de ce bucket externe. Aucun compte principal altostrat.com n'est autorisé à modifier la règle d'autorisation du bucket. Il ne peut donc pas révoquer le rôle de Tal. Il n'est pas non plus autorisé à créer des règles de refus dans cymbalgroup.com. Il ne peut donc pas utiliser une règle de refus pour empêcher Tal d'accéder au bucket.

Toutefois, avec les stratégies de limite d'accès des comptes principaux, les administrateurs altostrat.com peuvent s'assurer que Tal ne peut pas afficher les objets du bucket cymbalgroup.com ni de tout autre bucket en dehors de altostrat.com. Pour ce faire, les administrateurs peuvent créer une stratégie de limite d'accès des comptes principaux indiquant que les comptes principaux altostrat.com ne sont autorisés à accéder qu'aux ressources de altostrat.com. Il peut ensuite créer une liaison de règle pour l'associer à tous les comptes principaux de l'organisation altostrat.com. Avec une telle règle en place, Tal ne pourra pas afficher les objets du bucket cymbalgroup.com, même s'il dispose du rôle "Storage Admin" sur le bucket.

Évaluation de la configuration ouverte ("fail open")

Lors de la version Preview des stratégies de limite d'accès des comptes principaux, les stratégies de limite d'accès des comptes principaux sont en mode fail open. Cela signifie que si IAM ne peut pas évaluer une stratégie de limite d'accès des comptes principaux, il l'ignore et procède à l'évaluation des stratégies d'autorisation et de refus pertinentes.

Autorisations bloquées par les stratégies de limite d'accès des comptes principaux

Lorsque des comptes principaux tentent d'accéder à une ressource à laquelle ils ne sont pas autorisés, les stratégies de limite d'accès des comptes principaux les empêchent d'utiliser certaines autorisations IAM (Identity and Access Management), mais pas toutes, pour accéder à la ressource.

Si une stratégie de limite d'accès des comptes principaux bloque une autorisation, IAM applique les stratégies de limite d'accès des comptes principaux pour cette autorisation. En d'autres termes, il empêche les comptes principaux qui ne sont pas autorisés à accéder à une ressource d'utiliser cette autorisation pour y accéder.

Si une stratégie de limite d'accès des comptes principaux ne bloque pas une autorisation, elle n'a aucun effet sur la possibilité pour les comptes principaux d'utiliser cette autorisation.

Par exemple, imaginons qu'un compte principal, Lee ([e-mail]), se voit attribuer le rôle "Développeur Dataflow" (roles/dataflow.developer). Ce rôle inclut l'autorisation dataflow.jobs.snapshot, qui permet à Lee de prendre des instantanés des tâches Dataflow. Lee est également soumis à une règle de limite d'accès des comptes principaux qui l'empêche d'accéder aux ressources en dehors de example.com. Toutefois, si les règles de limite d'accès des comptes principaux ne bloquent pas l'autorisation dataflow.jobs.snapshot, Lee peut toujours prendre des instantanés des tâches Dataflow dans les organisations en dehors de example.com.

Les autorisations bloquées par une règle de limite d'accès des comptes principaux dépendent de la version de l'application de la limite d'accès des comptes principaux.

Versions d'application des limites d'accès principales

Chaque stratégie de limite d'accès des comptes principaux spécifie une version d'application, qui identifie une liste prédéfinie d'autorisations IAM que la stratégie de limite d'accès des comptes principaux peut bloquer. Vous spécifiez la version d'application lorsque vous créez ou mettez à jour une stratégie de limite d'accès des comptes principaux. Si vous ne spécifiez pas de version d'application, IAM utilise la dernière version d'application et continuera de l'utiliser jusqu'à ce que vous la modifiiez.

De temps en temps, IAM ajoute de nouvelles versions d'application des limites d'accès des comptes principaux qui peuvent bloquer des autorisations supplémentaires. Chaque nouvelle version peut également bloquer toutes les autorisations de la version précédente.

Pour bloquer les autorisations dans une nouvelle version d'application, vous devez mettre à jour vos règles de limites d'accès es comptes principaux dafin d'utiliser la nouvelle version. Si vous souhaitez que la version d'application de la règle soit mise à jour automatiquement à mesure que de nouvelles versions sont publiées, vous pouvez utiliser la valeur latest lorsque vous créez la règle. Toutefois, nous vous déconseillons d'utiliser cette valeur, car elle peut entraîner la perte inattendue de l'accès aux ressources par les comptes principaux.

Pour obtenir la liste complète des autorisations bloquées par chaque version d'application, consultez la section Autorisations bloquées par les stratégies de limite d'accès des comptes principaux.

Lier des stratégies de limite d'accès des comptes principaux à des ensembles de comptes principaux

Pour lier une stratégie de limite d'accès des comptes principaux à un ensemble de comptes principaux, vous devez créer une liaison de stratégie qui spécifie à la fois la stratégie de limite d'accès des comptes principaux que vous souhaitez appliquer et l'ensemble de comptes principaux pour lequel vous souhaitez l'appliquer. Une fois la stratégie liée à un ensemble de comptes principaux, les comptes principaux de cet ensemble ne peuvent accéder qu'aux ressources incluses dans les règles de la stratégie de limite d'accès des comptes principaux.

Vous pouvez lier une stratégie de limite d'accès des comptes principaux à un nombre illimité d'ensembles de comptes principaux. Chaque ensemble de comptes principaux peut être associé à dix stratégies de limite d'accès des comptes principaux.

Pour savoir comment gérer les stratégies de limite d'accès des comptes principaux, consultez Créer et appliquer des stratégies de limite d'accès des comptes principaux.

Ensembles de comptes principaux compatibles

Le tableau suivant liste les types d'ensembles de comptes principaux auxquels vous pouvez associer des règles de limite d'accès des comptes principaux. Chaque ligne contient les éléments suivants:

• Type d'ensemble de comptes principaux
• Comptes principaux de ce type d'ensemble de comptes principaux
• Format des ID pour ce type d'ensemble de comptes principaux
• Ressource Resource Manager (projet, dossier ou organisation) qui est parente des liaisons de stratégie pour ce type d'ensemble de comptes principaux

Ensemble de comptes principaux	Détails	Ressource parente des liaisons de stratégie
Pool d'identités de personnel	Contient toutes les identités du pool d'identités de personnel spécifié. Format : //iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID	Organisation contenant le pool d'identités de personnel
Pool d'identité de charge de travail	Contient toutes les identités du pool d'identités de charge de travail spécifié. Format : //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID	Projet contenant le pool d'identités de charge de travail
Domaine Google Workspace	Contient toutes les identités du domaine Google Workspace spécifié. Format : //iam.googleapis.com/locations/global/workspace/WORKSPACE_ID Vous pouvez trouver l'ID de votre espace de travail en utilisant les méthodes suivantes: Exécutez la commande gcloud organizations describe. Votre ID d'espace de travail se trouve dans le champ directoryCustomerId de la réponse. Utilisez la méthode organizations.get dans l'API Cloud Resource Manager. Votre ID d'espace de travail se trouve dans le champ directoryCustomerId de la réponse. Affichez votre ID de l'espace de travail dans la console d'administration. Cette méthode nécessite le rôle de super-administrateur Google Workspace.	Organisation associée au domaine Google Workspace
Ensemble de comptes principaux du projet	Contient tous les comptes de service et les pools d'identités de charge de travail du projet spécifié. Format : //cloudresourcemanager.googleapis.com/projects/PROJECT_ID	Le projet
Ensemble de comptes principaux du dossier	Contient tous les comptes de service et tous les pools d'identités de charge de travail de n'importe quel projet du dossier spécifié. Format : //cloudresourcemanager.googleapis.com/folders/FOLDER_ID	Le dossier
Ensemble de comptes principaux de l'organisation	Contient les identités suivantes: Toutes les identités de tous les domaines associés à votre numéro client Google Workspace Tous les pools d'identités de personnel de votre organisation Tous les comptes de service et les pools d'identités de charge de travail de tous les projets de l'organisation Format : //cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID	L'entreprise

Liaisons de stratégie conditionnelles pour les stratégies de limite d'accès des comptes principaux

Vous pouvez utiliser des expressions de condition dans les liaisons de règles pour les stratégies de limite d'accès des comptes principaux afin de préciser davantage les comptes principaux auxquels la stratégie s'applique.

Les expressions de condition pour les liaisons de règles se composent d'une ou plusieurs instructions associées par un maximum de 10 opérateurs logiques (&&, || ou !). Chaque instruction exprime une règle de contrôle basée sur des attributs qui s'applique à la liaison de règles et détermine finalement si la règle s'applique.

Vous pouvez utiliser les attributs principal.type et principal.subject dans les conditions des liaisons de règles. Aucun autre attribut n'est accepté dans les conditions des liaisons de règles.

• L'attribut principal.type indique le type d'entité de compte principal dans la requête (par exemple, les comptes de service ou les identités dans un pool d'identités de charge de travail). Vous pouvez utiliser des conditions avec cet attribut pour contrôler les types de comptes principaux auxquels s'applique une stratégie de limite d'accès des comptes principaux.

  Par exemple, si vous ajoutez l'expression de condition suivante à une liaison pour une règle de limite d'accès des comptes principaux, la règle ne s'applique qu'aux comptes de service :

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• L'attribut principal.subject indique l'identité du compte principal dans la requête, par exemple [e-mail]. Vous pouvez utiliser des conditions avec cet attribut pour contrôler précisément quels comptes principaux sont soumis à une stratégie de limite d'accès des comptes principaux.

  Par exemple, si vous ajoutez l'expression de condition suivante à une liaison pour une règle de limite d'accès des comptes principaux, la règle ne s'appliquera pas à l'utilisateur [e-mail] :

  principal.subject != '[e-mail]'
  

Pour en savoir plus sur les valeurs que vous pouvez utiliser pour ces conditions, consultez la documentation de référence sur les attributs de conditions.

Exemple: Utiliser des conditions pour réduire les ressources auxquelles un compte principal peut accéder

Vous pouvez utiliser des conditions dans les liaisons de stratégies de limite d'accès des comptes principaux pour réduire les ressources auxquelles un seul compte principal est autorisé à accéder.

Imaginons que vous disposiez d'un compte de service, dev-project-service-account, avec l'adresse e-mail [e-mail]. Ce compte de service est soumis à une stratégie de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder à toutes les ressources de l'organisation example.com. Cette règle est associée à l'ensemble de comptes principaux de l'organisation example.com.

Vous décidez que dev-project-service-account ne doit pas pouvoir accéder à toutes les ressources de example.com, mais uniquement aux ressources de dev-project. Toutefois, vous ne souhaitez pas modifier les ressources auxquelles les autres comptes principaux de l'ensemble de comptes principaux example.com peuvent accéder.

Pour effectuer cette modification, suivez la procédure permettant de réduire les ressources auxquelles les comptes principaux peuvent accéder, mais ajoutez une condition à la liaison de stratégie au lieu de la supprimer:

1. Vous confirmez que la seule stratégie de limite d'accès des comptes principaux à laquelle dev-project-service-account est soumise est celle qui permet aux comptes principaux d'accéder à toutes les ressources de example.com.

2. Vous créez une règle de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder aux ressources dans dev-project et l'associez à l'ensemble de comptes principaux pour dev-project. Vous utilisez la condition suivante dans la liaison de stratégie pour vous assurer que la stratégie n'est appliquée que pour dev-project-service-account:

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == '[e-mail]'"
   }
   

3. Vous exemptez dev-project-service-account de la stratégie de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder à toutes les ressources de example.com. Pour ce faire, ajoutez la condition suivante à la liaison de stratégie qui associe cette stratégie de limite d'accès des comptes principaux à l'ensemble de comptes principaux de l'organisation:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != '[e-mail]' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Pour savoir comment mettre à jour des stratégies de limite d'accès des comptes principaux existantes, consultez la section Modifier des stratégies de limite d'accès des comptes principaux.

Une fois cette condition ajoutée à la liaison de règles, dev-project-service-account n'est plus autorisé à accéder à toutes les ressources de example.com. Il ne peut accéder qu'aux ressources de dev-project.

Interactions avec les règles

IAM évalue chaque stratégie de limite d'accès des comptes principaux en combinaison avec vos règles d'autorisation et de refus, ainsi qu'avec vos autres stratégies de limite d'accès des comptes principaux. Toutes ces stratégies permettent de déterminer si un compte principal peut accéder à une ressource.

Interaction avec d'autres types de règles

Lorsqu'un compte principal tente d'accéder à une ressource, IAM évalue toutes les stratégies de limite, d'autorisation et de refus d'accès des comptes principaux pertinentes pour vérifier si le compte principal est autorisé à accéder à la ressource. Si l'une de ces stratégies indique que le compte principal ne doit pas pouvoir accéder à la ressource, IAM empêche l'accès.

Par conséquent, si une stratégie de limite d'accès des comptes principaux empêche un compte principal d'accéder à une ressource, IAM l'empêche d'accéder à cette ressource, quelles que soient les stratégies d'autorisation et de refus associées à la ressource.

De plus, les stratégies de limite d'accès des comptes principaux ne donnent pas aux comptes principaux l'accès aux ressources. Bien que les stratégies de limite d'accès des comptes principaux puissent rendre un compte principal éligible à l'accès à une ressource, seules les stratégies d'autorisation peuvent réellement accorder à ce compte l'accès à la ressource.

Pour en savoir plus sur l'évaluation des stratégies IAM, consultez Évaluation des stratégies.

Interaction entre les stratégies de limite d'accès des comptes principaux

Si une stratégie de limite d'accès des comptes principaux permet à un compte principal d'accéder à une ressource, il peut y accéder, quels que soient les autres comptes principaux auxquels il est soumis. Par conséquent, si un compte principal est déjà soumis à une stratégie de limite d'accès des comptes principaux, vous ne pouvez pas ajouter de stratégies de limite d'accès des comptes principaux pour réduire son accès.

Par exemple, imaginons qu'un utilisateur, Dana ([e-mail]), soit soumis à une seule règle de limite d'accès des comptes principaux, prod-projects-policy. Cette stratégie permet aux comptes principaux d'accéder aux ressources dans prod-project. Dana est soumise à cette règle, car elle est liée à l'ensemble de comptes principaux de son organisation.

Vous allez créer une règle de limite d'accès des comptes principaux, dev-staging-projects-policy, qui permet aux comptes principaux d'accéder aux ressources dans dev-project et staging-project, puis la lier à l'ensemble de comptes principaux de l'organisation.

En raison de ces stratégies de limite d'accès des comptes principaux, Dana peut accéder aux ressources de dev-project, staging-project et prod-project.

Si vous souhaitez réduire les ressources auxquelles Dana peut accéder, vous devez modifier ou supprimer les stratégies de limite d'accès des comptes principaux auxquelles Dana est soumis.

Par exemple, vous pouvez modifier dev-staging-projects-policy afin que les comptes principaux ne puissent pas accéder aux ressources dans dev-project. Dana ne pourra alors accéder qu'aux ressources de staging-project et prod-project.

Vous pouvez également supprimer prod-projects-policy en supprimant la liaison de stratégie qui l'associe à l'ensemble de comptes principaux de l'organisation. Dana ne pourra alors accéder qu'aux ressources de dev-project et staging-project.

Important :Si vous supprimez une stratégie de limite d'accès des comptes principaux pour réduire l'accès d'un compte principal, assurez-vous qu'il est toujours soumis à au moins une stratégie de limite d'accès des comptes principaux. Si un compte principal n'est soumis à aucune stratégie de limite d'accès des comptes principaux, il peut accéder à toutes les ressources Google Cloud. Pour savoir comment réduire de manière sécurisée l'accès d'un compte principal, consultez Réduire les ressources auxquelles les comptes principaux sont autorisés à accéder.

Toutefois, ces modifications n'affectent pas seulement Dana, mais également les autres comptes principaux soumis aux stratégies et liaisons de limite d'accès des comptes principaux modifiées. Si vous souhaitez réduire les ressources auxquelles un seul principal est autorisé à accéder, utilisez des liaisons de stratégie conditionnelles.

Héritage des règles

Les stratégies de limite d'accès des comptes principaux sont associées à des ensembles de comptes principaux, et non à des ressources Resource Manager. Par conséquent, elles ne sont pas héritées via la hiérarchie des ressources de la même manière que les règles d'autorisation et de refus.

Toutefois, les ensembles d'identités pour les ressources parentes de Resource Manager (dossiers et organisations) incluent toujours tous les comptes principaux dans les ensembles d'identités de leurs descendants. Par exemple, si un compte principal est inclus dans l'ensemble de comptes principaux d'un projet, il est également inclus dans les ensembles de comptes principaux de tous les dossiers ou organisations parents.

Prenons l'exemple d'une organisation, example.com. Cette organisation est associée au domaine example.com et dispose des ressources Resource Manager suivantes:

• Une organisation, example.com
• Un projet, project-1, qui est un enfant de l'organisation
• Un dossier, folder-a, qui est un enfant de l'organisation
• Deux projets, project-2 et project-3, qui sont enfants de folder-a

Les ensembles de comptes principaux de ces ressources contiennent les identités suivantes :

Ensemble de comptes principaux	Identités Google Workspace dans le domaine example.com	Pools de fédération d'identité de personnel dans example.com	Comptes de service et pools d'identités de charge de travail dans project-1	Comptes de service et pools d'identités de charge de travail dans project-2	Comptes de service et pools d'identités de charge de travail dans project-3
Compte principal défini pour example.com
Compte principal défini pour folder-a
Compte principal défini pour project-1
Compte principal défini pour project-2
Compte principal défini pour project-3

Par conséquent, les comptes principaux suivants sont concernés par les stratégies de limite d'accès des comptes principaux suivantes:

• Une identité Google Workspace dans le domaine example.com se trouve dans l'ensemble de comptes principaux pour example.com et sera affectée par les règles de limite d'accès des comptes principaux liées à cet ensemble.

• Un compte de service dans project-1 se trouve dans les ensembles de comptes principaux pour project-1 et example.com. Il est donc affecté par les règles de limite d'accès des comptes principaux liées à l'un de ces ensembles.

• Un compte de service dans project-3 se trouve dans les ensembles de comptes principaux pour project-3, folder-a et example.com, et sera affecté par les règles de limite d'accès des comptes principaux liées à l'un de ces ensembles de comptes principaux.

Stratégies de limite d'accès des comptes principaux et ressources mises en cache

Certains services Google Cloud mettent en cache des ressources visibles publiquement. Par exemple, Cloud Storage met en cache les objets lisibles publiquement.

La limite d'accès des comptes principaux peut empêcher les comptes principaux non éligibles de consulter une ressource visible publiquement si la ressource est mise en cache:

• Si la ressource est mise en cache, la limite d'accès des comptes principaux ne peut pas empêcher les comptes principaux de la consulter.
• Si la ressource n'est pas mise en cache, la limite d'accès des comptes principaux empêche les comptes principaux non éligibles de la consulter.

Dans tous les cas, les stratégies de limite d'accès des comptes principaux empêchent les comptes principaux non éligibles de modifier ou de supprimer des ressources visibles publiquement.

Structure d'une stratégie de limite d'accès des comptes principaux

Une stratégie de limite d'accès des comptes principaux est un ensemble de métadonnées et de détails de stratégie de limite d'accès des comptes principaux. Les métadonnées fournissent des informations telles que le nom de la stratégie et la date de sa création. Les détails de la stratégie définissent son fonctionnement, par exemple les ressources auxquelles les comptes principaux concernés peuvent accéder.

Par exemple, la stratégie de limite d'accès des comptes principaux suivante permet aux comptes principaux soumis à la stratégie d'accéder aux ressources de l'organisation avec l'ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Les sections suivantes décrivent les champs des métadonnées et des détails d'une stratégie de limite d'accès des comptes principaux.

Métadonnées

Les stratégies de limite d'accès des comptes principaux contiennent les métadonnées suivantes:

• name : nom de la règle de limite d'accès des comptes principaux. Ce nom est au format organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, où ORGANIZATION_ID correspond à l'ID numérique de l'organisation dans laquelle la stratégie de limite d'accès des comptes principaux a été créée et PAB_POLICY_ID est l'ID alphanumérique de la stratégie de limite d'accès des comptes principaux.
• uid : ID unique attribué à la règle de limite d'accès des comptes principaux.
• etag: identifiant de l'état actuel de la règle. Cette valeur change lorsque vous mettez à jour la stratégie. Pour éviter les mises à jour en conflit, la valeur etag doit correspondre à la valeur stockée dans IAM. Si les valeurs etag ne correspondent pas, la requête échoue.
• displayName : nom lisible de la règle de limite d'accès des comptes principaux.
• annotations : facultatif. Liste de paires clé-valeur définies par l'utilisateur. Vous pouvez utiliser ces annotations pour ajouter des métadonnées supplémentaires à la règle (par exemple, qui a créé la règle ou si elle a été déployée par un pipeline automatisé). Pour en savoir plus sur les annotations, consultez la section Annotations.
• createTime: heure de création de la règle de limite d'accès des comptes principaux.
• updateTime: heure de la dernière mise à jour de la règle de limite d'accès des comptes principaux.

Détails

Chaque stratégie de limite d'accès des comptes principaux contient un champ details. Ce champ contient les règles de limite d'accès des comptes principauxs et la version d'application :

• rules: liste des règles de limite d'accès des comptes principaux, qui définissent les ressources auxquelles les comptes principaux concernés peuvent accéder. Chaque règle contient les champs suivants:

  • description : description du libellé dans un format lisible.

  • resources: liste des ressources Resource Manager (projets, dossiers et organisations) auxquelles les comptes principaux doivent pouvoir accéder. Tout compte principal soumis à ce règlement peut accéder à ces ressources.

    Chaque stratégie de limite d'accès des comptes principaux peut référencer au maximum 500 ressources pour l'ensemble des règles de la stratégie.

  • effect : relation entre les comptes principaux et les ressources répertoriées dans le champ resources. Le seul effet que vous pouvez spécifier dans les règles de limite d'accès des comptes principaux est "ALLOW". Cette relation permet aux comptes principaux d'accéder aux ressources listées dans la règle.

• enforcementVersion: version d'application utilisée par IAM lors de l'application de la stratégie. La version de la stratégie de limite d'accès des comptes principaux détermine les autorisations qu'elle peut bloquer.

  Pour en savoir plus sur les versions des stratégies de limite d'accès des comptes principaux, consultez la section Versions d'application de la limite d'accès des comptes principaux sur cette page.

Structure d'une liaison de stratégie

Une liaison de stratégie pour une stratégie de limite d'accès des comptes principaux contient le nom d'une stratégie, le nom de l'ensemble de comptes principaux auquel lier la stratégie et des métadonnées décrivant la liaison de stratégie. Elle peut également contenir des conditions qui modifient les administrateurs exacts auxquels la règle s'applique.

Par exemple, la liaison de règle suivante lie la règle example-policy à tous les comptes principaux de l'organisation example.com, qui possède l'ID 0123456789012. La liaison de stratégie contient également une condition qui empêche l'application de la stratégie pour le principal [e-mail].

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for [e-mail]",
    "expression": "principal.subject != '[e-mail]'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Chaque liaison de règles contient les champs suivants:

• name: nom de la liaison de règles. Ce nom est au format RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, où RESOURCE_TYPE/RESOURCE_ID correspond au type et à l'ID de la ressource parente de la liaison de règles, et BINDING_ID est l'ID alphanumérique de la liaison de règles.
• uid: ID unique attribué à la liaison de règles.
• etag: identifiant de l'état actuel de la règle. Cette valeur change lorsque vous mettez à jour la stratégie. Pour éviter les mises à jour en conflit, la valeur etag doit correspondre à la valeur stockée dans IAM. Si les valeurs etag ne correspondent pas, la requête échoue.
• displayName: nom lisible de la liaison de règles.
• annotations : facultatif. Liste de paires clé-valeur définies par l'utilisateur. Vous pouvez utiliser ces annotations pour ajouter des métadonnées supplémentaires à la liaison de stratégie, par exemple, qui a créé la liaison de stratégie ou si elle a été déployée par un pipeline automatisé. Pour en savoir plus sur les annotations, consultez la section Annotations.

• target: compte principal auquel lier la stratégie. La valeur est au format {"principalSet": PRINCIPAL_SET}, où PRINCIPAL_SET est l'ID de l'ensemble de comptes principaux auquel vous souhaitez lier la règle.

  Chaque cible peut être associée à 10 règles maximum.

• policyKind: type de stratégie référencé par la liaison de stratégie. Pour les liaisons de stratégie pour les stratégies de limite d'accès des comptes principaux, cette valeur est toujours PRINCIPAL_ACCESS_BOUNDARY.

• policy: règle de limite d'accès des comptes principaux à lier à l'ensemble de comptes principaux cible.

• policyUid : ID unique attribué à la règle de limite d'accès des comptes principaux référencée dans le champ policy.

• condition : facultatif. Expression logique qui affecte les comptes principaux pour lesquels IAM applique la stratégie. Si la condition renvoie "true" ou ne peut pas être évaluée, Identity and Access Management applique la stratégie pour le principal à l'origine de la requête. Si la condition renvoie la valeur "false", Identity and Access Management n'applique pas la stratégie au principal. Pour en savoir plus, consultez la section Limite d'accès des comptes principaux et conditions sur cette page.

• createTime: heure de création de la liaison de stratégie.

• updateTime: heure de la dernière mise à jour de l'association de stratégie.

Cas d'utilisation

Vous trouverez ci-dessous des situations courantes dans lesquelles vous pouvez utiliser des stratégies de limite d'accès des comptes principaux, ainsi que des exemples de stratégies de limite d'accès des comptes principaux et de liaisons de stratégie que vous pouvez créer dans chacune de ces situations. Pour savoir comment créer des stratégies de limite d'accès des comptes principaux et les associer à des ensembles de comptes principaux, consultez Créer et appliquer des stratégies de limite d'accès des comptes principaux.

Limiter les comptes principaux aux ressources de votre organisation

Vous pouvez utiliser des stratégies de limite d'accès des comptes principaux pour vous assurer que les comptes principaux de votre organisation ne peuvent accéder qu'aux ressources de votre organisation.

Par exemple, imaginez que vous souhaitiez vous assurer que tous les comptes principaux de l'organisation example.com ne peuvent accéder qu'aux ressources de example.com. Les comptes principaux de example.com incluent toutes les identités du domaine example.com, tous les pools d'identités de personnel de example.com, ainsi que tous les comptes de service et pools d'identités de charge de travail de n'importe quel projet de example.com.

Aucune stratégie de limite d'accès des comptes principaux ne s'applique à l'un des comptes principaux de votre organisation. Par conséquent, tous les comptes principaux peuvent accéder à toutes les ressources.

Pour empêcher les comptes principaux d'accéder aux ressources en dehors de example.com, vous devez créer une stratégie de limite d'accès des comptes principaux qui leur permet d'accéder aux ressources dans example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Vous créez ensuite une liaison de règle pour lier cette règle à l'ensemble de comptes principaux:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Désormais, tous les comptes principaux de example.com ne peuvent que accéder aux ressources de example.com. Ils ne peuvent pas utiliser les autorisations bloquées par la règle de limite d'accès des comptes principaux pour accéder aux ressources en dehors de example.com, même s'ils disposent de ces autorisations pour ces ressources.

Limiter les comptes de service aux ressources d'un seul projet

Vous pouvez utiliser des stratégies de limite d'accès des comptes principaux pour vous assurer que les comptes de service d'un projet spécifique ne peuvent accéder qu'aux ressources de ce projet.

Par exemple, imaginons que vous disposiez d'un projet, example-dev. Vous souhaitez vous assurer que les comptes de service de example-dev ne peuvent accéder qu'aux ressources de example-dev.

Vous disposez d'une stratégie de limite d'accès des comptes principaux qui permet à tous les comptes principaux de votre organisation, y compris les comptes de service dans example-dev, d'accéder aux ressources dans example.com. Pour voir à quoi ressemble ce type de stratégie, consultez Limiter les comptes principaux aux ressources de votre organisation.

Pour que les comptes de service de example-dev ne puissent pas accéder aux ressources en dehors de example-dev, vous devez d'abord créer une règle de limite d'accès des comptes principaux qui permet aux comptes principaux d'accéder aux ressources dans example-dev.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Ensuite, vous créez une liaison de règle pour lier cette règle à tous les comptes principaux dans example-dev, puis vous ajoutez une condition pour que la liaison de règle ne s'applique qu'aux comptes de service :

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Toutefois, cette stratégie ne limite pas à elle seule l'éligibilité des comptes de service. En effet, une stratégie de limite d'accès des comptes principaux permet à tous les comptes principaux de example.com d'accéder à toutes les ressources de example.com. Les stratégies de limite d'accès des comptes principaux sont cumulables. Par conséquent, les comptes de service de example-dev peuvent toujours accéder à toutes les ressources de example.com.

Pour vous assurer que les comptes de service dans example-dev ne peuvent que accéder aux ressources dans example-dev, vous devez ajouter une condition à la liaison de stratégie pour la stratégie de limite d'accès des comptes principaux existante qui l'empêche d'être appliquée aux comptes de service dans example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

Désormais, les comptes de service dans example-dev ne peuvent accéder qu'aux ressources de example-dev. Ils ne peuvent pas utiliser les autorisations bloquées par la règle de limite d'accès des comptes principaux pour accéder aux ressources en dehors de example-dev, même s'ils disposent de ces autorisations pour ces ressources.

Étape suivante

• Découvrez comment créer et appliquer des stratégies de limite d'accès des comptes principaux.
• Consultez l'autorisation bloquée par chaque version de l'application des stratégies de limite d'accès des comptes principaux.