Si une SCP AWS autorise une action, les utilisateurs du compte peuvent-ils l'effectuer ?

Beaucoup de candidats entendent « politique qui autorise » et pensent à un allow IAM. Dans AWS Organizations, ce n'est pas le cas, et se tromper mène à une fausse confiance ou à des blocages.

Un plafond, pas une autorisation

La documentation AWS est explicite : les SCP « n'accordent pas de permissions » et définissent « un garde-fou » qui limite les actions des utilisateurs et rôles IAM de l'organisation. Pour agir, un principal a besoin d'une politique basée sur l'identité ou la ressource qui l'accorde, et chaque SCP au-dessus du compte doit l'autoriser. Un utilisateur sans politique IAM n'a aucun accès, même si les SCP autorisent tout.

Ce que les SCP ne couvrent pas

Les SCP n'affectent que les comptes membres. Elles n'ont aucun effet sur les utilisateurs ou rôles du compte de gestion, ni sur les rôles liés à un service. Elles ne s'appliquent pas non plus aux principaux de comptes extérieurs à l'organisation. C'est pourquoi le compte de gestion doit contenir le strict minimum.

Piège opérationnel

AWS recommande de tester avant d'attacher une SCP à la racine, en passant par une UO et en y déplaçant les comptes progressivement. Retirer la politique FullAWSAccess par défaut sans la remplacer fait échouer toutes les actions des comptes membres.

Pourquoi les distracteurs sont tentants

« Les SCP accordent l'accès » les confond avec les allow IAM. « Seulement root » et « seulement le compte de gestion » inversent la portée réelle.

Ce que veulent les recruteurs

« Un plafond, pas une autorisation — les permissions effectives sont l'intersection », plus les exceptions du compte de gestion et des rôles liés à un service.