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.

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.

Évaluation de la stratégie

Lorsqu'un compte principal tente d'accéder à une ressource, IAM évalue toutes les stratégies d'autorisation et de refus pertinentes pour vérifier si le compte principal est autorisé à accéder à la ressource. Les stratégies sont évaluées dans l'ordre suivant :

  1. Cloud IAM vérifie toutes les stratégies de refus pertinentes pour voir si l'entité principale a été refusée. Les stratégies de refus applicables sont les stratégies de refus associées à la ressource, ainsi que les stratégies de refus héritées.

    Si l'une de ces stratégies de refus empêche le compte principal d'utiliser une autorisation requise, IAM l'empêche d'accéder à la ressource.

    Si aucune stratégie de refus n'empêche le compte principal d'utiliser une autorisation requise, IAM passe à l'étape suivante.

  2. Cloud IAM vérifie toutes les stratégies d'autorisation pertinentes pour voir si le compte principal dispose des autorisations requises. Les stratégies d'autorisation pertinentes sont les stratégies d'autorisation associées à la ressource, ainsi que toutes les stratégies d'autorisation héritées.

    Si le compte principal dispose des autorisations requises, IAM lui permet d'accéder à la ressource.

    Si le compte principal ne dispose pas des autorisations requises, IAM l'empêche d'accéder à la ressource.

Le schéma suivant illustre ce flux d'évaluation des stratégies :

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 correspondant à 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 répertoriés dans la section Autorisations compatibles dans les stratégies de refus. Vous ne pouvez pas utiliser de caractères génériques dans d'autres noms d'autorisations.

L'identifiant d'un groupe d'autorisations remplace une ou plusieurs sections d'un nom d'autorisation par un caractère générique (*). Le groupe d'autorisations inclut toutes les autorisations correspondant à ce modèle.

Les caractères génériques peuvent apparaître aux emplacements suivants :

  • 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 modèle spécifié. Par exemple, imaginons 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 autorisation pour le type de ressource exampleResource, telle que example.googleapis.com/exampleResource.newPermission, l'utilisateur est automatiquement refusé.

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 de project-admins@example.com 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"
        ],
        "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. Son format est le 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.

  • 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@example.com) :

{
  "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@example.com peuvent gérer les rôles personnalisés, même si d'autres utilisateurs disposent des autorisations requises.

Par exemple, imaginez que yuri@example.com et tal@example.com ont le rôle Administrateur des rôles de l'organisation (roles/iam.organizationRoleAdmin). Cependant, yuri@example.com est membre de custom-role-admins@example.com, et tal@example.com ne l'est pas. Avec cette stratégie de refus, seul yuri@example.com 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@example.com, 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 eng@example.com :

{
  "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 à eng@example.com sur le dossier Engineering sans autoriser au groupe de créer ou de supprimer les clés de compte de service dans example-prod.

Les membres de eng@example.com 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@example.com est membre de eng@example.com, 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 de eng@example.com 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@example.com. Pour autoriser les membres de eng-prod@example.com à 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 domaine eng-prod@example.com peuvent créer et supprimer des clés de compte de service dans tous les projets, y compris example-prod. Par exemple, si charlie@example.com est membre de eng-prod@example.com, il peut créer et supprimer des clés dans example-dev, example-test et example-prod, même s'il est également membre de eng@example.com.

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 projet project-admins@example.com puissent supprimer des projets taggé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 de project-admins@example.com, 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 de project-admins@example.com de supprimer les projets taggés prod.

Par exemple, considérons deux utilisateurs, bola@example.com et kiran@example.com. Les deux utilisateurs disposent du rôle "suppression de projets" (roles/resourcemanager.projectDeleter). En outre, kiran@example.com est membre de project-admins@example.com. Avec cette règle de refus, bola@example.com ne peut supprimer que des projets taggés dev ou test. kiran@example.com peut supprimer tous les projets, quels que soient leurs tags.

Étape suivante