Un ingénieur en sécurité est en train de créer une procédure d'isolation Amazon EC2 pour la réponse aux incidents. L'objectif est de bloquer tout le trafic entrant et sortant vers une instance cible, à l'exception de l'accès par l'équipe d'investigation numérique. Chaque instance possède son propre security group, et plusieurs instances partagent le même sous-réseau. Pendant les tests, l'ingénieur ouvre une session SSH vers la cible, puis supprime les règles de security group existantes et ajoute des règles pour autoriser l'équipe d'investigation numérique sur le port 22. La session SSH existante reste active, bien que l'ICMP vers l'IP publique soit bloqué. Que doit faire l'ingénieur pour isoler complètement l'instance ?

La suppression de la règle du groupe de sécurité pour le port 22 bloque l'accès SSH traditionnel, y compris la session existante après un court délai. L'attachement d'une politique de rôle d'instance avec les autorisations nécessaires pour AWS Systems Manager Session Manager permet à l'équipe d'investigation numérique d'accéder à l'instance via Session Manager, qui utilise une connexion basée sur l'agent et ne dépend pas des ports réseau ouverts traditionnels. Cela assure un isolement complet tout en maintenant un accès contrôlé pour l'investigation. L'ajout et la suppression immédiate de règles 0.0.0.0/0 ne garantissent pas un isolement complet et peuvent perturber le trafic existant de manière imprévisible. La création d'une ACL réseau pour le sous-réseau affecterait toutes les instances du sous-réseau, pas seulement l'instance cible, et pourrait bloquer l'accès de l'équipe d'investigation. L'utilisation de règles de pare-feu basées sur l'hôte est moins efficace et plus complexe à gérer que les groupes de sécurité ou Session Manager pour l'isolement.