Stratégies de refus

Les stratégies de refus d'IAM (Identity and Access Management) vous permettent de définir des garde-fous pour l'accès aux ressources Google Cloud. Les stratégies de refus vous permettent de définir des règles de refus qui empêchent certains comptes principaux d'utiliser certaines autorisations, quels que soient les rôles qui leur sont attribués.

Cette page présente les politiques de refus et les règles de refus. Pour savoir comment créer et mettre à jour des politiques de refus, consultez la section Refuser l'accès aux ressources.

Fonctionnement des stratégies de refus

Les stratégies de refus sont composées de règles de refus. Chaque règle de refus spécifie les éléments suivants :

  • Un ensemble de comptes principaux auxquels les autorisations sont refusées
  • Les autorisations refusées aux comptes principaux ou qui ne peuvent pas être utilisées
  • Facultatif : la condition qui doit être vraie pour que l'autorisation soit refusée

Lorsqu'un compte principal se voit refuser une autorisation, il ne peut rien faire qui nécessite cette autorisation, quels que soient les rôles IAM qui lui ont été attribués. En effet, IAM vérifie toujours les stratégies de refus pertinentes avant de vérifier les stratégies d'autorisation appropriées. Pour en savoir plus, consultez la section Évaluation des règles.

Pour spécifier où vous souhaitez appliquer une stratégie de refus, vous devez associer la stratégie à un projet, un dossier ou une organisation. Lorsqu'une stratégie de refus est associée à l'une de ces ressources, les comptes principaux ne peuvent pas utiliser les autorisations spécifiées pour accéder à la ressource ni à ses descendants. Pour en savoir plus sur les emplacements où vous pouvez joindre une stratégie de refus, consultez la section Point d'attachement sur cette page.

Vous pouvez associer plusieurs stratégies de refus à une même ressource. Cela vous permet de créer des stratégies de refus distinctes pour différents types de règles de refus. Par exemple, vous pouvez placer des règles de refus liées à la conformité dans une stratégie, puis utiliser une autre stratégie pour d'autres règles de refus. Chaque stratégie de refus est évaluée indépendamment de toutes les autres stratégies de refus.

Chaque ressource peut comporter jusqu'à 500 stratégies de refus. Prises ensemble, ces stratégies de refus peuvent contenir un total de 500 règles de refus.

Point d'attachement

Chaque règle de refus est associée à une organisation, un dossier ou un projet. Lorsqu'elles sont associées à l'une de ces ressources, les règles de refus sont héritées par toutes les ressources de niveau inférieur contenues dans ce projet, ce dossier ou cette organisation. Pour utiliser des règles de refus, vous avez besoin d'un identifiant pour la ressource à laquelle la règle de refus est associée, appelée point de rattachement. Cet identifiant utilise l'un des formats du tableau suivant :

Format des points de rattachement
Organisation

cloudresourcemanager.googleapis.com/organizations/ORG_ID
Remplacez ORG_ID par l'ID numérique de l'organisation. Pour l'API REST, encodez l'intégralité de la valeur au format URL.

Exemple pour la CLI gcloud :
cloudresourcemanager.googleapis.com/organizations/123456789012

Exemple pour l'API REST :
cloudresourcemanager.googleapis.com%2Forganizations%2F123456789012

Dossier

cloudresourcemanager.googleapis.com/folders/FOLDER_ID
Remplacez FOLDER_ID par l'ID numérique du dossier. Pour l'API REST, encodez l'intégralité de la valeur au format URL.

Exemple pour la CLI gcloud :
cloudresourcemanager.googleapis.com/folders/987654321098

Exemple pour l'API REST :
cloudresourcemanager.googleapis.com%2Ffolders%2F987654321098

Projet

cloudresourcemanager.googleapis.com/projects/PROJECT_ID
Remplacez PROJECT_ID par l'ID alphanumérique ou numérique du projet. Pour l'API REST, encodez l'intégralité de la valeur au format URL.

Exemple pour la CLI gcloud :
cloudresourcemanager.googleapis.com/projects/my-project

Exemple pour l'API REST :
cloudresourcemanager.googleapis.com%2Fprojects%2Fmy-project

Héritage des stratégies de refus

Les stratégies de refus, telles que les stratégies d'autorisation, sont héritées via la hiérarchie des ressources. Lorsque vous associez une stratégie de refus à un projet, un dossier ou une organisation, la stratégie est appliquée à toutes les ressources au sein de ce projet, ce dossier ou cette organisation.

Par exemple, si une règle de refus pour une organisation indique qu'un compte principal ne peut pas utiliser une autorisation spécifique, le compte principal ne peut pas utiliser cette autorisation pour n'importe quelle ressource au sein de l'organisation. Cette règle s'applique même si les dossiers et les projets de cette organisation sont associés à des règles de refus plus permissives.

De même, si une règle de refus pour un projet indique qu'un compte principal ne peut pas utiliser une autorisation spécifique, le compte principal ne peut utiliser cette autorisation sur aucune ressource du projet. Cette règle s'applique même si les règles d'administration et de dossier parent sont plus permissives.

Conditions de refus

Les conditions de refus spécifient les conditions qui doivent être remplies pour qu'une règle de refus s'applique. Si la condition renvoie true ou ne peut pas être évaluée, la règle de refus s'applique et les comptes principaux ne peuvent pas utiliser les autorisations spécifiées. Si la condition renvoie false, la règle de refus ne s'applique pas et les comptes principaux peuvent utiliser les autorisations spécifiées, le cas échéant.

Les conditions de refus ont la même structure que les conditions IAM. Cependant, les conditions de refus ne reconnaissent que les fonctions de tags de ressources.

Pour savoir comment écrire des conditions, consultez la page Présentation des conditions IAM.

Groupes d'autorisations

Certains services vous permettent de refuser des groupes d'autorisations. Les groupes d'autorisations sont des ensembles d'autorisations qui correspondent à un modèle spécifié. Vous pouvez utiliser un groupe d'autorisations pour refuser des ensembles d'autorisations associées. Par exemple, vous pouvez refuser toutes les autorisations pour un seul service ou une seule ressource.

Les groupes d'autorisations compatibles sont listés dans la section Autorisations compatibles avec les stratégies de refus. Les identifiants des groupes d'autorisations compatibles remplacent une ou plusieurs sections d'un nom d'autorisation par un caractère générique (*). Les autorisations incluses dans chaque groupe dépendent de la position du caractère générique:

  • SERVICE_FQDN/RESOURCE.* : refuse toutes les autorisations pour la ressource donnée.
  • SERVICE_FQDN/*.* : refuse toutes les autorisations pour le service spécifié.
  • SERVICE_FQDN/*.VERB : refuse toutes les autorisations pour un service qui se termine par le verbe spécifié.

Les groupes d'autorisations incluent toutes les autorisations actuelles et futures qui correspondent au format spécifié. Par exemple, imaginez que vous utilisiez le groupe d'autorisations example.googleapis.com/exampleResource.* pour refuser à un utilisateur toutes les autorisations pour le type de ressource exampleResource. Si example.googleapis.com ajoute une nouvelle autorisation pour le type de ressource exampleResource, tel que example.googleapis.com/exampleResource.newPermission, l'utilisateur se verra automatiquement refuser la nouvelle autorisation.

Vous ne pouvez utiliser des caractères génériques que dans les groupes d'autorisations compatibles. L'utilisation de caractères génériques dans d'autres noms d'autorisation n'est pas prise en charge.

Structure d'une stratégie de refus

Une stratégie de refus est un ensemble de métadonnées et de règles de refus. Une règle de refus associe un ensemble de comptes principaux à un ensemble d'autorisations que les comptes principaux sont autorisés ou non à utiliser. Chaque règle peut également spécifier une condition qui détermine le moment où l'autorisation est refusée.

Par exemple, la stratégie de refus suivante empêche tous les comptes principaux de supprimer des projets, sauf si le compte principal est membre du groupe project-admins ou si le projet en cours de suppression possède un tag avec la valeur test.

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

Les sections suivantes décrivent les champs des métadonnées et des règle de refus d'une stratégie de refus.

Métadonnées

Les stratégies de refus contiennent les métadonnées suivantes :

  • name : nom de la stratégie de refus. Ce nom est au format policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, où ATTACHMENT_POINT correspond au projet, au dossier ou à l'organisation qui sont associés à la stratégie de refus et POLICY_ID est l'ID alphanumérique de la stratégie de refus.
  • uid : ID unique attribué à la stratégie de refus par Google.
  • kind : type de stratégie. La valeur kind d'une stratégie de refus est toujours DenyPolicy.
  • displayName : facultatif. Nom lisible de la stratégie de refus.
  • etag : identifiant d'une version de 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.
  • createTime : heure de création de la stratégie de refus.
  • updateTime : la dernière fois que la stratégie de refus a été mise à jour.

Règles de refus

Chaque règle de refus peut comporter les champs suivants :

  • deniedPrincipals : Les comptes principaux qui se voient refuser ces autorisations. Vous pouvez répertorier les comptes principaux individuels et les ensembles de comptes principaux. Les types d'entités principales individuelles incluent les comptes utilisateur, les comptes de service et les identités uniques au sein d'un pool d'identités de charge de travail ou de personnel. Les ensembles de comptes principaux incluent les groupes Google, les domaines Cloud Identity, les ensembles d'identités de charge de travail ou de personnel, ainsi que tous les utilisateurs d'Internet.

    Pour obtenir la liste des types de comptes principaux et des identifiants valides, consultez la page Identifiants des comptes principaux pour l'API IAM v2.

  • exceptionPrincipals : facultatif. Les comptes principaux exclus de la règle de refus. Ces comptes principaux ne reçoivent pas les autorisations spécifiées, même s'ils sont répertoriés dans deniedPrincipals ou font partie d'un groupe répertorié dans deniedPrincipals.

    Vous pouvez répertorier les comptes principaux individuels et les ensembles de comptes principaux. Les types d'entités principales individuelles incluent les comptes utilisateur, les comptes de service et les identités uniques au sein d'un pool d'identités de charge de travail ou de personnel. Les ensembles de comptes principaux incluent les groupes Google, les domaines Cloud Identity, les ensembles d'identités de charge de travail ou de personnel, ainsi que tous les utilisateurs d'Internet.

    Pour obtenir la liste des types de comptes principaux et des identifiants valides, consultez la page Identifiants des comptes principaux pour l'API IAM v2.

  • deniedPermissions: autorisations que les comptes principaux spécifiés ne peuvent pas utiliser, ou qui leurs sont refusées. Ces autorisations utilisent le format d'autorisation IAM v2, qui utilise des noms de domaine complets pour identifier le service. Il a le format suivant : SERVICE_FQDN/RESOURCE.ACTION. Les API Google utilisent le domaine *.googleapis.com. Par exemple, iam.googleapis.com/roles.delete.

    Seules certaines autorisations peuvent être refusées. Pour obtenir la liste complète des autorisations pouvant être refusées, consultez la section Autorisations compatibles dans les stratégies de refus.

    Dans certains cas, vous pouvez également utiliser des groupes d'autorisations pour refuser des ensembles d'autorisations. Pour en savoir plus, consultez la section Groupes d'autorisations.

  • exceptionPermissions : facultatif. Liste des autorisations que les comptes principaux spécifiés peuvent utiliser, même si ces autorisations sont incluses dans deniedPermissions. Par exemple, vous pouvez utiliser ce champ pour créer des exceptions pour des autorisations spécifiques dans un groupe d'autorisations.

  • denialConditions : facultatif. Une expression logique qui affecte la période de refus de la règle. Si la condition renvoie true ou ne peut pas être évaluée, l'autorisation est refusée. Si la condition renvoie false, l'autorisation n'est pas refusée. Pour en savoir plus, consultez la section Conditions de refus sur cette page.

Cas d'utilisation courants

Vous trouverez ci-dessous des situations courantes dans lesquelles vous pouvez utiliser des stratégies de refus, ainsi que des exemples de règles de refus que vous pouvez créer dans chacune de ces situations. Pour savoir comment créer et mettre à jour des politiques de refus, consultez la section Refuser l'accès aux ressources.

Centraliser les droits d'administrateur

Vous pouvez utiliser des stratégies de refus pour limiter certains types d'activités d'administration à un ensemble spécifique de comptes principaux.

Par exemple, imaginons que vous souhaitiez limiter la gestion des rôles personnalisés pour votre organisation à une seule équipe centrale. Pour ce faire, vous créez une règle de refus qui refuse les autorisations requises pour la gestion des rôles personnalisés à tous les utilisateurs, à l'exception des utilisateurs du groupe d'administration (custom-role-admins) :

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

Ensuite, vous devez associer la stratégies de refus à votre organisation.

Désormais, seuls les membres du groupe custom-role-admins peuvent gérer les rôles personnalisés, même si d'autres utilisateurs disposent des autorisations requises.

Par exemple, imaginons que Yuri et Tal aient le rôle Administrateur des rôles de l'organisation (roles/iam.organizationRoleAdmin). Cependant, Yuri est membre de custom-role-admins, et Tal ne l'est pas. Avec cette stratégie de refus, seul Yuri peut créer, supprimer et mettre à jour des rôles.

Créer des exceptions aux autorisations d'accès

Vous pouvez utiliser des règles de refus pour refuser les autorisations héritées. Cette fonctionnalité vous permet d'accorder un rôle à un niveau élevé dans la hiérarchie des ressources, puis de refuser les autorisations du rôle sur les ressources individuelles de niveau inférieur, si nécessaire.

Par exemple, imaginons que vous disposiez d'un dossier, Engineering, qui contient plusieurs projets. Vous souhaitez attribuer à un groupe, eng, les autorisations du rôle "Administrateur de clés de compte de service" (roles/iam.serviceAccountKeyAdmin) sur presque tous les projets du dossier. Cependant, vous ne souhaitez pas que le groupe puisse créer et supprimer des clés de compte de service dans un projet spécifique du dossier, example-prod.

Au lieu d'attribuer le rôle d'administrateur de clé de compte de service à chaque projet individuel, vous créez la règle de refus suivante, qui refuse les autorisations de création et de suppression aux utilisateurs principaux du rôle d'administrateur de clé de compte de service dans le groupe eng:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Vous ajoutez ensuite cette règle de refus à une stratégie de refus, puis vous l'associez au projet example-prod.

Après avoir associé la stratégie de refus au projet, vous pouvez attribuer le rôle d'administrateur de clé de compte de service au groupe eng sur le dossier Engineering sans autoriser le groupe à créer ou à supprimer des clés de compte de service dans example-prod.

Les membres du groupe eng peuvent ensuite créer et supprimer des clés de compte de service dans tous les projets, à l'exception de example-prod. Par exemple, si Izumi est membre du groupe eng, il peut créer et supprimer des clés pour les comptes de service dans example-dev et example-test, mais pas dans example-prod.

Toutefois, imaginons que vous souhaitiez qu'un sous-ensemble du groupe eng puisse créer et supprimer des clés de compte de service dans example-prod. Ce sous-ensemble est représenté par le groupe eng-prod. Pour autoriser les membres du groupe eng-prod à créer et supprimer des clés de compte de service dans example-prod, vous pouvez exclure le groupe de la règle de refus:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/eng-prod@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Avec cette stratégie de refus révisée, les membres du groupe eng-prod peuvent créer et supprimer des clés de compte de service dans tous les projets, y compris example-prod. Par exemple, si Charlie est membre du groupe eng-prod, il peut créer et supprimer des clés dans example-dev, example-test et example-prod, même s'il est également membre du groupe eng.

Bloquer l'accès en fonction de tags

Un tag est une paire clé-valeur pouvant être associée à une organisation, un dossier ou un projet. Vous pouvez utiliser des stratégies de refus pour refuser des autorisations basées sur des tags sans ajouter de condition IAM à chaque attribution de rôle.

Par exemple, imaginons que vous ajoutiez un tag dev, test ou prod à tous vos projets. Vous souhaitez que seuls les membres du groupe project-admins puissent supprimer des projets tagués prod.

Pour résoudre ce problème, vous créez une règle de refus qui refuse l'autorisation cloudresourcemanager.googleapis.com/projects.delete à tous les utilisateurs, à l'exception du groupe project-admins, pour les ressources taggées prod:

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

Vous ajoutez ensuite cette règle de refus à une stratégie de refus et vous l'associez à votre organisation.

En raison de cette règle de refus, vous pouvez limiter l'accès des comptes principaux sans ajouter de condition à leurs attributions de rôles. À la place, vous pouvez attribuer des rôles aux comptes principaux qui contiennent l'autorisation cloudresourcemanager.googleapis.com/projects.delete, et vous appuyer sur la règle de refus pour empêcher les comptes principaux situés en dehors du groupe project-admins de supprimer les projets tagués prod.

Prenons l'exemple de deux utilisateurs, Bola et Kiran. Les deux utilisateurs disposent du rôle "suppression de projets" (roles/resourcemanager.projectDeleter). En outre, Kiran est membre du groupe project-admins. Avec cette règle de refus, Bola ne peut supprimer que des projets tagués dev ou test. Kiran peut supprimer tous les projets, quels que soient leurs tags.

Étape suivante