Une entreprise utilise AWS Organizations et prévoit d'ajouter environ 1 000 comptes supplémentaires. Actuellement, seule l'équipe de sécurité centrale peut créer des rôles IAM. Pour réduire les goulots d'étranglement, les équipes d'application doivent pouvoir provisionner leurs propres rôles IAM, mais ces rôles doivent être limités en portée et ne doivent pas permettre l'escalade de privilèges. Quelle est la solution présentant le moins de frais opérationnels ?

La création d'une SCP et d'une limite d'autorisations IAM (permissions boundary) est la solution la moins coûteuse en termes d'opérations. La SCP, attachée à l'OU racine, peut spécifier que seuls les rôles avec une limite d'autorisations spécifique peuvent créer de nouveaux rôles IAM. La limite d'autorisations définit les autorisations maximales qu'un rôle peut avoir, empêchant ainsi l'escalade de privilèges. Cette approche centralise le contrôle tout en déléguant la création de rôles aux équipes d'application, réduisant les goulots d'étranglement. Les autres options sont moins efficaces : Créer un groupe IAM pour chaque équipe avec des politiques attachées et des utilisateurs IAM est une approche de gestion des identités, mais ne délègue pas la création de rôles IAM de manière contrôlée. Déléguer la création de rôles aux chefs d'équipe avec des examens trimestriels augmente la charge opérationnelle et dépend de la formation et de la diligence des chefs d'équipe. Placer chaque compte dans sa propre OU et attacher une SCP pour n'autoriser que les services requis ne résout pas directement le problème de la création de rôles IAM avec des limites de permissions.