Comment mettez-vous concrètement en oeuvre le moindre privilège dans IAM ?

Partez d'une position de refus par défaut et accordez les permissions à partir de l'usage observé plutôt que de suppositions. Générez une première politique depuis les journaux d'accès, restreignez-la avec des ARN de ressources et des clés de condition au lieu de jokers, et donnez à chaque charge de travail son propre rôle. Ajoutez des garde-fous au niveau de l'organisation, comme les service control policies et les permission boundaries, pour que personne ne puisse s'accorder davantage, puis passez en revue les permissions inutilisées de façon régulière et élaguez.

Le piège, c'est de vouloir écrire la politique parfaite dès le départ, ce qui soit bloque l'équipe, soit finit en joker parce que tout le monde en a eu marre. Ce qui marche, c'est de partir large sur un compte hors production, de capturer ce que la charge de travail appelle vraiment depuis la piste d'audit, et de générer une politique à partir de ça. Ensuite je resserre : de vrais ARN de ressources plutôt qu'une étoile, et des clés de condition là où ça compte, pour qu'un rôle ne puisse assumer que des choses depuis nos propres comptes ou n'agir que dans une seule région. Chaque charge de travail a son propre rôle plutôt qu'un gros rôle applicatif partagé, parce que les rôles partagés sont la façon dont un service finit capable de supprimer les données d'un autre. Au-dessus, il y a les garde-fous de l'organisation : des service control policies qui refusent des catégories entières, comme désactiver la journalisation ou créer des buckets publics, plus des permission boundaries pour qu'une équipe puisse créer des rôles sans dépasser sa limite. Puis la revue : rapports d'accès inutilisés tous les mois, et tout ce qui n'a pas bougé depuis quatre-vingt-dix jours est retiré. Les permissions ne font que croître, sauf si quelqu'un prend l'habitude d'élaguer.