Google Cloud a déménagé Stratégies de refus IAM en pleine disponibilité générale. Les stratégies IAM Deny fonctionnent parallèlement aux stratégies IAM Allow pour fournir davantage d’options pour contrôler quels mandataires ont accès à quelles ressources. Les règles de refus IAM sont disponibles avec Google Cloud IAM pour la plupart des autorisations.

Ravi Shah, responsable des produits pour Google Cloud, décrit les politiques IAM Deny comme fournissant « un contrôle d’accès puissant et grossier pour aider à mettre en œuvre des politiques de sécurité à grande échelle ». Ceci est destiné à compléter le contrôle plus granulaire fourni par les stratégies d’autorisation IAM. Les stratégies de refus IAM sont évaluées en premier et remplacent toujours les stratégies d’autorisation IAM.

Les stratégies de refus sont constituées de règles de refus. Les règles de refus spécifient un ensemble de mandataires qui se voient refuser des autorisations, les autorisations qui leur sont refusées et, éventuellement, une condition qui doit être vraie pour que l’autorisation soit refusée. Les stratégies de refus sont appliquées au niveau du projet, du dossier ou de l’organisation. Chaque projet, dossier ou organisation peut avoir jusqu’à cinq stratégies de refus, qui sont évaluées indépendamment. Une fois attachée à un projet, un dossier ou une organisation, la stratégie Refuser s’applique à toutes les ressources de ce groupement.

Les règles de refus IAM ne peuvent pas être utilisées avec toutes les autorisations dans Google Cloud. Les stratégies de refus nécessitent l’IAM v2 format d’autorisation. Ceux-ci sont sous la forme SERVICE_FQDN/RESOURCE.ACTION où SERVICE_FQDN est la valeur de SERVICE_ID de l’ v1 API avec .googleapis.com y est annexé. Par exemple, l’autorisation de supprimer un rôle dans le v2 Le format d’autorisation est iam.googleapis.com/roles.delete. Un Liste des autorisations prises en charge est disponible dans la documentation Google Cloud.

Les stratégies de refus IAM prennent en charge une condition facultative. La règle de refus ne prend effet que si la condition est évaluée à true ou ne peut pas être évaluée. Si la condition a la valeur false, l’accès à l’autorisation n’est pas refusé au principal par cette stratégie.

L’exemple suivant empêche tous les mandataires de supprimer des projets, sauf s’ils sont membres du project-admins@example.com Le groupe de sécurité ou le projet possède une balise 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')"
        }
      }
    }
  ]
}

L’introduction de règles de refus IAM aligne plus étroitement la mise en œuvre d’IAM par Google Cloud avec AWS. Les deux outils IAM sont structurés autour d’une approche de refus implicite impliquant que toutes les demandes sont refusées sauf autorisation spécifique. Le refus explicite est évalué en premier dans les deux solutions cloud et remplace tous les privilèges d’autorisation ultérieurs.

Les règles Google Cloud IAM Deny sont désormais disponibles dans le Outil IAM pour un sous-ensemble d’autorisations. Vous trouverez plus de détails sur IAM Deny dans le Publier un article de blog et au sein de l’ Documentation Google Cloud.