Une organisation possède 10 comptes AWS dans AWS Organizations. Chaque compte exécute AWS Config et appartient soit à l'OU Prod, soit à l'OU NonProd. Chaque compte dispose d'une règle EventBridge qui notifie un sujet SNS lorsqu'une règle entrante de groupe de sécurité EC2 est créée avec la source 0.0.0.0/0 ; l'équipe de sécurité s'abonne au sujet SNS. Pour tous les comptes de l'OU NonProd, l'équipe de sécurité doit supprimer la possibilité de créer des règles entrantes de groupe de sécurité qui autorisent 0.0.0.0/0. Quelle approche permet d'atteindre cet objectif 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 ec2:AuthorizeSecurityGroupIngress lorsque aws:SourceIp est égal à 0.0.0.0/0 et d'appliquer la SCP à l'OU NonProd. Les SCP sont le moyen le plus efficace et le moins coûteux de mettre en œuvre des contrôles de sécurité préventifs à l'échelle de plusieurs comptes AWS au sein d'une OU. Elles empêchent l'action avant qu'elle ne se produise, réduisant ainsi les frais opérationnels par rapport aux solutions réactives. Modifier la règle EventBridge pour appeler une fonction Lambda qui supprime la règle incriminée est une solution réactive et non préventive. Elle permet la création de la règle avant de la supprimer, ce qui est moins idéal et plus coûteux en termes de frais opérationnels. Attacher la règle AWS Config gérée vpc-sg-open-only-to-authorized-ports n'est pas la bonne règle pour ce cas d'utilisation, car elle se concentre sur les ports autorisés, pas sur la source 0.0.0.0/0. Créer une SCP qui autorise ec2:AuthorizeSecurityGroupIngress uniquement lorsque aws:SourceIp n'est pas 0.0.0.0/0 est une approche d'autorisation explicite, qui est plus complexe à gérer et peut involontairement bloquer d'autres configurations valides. La politique de refus explicite est plus simple et plus directe pour ce besoin spécifique.