Frontières de permissions IAM : déléguer IAM aux équipes sans danger

Une frontière de permissions est une politique gérée qui fixe le plafond de ce qu’un utilisateur ou un rôle IAM pourra jamais faire : les permissions effectives deviennent l’intersection des politiques d’identité et de la frontière. Une frontière n’accorde rien par elle-même. Son vrai but, c’est la délégation — laisser les équipes applicatives créer et gérer leurs propres rôles, pendant qu’une condition sur iam:CreateRole force chaque rôle qu’elles créent à porter la frontière, pour que personne ne puisse frapper un rôle plus puissant que ce que le plafond permet.

Ce qui se passe

Sans frontières, la délégation IAM est binaire : soit une équipe centrale crée chaque rôle (et devient le goulot que chaque déploiement attend), soit les équipes reçoivent iam:* et n’importe quel développeur peut se créer un rôle admin — l’escalade de privilèges comme fonctionnalité. Les frontières cassent l’impasse. La mécanique : attachez une politique gérée comme frontière sur un principal, et chaque requête est évaluée contre la politique d’identité et la frontière; une action doit être permise par les deux pour réussir (un deny explicite dans l’une ou l’autre gagne quand même sur tout). La frontière est un plafond, pas un plancher — une frontière permettant s3:* n’accorde rien à un rôle dont la politique d’identité ne permet que dynamodb:GetItem.

Le patron de délégation ajoute un truc d’application. Le rôle de l’équipe reçoit iam:CreateRole, iam:AttachRolePolicy et compagnie — mais seulement sous une condition que iam:PermissionsBoundary égale l’ARN de votre politique frontière standard. Créer un rôle sans la frontière, ou avec une autre, échoue. Combiné à des deny explicites sur le retrait ou l’échange de frontières et sur la modification de la politique frontière elle-même, le plafond devient auto-appliqué : les équipes avancent vite en dessous, et ne peuvent pas le monter. Deux mises en garde honnêtes. Un : les frontières ne contraignent pas les politiques de ressources — une politique de compartiment qui accorde directement à l’utilisateur précis fonctionne même si la frontière ne le permettrait pas. Deux : les frontières sont par principal, pas à l’échelle du compte; pour des plafonds de compte, il vous faut des SCP, couvertes dans notre article sur la base SCP. Le chapitre sur la logique d’évaluation de la documentation IAM montre exactement où les frontières se placent dans la chaîne de décision.

Quoi vérifier en premier

Si l’escalade est présentement possible. Tout principal détenant iam:CreateRole plus iam:AttachRolePolicy sans condition de frontière peut déjà s’auto-escalader — c’est la population à corriger.
Ce que le plafond devrait contenir. La frontière doit permettre tout ce que les équipes déploient légitimement (leurs services, leurs régions), sinon elle sera combattue au lieu d’être adoptée.
Qui peut modifier la politique frontière. Une frontière modifiable par les gens qu’elle contraint est de la décoration.
L’usage existant des frontières — certains comptes en ont déjà d’à moitié adoptées d’une vieille initiative, attachées de façon incohérente.

Comment vérifier

# Ce rôle a-t-il une frontière, et laquelle?
aws iam get-role --role-name team-app-role \
  --query 'Role.PermissionsBoundary'

# Trouver les principaux autorisés à créer des rôles (candidats au patron de délégation)
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/IAMFullAccess

# Test : comme rôle délégué, tenter de créer un rôle SANS la frontière — doit échouer
aws iam create-role --role-name escalation-test \
  --assume-role-policy-document file://trust.json

Chemin console : IAM > Roles > (role) > Permissions boundary montre le plafond attaché. Le test create-role devrait retourner un refus explicite mentionnant la condition de frontière; s’il réussit, la politique de délégation ne fait pas son travail — supprimez le rôle de test.

Le runbook

Écrivez la politique frontière comme plafond. Permettez les familles de services que les équipes déploient (calcul, stockage, files dans les régions approuvées) et omettez ce qu’elles ne doivent jamais toucher : organizations:*, account:*, les actions d’écriture CloudTrail, et IAM sauf les lectures.
Accordez les pouvoirs IAM seulement avec la condition de frontière. Le coeur de la politique de délégation :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateRolesOnlyWithBoundary",
      "Effect": "Allow",
      "Action": ["iam:CreateRole", "iam:AttachRolePolicy", "iam:PutRolePolicy",
                 "iam:DetachRolePolicy", "iam:DeleteRolePolicy", "iam:UpdateRole"],
      "Resource": "arn:aws:iam::111122223333:role/team-*",
      "Condition": {
        "StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/team-boundary"}
      }
    },
    {
      "Sid": "NoBoundaryTampering",
      "Effect": "Deny",
      "Action": ["iam:DeleteRolePermissionsBoundary", "iam:DeleteUserPermissionsBoundary"],
      "Resource": "*"
    },
    {
      "Sid": "NoEditingTheCeiling",
      "Effect": "Deny",
      "Action": ["iam:CreatePolicyVersion", "iam:DeletePolicy",
                 "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion"],
      "Resource": "arn:aws:iam::111122223333:policy/team-boundary"
    }
  ]
}

Contraignez les noms avec un chemin ou un préfixe. Le motif de ressource team-* garde les rôles délégués dans leur propre espace de noms, loin des rôles de plateforme.
Pilotez avec une équipe avant d’imposer. Les premières semaines font remonter chaque service que la frontière a oublié; élargir le plafond délibérément vaut mieux que des équipes qui le contournent.
Alertez sur les refus et les changements liés aux frontières. Les événements CloudTrail pour les tentatives de DeleteRolePermissionsBoundary et les CreateRole refusés montrent autant les attaques que la friction — vous voulez voir les deux.

Quand ce n’est pas la bonne approche

Si le vrai but est « les développeurs ne doivent pas toucher à la production », la séparation de comptes plus les SCP fait ça avec bien moins de machinerie — les frontières servent à déléguer l’écriture d’IAM dans un compte, pas à isoler des environnements en général. Passez aussi votre tour quand une équipe centrale possède sans douleur toute la création de rôles à votre échelle; le patron ne mérite sa complexité qu’une fois que la demande dépasse l’équipe de plateforme.

Erreurs fréquentes

Attendre de la frontière qu’elle accorde des accès — c’est seulement un plafond, et une politique d’identité vide veut toujours dire aucune permission.
Appliquer la frontière sur iam:CreateRole mais oublier iam:PutRolePermissionsBoundary et les actions de suppression, laissant une échappatoire d’échange de plafond.
Laisser l’équipe contrainte modifier la politique frontière elle-même.
Supposer que les frontières s’empilent avec les politiques de ressources — un accord direct à l’utilisateur dans une politique de compartiment contourne le plafond.

Garder le contrôle

Gardez la politique frontière dans l’infrastructure-en-code avec revue obligatoire de l’extérieur des équipes qu’elle contraint.
Diffez Role.PermissionsBoundary sur tous les rôles chaque semaine; chaque rôle de l’espace de noms délégué doit porter la frontière standard.
Versionnez les élargissements du plafond comme des changements d’API : proposés, revus, annoncés.
Jumelez les frontières aux SCP pour que le compte ait un plafond même pour les principaux que quelqu’un a oublié de border.

Les frontières font la différence entre « les équipes attendent l’équipe de plateforme » et « les équipes se servent elles-mêmes sous un plafond que personne ne peut monter d’en bas » — de l’IAM réellement avancé, qui vaut le coût exactement quand la douleur de délégation est réelle. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.