Une startup gère un parc d'instances EC2 Amazon Linux 2 dans des sous-réseaux privés, et les ingénieurs utilisent SSH pour le dépannage. Le VPC dispose de sous-réseaux privés et publics, d'une passerelle NAT et d'un VPN Site-à-Site vers les locaux. Les groupes de sécurité EC2 actuels autorisent les connexions SSH directes depuis le réseau sur site. L'entreprise souhaite renforcer les contrôles SSH et l'audit des commandes exécutées par les ingénieurs. Quelle approche un architecte de solutions devrait-il recommander ?

L'option correcte est de créer un rôle IAM avec la politique AmazonSSMManagedInstanceCore et d'utiliser AWS Systems Manager Session Manager. Cette approche renforce la sécurité en éliminant l'accès SSH direct (port 22) depuis le réseau sur site, réduisant ainsi la surface d'attaque. Session Manager ne nécessite pas de ports entrants ou de clés SSH, et toutes les commandes exécutées sont auditées et peuvent être enregistrées dans S3 ou CloudWatch Logs, répondant ainsi aux exigences d'audit. Les autres options sont moins optimales : EC2 Instance Connect permet un accès SSH sécurisé, mais ne fournit pas nativement l'audit des commandes exécutées par les ingénieurs. Restreindre les groupes de sécurité aux adresses IP des ingénieurs améliore la sécurité mais ne fournit pas l'audit des commandes et maintient l'exposition du port 22. L'agent CloudWatch peut collecter des journaux, mais Session Manager offre une solution plus intégrée pour l'audit des sessions. L'activation d'AWS Config et Firewall Manager aide à maintenir la conformité des groupes de sécurité, mais ne résout pas le problème de l'audit des commandes SSH ni l'exposition du port 22.