Pourquoi vous utilisez mal l'IAM d'AWS

Je travaille sur des environnements AWS depuis plus de 6 ans maintenant. Que ce soit en tant qu'Ops, architecte, ou architecte sécurité, il y toujours une constante que je constate autour de moi : l'IAM d'AWS est très souvent mal utilisé.

Dans ce billet, je vous propose de faire un petit tour d'horizon des raisons probables.

Parce que la doc vous indique de mettre du wildcard

La documentation est censée être le pilier sur lequel s'appuyer. Toutefois, force est d'admettre que la documentation d'AWS est loin d'être un exemple en ce qui concerne l'IAM.

Bien que la firme prône le least privilege, beaucoup de ses documentations en sont très loin.

De mon point de vue, la documentation est censé montrer des exemples les plus sécurisés possible pour "pousser" les utilisateurs à adopter les bons réflexes. Force est d'admettre que ce n'est pas le cas.

Parce que les APIs sont inconsistantes

Principal souci du modèle d'AWS, qui fait que chaque équipe produit est autonome : L'inconsistance des API.

Les même actions ne correspondent pas forcément au même verbes API...

Ainsi la simple action de créer un tag peut avoir plusieurs nom différents en fonction des services, comme par exemple :

• elasticloadbalancing:addTags
• ec2:createTags
• ecr:tagResource

Mais comme ce serait trop simple, toutes les API n'ont pas forcément les mêmes type de cible.

Ainsi si je veux cibler des ressources en fonction de leurs tags, j'ai encore une fois des filtres différents :

• aws:ResourceTag/${TagKey}
• aws:TagKeys
• elasticmapreduce:ResourceTag/${TagKey}

Parce que le filtrage est inégal

Lorsqu'on met en place un modèle zero trust basé sur le least privilege, on va vouloir cloisonner au mieux les droits que l'on donne pour éviter toute action non désirée.

Maintenant on arrive au vrai problème.

En fonction des ressources, on pourra (ou non) filtrer correctement, mais pas forcément au même niveau.

Certaines ressources ont des ARN prévisibles, dans ce cas il est simple filtrer en amont (avant même que la moindre ressource soit créé).

D'autres fonctionne sur des identifiants internes créés par AWS, comme les security group par exemple.

Dans ce cas, il est parfois possible de filtrer sur la présence de certains tags, mais une fois de plus, pas tout le temps!

En effet, tous les services n'appliquent pas les tags de la même manière. Certains vont l'appliquer dès la création, d'autres après. Parfois tout se fait en un seul appel API, parfois en plusieurs...

Parce qu'il y a de multiples type de policies

J'aime à dire que l'IAM d'AWS est sans doute l'un des plus complet à ce jour. Toutefois, sa complétude vient aussi avec une complexité certaine : Le nombre de policies et les différentes couches qui s'appliquent à chaque évaluation.

• Commençons par le plus simple : les policy IAM "classiques", que l'on appelle aussi "Identity based policies", ce sont les politiques que tout le monde exploite directement lorsque vous vous connectez à AWS. Ce sont aussi ces dernières qui sont utilisées quand vous utilisez des roles AWS.
• Ensuite, il y a les "resource based policies", qui au contraire des précédentes sont directement attachées à un service, comme S3, SQS ou IAM (pour les trusts)
• Puis viennent les boundaries, ces policies sont attachées à des roles ou utilisateurs pour filtrer les droits, un peu comme un tamis.
• On pourrait aussi parler des SCP, qui englobent tout un compte ou une OU du service AWS Organization, pour appliquer des boundaries globales.
• il y a enfin des policies qui peuvent être crée à la connexion avec un utilisateur fédéré : les session policies

Cinq type des policies qui peuvent toutes être utlisées en même temps lorsque vous accédez à un service, cinq!

Je ne peux que comprendre ceux qui se perdent dans ces multiples niveaux d'abstraction.

Parce qu'il y a beaucoup de limitations

Comme tous les services d'AWS, l'IAM a ses propres limitations.

Par exemple, un role IAM ne peut pas avoir plus de 10 managed policies d'attachées, et chacune de ces policies ne peut pas dépasser 6144 bytes (sans les espaces/sauts de ligne).

Un role ou un utilisateur ne peut pas avoir plus d'une boundary attachées.

Ces limitations empêchent de pouvoir composer des roles ou utilisateurs de manière optimale car si l'on veut restreindre au maximum, on est obligé de recréer des policy pour chaque ressource!

De plus quand on veut pouvoir donner des accès console + CLI, on est parfois obligé de donner plus de droit que souhaité car sinon on empêche la console de fonctionner correctement.

Parce que même le support y perd son latin

Mon dernier point et non des moindre : le support lui même s'y perd!

j'ai déjà eu à contacter le support à de multiples reprises pour des soucis d'IAM, et force est d'admettre que très souvent le support tatône pour trouver une policy fonctionnelle ou comprendre d'où peuvent venir les blocages.

Entre l'inconsistance des API, des ressources, des filtres et la complexité de certaines policies lorsqu'on veut filtrer efficacement, c'est parfois compliqué de suivre le fil.

Comment améliorer les choses ?

Malgré tout les points que j'ai cité, il est toujours possible de faire "proprement" des policies (du moins du mieux possible), toutefois, ca demande du temps et de l'outillage.

Pour ma part, voici ce que j'utilise très (très) souvent :

• La documentation officielle de toutes les API, avec leurs filtres : Cette documentation est relativement bien tenue à jour et vous permet d'avoir déjà une bonne vision d'ensemble
• Le simulateur de policy d'AWS : qui vous permet de tester une policy sur une action particulière, très utile quand on veut filtrer sur des ARN ou tags par exemple.
• Des linter de policy, que ce soit celui intégré dans AWS Access Analyzer ou des outils tiers comme Parliament par exemple

Il faut garder en tête que l'IAM d'AWS reste complexe de part sa puissance. Pour ma part, même après des années à en faire quotidiennement, je suis très loin d'en maîtriser 100% de ses aspects...