Les permission boundaries AWS pour les nuls

Les permission boundaries d'AWS sont déroutantes. Je sais qu'elles sont déroutantes parce qu'elles m'ont dérouté, et il m'a fallu quelques années pour les comprendre. Je sais aussi qu'elles sont déroutantes parce que Corey Quinn l'a dit, et a demandé que quelqu'un les rende moins déroutantes.

Je vais probablement échouer, mais allons-y.

En résumé : les politiques IAM classiques vous autorisent à faire des choses, mais peuvent aussi vous empêcher d'en faire. Les permission boundaries se contentent de vous empêcher de faire des choses. Vous les utilisez surtout pour laisser quelqu'un administrer une partie de l'IAM, mais pas au point de pouvoir élever ses privilèges (pour lui-même ou pour quelqu'un d'autre). Elles constituent un garde-fou. Si vous laissez quelqu'un gérer l'IAM dans un compte et que vous ne voulez pas qu'il puisse élever ses privilèges, vous avez presque toujours besoin d'une permission boundary !

La documentation officielle d'AWS est très détaillée, mais reste plutôt déroutante. Cet article vise à vous aider à comprendre les concepts et la raison de leur existence, et non à maîtriser les subtilités de leur rédaction (à une exception près).

Imaginez que je suis un élève de CM2, pas un débutant, et expliquez-les-moi encore

Eh bien, si vous insistez.

Avant les IAM Permission Boundaries, il était VRAIMENT DIFFICILE de laisser quelqu'un gérer les autorisations IAM sur ses propres ressources sans créer un problème de sécurité en attribuant trop d'autorisations à quelque chose comme une instance EC2 ou… à lui-même. Le problème se posait surtout lorsque vous vouliez le laisser rédiger des politiques IAM puis les attribuer. C'est le problème de l'administration déléguée. « Laisser quelqu'un administrer certaines choses liées à l'IAM, mais pas celles-là ».

Ce scénario est très courant. Les développeurs créent souvent un rôle pour une instance, une fonction lambda ou une tâche de conteneur dans leur pile applicative, puis attribuent des autorisations à ce rôle. Cela peut être aussi simple que de permettre à une instance de lire des données dans un bucket S3. Il s'avère que c'est difficile à gérer d'un point de vue sécurité :

• Si vous laissez le développeur rédiger ses propres politiques, il pourrait ajouter des privilèges excessifs… comme *.*.
• Si vous laissez le développeur attribuer des politiques, il pourrait rattacher une politique existante comportant trop d'autorisations.
• Si vous autorisez le développeur à créer un nouveau rôle ET à attribuer une politique… vous rencontrez les mêmes problèmes.

Oui, vous pourriez confier tout cela à la sécurité ou à un administrateur de haut niveau, mais ce serait inefficace. Les permission boundaries vous permettent d'avoir deux niveaux d'administrateurs IAM : ceux de haut niveau, responsables de la sécurité globale, et ceux de niveau inférieur, qui gèrent le quotidien.

Une permission boundary n'est qu'une politique IAM qui énumère les privilèges maximaux qu'une personne ou une ressource peut détenir. Vous rattachez cette politique et les développeurs qui gèrent la ressource ne pourront jamais lui accorder plus d'autorisations que ce que permet la boundary. Vous pouvez même autoriser le développeur à créer de nouveaux rôles et utilisateurs et à leur attribuer des autorisations, à condition d'exiger que tout ce qu'il crée porte cette permission boundary. Ainsi, il ne pourra jamais créer ou modifier quoi que ce soit en lui accordant plus d'autorisations que vous ne le souhaitez.

Je ne suis pas sûr que ce soit à la portée d'un élève de CM2, mais pourriez-vous me donner un exemple

Alice est la super-administratrice d'une organisation AWS. Elle doit superviser des centaines de comptes, et chaque compte a ses propres administrateurs locaux et développeurs qui réalisent la construction effective des applications.

Bob est l'un de ces développeurs locaux. Bob construit une nouvelle application et il est plus efficace qu'il crée lui-même ses rôles et ses politiques, puisqu'il sait ce dont son application a besoin.

Alice décide de laisser Bob gérer l'IAM pour certaines parties de son application. Plus précisément :

• Bob peut rédiger et attribuer de nouvelles politiques IAM avec les autorisations dont ses instances et ses fonctions lambda ont besoin.
• D'autres services AWS sont utilisés et ces composants ne doivent jamais y toucher. Vous ne pouvez donc pas simplement les désactiver avec une Service Control Policy. Cela casserait ces services pour les composants autorisés à les utiliser.
• Bob n'est pas autorisé à s'attribuer une nouvelle politique à lui-même.

C'est un cas classique d'administration déléguée : Bob est autorisé à administrer seulement une partie de l'IAM. C'est là que vous utiliseriez une permission boundary :

• Alice crée une permission boundary « A » qui autorise les accès aux services AWS avec lesquels les instances et les fonctions lambda de Bob peuvent communiquer (p. ex. S3, SNS, SQS).
• Alice crée une permission boundary « B » qui autorise Bob à créer des rôles et des politiques IAM (et à les attribuer) mais PAS à se les attribuer à lui-même.
• Alice donne à Bob les autorisations IAM pour créer et attribuer de nouveaux rôles et politiques, mais tout nouveau rôle doit porter la permission boundary « A ». Cela signifie que ces instances et fonctions lambda n'auront JAMAIS plus d'autorisations que celles définies dans la boundary, mais elles peuvent en avoir moins.
• Alice attribue la permission boundary « B » à Bob pour l'empêcher de s'attribuer des autorisations à lui-même. Il ne peut désormais plus supprimer l'obligation de déployer les ressources avec « A ».

Oui, il existe plusieurs façons d'aborder ce problème… mais en bref, dès que vous voulez laisser quelqu'un administrer une partie de l'IAM dans un compte, vous avez probablement besoin d'une permission boundary si vous ne voulez pas qu'il en fasse trop.

Rappelez-moi pourquoi une Service Control Policy ne convient pas ici

Parfois une SCP peut convenir, mais vous ne pouvez utiliser une SCP que si vous êtes dans une Organization, alors qu'une permission boundary fonctionne dans n'importe quel compte. De plus, les SCP sont très efficaces pour limiter les appels d'API possibles (et donc les services AWS utilisables), mais elles ne sont pas vraiment conçues pour ce niveau de granularité et de conditions.

Pensez à mon exemple ci-dessus : Alice devrait peut-être connaître les identifiants de ressources pour autoriser l'accès aux services du compte, mais pas depuis les ressources créées par Bob. Il existe des moyens de gérer cela (p. ex. les chemins de ressources), mais ce n'est pas plus simple que notre exemple de permission boundary et cela ne fonctionne pas toujours selon les clés de condition prises en charge.

Dans mon Incident Response Training Range, j'utilise une SCP pour empêcher les utilisateurs administrateurs (les participants) des comptes de casser mon accès au niveau Organizations, entre autres. Mais cela ne fonctionne que parce que je leur accorde l'IAM complet et qu'ils sont déjà l'un de ces super-administrateurs. Si je voulais limiter leur capacité à créer des ressources dotées d'autorisations excessives, il me faudrait une permission boundary ou une SCP pour les restreindre à l'attribution de certaines politiques préétablies.

Ne puis-je pas simplement utiliser des politiques Deny

Pas vraiment. Nous avons essayé avant l'existence des permission boundaries et, outre la complexité, il y avait tout simplement trop de failles.

Puis-je avoir un autre exemple simple

Bien sûr ! En voici un que nous utilisons nous-mêmes.

Certains utilisateurs nous laissent apporter des modifications IAM dans leurs comptes. Nous utilisons pour cela un rôle inter-comptes. Lorsque les utilisateurs déploient le rôle, ils appliquent une permission boundary qui ne nous permet jamais de modifier nos propres autorisations. Cela empêche l'élévation de privilèges.

Je crois comprendre, mais comment toutes ces politiques IAM interagissent-elles

Consultez la documentation AWS sur la logique d'évaluation des politiques, mais voici mes notes essentielles :

• Les Service Control Policies limitent ce que chacun est autorisé à faire dans un compte (p. ex. elles peuvent activer et désactiver des services).
• Les politiques d'autorisation IAM permettent aux utilisateurs et aux rôles de faire des choses dans un compte.
• Les politiques de ressources IAM permettent aux utilisateurs et aux rôles d'interagir avec la ressource à laquelle la politique est rattachée.
• Les permission boundaries définissent les privilèges maximaux qu'un utilisateur ou un rôle peut détenir. Elles ne vous autorisent pas à faire des choses, mais elles peuvent vous empêcher d'en faire.

Toutes les politiques fonctionnent ensemble. Pour faire quelque chose, vous devez disposer d'une autorisation quelque part dans la pile et n'avoir aucune politique de refus qui vous en empêche. Un seul Deny l'emporte sur n'importe quel Allow, où qu'il se trouve.

Rappelez-moi quand utiliser les permission boundaries

Lorsque vous voulez autoriser quelqu'un à administrer une partie de l'IAM dans un compte tout en limitant sa portée, vous devriez penser à une permission boundary.

Même lorsque vous utilisez des outils IAM avancés comme notre nouveau FireMon Authorization Control, vous pourriez encore souhaiter recourir à des permission boundaries, en particulier dans les comptes hautement sensibles.

Quel est cet exemple que vous aviez annoncé ?

Bien que les permission boundaries soient conçues pour vous empêcher de faire certaines choses, elles exigent tout de même que vous précisiez l’ensemble des autorisations allow. Autrement dit, si vous rédigez une permission boundary avec une instruction DENY pour bloquer la seule action que vous ne voulez pas autoriser pour cet utilisateur ou ce rôle, il vous faudra malgré tout une instruction ALLOW *, faute de quoi il ne pourra rien faire.

C’est ce point qui m’a d’abord dérouté, car j’avais mal lu la description d’Amazon et je pensais qu’une permission boundary suffisait à bloquer des actions. C’est possible, mais, hormis un cas d’usage de politique de ressource que je ne souhaite pas aborder aujourd’hui, la permission boundary doit également inclure tout ce que vous voulez autoriser. Vous ne pouvez pas vous contenter de refuser (DENY) une action dans la permission boundary et d’en autoriser (ALLOW) d’autres dans la politique d’autorisations IAM classique : cela ne fonctionnera pas. La permission boundary doit elle aussi comporter les instructions ALLOW (et oui, je triche et j’utiliserai parfois ALLOW * ici).

Je ne comprends toujours pas

Envoyez-moi un e-mail. Sérieusement, ces mécanismes sont vraiment déroutants.