Introduction
La connexion aux instances RDS privées depuis votre machine locale n'est pas simple, car les bases de données privées ne peuvent pas être directement connectées. Nous avons besoin d'un saut depuis une instance EC2 interne pour pouvoir accéder aux bases de données privées. Dans mon article précédent, j'ai expliqué comment se connecter à des instances EC2 privées en utilisant les EC2 Instance Connect Endpoints (EIC Endpoints ou EICE). Nous allons utiliser cette fonctionnalité très sécurisée pour nous connecter aux bases de données RDS privées.
Il existe différents moyens de se connecter aux bases de données RDS privées. L'architecture dépendra de vos besoins, notamment du niveau de sécurité recherché. L'objectif de cet article est de fournir des directives pour établir une connexion facile, rapide et sécurisée en utilisant le nouveau service de pointe, les EIC Endpoints d'AWS.
Nous allons explorer un environnement où aucun VPN ni aucune appliance physique de sécurité n'ont été mis en œuvre ou n'étaient requis, et où aucune adresse IP publique, passerelle NAT, ou sous-réseau public n'est utilisé.
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...
Après avoir créé une instance AWS RDS, nous souhaitons nous connecter pour appliquer des scripts et développer la base de données. Cependant, au moment de la rédaction de cet article, il n'existait pas de moyen simple de se connecter et d'interroger directement les bases de données AWS RDS via la console.
Actuellement, seules les bases de données AWS Aurora Serverless disposent de l'éditeur de requêtes SQL via la console. Par conséquent, si vous avez une simple instance privée de base de données AWS RDS PostgreSQL ou MySQL et que vous souhaitez effectuer une requête simple, vous aurez à fournir un effort supplémentaire. De plus, vous devrez veiller à sécuriser efficacement votre réseau de base de données et votre pare-feu pour interroger la base de données depuis l'extérieur.
Risques et inconvénients
Si vous décidez de rendre votre base de données publique, une fois qu'elle est exposée sur Internet, vous vous exposez à des risques importants - c'est comme laisser la porte d'entrée ouverte aux pirates. De plus, si les informations d'identification sont divulguées, cela pourrait conduire à un accès non autorisé, permettant aux attaquants de manipuler et de compromettre le contenu de la base de données.
Les pirates adorent exploiter des vulnérabilités, car elles leur permettent de lancer des attaques pour accéder à des informations sensibles telles que les données des clients et les dossiers financiers. Dans de tels scénarios, les attaques de logiciels malveillants et de ransomwares sont beaucoup plus probables. Ces attaques peuvent corrompre ou chiffrer les données, forçant les victimes à payer une rançon pour les récupérer.
De plus, rendre votre base de données publique signifie ignorer les consignes de sécurité à vos risques et périls. Les pirates peuvent exploiter les vulnérabilités connues plus rapidement que vous ne pouvez dire "cyberattaque". Les correctifs de sécurité et les mises à jour deviennent difficiles à mettre en œuvre rapidement, ce qui augmente le risque d'exploitation de vulnérabilités connues. Les attaques par Distributed Denial-of-Service (DDoS) sont une menace imminente, submergeant la base de données de demandes excessives et provoquant une interruption de l'application.
Enfin, vous pourriez enfreindre les règles si votre secteur d'activité est soumis à des normes de sécurité strictes. Prendre la conformité à la légère n'est pas conseillé : les réglementations exigent des mesures de sécurité solides, et rendre une base de données publique pourrait ne pas suffire pour respecter ces normes.
Approche recommandée
Meilleures pratiques pour assurer la sécurité de votre base de données
Tout d'abord, abandonnez l'idée de base de données publique : il est essentiel d'utiliser des bases de données privées dans des réseaux privés avec des groupes de sécurité stricts ! L'adoption d'un ensemble solide de bonnes pratiques est impérative.
Pour renforcer la sécurité de vos bases de données, vous pouvez opter pour des stratégies efficaces comme la désignation de sous-réseaux privés, l'utilisation de Network Access Control Lists (NACL) et de Security Groups qui restreignent les accès non autorisés tout en améliorant la protection des données. En parallèle, verrouillez vos bases de données avec des outils de sécurité réseau pour empêcher tout accès non autorisé. L'application rigoureuse de mécanismes d'authentification et de chiffrement renforce encore la sécurité et minimise les risques potentiels.
Surveillez activement les activités de la base de données pour détecter tout comportement suspect et réagir rapidement. La mise en œuvre rapide des correctifs de sécurité et des mises à jour est essentielle pour prévenir l'exploitation de vulnérabilités par des pirates. En restant informé des tendances et des correctifs de sécurité, vous pouvez maintenir la protection de vos données et montrer votre engagement en matière de sécurité. Adopter une approche proactive conforme aux réglementations sectorielles renforce davantage la sécurité et garantit le respect de la conformité.
En conclusion, en évitant les bases de données publiques et en adoptant ces mesures de sécurité, vous offrez à vos précieuses données une forteresse de protection contre les dangers numériques qui les guettent. C'est un moyen essentiel de préserver la confidentialité de vos informations et d'assurer la sécurité de votre environnement.
Cependant, après tout cela, comment puis-je me connecter à ma base de données privée facilement?
EC2 Instance Connect Endpoints comme hôte bastion
Un hôte bastion, également connu sous le nom de jump server, jump box ou simplement bastion, joue le rôle d'une passerelle intermédiaire. Il offre un accès au sous-réseau interne, permettant ainsi d'atteindre les bases de données dotées d'une adresse IP interne. Cette passerelle agit comme un point d'entrée sous contrôle. Elle offre aux utilisateurs autorisés la possibilité d'établir une connexion sécurisée vers des ressources internes du réseau tout en préservant la séparation entre les environnements réseau externe et interne.
Les hôtes bastion ne sont pas toujours bien considérés par les équipes de sécurité, car ils peuvent engendrer des risques en cas de configuration incorrecte. C'est pourquoi il peut être nécessaire de mettre en place un VPN hautement sécurisé avec des appliances de sécurité ou d'utiliser AWS Direct Connect. Cependant, dans les situations où ni un VPN et ni AWS Direct Connect ne sont disponibles, et où vous souhaitez rediriger un port de base de données tel que TCP 5432 ou 3306, l'utilisation d'un hôte bastion devient nécessaire. AWS SSM Session Manager et EIC Endpoints ne sont pas en mesure de se connecter directement aux bases de données, car ils ne prennent en charge que les protocoles SSH (Secure Socket Shell) et SCP (Secure Copy Protocol), qui s'exécutent exclusivement sur le port TCP 22.
Comme expliqué dans mon précédent article, nous avons examiné comment établir une connexion sécurisée avec des instances EC2 privées en utilisant les EIC Endpoints. Ainsi, une question se pose : Est-il possible d'utiliser les connexions aux instances EC2 via les EIC Endpoint comme des hôtes bastion privés pour manipuler des bases de données ? La réponse est claire : oui.
Le EC2 Instance Connect Endpoint (EICE) agit comme un Proxy de Gestion d'Identité (Identity-Aware Proxy, IAP), autorisant le transfert TCP 22 pour permettre l'accès administratif tout en garantissant le contrôle, l'isolation et la journalisation. Il associe des mécanismes de contrôle réseau et d'authentification. En d'autres termes, cela vous permet d'accéder directement à vos instances sans nécessiter l'utilisation d'une adresse IP publique.
Par conséquent, l'instance EC2 pourrait être exploitée en tant qu'hôte bastion, avec sa connexion renforcée par l'utilisation de l'EICE. Cette approche rendrait l'ensemble du scénario à la fois très sécurisé et simple à mettre en place. Enfin, l'hôte bastion serait en mesure d'accéder à l'instance de base de données en permettant les ports appropriés via les deux Security Groups.
Principales caractéristiques et avantages
Le principal avantage de cette architecture est qu'elle ne dispose d'aucune adresse IP publique ni d'aucune clé SSH à longue durée de vie. Bien qu'un hôte bastion doit être déployé, il n'est pas nécessaire d'avoir une connectivité Internet dans le VPC. Cela évite la mise en place d'une Internet Gateway (IGW) ou d'une NAT Gateway, ainsi que l'utilisation d'adresses IP publiques. En respectant les règles d'entrée et de sortie des Security Groups et NACLs, cette solution permettrait de garantir la sécurité tout en offrant une connectivité.
Étude de cas avec les Bonnes Pratiques
Mettons tout cela en pratique...
Pour illustrer, nous allons mettre en place un exemple avec deux instances de base de données AWS RDS (PostgreSQL et MySQL) situées dans deux sous-réseaux distincts d'un même VPC. Chaque base de données disposera de son propre Security Group. L'instance EC2 (bastion) et le EICE auront également leurs propres Security Groups. L'instance EC2 servira d'hôte bastion pour se connecter aux bases de données, et la connexion à cette instance EC2 se fera via le EICE. Le Security Group du EICE autorisera uniquement la connexion au Security Group de l'hôte bastion, qui autorisera à son tour uniquement la connexion aux bases de données. La connexion aux bases de données sera établie en créant un tunnel à travers le EICE et en transmettant la clé publique à l'hôte bastion EC2 au moment de la connexion.
Les commandes suivantes prennent en compte les variables suivantes:
EC2IDA est l'ID de l'instance EC2 Bastion (demo-ec2-A)
EICEID est l'ID du EC2 Instance Connect Endpoint dans le VPC (demo-eice-1)
RDSDBPOSTGRESENDPOINT endpoint de la base de données PostgreSQL
RDSDBMYSQLENDPOINT endpoint de la base de données MySQL
Il y a trois commandes à exécuter pour établir la connexion entre votre machine locale et la base de données:
- Générez les clés publique et privée à l'aide de la commande ssh-keygen
- Transmettez la clé publique à l'EC2 IMDS du bastion
- Établissez le tunneling avec le bastion en utilisant le EC2 Instance Connect endpoint, puis, à l'aide des clés, créez la redirection de port pour acheminer la connexion depuis/vers les bases de données vers votre adresse locale.
Dans la commande 3, il y a une sous-commande à prendre en compte. Le tunnel est créé à l'aide de la sous-commande "ssh -o ProxyCommand=". Mais dans ce cas, le tunnel ne peut pas être réutilisé.
Tunnels séparés
Pour utiliser des tunnels séparés (un pour le bastion hôte et un autre pour le bastion vers la base de données), vous devez utiliser un ProxyCommand. Les commandes détaillées seront présentées ci-dessous.
Commencez par nettoyer les anciennes clés, ensuite générez de nouvelles clés et enfin envoyez-les aux métadonnées EC2 (IMDS) :
$ yes | rm -r my-key-pairA my-key-pairA.pub; \
ssh-keygen -t rsa -b 4096 -f my-key-pairA -q -N ""
$ 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
Pour vous connecter aux bases de données PostgreSQL, ouvrons le tunnel avec le bastion en utilisant le "ProxyCommand". Dans la même commande, effectuons le port-forwarding en arrière-plan (-f) avec la base de données PostgreSQL en utilisant le tunnel vers notre port local 10021. Remarquez qu'il n'est pas nécessaire de spécifier un port avec le tunnel et la cible, car cela est géré par le "ProxyCommand". Veuillez noter que le port cible pour PostgreSQL est 5432.
$ ssh -f \
-o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
-i ./my-key-pairA \
-N -L localhost:10021:"$RDSDBPOSTGRESENDPOINT":5432 ec2-user@localhost \
-o ProxyCommand='aws ec2-instance-connect open-tunnel \
--instance-connect-endpoint-id '$EICEID' \
--instance-id '$EC2IDA
Pour vous connecter aux bases de données MySQL, la même chose que pour PostgreSQL, mais en veillant à ce que l'endpoint soit celui de MySQL et que le port cible soit le 3306. Dans notre scénario, nous utilisons le port 10022 pour MySQL.
$ ssh -f \
-o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
-i ./my-key-pairA \
-N -L localhost:10022:"$RDSDBMYSQLENDPOINT":3306 ec2-user@localhost \
-o ProxyCommand='aws ec2-instance-connect open-tunnel \
--instance-connect-endpoint-id '$EICEID' \
--instance-id '$EC2IDA
Pour les deux bases de données, la seule variation consistera à changer l'endpoint et le port de la base de données. Tous les autres éléments demeurent inchangés. Ainsi, un script pourrait être facilement créé pour s'adapter aux différents ports de base de données que vous pourriez utiliser.
Tunnel unique
Si vous souhaitez réutiliser le tunneling, la commande numéro 3 doit doit être exécutée séparément. Cela vous fournira le port du tunneling qui agira comme port de redirection pour les autres bases de données.
Voici un exemple de connexion en utilisant le port 10020 comme tunneling. Veuillez noter que les clés doivent être envoyées au bastion juste avant la connexion.
Tout d'abord, nous nettoyons les anciennes clés, nous générons de nouvelles clés, puis nous les envoyons aux métadonnées EC2 (IMDS) :
$ yes | rm -r my-key-pairA my-key-pairA.pub; \
ssh-keygen -t rsa -b 4096 -f my-key-pairA -q -N ""
$ 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
Ensuite, nous ouvrons le tunnel avec le bastion en utilisant le port 10020:
$ aws ec2-instance-connect open-tunnel \
--instance-connect-endpoint-id $EICEID \
--instance-id $EC2IDA \
--remote-port 22 \
--local-port 10020 &
Ensuite, nous effectuons le port-forwarding avec la base de données PostgreSQL en utilisant le port de tunnel 10020 vers notre port local 10021:
$ ssh -o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
-i ./my-key-pairA \
-N -L localhost:10021:$RDSDBPOSTGRESENDPOINT:5432 ec2-user@localhost \
-p 10020 &
Enfin, nous effectuons le port-forwarding avec la base de données MySQL en utilisant le port de tunnel 10020 vers notre port local 10022:
$ ssh -o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
-i ./my-key-pairA \
-N -L localhost:10022:$RDSDBMYSQLENDPOINT:3306 ec2-user@localhost \
-p 10020 &
Test des connexions
Après avoir créé le tunneling et configuré la redirection de port, la connexion peut être facilement établie. La base de données PostgreSQL peut être connectée en utilisant le programme psql :
$ psql -h localhost -p 10021 -d postgres -U masteruser
Password for user masteruser:
psql (15.4 (Ubuntu 15.4-1.pgdg20.04+1), server 15.3)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, compression: off)
Type "help" for help.
postgres=>
La base de données MySQL peut être connectée en utilisant le programme mysql:
$ mysql -h 127.0.0.1 -P 10022 -u masteruser -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 35
Server version: 8.0.33 Source distribution
Copyright (c) 2000, 2023, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
Nettoyage des connexions
Après avoir utilisé la base de données, il est fortement recommandé de fermer vos connexions et vos tunnels.
Tunnel unique
Pour supprimer proprement le tunnel créé avec ProxyCommand ( tunneling et de port-forwarding), utilisez les commandes suivantes pour fermer les connexions PostgreSQL :
$ ps aux | grep '[s]sh.*.rds.amazonaws.com:5432*'
$ pkill -f '[s]sh.*.rds.amazonaws.com:5432*'Et utilisez la commande suivante pour fermer les connexions MySQL :
$ ps aux | grep '[s]sh.*.rds.amazonaws.com:3306*'
$ pkill -f '[s]sh.*.rds.amazonaws.com:3306*'Tunnels séparés
Pour nettoyer les tunnels ensemble, vous pourriez supprimer les tâches en arrière-plan. Veuillez noter que dans cet exemple, nous supposons que vous n'avez pas d'autres tâches en arrière-plan, mais uniquement celles de l'exemple. Ainsi, vous pourriez simplement utiliser la commande suivante :
kill $(jobs -p)
Pour nettoyer les tunnels créés séparément et permettre la gestion de plusieurs connexions, utilisez les commandes "jobs" et "fg". La commande "jobs" vous permettra d'identifier les processus que vous avez lancés. Une fois que vous avez identifié le processus, utilisez la commande "fg" suivie du numéro de job (#numéro du processus) pour le supprimer. Ensuite, appuyez sur Ctrl+C pour interrompre la connexion. Répétez cette opération pour toutes les connexions, en commençant par le numéro le plus élevé jusqu'au numéro le plus bas :
$ jobs
[1] Running /usr/local/aws-cli/v2/current/bin/aws ec2-instance-connect open-tunnel --instance-connect-endpoint-id $EICEID --instance-id $EC2IDA --remote-port 22 --local-port 10020 &
[2]- Running ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ./my-key-pairA -N -L localhost:10021:$RDSDBPOSTGRESENDPOINT:5432 ec2-user@localhost -p 10020 &
[3]+ Running ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ./my-key-pairA -N -L localhost:10022:$RDSDBMYSQLENDPOINT:3306 ec2-user@localhost -p 10020 &
$ fg 3
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ./my-key-pairA -N -L localhost:10022:$RDSDBMYSQLENDPOINT:3306 ec2-user@localhost -p 10020
^C
$ fg 2
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i ./my-key-pairA -N -L localhost:10021:$RDSDBPOSTGRESENDPOINT:5432 ec2-user@localhost -p 10020
^C
$ 2023-08-24 15:25:00,956 - awscli.customizations.ec2instanceconnect.websocket - ERROR - [1] Encountered error with websocket: (104, 'Connection reset by peer')
[1] Closing tcp connection.
$ fg 1
/usr/local/aws-cli/v2/current/bin/aws ec2-instance-connect open-tunnel --instance-connect-endpoint-id $EICEID --instance-id $EC2IDA --remote-port 22 --local-port 10020
^C
$ jobs
$Amélioration de l’approche
Comment pourrions-nous rendre cette architecture encore meilleure ?
L'objectif est d'augmenter la sécurité de l'architecture en couches en combinant différentes technologies de protection. Plus nous ajoutons des couches de sécurité à l'architecture de l'application, plus nous renforçons la sécurité globale.
Pour améliorer la sécurité de notre architecture en couches, nous pouvons mettre en œuvre les mesures suivantes :
- Restreindre l'accès aux utilisateurs autorisés uniquement.
- Activer l'authentification multifacteur (MFA) pour renforcer la sécurité de la connexion aux environnements AWS.
- Appliquer le principe du moindre privilège aux stratégies IAM pour EC2 Instance Connect.
- Utiliser des rôles IAM pour gérer l'accès aux instances EC2 via EC2 Instance Connect.
- Chiffrer les disques EBS du bastion et les bases de données RDS à l'aide de KMS.
- Sécuriser le bastion en restreignant l'utilisateur "ec2-user" aux administrateurs.
- Créer un utilisateur "dbuser" sur le bastion avec des privilèges limités pour le tunneling et le port-forwarding.
- Maintenir le système d'exploitation du bastion EC2 à jour avec les correctifs de sécurité.
- Surveiller et auditer l'accès en intégrant les journaux avec AWS CloudTrail.
- Tester et valider l'utilisation des ressources, des contrôles d'accès, des stratégies IAM, etc.
- Rester informé des améliorations de sécurité, de la documentation AWS et des nouvelles évolutions.
Même si notre architecture ne dispose pas d'adresse IP publique susceptible d'être trouvé par des robots, il est essentiel de suivre les meilleures pratiques de sécurité pour garantir la robustesse de l'ensemble.
Connexion directe (non disponible actuellement par AWS - 30/09/23)
Apparemment, AWS permettait la connexion directe aux bases de données RDS une fois qu'EICE avait été initialement rendu disponible, mais ce n'est plus le cas. Si vous essayez le code ci-dessous, la commande passera, mais lorsque vous essayez de vous connecter à la base de données, cela échouera.
$ aws ec2-instance-connect open-tunnel \
--instance-connect-endpoint-id $EICEID \
--private-ip-address $RDSDBPOSTGRESENDPOINT \
--local-port 10021 \
--remote-port 5432 &Cela est dû au fait qu'EICE accepte UNIQUEMENT les ports 22 et 3389
"The specified RemotePort is not valid. Specify either 22 or 3389 as the RemotePort and retry your request."
$ psql -h localhost -p 10021 -d postgres -U masteruser
[1] Accepted new tcp connection, opening websocket tunnel.
2023-09-29 23:38:08,177 - awscli.customizations.ec2instanceconnect.websocket -
ERROR - {"ErrorCode":"InvalidParameter","Message":"The specified RemotePort is not valid.Specify either 22 or 3389 as the RemotePort and retry your request."}
psql: error: connection to server at "localhost" (127.0.0.1), port 10021 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
AWS_ERROR_HTTP_WEBSOCKET_UPGRADE_FAILURE: Failed to upgrade HTTP connection to WebsocketCela signifie que vous êtes obligé de passer par une instance EC2.
Si la connexion directe était possible, l'approche serait bien meilleure, sécurisée et plus rapide. Attendons de voir si AWS la rendra disponible. En attendant, nous avons besoin d'une instance EC2 pour accéder à la base de données RDS.
Conclusion
En conclusion, AWS EC2 Instance Connect Endpoints offre une connexion Identity-Aware Proxy (IAP) avec des instances EC2 privées utilisées comme hôtes bastion. Cette connexion est renforcée par l'envoi de clés via EC2 IMDS, établissant ainsi un tunnel sécurisé entre nos bases de données privées et nos ordinateurs locaux. Cette approche nous permet d'utiliser nos environnements de développement (IDEs) préférés pour accéder aux bases de données.
Nous avons réussi à établir des connexions sans problème avec tous ces IDE en utilisant cette méthode. La connexion offre une expérience fluide et stable avec des performances rapides, en fonction de l'IDE de base de données utilisé. De plus, les interactions en ligne de commande donnent l'impression que les bases de données sont hébergées localement. Un point encore plus remarquable est l'absence d'Internet Gateway (IGW), de Network Address Translation (NAT) ou d'adresse IP publique (entrant ou sortant) dans cette architecture. L'unique point d'entrée est le EC2 Instance Connect Endpoint, accessible uniquement via le DNS AWS, accessible lui-même via la connexion AWS. Ainsi, si la sécurité de la connexion AWS est renforcée par une authentification multifacteur (MFA) et que les rôles et les policies sont configurés avec des privilèges minimaux, la solution paraît bien sécurisée.
Cependant, il est important de noter que différents besoins en matière de sécurité peuvent exister au sein des entreprises. Par conséquent, il est essentiel de s'assurer que les équipes de sécurité sont alignées sur l'approche appropriée pour l'accès distant à votre infrastructure.
Je vous encourage à explorer les références et à approfondir les détails pour adapter au mieux cette approche à votre projet et à vos environnements spécifiques.
Références
Marcio Boldorini
Contributors to Wikimedia projects
Autres références
Images generated with https://chat.openai.com/with the assistance of DALL·E 2
