Une entreprise a créé un VPC pour une nouvelle application dans un nouveau compte AWS. Le VPC est appairé à un VPC existant dans un autre compte de la même région pour l'accès à la base de données. Des instances Amazon EC2 seront fréquemment créées et terminées dans le VPC de l'application, mais seules certaines doivent se connecter aux bases de données du VPC appairé sur le port TCP 1521. Un ingénieur en sécurité doit s'assurer que seules les instances requises peuvent atteindre les bases de données. Que doit faire l'ingénieur ?

L'option correcte permet un contrôle granulaire en utilisant la référence de groupe de sécurité. En créant un groupe de sécurité dans le VPC de l'application (sans règles entrantes, car il s'agit du client) et en le référençant dans la règle entrante du groupe de sécurité de la base de données, seules les instances associées à ce groupe de sécurité client peuvent initier des connexions sur le port 1521. Cela est crucial car les instances EC2 sont fréquemment créées et terminées, et cette méthode s'adapte dynamiquement sans nécessiter de mises à jour manuelles des plages CIDR. Les options incorrectes sont les suivantes : La première option utilise une NACL et un groupe de sécurité avec un CIDR. Les NACL sont sans état et opèrent au niveau du sous-réseau, ce qui est trop large pour un contrôle au niveau de l'instance. L'utilisation d'un CIDR rend la gestion difficile avec des instances dynamiques. La deuxième option utilise des CIDR des VPC, ce qui est trop permissif car toutes les instances du VPC de l'application pourraient se connecter, et non seulement celles requises. La quatrième option utilise un groupe de sécurité dans le VPC de l'application avec une règle entrante (ce qui est incorrect pour un client initiant une connexion) et une NACL trop permissive.