Tour d'horizon actualisé des différentes manières de se connecter en toute sécurité à des instances EC2 privées
L'accès aux instances EC2 privées est un besoin fréquent pour certains profils au sein des organisations, généralement les administrateurs et quelques développeurs autorisés. Traditionnellement, les utilisateurs d'AWS ont eu recours à des bastions (jump boxes), à des VPN (Virtual Private Connections) ou à AWS Direct Connect pour y répondre. Si AWS EC2 propose depuis un certain temps des alternatives modernes à ces solutions old-school, une amélioration récente apportée à l'une de ces approches en juin 2023 mérite que l'on revienne sur le sujet. Cet article présente ces différentes options pour se connecter aux instances EC2 privées, leurs avantages, leurs inconvénients ainsi que la manière de les utiliser.
Note : dans ce contexte, une instance privée est une instance EC2 sans adresse IPv4 publique, ou non lancée dans un sous-réseau VPC public. Par définition, un sous-réseau public est un sous-réseau dont la table de routage dirige le trafic vers Internet via une Internet Gateway.
Récapitulatif de la connexion SSH traditionnelle.
Il existe deux moyens traditionnels courants pour se connecter de façon sécurisée à une instance EC2 privée : 1) établir un tunnel chiffré sécurisé via un Client-VPN ou un VPN Site-to-Site (incluons aussi AWS Direct Connect dans ce groupe, bien qu'il ne s'agisse pas techniquement d'un tunnel) et 2) utiliser une instance EC2 publique comme jump box (couramment appelée hôte bastion) pour ouvrir une nouvelle connexion vers l'instance privée. Les deux options ont un coût et impliquent (dans certains cas) une configuration loin d'être triviale. Examinons-les de plus près :
- AWS Client-VPN, AWS Site-to-Site VPN (ou solutions VPN similaires) ou AWS Direct Connect
Cette approche a été (et reste) un moyen répandu d'autoriser la connectivité depuis n'importe quel réseau vers un réseau privé, en établissant un tunnel chiffré (dans le cas des VPN) ou une liaison privée dédiée (dans le cas d'AWS Direct Connect). Elle a toutefois un coût : il faut au minimum une instance ou un service managé comme point de terminaison de la connexion VPN, parfois des frais liés à la durée de connexion, le tout avec un niveau de complexité variable.
- Jump box ou Bastion
Option encore plus répandue, moins coûteuse et moins complexe que la mise en place d'un VPN ou de Direct Connect, cette approche consiste à utiliser une instance EC2 publique qui reçoit la connexion du client puis ouvre une nouvelle connexion vers l'instance EC2 privée (voir le schéma ci-dessous). Vous pouvez l'employer pour le SSH (généralement via le SSH Agent Forwarding) et le RDP (via Remote Desktop Gateway). Inconvénient : en plus du coût de l'instance bastion, vous augmentez votre surface d'attaque en exposant publiquement ce bastion. Il faut bien sûr mettre en œuvre toutes les mesures de sécurité disponibles pour protéger vos hôtes bastions : accès contrôlé aux identifiants de la machine (clés privées), restrictions réseau via les Security Groups et les Network Access Control Lists (NACL), et application régulière des correctifs du système d'exploitation. Autant de tâches qui pèsent sur l'exploitation de votre infrastructure.

Connexion via bastion
Si les options ci-dessus restent techniquement valables, AWS propose deux méthodes modernes, plus faciles à gérer et plus économiques pour offrir le même type d'accès à vos instances privées. Passons-les en revue.
MÉTHODE D'ACCÈS 1 : Session Manager vous permet de vous passer entièrement de SSH (si vous le souhaitez).
AWS Session Manager, lancé en 2018, est une fonctionnalité d'AWS Systems Manager qui permet d'administrer de manière interactive vos instances EC2, vos appareils edge ainsi que vos serveurs et machines virtuelles (VM) on-premise.
Avec Session Manager, ni SSH ni RDP ne sont requis sur l'instance EC2 privée à laquelle vous vous connectez (ils n'ont pas besoin d'être installés, configurés ni en cours d'exécution). Vous pouvez néanmoins utiliser les protocoles SSH ou RDP pour vous connecter à l'instance EC2 privée à travers Session Manager (voir ci-dessous).
Configurer Session Manager :
- L'instance EC2 privée doit exécuter Systems Manager Agent, qui est préinstallé sur plusieurs AMI, mais que vous pouvez aussi installer manuellement (et pas uniquement sur des instances EC2).
- Le sous-réseau auquel l'instance EC2 privée de destination est rattachée doit disposer d'une connectivité Internet directe ou indirecte via une Internet Gateway ou une NAT Gateway. Vous pouvez aussi configurer des VPC endpoints pour Session Manager afin de gérer des instances EC2 privées sans accès Internet sortant. Visualisons ces 2 options :
- Option de configuration réseau 1 : si vous disposez déjà d'une NAT Gateway dans un sous-réseau public (et que la facturation du trafic supplémentaire généré par l'agent Systems Manager via la NAT Gateway ne vous gêne pas), le schéma suivant illustre le fait que l'agent Session Manager a besoin d'une connectivité sortante vers les endpoints Session Manager pour permettre le démarrage des sessions clientes.

Session Manager avec NAT Gateway
- Option de configuration réseau 2 : si vous préférez ne pas utiliser d'Internet Gateway ni de NAT Gateway, il vous faut un VPC Endpoint pour chaque service : Systems Manager, Session Manager Message Gateway Service et Message Delivery Service. Pour plus de détails, consultez cette page et celle-ci. Notez que les VPC Endpoints possèdent leurs propres Security Groups (et Resource Policies) que l'on peut exploiter pour un contrôle d'accès supplémentaire au niveau du réseau et des identités.

Session Manager avec VPC Endpoints
Utiliser Session Manager :
- Vous pouvez utiliser la console de gestion AWS ou l'AWS Command Line Interface (AWS CLI) pour démarrer des sessions vers les nœuds auxquels votre administrateur système vous a accordé l'accès via des stratégies AWS Identity and Access Management (IAM). Si vous préférez l'AWS CLI, vous devrez d'abord installer le plugin Session Manager pour l'AWS CLI.
- Vous bénéficiez d'un contrôle d'accès centralisé aux instances via des stratégies IAM, à la fois sur l'instance de destination (le rôle attribué à l'instance doit accorder à Systems Manager Agent les permissions nécessaires pour interagir avec les API Systems Manager/Session Manager) et sur l'identité qui tente d'accéder à l'instance EC2 (l'utilisateur ou le rôle IAM doit disposer des permissions de démarrer une connexion Session Manager).
- Vous pouvez attribuer les permissions d'instance au niveau du compte via un rôle AWS Identity and Access Management (IAM), ou au niveau de l'instance via un instance profile. Si votre cas d'usage le permet, AWS recommande d'octroyer l'accès au niveau du compte via la Default Host Management Configuration.
- Vous pouvez aussi utiliser les protocoles SSH ou RDP (dans ce cas, un fichier d'identifiants est nécessaire côté client).
- Vous pouvez même vous connecter en toute sécurité à une instance de base de données Amazon RDS ou Amazon EC2 avec votre interface graphique préférée, via le port forwarding et un bastion EC2 placé dans un sous-réseau privé.
Autres points à connaître sur Session Manager :
- Session Manager prend en charge des fonctionnalités de journalisation et d'audit. Vous pouvez vous appuyer sur AWS CloudTrail et Amazon CloudWatch Logs (et éventuellement un bucket S3) pour conserver un historique de toute l'activité des sessions. La journalisation n'est pas disponible pour les sessions Session Manager qui passent par le port forwarding ou par SSH, car SSH chiffre l'ensemble des données de session et Session Manager se contente alors de servir de tunnel pour les connexions SSH.
- L'accès aux instances Amazon EC2 via Session Manager n'engendre aucun coût supplémentaire. Les frais standard de transfert de données s'appliquent. En revanche, l'utilisation de Session Manager pour accéder de manière interactive à des instances on-premise implique un coût.
MÉTHODE D'ACCÈS 2 : EC2 Instance Connect Endpoint, la nouvelle façon de se connecter en SSH/RDP à une machine.
EC2 Instance Connect Endpoint vous permet de vous connecter à une instance via SSH ou RDP, à l'aide d'un SSH reposant sur des clés éphémères, sans que l'instance ait besoin d'une adresse IPv4 publique. Avant juin 2023, EC2 Instance Connect offrait une fonctionnalité similaire, mais ne donnait accès qu'aux instances EC2 publiques (cette option reste disponible pour ce type de machine). EC2 Instance Connect a été lancé en 2019.
Configurer EC2 Instance Connect Endpoint :
- Aucun agent n'est requis sur l'instance de destination. Cette approche permet d'accéder à des instances qui ne prennent pas forcément en charge les agents, comme certaines appliances tierces.
- Aucune connectivité Internet directe ou indirecte via Internet Gateway ou NAT Gateway n'est requise. Vous devez en revanche configurer un endpoint dans un sous-réseau du VPC contenant votre instance de destination. À l'heure où ces lignes sont écrites (novembre 2023), vous ne pouvez créer qu'un seul EC2 Instance Connect Endpoint par VPC (voir les quotas). Quelques minutes sont nécessaires pour que l'endpoint devienne disponible.

EC2 Instance Connect Endpoint
Utiliser EC2 Instance Connect Endpoint :
- Vous pouvez utiliser la console de gestion AWS, votre propre clé et client SSH ou l'AWS Command Line Interface (AWS CLI) pour vous connecter à vos nœuds privés. Vous devez ouvrir un tunnel via l'AWS CLI avant d'établir une connexion à l'aide d'un client RDP.
- Vous pouvez utiliser vos propres clés SSH si vous le souhaitez (dans ce cas, un fichier d'identifiants est nécessaire côté client). Pour établir une connexion RDP avec l'utilisateur administrateur par défaut, vous aurez besoin de la clé privée de la Key Pair par défaut associée à l'EC2 afin de déchiffrer le mot de passe initial de l'administrateur, comme lors d'une connexion à des instances Windows publiques.
- EC2 Instance Connect Endpoint offre un contrôle d'accès centralisé aux instances en combinant des contrôles basés sur l'identité (permissions IAM attribuées à l'utilisateur ou au rôle IAM qui initie la connexion) et sur le réseau (Security Groups appliqués à l'endpoint et à l'instance de destination). Vous pouvez configurer EC2 Instance Connect Endpoint pour conserver l'adresse IP du client. Cela peut influer sur la configuration de vos Security Groups et Network Access Control Lists (NACL).
Autres points à connaître sur EC2 Instance Connect Endpoint :
- Il s'appuie sur des identifiants temporaires : même en cas de compromission d'une clé privée, celle-ci ne peut pas être utilisée au-delà de la période de validité des identifiants.
- Vous pouvez journaliser les opérations sur les ressources et auditer les connexions établies via EC2 Instance Connect Endpoint à l'aide des logs AWS CloudTrail. Contrairement à Session Manager, la journalisation de l'activité des utilisateurs doit être gérée au niveau du système d'exploitation de l'instance de destination.
- Certaines limitations sont à connaître. Pour n'en citer que deux : seuls les ports 22 et 3389 sont pris en charge, et EC2 Instance Connect Endpoint ne gère pas les connexions à une instance via des adresses IPv6.
- L'utilisation des EC2 Instance Connect Endpoints n'engendre aucun coût supplémentaire. Les frais standard de transfert de données s'appliquent.
Conclusion
Dans cet article, j'ai présenté quatre méthodes pour se connecter en toute sécurité à des instances EC2 privées sur AWS.
Les méthodes traditionnelles comprennent : 1) la mise en place d'AWS Client-VPN, d'un VPN Site-to-Site ou d'AWS Direct Connect (qui reposent sur des tunnels chiffrés ou des liaisons dédiées, mais s'accompagnent d'une certaine complexité et d'un coût) et 2) l'utilisation d'une instance EC2 publique comme jump box (économique, mais qui élargit la surface d'attaque).
L'article présente ensuite deux approches modernes, plus simples et moins coûteuses :
- Session Manager : une fonctionnalité d'AWS Systems Manager qui permet l'administration interactive des instances EC2 sans nécessiter SSH ni RDP (que vous pouvez toutefois utiliser en option) sur l'instance privée. Elle s'appuie sur Systems Manager Agent, requiert que le sous-réseau de destination dispose d'une connectivité Internet sortante (via une NAT Gateway ou un VPC Interface Endpoint) et offre un contrôle d'accès centralisé via des stratégies IAM.
- EC2 Instance Connect Endpoint : permet l'accès SSH ou RDP aux instances dépourvues d'adresse IPv4 publique. Il ne nécessite pas d'agent sur l'instance de destination ni de connectivité Internet directe (il suffit de rattacher l'endpoint à un sous-réseau du VPC). Le contrôle d'accès est assuré par les permissions IAM et les Security Groups.
Session Manager comme EC2 Instance Connect Endpoint offrent des capacités d'audit (Session Manager permettant en outre la journalisation optionnelle de l'activité des sessions) et n'entraînent aucun frais supplémentaire pour accéder aux instances Amazon EC2, hormis les frais standard de transfert de données.
Je vous encourage à adopter dès maintenant ces options de connexion améliorées : elles peuvent aussi vous aider à atténuer l'impact de la nouvelle tarification des adresses IPv4 publiques annoncée par AWS pour le 1er février 2024. Si vous avez besoin d'aide, nos équipes Customer Reliability Engineering (CRE) et Technical Account Managers (TAM) chez DoiT se feront un plaisir de vous accompagner — il vous suffit de nous contacter !