Exemples de cas d'utilisation des stratégies de limite d'accès des comptes principaux

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 et de liaisons de stratégies 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 lier à des ensembles de comptes principaux, consultez Créer et appliquer des stratégies de limite d'accès des comptes principaux.

Empêcher les utilisateurs d'accéder à des ressources en dehors de votre organisation

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

Règle de limite d'accès des comptes principaux empêchant l'accès à une ressource

Règle de limite d'accès des comptes principaux empêchant l'accès à une ressource

  • Le compte principal Tal (tal@example.com) fait partie de l' organisation Google Workspace example.com.
  • Le rôle d'administrateur de l'espace de stockage (roles/storage.admin) est attribué à Tal sur un bucket Cloud Storage d'une autre organisation, cymbalgroup.com. Ce rôle contient l'autorisation storage.objects.get, qui est requise pour afficher les objets dans le bucket.
  • Aucune stratégie de refus dans cymbalgroup.com n'empêche Tal d'utiliser l'autorisation storage.objects.get.

Les administrateurs example.com ne peuvent pas utiliser de stratégies d'autorisation et de refus pour empêcher Tal d'afficher des objets dans ce bucket externe. Aucun compte principal example.com n'est autorisé à modifier la stratégie 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 de stratégies de refus dans cymbalgroup.com. Il ne peut donc pas utiliser de stratégie de refus pour empêcher Tal d'accéder au bucket.

Toutefois, grâce aux stratégies de limite d'accès des comptes principaux, les administrateurs example.com peuvent empêcher Tal d'afficher des objets dans le bucket cymbalgroup.com ou dans tout bucket en dehors de example.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 example.com ne sont autorisés à accéder qu'aux ressources de 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": "4"
  }
}

Il peut ensuite créer une liaison de règle pour l'associer à tous les comptes principaux de l'organisation example.com :

{
  "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"
}

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.

Avec cette stratégie en place, les comptes principaux de example.com ne peuvent pas utiliser les autorisations qui sont bloquées par la stratégie 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.

Dans ce cas, la stratégie de limite d'accès des comptes principaux utilise la version d'application 4. Elle peut donc bloquer l'autorisation storage.objects.get. Par conséquent, Tal ne pourra pas afficher les objets dans le bucket cymbalgroup.com, même si le rôle d'administrateur de l'espace de stockage lui est attribué sur le bucket.

Autoriser les comptes de service à accéder aux ressources d'un seul projet

Vous pouvez également utiliser des stratégies de limite d'accès des comptes principaux pour autoriser des sous-ensembles de comptes principaux à accéder à des sous-ensembles de ressources de votre organisation.

Par exemple, imaginons que vous disposiez d'un projet, example-dev, dont le numéro est 901234567890. Vous souhaitez vous assurer que les comptes de service de example-dev ne sont autorisés à accéder qu'aux ressources de example-dev.

Pour ce faire, vous devez d'abord créer une stratégie de limite d'accès des comptes principaux qui autorise les comptes principaux à accéder aux ressources de dev-project :

{
  "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": "4"
  }
}

Cette stratégie de limite d'accès des comptes principaux utilise la version d'application 4, ce qui signifie qu' elle peut bloquer toutes les autorisations compatibles avec la version d'application 4.

Après avoir créé la stratégie de limite d'accès des comptes principaux, vous créez une liaison de règle pour lier la nouvelle stratégie à tous les comptes principaux de 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'"
  }
}

S'il s'agit de la seule stratégie de limite d'accès des comptes principaux à laquelle les comptes de service sont soumis, ils ne pourront pas utiliser les autorisations que la stratégie de limite d'accès des comptes principaux peut bloquer pour accéder à des ressources en dehors de example-dev.

Gérer l'éligibilité pour différents groupes de comptes principaux

Vous pouvez utiliser plusieurs stratégies de limite d'accès des comptes principaux dans la même organisation pour autoriser différents comptes principaux à accéder à différentes ressources. Lorsque vous utilisez plusieurs stratégies de limite d'accès des comptes principaux, utilisez des conditions dans vos liaisons de règles pour vous assurer que chaque stratégie ne s'applique qu'aux comptes principaux auxquels vous souhaitez l'appliquer.

Par exemple, imaginons que vous souhaitiez que la plupart des comptes principaux puissent accéder à toutes les ressources de votre organisation, comme indiqué dans Empêcher les utilisateurs d'accéder à des ressources en dehors de votre organisation. Toutefois, vous souhaitez également vous assurer que les comptes de service de example-dev ne sont autorisés à accéder qu'aux ressources de example-dev, comme indiqué dans Autoriser les comptes de service à accéder aux ressources d'un seul projet.

Pour atteindre cet objectif, procédez comme suit :

  1. En suivant l'exemple de la section Empêcher les utilisateurs d'accéder à des ressources en dehors de votre organisation, vous créez une stratégie de limite d'accès des comptes principaux qui autorise les comptes principaux à accéder aux ressources de example.com et vous la liez à l'ensemble de comptes principaux de l'organisation.

  2. En suivant l'exemple de la section Autoriser les comptes de service à accéder aux ressources d'un seul projet, vous créez une stratégie de limite d'accès des comptes principaux qui autorise les comptes de service de example-dev à accéder aux ressources de example-dev et vous la liez aux comptes de service de example-dev.

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

    "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') && principal.subject != 'example-dev@appspot.gserviceaccount.com' && principal.subject != '901234567890-compute@developer.gserviceaccount.com')"
}

Cette dernière étape est essentielle. Si vous n'exemptez pas les comptes de service example-dev de la stratégie de limite d'accès des comptes principaux initiale, cette stratégie leur permettra d'accéder à toutes les ressources de example.com, quelles que soient les autres stratégies de limite d'accès des comptes principaux auxquelles ils sont soumis. Pour en savoir plus, consultez Définir les ressources éligibles.

Il est également important de créer et d'associer une stratégie de limite d'accès des comptes principaux aux comptes de service example-dev avant de les exempter de la stratégie de limite d'accès des comptes principaux initiale. Cette procédure garantit que les comptes de service sont toujours soumis à au moins une stratégie de limite d'accès des comptes principaux, ce qui les empêche de pouvoir devenir éligibles à l'accès à toutes les Google Cloud ressources. Pour en savoir plus sur la réduction sécurisée des ressources auxquelles un compte principal est autorisé à accéder, consultez Réduire les ressources auxquelles les comptes principaux sont autorisés à accéder.

Étape suivante