Déléguer la création de rôles en toute sécurité

Les équipes avancent plus vite lorsqu’elles peuvent créer leurs propres rôles et politiques IAM, mais un accès IAM sans restriction est dangereux : un développeur pourrait s’accorder des droits d’administrateur. Le défi consiste à laisser les équipes créer des rôles tout en garantissant que ceux-ci restent dans des limites sûres. Les limites d’autorisations rendent cela possible ; c’est un scénario fréquemment évalué à l’examen.

Sans garde-fous, accorder à quelqu’un iam:CreateRole et iam:AttachRolePolicy revient en pratique à lui donner les droits d’administrateur. Cette personne pourrait créer un rôle avec AdministratorAccess et l’assumer. Cette voie d’élévation de privilèges est précisément celle que la délégation sécurisée doit fermer tout en autorisant la création légitime de rôles.

La solution consiste à exiger que tout rôle créé par un utilisateur délégué comporte une limite d’autorisations précise. Même s’il associe AdministratorAccess au nouveau rôle, la limite plafonne ses autorisations effectives. Le rôle créé ne pourra jamais dépasser ce que la limite autorise, ce qui neutralise le risque d’élévation.

Une politique de délégation sécurisée utilise deux vérifications de condition : l’une garantit que le nouveau rôle possède la limite requise (via iam:PermissionsBoundary), et l’autre empêche l’utilisateur de modifier ou supprimer la limite elle-même. Les deux sont nécessaires, sinon un développeur ingénieux pourrait simplement supprimer la limite ensuite.

Cette condition force chaque appel à CreateRole à associer la limite nommée. Sans elle, l’action de création est refusée.

Vous devez également empêcher l’utilisateur délégué de modifier la politique de limite ou de la détacher des rôles. Ajoutez des instructions Deny explicites pour des actions telles que iam:DeleteRolePermissionsBoundary et iam:CreatePolicyVersion visant l’ARN de la limite. Sinon, le garde-fou pourrait être supprimé discrètement, ce qui anéantirait toute la conception.

Les politiques de délégation restreignent souvent le chemin ou le nom des rôles qu’un utilisateur peut créer, par exemple uniquement sous /developers/. Cela cantonne ses rôles à un espace de noms connu, ce qui facilite leur audit et empêche toute interférence avec des rôles privilégiés ailleurs dans le compte.

Même avec une limite, surveillez la politique de confiance du nouveau rôle. Un développeur pourrait créer un rôle approuvé par un compte externe. Restreignez les principaux qu’il peut définir comme étant approuvés, ou associez la délégation à des SCP et à Access Analyzer afin que toute relation de confiance externe inattendue soit détectée et bloquée.

Lorsqu’elle est correctement mise en œuvre, la délégation offre aux équipes un véritable libre-service : elles créent et gèrent librement les rôles dans les limites autorisées, tandis que l’équipe de sécurité peut rester sereine, sachant qu’aucun rôle ne pourra dépasser le plafond. Cet équilibre entre rapidité et sécurité correspond exactement à ce que l’examen SCS-C02 vous demande de concevoir.

Dans les environnements comportant plusieurs comptes, associez des limites par identité à des SCP à l’échelle des comptes. La SCP définit un plafond pour l’ensemble du compte, tandis que les limites affinent les restrictions pour chaque utilisateur délégué. La superposition des deux assure une défense en profondeur : une faille dans un contrôle est rattrapée par l’autre.

La délégation sécurisée de la création de rôles exige de définir une limite d’autorisations sur chaque rôle créé, de protéger la limite contre toute modification ou suppression au moyen de refus explicites, de limiter les chemins et les noms, et de restreindre la confiance des nouveaux rôles. Ajoutez des SCP pour définir des plafonds à l’échelle des comptes. Cela ferme les voies d’élévation de privilèges tout en préservant le libre-service des équipes.

Testez la délégation sécurisée.

Déléguer en toute sécurité la création de rôles IAM signifie exiger une limite d’autorisations sur chaque rôle créé via la condition iam:PermissionsBoundary, interdire toute modification de cette limite, limiter les chemins et les noms des rôles, et restreindre les politiques de confiance des nouveaux rôles. Associez-y des SCP pour définir des plafonds à l’échelle des comptes, afin de fermer les voies d’élévation de privilèges tout en permettant le libre-service.