AWS a discrètement introduit cet été une nouvelle fonctionnalité IAM, les Permissions Boundaries. L'annonce a fait peu de bruit, probablement en raison des mécanismes pointus mis en œuvre. Pourtant, c'est un ajout critique, qui va démultiplier l'efficacité de gestion des clouds d'entreprise dans certains cas.

Nous vous proposons dans cet article d'expliquer la raison d'être des Boundaries, leur cas d'usage et fonctionnement. Il sera suivi d'ici quelques jours d'un second article plus pratique, qui vous permettra de jouer avec les Boundaries pour bien en saisir les mécanismes.

Bonne lecture !

De l'importance de fixer des limites

Un des crédos récurrents de DevOps est "you build it, you run it" : laisser chaque équipe produit gérer sa propre production en autonomie. À l'échelle du cloud d'entreprise (qu'il soit privé ou public), cela amène souvent à définir au moins deux niveaux d'administrateurs : un niveau d'admins centraux, responsables de la plateforme en elle-même et de ses services transverses, et un niveau d'admins métier, chacun maître d'une "zone" isolée, fournie par les admins centraux, et sur laquelle il exploite les applications de son équipe.

Ce pattern est facilement implémentable dans AWS à l'aide du service transverse IAM. A travers les policies IAM, un admin central peut modéliser finement les droits nécessaires à un admin métier, et les lui fournir.

[caption id="attachment_77009" align="aligncenter" width="786"]

Figure 1 - à l'échelle, plusieurs niveaux d'administrateurs

[/caption]

IAM permet également de gérer le deuxième étage de la fusée, à savoir l'assignation de droits à des ressources AWS elles-mêmes. C'est à travers des rôles IAM que l'on va fournir le droit à des ressources AWS de manipuler d'autres services. L'administrateur métier va typiquement vouloir créer un rôle par ressource (VM EC2, fonction Lambda, …), qui donne à celle-ci les stricts droits AWS nécessaires à son fonctionnement.

De prime abord, c'est une amélioration de sécurité. Malheureusement, cela casse complètement notre modèle de délégation ! Un utilisateur qui a le droit de créer des rôles peut en effet y mettre n'importe quels droits, y compris ceux dont il ne dispose pas lui-même. Il lui est alors trivial de devenir administrateur :

[caption id="attachment_77014" align="aligncenter" width="622"]

Figure 2 - un admin limité peut usurper des droits en créant un rôle

[/caption]

Une classique faille d'escalade de privilèges donc, exploitable sans grand effort par un attaquant. Jusqu'à peu, la règle d'or de l'IAM était donc très contraignante : "seul un administrateur central peut créer rôles et policies". Cette contrainte obligeait à choisir entre deux approches limitées :

• Impliquer constamment l'administrateur central pour créer des rôles métier, une solution coûteuse et à l'antithèse de l'autonomie chère au "you build it, you run it".
• Prédéfinir des rôles aux droits larges, à l'antithèse des bonnes pratiques de ségrégation.

Ce statu quo dure depuis les débuts de l'IAM AWS, limitant fortement la flexibilité des déploiements à large échelle… Jusqu'à l'arrivée des Permissions Boundaries. Annoncée via un post de blog peu didactique, cette fonctionnalité IAM répond exactement à cette problématique : permettre à un utilisateur de créer lui-même des rôles IAM, sans excéder les droits qui lui ont été fournis. Une vraie révolution dans le modèle AWS !

Une Boundary pour dans l'IAM les limiter

Concrètement la Permissions Boundary apparaît à deux endroits stratégiques dans l'IAM AWS.

Premièrement, c'est une une nouvelle propriété optionnelle de chaque utilisateur/rôle, et qu'on peut faire pointer vers une Policy AWS.  Celle-ci va alors agir comme un filtre obligatoire sur les droits du rôle : seuls les droits listés par le rôle et par la Boundary seront réellement actifs.

[caption id="attachment_77017" align="aligncenter" width="881"]

Figure 3 - un rôle avec Permissions Boundary

[/caption]

Dans la Figure 3, la Permissions Boundary n'inclut pas de droits S3 : bien que le rôle les ait demandés, il ne les aura pas. Inversement, la Boundary permettait toutes les actions sur DynamoDB et EC2, mais le rôle ne les a pas demandés : il ne les aura pas non plus ! La Boundary ne fait au mieux que supprimer des droits du rôle, sans en ajouter.

Deuxièmement, elle apparaît comme une nouvelle condition dans les policies IAM AWS. On peut spécifier cette condition à la plupart des actions manipulant des rôles, et obliger un utilisateur à spécifier une Boundary lorsqu'il crée et manipule ses rôles.

[caption id="attachment_77020" align="aligncenter" width="935"]

Figure 4 - contraindre un utilisateur à utiliser une Boundary

[/caption]

Dans la figure 4, l'administrateur central a autorisé limited_user à créer et supprimer des rôles, mais uniquement sous condition que la Boundary soit associée au rôle. L'API AWS bloquera les appels qui ne respectent pas cette condition.

Ces deux ajouts suffisent à rendre les Permissions Boundaries efficaces pour déléguer la création de rôle. Elles doivent bien sûr s'insérer dans une stratégie de sécurité AWS plus large, mais le mécanisme est somme toute assez simple.

Organisations ou Boundaries ?

AWS propose déjà depuis quelques temps le service Organizations, qui permet de découper le cloud d'entreprise en plusieurs comptes AWS et de les gérer de manière centralisée. Pourquoi rajouter des limites à base de Boundaries ?

En pratique, organisations et Boundaries ne servent pas le même usage, et gagnent même à être utilisées ensemble. Si les organisations sont très utiles pour découper le cloud selon l'organisation de l'entreprise, elles ne gèrent pas les droits à l'intérieur de chaque compte, qui restent du domaine du service IAM. Imaginons par exemple que l'entreprise veuille remonter les traces d'audit CloudTrail des comptes délégués dans un puits de logs centraux : configurer l'envoi de ces logs se fera toujours dans chaque compte. Les Permissions Boundaries permettront de protéger cette configuration des administrateurs délégués.^<a id="ref1" href="#note1">1</a>^

L'utilisation d'organisations et de Boundaries, ensemble ou séparément, dépendra donc de la structure de l'entreprise, de sa culture et des modèles de risques envisagés.

Conclusion

C'est une bien belle feature que nous offre là AWS pour enrichir nos plateformes. Si on peut faire usages de VMs sans leur assigner de rôles dans de nombreux cas, ce n'est pas le cas pour les fonctions Lambda ou les clusters Elastic MapReduce, qui ont quasiment toujours besoin de manipuler d'autres services AWS. Les limites de l'IAM AWS obligeaient jusqu'à présent à trancher entre autonomie des équipes métier et sécurité : les Permissions Boundaries devraient permettre de résoudre ce dilemme dans de nombreux cas.

Alors, faut-il partir à fond sur les Permissions Boundaries ? Pas si vite. Dans de nombreux cas, les Organizations AWS suffiront si on peut fournir un compte AWS en autonomie complète à chaque équipe. Le besoin de Boundaries ne devrait se faire sentir que si l'entreprise souhaite définir des limites à ce qu'un administrateur délégué peut faire dans son compte, ou en cas de cohabitation dans le même compte.

Les Permissions Boundaries ajoutent également un niveau de complexité à l'IAM AWS. L'autonomie laissée aux utilisateurs qui peuvent créer des rôles à base de Boundaries est puissante, mais va mener à une multiplication des rôles dans le compte AWS, rendant les inventaires et audits plus difficiles. Par ailleurs, le modèle IAM autour des Boundaries est complexe, et une erreur dans la définition de droits peut permettre à un utilisateur délégué de sortir de sa "bulle". Leur implémentation doit donc s'inscrire dans une politique de sécurité globale, après une analyse de sécurité spécifique et en incluant bonnes pratiques d'administration et défense en profondeur : politiques de nommage, utilisation des services d'audit AWS (CloudTrail, Config, Trusted Advisor, …)

Que cela ne vous rebute pas pour autant : pour les cas d'usage cités plus haut, les Permissions Boundaries représentent bien un gain net, à la fois en sécurité et en efficacité.

Notes

^<a id="note1" href="#ref1">1</a>^: Organizations propose bien les SCP pour désactiver des services AWS, mais en mode "tout ou rien" : si on désactive les actions CloudTrail par SCP, même le propriétaire du compte ne pourra plus configurer CloudTrail.