Connectez-vous à votre base de données RDS privée via AWS SSM

Introduction

Comme nous l'avons vu précédemment dans mon article, nous avons réussi à nous connecter aux instances EC2 en utilisant AWS Systems Manager Session Manager. J'ai écrit un autre article sur le même concept, mais en utilisant EC2 Instance Connect Endpoints - nous pouvons également connecter des bases de données de cette manière. Cela constitue la base pour se connecter à une base de données RDS en utilisant un processus de port-forwarding. Selon l'architecture sur laquelle vos systèmes sont basés, il y aura des avantages et des inconvénients à les utiliser.

Dans cet article, nous utiliserons AWS Systems Manager Session Manager pour pouvoir nous connecter aux bases de données RDS via un processus de port-forwarding.

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és.

💡

Avertissement

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 de nombreuses personnes : ne vous y trompez pas, il n'existe pas de système invulnérable - c'est une question de connaissances, de temps, d'argent et d'efforts.

Challenge existant

Risques & limites...

Comme mentionné dans l'article précédent, il peut être nécessaire de se connecter aux bases de données RDS dans certains projets si vous construisez la base de données et que vous ne restaurez pas une base existante. Si le type de base de données privée est RDS PostgreSQL ou MySQL, il n'y aura pas d'interface graphique dans la console AWS.

Nous avons déjà discuté des problèmes liés à avoir une base de données publique, mais il est toujours important de s'assurer que le message soit clair : les bases de données doivent être privées. Pour les connexions SSM, nous garderons également la base de données privée, bien sûr. En plus de garder la base de données privée, nous veillerons à ajouter d'autres mesures pour renforcer la sécurité de la connexion aux bases de données. Et, comme nous ne sommes pas connectés au réseau privé pour atteindre ces bases de données, nous devrons nous assurer que tout le chemin que nous créons garantit la confidentialité et la sécurité.

Approche recommandée

Meilleures pratiques pour assurer la sécurité de votre base de données

Sécurisez vos sources de données dans des réseaux privés, chiffrées, avec un firewall et suivez les meilleures pratiques du marché

La sécurité du Cloud repose sur plusieurs niveaux de protection, incluant la sécurité physique, la sécurité des réseaux, la sécurité des données en transit, ainsi que la sécurité des points d'accès (Endpoints) et des données elles-mêmes. Dans le cadre de notre exemple, nous mettrons l'accent sur l'amélioration de nombreux aspects pour assurer la mise en place d'une architecture fiable. Toutefois, il est important de noter que certains aspects, tels que la durabilité, ne seront pas abordés dans cet article, l'objectif étant de focaliser sur la démonstration de la connexion aux bases de données RDS via SSM. Pour simplifier l'exposition, nous généraliserons certains concepts.

EC2 Instance comme hôte bastion

Nous devons suivre le même modèle que précédemment, car il n'y a aucun moyen d'atteindre cette base de données de manière privée sans passer par un EC2. Cependant, nous le ferons de manière sécurisée, en utilisant des EndPoints privés, une instance privée pour un bastion et une base de données privée. Si vous regardez l'architecture, nous avons essentiellement rendu tout ce qui est possible privé.

Exemple d'architecture AWS pour accéder à une base de données privée en utilisant le service AWS Systems Manager

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. Bien qu'un hôte bastion doive être déployé, il n'est pas nécessaire d'avoir une connectivité Internet dans le VPC, ce qui é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 les VPC Endpoints 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 les VPC Endpoints. Le Security Group de les VPC Endpoints 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 à la base de données entrera dans AWS via les VPC Endpoints, passant par le groupe de sécurité de l'instance EC2 bastion et à travers l'EC2, et après le groupe de sécurité de la base de données et d'atteindre finalement la base de données.

Architecture représentant la connexion aux bases de données AWS RDS privées (PostgreSQL et MySQL) en utilisant le service EICE et une instance EC2 en tant qu'hôte bastion.

Aucune adresse IP publique n'est utilisée et la plage d'adresses pourrait éventuellement être encore plus restreinte

Les commandes suivantes prennent en compte les variables suivantes:

EC2IDA est l'ID de l'instance EC2 Bastion (demo-ec2-A)
RDSDBPOSTGRESENDPOINT endpoint de la base de données PostgreSQL
RDSDBMYSQLENDPOINT endpoint de la base de données MySQL

Prérequis

Pour les prérequis de la connexion SSM, veuillez consulter cet article dans lequel je décris en détail comment l'installer.

Premiers tests

Il peut être utile d'effectuer quelques tests pour s'assurer que l'architecture SSM est en place avant de tenter de se connecter. Comme nous avons plusieurs couches et éléments dans l'architecture, je suggère de tester ces éléments avant de tenter une connexion.

La première chose à tester est que le Plugin de Session Manager est installé localement. Utilisez la commande suivante :

$ session-manager-plugin

Vérifiez également que votre version est égale ou supérieure à : 1.2.536.0

$ session-manager-plugin --version

Après cela, testez que l'agent SSM fonctionne dans l'EC2 (bastion). Vous devriez pouvoir vérifier cela en utilisant AWS CLI et la commande suivante :

$ aws ssm describe-instance-information \
  --instance-information-filter-list \
  '[{"key":"InstanceIds","valueSet":["'$EC2IDA'"]}]' \
  --query 'InstanceInformationList[0].AgentVersion'

Si cela retourne OK, nous pourrons pousser les documents SSM pour changer la configuration par défaut – cela est nécessaire pour utiliser par exemple KMS. Vous pouvez vérifier comment cela peut être réalisé ici. Une fois les vérifications effectuées, nous sommes prêts à continuer le processus.

Créer un port-forwarding avec SSM

Pour se connecter aux bases de données, nous démarrons une session avec SSM, en ciblant le Endpoint de la base de données, le port de la base de données respectif, et nous le redirigeons vers un port local. Nous enregistrons également l'historique de connexion via un fichier appelé ssmlocaloutputhistory:

Chiffrement de base de données PostgreSQL | Thales

Pour se connecter à la base de données PostgreSQL, nous démarrons une session avec SSM, en ciblant l'endpoint de la base de données, le port 5432, et nous le redirigeons vers un port local 10021 :

$ aws ssm start-session --target $EC2IDA \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"portNumber":["5432"], \
  "localPortNumber":["10021"], \
  "host":["'$RDSDBPOSTGRESENDPOINT'"]}' \
  >> ssmlocaloutputhistory 2>&1 &

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=>

Pour se connecter à la base de données MySQL, nous démarrons une session avec SSM, en ciblant l'endpoint de la base de données, le port 3306, et nous le redirigeons vers un port local 10022 :

$ aws ssm start-session --target $EC2IDA \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"portNumber":["3306"], \
  "localPortNumber":["10022"], \
  "host":["'$RDSDBMYSQLENDPOINT'"]}' \
  >> ssmlocaloutputhistory 2>&1 &

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, et dans le cas du SSM, terminez la session SSM dans AWS.

Dans le cas de SSM, la libération des ports et des sessions AWS SSM peut être effectuée avec la commande ci-dessous :

$ YOURUSER=$(aws sts get-caller-identity | \
jq -r '.Arn' | \
rev | \
cut -d'/' -f 1 | \
rev)

$ aws ssm describe-sessions --state "Active" | \
jq -r '.[][] | select (.Owner | endswith("user/'$YOURUSER'")) | .SessionId' | \
xargs -I % sh -c 'aws ssm terminate-session --session-id %'

Nous utilisons (aws ssm describe-sessions) pour lister toutes les sessions actives. Ensuite, via jq, nous filtrons uniquement $YOURUSER (qui contient le login de votre utilisateur). Après cela, nous prenons l'Id de la session et via (xargs) nous terminons toutes les sessions filtrées.

Amélioration de l’approche

Comment pourrions-nous rendre cette architecture encore meilleure ?

L'objectif est de renforcer la sécurité de notre architecture multicouche en intégrant diverses technologies de défense. En superposant plusieurs niveaux de sécurité à la structure de notre application, nous augmentons ainsi la protection générale.

Pour augmenter la sécurité des environnements AWS, il est conseillé d'activer l'authentification multifacteur (MFA), ce qui ajoute une couche supplémentaire de sécurité lors de la connexion. Il est essentiel de n'autoriser l'accès qu'aux utilisateurs ayant reçu l'autorisation explicite, en se conformant strictement au principe du moindre privilège dans l'attribution des stratégies IAM. Les rôles IAM devraient être employés judicieusement pour contrôler l'accès aux instances EC2 de manière sécurisée.

La sécurité des données stockées sur les disques EBS et dans les bases de données RDS peut être renforcée par le chiffrement via AWS Key Management Service (KMS). Il est également crucial de limiter les privilèges de l'utilisateur "ec2-user" sur le bastion, le réservant exclusivement aux administrateurs. Tout cela en créant un utilisateur "dbuser" sur le bastion pour le tunneling et le port-forwarding avec des droits restreints.

Assurer la mise à jour régulière du système d'exploitation du bastion EC2 avec les derniers correctifs de sécurité est fondamental pour maintenir la robustesse du système. La surveillance et l'audit de l'accès doivent être intégrés avec AWS CloudTrail pour une traçabilité et une révision efficaces. Il est vital de tester et de valider régulièrement l'efficacité des ressources utilisées, des contrôles d'accès et des stratégies IAM.

Enfin, rester au courant des dernières pratiques de sécurité, des mises à jour de la documentation AWS et des nouveautés est indispensable pour garantir une architecture AWS sécurisée et à jour. Bien que notre architecture ne possède pas d'adresse IP publique accessible aux robots, il demeure crucial d'appliquer les meilleures pratiques de sécurité afin d'assurer la solidité globale du système.

Conclusion

En conclusion, AWS Systems Manager Session Manager offre une solution robuste pour se connecter de manière sécurisée aux bases de données AWS RDS via le port-forwarding. Sa capacité à fonctionner sans IP publique, sa dépendance uniquement au TCP 443 et ses fonctionnalités de confidentialité améliorées utilisant les clés KMS des clients en font un choix sécurisé et efficace pour la gestion de l'accès aux bases de données. De plus, son intégration avec AWS CLI et AWS Console, ainsi que la surveillance organisée et la journalisation des connexions de sessions, ajoutent à son attrait pour une utilisation en entreprise.

Cependant, les utilisateurs potentiels doivent être conscients des complexités et des exigences supplémentaires qui accompagnent l'utilisation du Session Manager à cette fin. La nécessité de points de terminaison VPC supplémentaires, le déploiement d'un agent à la fois sur les hôtes locaux et les instances bastion, et les problèmes potentiels de handshake avec KMS via AWS CLI, qui peuvent nécessiter des solutions tierces, pourraient introduire des obstacles. De plus, le coût global peut augmenter en raison de la nécessité de ces ressources supplémentaires.

Les organisations envisageant d'utiliser le Session Manager pour se connecter aux bases de données RDS devraient peser ces avantages contre les défis et coûts potentiels. Une planification et une mise en œuvre appropriées peuvent atténuer de nombreux aspects négatifs, permettant aux utilisateurs de tirer pleinement parti des avantages en matière de sécurité et de gestion du Session Manager dans leurs environnements AWS.

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.