Une organisation utilise AWS Organizations pour gérer plusieurs comptes AWS. Un architecte de solutions doit appliquer une politique selon laquelle seuls les rôles d'administrateur peuvent effectuer des actions IAM dans toute l'organisation. L'architecte n'a pas accès à tous les comptes AWS. Quelle approche applique cela avec le moins de frais opérationnels ?

La bonne réponse est de créer une politique de contrôle de service (SCP) qui refuse les actions IAM pour tous les principaux, à l'exception des rôles d'administrateur, et de l'attacher à l'unité d'organisation (OU) racine. Les SCP sont appliquées de manière centralisée via AWS Organizations et s'appliquent à tous les comptes membres, même si l'architecte n'a pas un accès direct à chaque compte. Cela garantit une application cohérente avec un minimum d'efforts opérationnels. L'option de créer un SCP qui autorise les actions IAM uniquement pour les rôles d'administrateur ne serait pas efficace car les SCP ne sont pas des politiques d'autorisation ; elles définissent les autorisations maximales. Une SCP de refus est nécessaire pour restreindre les actions. L'utilisation de CloudTrail et Lambda est réactive et complexe, entraînant des frais opérationnels élevés et ne prévenant pas l'action initiale. Les limites d'autorisations (permissions boundaries) sont définies rôle par rôle et nécessiteraient un accès à chaque compte pour être appliquées, ce qui est contraire à la contrainte de l'architecte.