Établissez une connexion à distance avec vos instances AWS privées en utilisant les EC2 Instance Connect EndPoints

Introduction

Après avoir créé une instance privée AWS EC2, l'une des premières questions qui se posent est la suivante : comment établir une connexion SSH sécurisée en utilisant exclusivement des adresses IP privées ?

Auparavant, pour rediriger les connexions SSH vers les instances disposant d'adresses IP privées, les clients étaient contraints de mettre en place des bastions. Cette approche nécessitait des mises à jour, une gestion d'audit et des vérification constantes, ce qui engendrait une augmentation de la charge opérationnelle ainsi que des frais supplémentaires. De plus, il est important de souligner que l'utilisation de ces bastions exposait également à des risques potentiels en termes de sécurité.

Eh bien, AWS propose différentes méthodes pour y parvenir, en fonction de vos besoins et surtout du niveau de sécurité requis. Parfois, nous souhaitons effectuer des tests faciles à des fins de développement ou de POC, mais il est crucial de s'assurer que les instances ne soient pas accessibles au public. À d'autres moments, nous déployons des systèmes en production pour des entreprises ayant des normes de sécurité strictes, ce qui nécessite une approche différente.

Les approches suivantes pourraient ne pas être recommandées pour une utilisation au sein d'entreprises nécessitant des normes de sécurité élevées, où l'utilisation d'appliances physiques est la norme et obligatoire. Bien que la solution proposée soit très sécurisée, il est toujours préférable de discuter de tout projet avec votre responsable de la sécurité, de partager des informations avec vos collègues et de veiller à ce que tout le monde comprenne la mise en œuvre envisagée. Il est également important de garder à l'esprit que, comme le disent souvent beaucoup : ne vous y trompez pas, il n'existe pas de systèmes invulnérables - c'est une question de connaissances, de temps, d'argent et d'efforts.

Challenge existant

Risques, limites, désavantages...

Dès que nous sommes dans le Cloud et que nous souhaitons expérimenter de nouvelles choses, nous finissons souvent par créer une nouvelle instance EC2 et nous y connecter. Le moyen le plus simple de se connecter à une instance EC2 est d'utiliser la console AWS, en utilisant une adresse IPv4 publique accessible depuis internet et en exposant le port SSH. Cette méthode permet la communication entre vos instances et Internet, mais présente un niveau de sécurité très faible, en particulier lorsque l'instance est exposée à tout internet.

Risques actuels

Un accès facile est tout aussi avantageux pour les attaquants. Utiliser des adresses IP publiques pour les instances EC2 et exposer les ports SSH ne constitue pas une bonne pratique et n'est pas recommandé, car cela augmente la surface d'attaque. Ce risque pourrait éventuellement être atténué par l'utilisation de l'authentification à l'aide de paires de clés RSA, mais cela n'est pas encore suffisamment efficace, car les paires de clés pourraient éventuellement être compromises.

Les adresses IP publiques conviennent mieux aux DMZ ou aux Application Load Balancers (ALB) qui doivent être exposés pour une connexion publique, mais elles ne devraient pas exposer les ports SSH. Les instances EC2 internes doivent éviter toute exposition directe à Internet. De plus, cela pourrait potentiellement exposer des vulnérabilités inconnues aujourd'hui, ce qui pourrait rendre votre instance entièrement accessible au monde à l'avenir.

Limites

En plus des problèmes liés aux risques, au moment de la rédaction de cet article, il existait un nombre limité d'adresses IP publiques autorisées par AWS à fonctionner dans un compte et une région AWS spécifiques. Cette limitation est logique car les adresses IP publiques sont une ressource mondiale et non une ressource interne d'AWS. Afin d'éviter cette problématique, il est conseillé de ne pas recourir à l'utilisation d'adresses IP publiques pour un accès direct, même à des fins de développement et de test.

Désavantages

Outre les risques et limitations liés à l'utilisation directe d'adresses IP publiques dans les instances EC2 pour les connexions à distance, AWS commencera à facturer l'utilisation des adresses IPv4 à partir du 1er février 2024. Au moment de la rédaction de cet article, les frais d'utilisation seraient calculés par heure, que l'IP soit inactif ou en cours d'utilisation.

Approche recommandée

EC2 Instance Connect Endpoints est la réponse

Lorsque vous utilisez les environnements AWS, l'approche actuelle simple et sécurisée consiste à utiliser EC2 Instance Connect Endpoints (EIC Endpoints). En adoptant cette approche, vous n'avez plus besoin d'installer une Internet Gateway (IGW) dans votre VPC, de mettre en place un hôte Bastion, ni d'attacher une adresse IP publique à vos instances EC2. De plus, il n'est même pas nécessaire d'installer des agents spécifiques (comme c'est le cas avec AWS Session Manager) pour vous connecter à votre instance depuis le Web.

L'Endpoint EIC est un Identity-Aware Proxy (IAP) qui permet le transfert TCP, offrant un accès administratif tout en garantissant un contrôle, un isolement et une journalisation adéquats. Il combine des contrôles basés sur le réseau et des contrôles d'identité. En substance, cela signifie qu'il vous permet d'accéder directement à vos instances sans nécessiter l'utilisation d'une adresse IP publique.

L'image suivante illustre la manière dont une connexion serait établie. L'utilisateur utilisera le EIC, qui passe par une Elastic Network Interface (ENI) pour finalement se connecter à l'instance. L'ENI et l'EC2 possèdent tous deux des groupes de sécurité (SG) distincts. Le premier groupe autorise exclusivement les connexions sortantes vers les groupes de sécurité de la cible.

Caractéristiques et avantages clés

En utilisant les EIC Endpoints, l'utilisation d'adresses IP publiques n'est plus nécessaire, et vous n'avez plus besoin de clés SSH à longue durée de vie. Avec les EIC Endpoints, il n'est pas requis de déployer des hôtes bastion et vous n'êtes pas non plus obligé d'assurer la connectivité Internet de votre VPC, ce qui élimine le besoin de déployer une Internet Gateway (IGW) ou une NAT Gateway. Ainsi, les avantages sont évidents : facilité, flexibilité, disponibilité et surtout sécurité.

Étude de cas avec les Bonnes Pratiques

Mettons tout cela en pratique...

Pour illustrer, nous allons mettre en œuvre un exemple comprenant deux instances EC2 situées dans deux sous-réseaux distincts au sein du même VPC. Chaque instance disposera de son propre groupe de sécurité. L'EIC possédera également son propre groupe de sécurité, autorisé uniquement à établir des connexions sortantes en direction des groupes de sécurité des instances EC2.

Les commandes suivantes prennent en compte les variables suivantes :

Où:

SGGROUPID est l'ID du Security Group du l'EIC (demo-sg-eci)
SUBNETIDA est l'ID de Subnet privé A (demo-sub-A)
EICENAME est le nom du EC2 Instance Connect Endpoint (demo-eice-1)
EC2IDA est l'ID d'instance EC2 de l'instance A (demo-ec2-A)
EC2IDB est l'ID d'instance EC2 de l'instance B (demo-ec2-B)

Pour créer le EIC Endpoint, utilisez la commande suivante :

$ aws ec2 create-instance-connect-endpoint \
--region us-east-1 \
--subnet-id $SUBNETIDA \
--security-group-ids $SGGROUPID \
--no-preserve-client-ip \
--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value='$EICENAME'}]'

La commande répondra aux détails, mais elle ne sera pas prête à être utilisée.

{
    "InstanceConnectEndpoint": {
        "OwnerId": "548633167931",
        "InstanceConnectEndpointId": "eice-08368be6fdb6eabb8",
        "InstanceConnectEndpointArn": "arn:aws:ec2:us-east-1:548633167931:instance-connect-endpoint/eice-08368be6fdb6eabb8",
        "State": "create-in-progress",
        "StateMessage": "",
        "NetworkInterfaceIds": [],
        "VpcId": "vpc-0938fdae8c4b255fc",
        "CreatedAt": "2023-08-09T22:19:21+00:00",
        "SubnetId": "subnet-03ab7dc550319e801",
        "PreserveClientIp": false,
        "SecurityGroupIds": [
            "sg-0acd1061da58bdf4d"
        ],
        "Tags": [
            {
                "Key": "Name",
                "Value": "demo-eice-1"
            }
        ]
    },
    "ClientToken": "21a09029-e0c1-465f-810b-dee76d57093f"
}

La création d'un EICE peut prendre un certain temps, parfois jusqu'à 10 minutes. Par conséquent, après avoir lancé la commande de création, utilisez la commande suivante pour surveiller l'avancement de la création jusqu'à son achèvement:

$ eicstate='create-in-progress'; \
spin='-\|/'; \
i=0; \
while [[ $eicstate = 'create-in-progress' ]]; do \
eicstate=$(aws ec2 describe-instance-connect-endpoints \
--region us-east-1 \
--filters Name=tag:Name,Values=$EICENAME \
--query "InstanceConnectEndpoints[].State" \
--output text); \
i=$(( (i+1) %4 )); \
echo -ne "waiting... $eicstate ${spin:$i:1} \033[0K\r"; \
sleep 1; \
done

Cela présentera dans le terminal un état de progression tel que :

waiting... create-in-progress -

Une fois que l'EICE est créée, utilisez les commandes suivantes pour vous connecter à l'instance EC2 A ou B.

$ aws ec2-instance-connect ssh \
--instance-id $EC2IDA \
--connection-type eice

The authenticity of host '10.0.38.237 (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:JlqprpQoEmjoNChs7lx5nFBW+4YDEN3V3JfRUYwQrFU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.38.237' (ECDSA) to the list of known hosts.
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-10-0-38-237 ~]$

$ aws ec2-instance-connect ssh \
--instance-id $EC2IDB  \
--connection-type eice

The authenticity of host '10.0.170.109 (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:QLfKbqPx9KMWgdZqgJ/Jqq2y/yiTP8QVDhl5aya05uQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.0.170.109' (ECDSA) to the list of known hosts.
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-10-0-170-109 ~]$

Amélioration de l’approche

Comment pourrions-nous rendre cette architecture encore meilleure ?

L'objectif demeure toujours de dissuader, détecter, retarder et refuser les connections non autorisées dans nos ressources. C'est là que la sécurité en profondeur intervient. Cette notion consiste à renforcer la sécurité de l'architecture en superposant différentes couches de protection. L'idée est d'ajouter des couches de sécurité à l'architecture de l'application, ce qui contribue à renforcer sa sécurité globale.

Ainsi, afin d'améliorer la sécurité de notre solution, nous pourrions générer des paires de clés privées et publiques localement, puis envoyer la clé publique SSH aux métadonnées de l'instance via l'API EC2 Instance Connect. Ces métadonnées resteront accessibles pendant 60 secondes, ce laps de temps étant amplement suffisant pour établir une connexion avec l'instance.

Passées 60 secondes, l'accès à l'instance via ces clés ne sera plus possible, et une nouvelle paire de clés privée/publique devra être générée/envoyée si une autre connexion est requise. Naturellement, les stratégies IAM nécessaires pour autoriser votre utilisateur à transmettre la clé publique aux métadonnées de l'instance devront être ajoutées.

Tout d'abord, veuillez supprimer toute anciennes clés du dossier dans lequel vous allez créer les nouvelles clés publiques et privées:

$ yes | rm -r my-key-pairA my-key-pairA.pub

Générez les clés publiques et privées :

$ ssh-keygen -t rsa -b 4096 -f my-key-pairA -q -N ""

Envoyez la clé publique aux métadonnées de l'instance EC2 IMDS en utilisant la commande send-ssh-public-key.

$ aws ec2-instance-connect send-ssh-public-key \
--region us-east-1 \
--availability-zone us-east-1a \
--instance-id $EC2IDA \
--instance-os-user ec2-user \
--ssh-public-key file://my-key-pairA.pub

AWS répondra et nous devons obtenir un succès : True.

{
    "RequestId": "0114463a-594a-4420-8350-f6bc791b9d86",
    "Success": true
}

Utilisez la commande suivante pour vous connecter à l'instance pendant les 60 secondes suivantes :

$ aws ec2-instance-connect ssh \
--instance-id $EC2IDA \
--private-key-file ./my-key-pairA
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
Last login: Wed Aug  9 22:34:28 2023 from 10.0.114.108
[ec2-user@ip-10-0-38-237 ~]$ exit
logout
Connection to 10.0.38.237 closed.

Si la tentative de connexion à l'instance prend plus de 60 secondes, vous recevrez un message d'erreur. Si cela se produit, il vous suffit de renvoyer la clé (il n'est pas nécessaire de recréer la clé).

ec2-user@10.0.38.237: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Conclusion

En conclusion, AWS EC2 Instance Connect (EIC) simplifie la gestion des accès SSH tout en renforçant la sécurité grâce à un Identity-Aware Proxy (IAP) qui autorise le transfert TCP sur le port 22 pour permettre un accès administratif direct à vos instances EC2, sans nécessiter d'adresse IP publique. De plus, nous pouvons encore améliorer la sécurité en générant des paires de clés privées et publiques, puis en les transmettant au service de métadonnées EC2 Instance Metadata Service (IMDS) via l'API du service EC2 Instance Connect.

Il est essentiel de comprendre que différents projets requièrent différents niveaux de sécurité. Veillez toujours à obtenir l'approbation des équipes de sécurité quant à l'approche choisie pour l'accès à distance à votre infrastructure.

Je vous encourage vivement à lire les références et à approfondir les détails qui pourraient être les plus adaptés à votre projet et à vos environnements spécifiques.

Références

Amazon EC2 Instance Connect supports SSH and RDP connectivity without public IP address

Amazon Web Services, Inc.

Connect using EC2 Instance Connect - Amazon Elastic Compute Cloud

The following instructions explain how to connect to your Linux instance using EC2 Instance Connect.

Amazon Elastic Compute Cloud