6.1 - Gestion centralisée des comptes (Organizations, Control Tower, SCP)
L'objectif 6.1 de l'AWS Certified Security Specialty couvre l'exploitation de nombreux comptes comme un parc gouverné. Les Service Control Policies plafonnent ce que les comptes membres peuvent faire et n'accordent jamais rien, une politique d'identité doit donc encore autoriser l'action, un Deny explicite dans n'importe quelle politique du chemin du compte l'emporte, et l'héritage s'intersecte : si le root n'autorise que S3 et EC2 tandis qu'une OU enfant n'autorise que S3 et DynamoDB, les comptes en dessous ne gardent que S3. Une conception en allow-list ne fonctionne qu'une fois FullAWSAccess détaché, un Allow avec NotAction laisse discrètement tout le reste permis, les SCP ne restreignent pas les rôles liés aux services, un nouveau plafond s'applique dès qu'un compte change d'OU, et une SCP ne contraint jamais le compte de gestion, ce qui explique qu'une action refusée à l'échelle de l'org y ait quand même abouti. AWS Control Tower superpose des contrôles préventifs qui bloquent un appel et des contrôles détectifs qui signalent un écart, provisionne les comptes via Account Factory dans la bonne OU, et signale une dérive quand quelqu'un déplace un compte à la main. Tu actives l'accès de confiance et enregistres un administrateur délégué pour que les services de sécurité tournent hors du compte de gestion, un trail d'organisation ne peut pas être arrêté par un membre, et aws:PrincipalOrgID ou aws:PrincipalOrgPaths cadre les politiques de ressource sans lister d'ID de comptes. Attends-toi à des scénarios de gouvernance.
Une SCP l'a refusé pour toute l'org mais l'appel a réussi = il venait du compte de gestion, où les SCP ne s'appliquent pas. Allow-list de trois services = détacher d'abord FullAWSAccess, sinon rien n'est restreint. Faire confiance à tous les comptes présents et futurs de l'org = condition sur aws:PrincipalOrgID.
Questions d'entraînement
1. Une entreprise veut un environnement multi comptes preconfigure avec un compte d'archivage des journaux, un compte d'audit et un jeu de controles par defaut. Quel service fournit cela cle en main ?
- AWS Systems Manager, qui centralise les correctifs et l'inventaire sur toutes les instances enregistrees du parc
- AWS Control Tower (bonne réponse)
- Amazon Inspector
- AWS Resource Access Manager
Control Tower construit une zone d'atterrissage au dessus d'Organizations : il cree les comptes d'archivage et d'audit, applique des controles de base et enrole les nouveaux comptes via Account Factory. Systems Manager gere des instances, pas une structure de comptes. Inspector recherche des vulnerabilites dans les charges de travail. Resource Access Manager partage des ressources entre comptes et ne cree rien.
2. Une equipe securite attache au root de l'organisation une SCP qui refuse toute action hors de deux regions approuvees. Des ingenieurs lancent malgre tout des ressources dans une troisieme region. Quelle explication est techniquement correcte ?
- Les SCP mettent jusqu'a vingt quatre heures a se propager aux comptes membres, donc la politique n'est pas encore active et les lancements echoueront d'eux memes une fois la replication terminee
- Les SCP ne filtrent que le trafic de la console et ne s'appliquent jamais aux appels API ou CLI
- Une SCP attachee au root est indicative et doit etre dupliquee sur chaque unite d'organisation pour prendre effet
- Ils travaillent dans le compte de gestion, que les SCP ne restreignent jamais (bonne réponse)
Le compte de gestion n'est jamais affecte par les SCP, meme par une SCP attachee au root, ce qui est precisement la raison pour laquelle aucune charge sensible ne doit y resider. Les SCP prennent effet en quelques instants, elles s'appliquent a tous les chemins d'appel y compris API et CLI, et une politique attachee au root couvre deja toutes les UO en dessous par heritage.
3. Une equipe securite veut piloter GuardDuty et Security Hub pour toute l'organisation sans travailler depuis le compte de gestion. Quel montage est recommande ?
- Enregistrer un compte de securite dedie comme administrateur delegue de chaque service (bonne réponse)
- Donner a chaque ingenieur securite un role IAM dans le compte de gestion avec AdministratorAccess afin qu'ils pilotent les services depuis la directement
- Activer les services separement dans chaque compte membre et consulter les consoles une par une
- Partager les identifiants root de l'organisation avec les responsables securite
L'administration deleguee deplace la console operationnelle d'un service dans un compte membre pendant que le compte de gestion ne conserve que la gouvernance de l'organisation. Travailler depuis le compte de gestion concentre le rayon d'impact sur le compte qu'aucune SCP ne restreint, l'activation compte par compte fait perdre la vue agregee, et partager des identifiants root n'est jamais acceptable.
4. Une organisation doit appliquer des controles plus stricts aux comptes qui hebergent des charges reglementees qu'aux comptes bac a sable. Quelle est la structure la plus propre ?
- Une unite d'organisation unique contenant tout, avec des balises par ressource portant le niveau de conformite et un script nocturne qui les reconcilie
- Un compte AWS par charge de travail sans aucune unite d'organisation
- Des unites d'organisation separees, chacune avec ses propres SCP (bonne réponse)
- Une SCP par utilisateur IAM, attachee directement a l'utilisateur
Regrouper les comptes en UO selon leurs exigences de controle permet a une seule SCP de couvrir toute une classe de comptes et fait heriter le bon plafond aux nouveaux comptes des leur creation. Les balises ne sont pas une frontiere d'application, des comptes sans UO ne peuvent rien heriter, et les SCP s'attachent uniquement a un root, a une UO ou a un compte, jamais a un utilisateur ni a un role.
5. Une equipe veut une strategie de liste blanche ou les comptes d'une UO ne peuvent utiliser que trois services. Que faut il faire en plus d'attacher la SCP de liste blanche ?
- Activer l'indicateur de liste blanche dans la page de parametres d'Organizations pour toute l'organisation
- Attacher dans chaque compte une politique d'identite accordant les trois services, puisque la SCP ne les accordera pas
- Detacher la politique FullAWSAccess de cette UO et des comptes qu'elle contient (bonne réponse)
- Recreer les comptes, car un compte ne peut pas passer d'une liste noire a une liste blanche
Chaque UO et chaque compte porte FullAWSAccess par defaut ; les permissions SCP effectives sont l'intersection le long de l'arbre, donc tant que cette politique grande ouverte reste attachee, la liste blanche etroite est diluee a ce niveau. Il n'existe aucun interrupteur de liste blanche dans Organizations, et si des politiques d'identite restent effectivement necessaires, la question porte sur ce qui rend la liste blanche operante. Un compte n'a jamais besoin d'etre recree pour changer de strategie.
6. Avant qu'un service comme Config ou CloudTrail puisse agir sur tous les comptes d'une organisation, que faut il faire dans Organizations ?
- Rien, tout service atteint chaque compte membre des que l'organisation existe
- Activer l'acces de confiance pour ce service (bonne réponse)
- Creer un utilisateur IAM partage et replique dans chaque compte membre pour que le service puisse s'authentifier sur chacun d'eux
- Deplacer tous les comptes membres sous la meme unite d'organisation
L'acces de confiance autorise un service a creer dans les comptes membres les roles lies au service dont il a besoin et a operer a l'echelle de l'organisation. L'acces n'est jamais implicite, repliquer des utilisateurs IAM est l'inverse de la conception voulue et cree des identifiants durables, et le placement en UO change l'heritage des politiques mais n'accorde a aucun service une portee organisationnelle.