Mettre à jour les certificats SSL / TLS Amazon RDS - Elastic Beanstalk


14

AWS a récemment annoncé la nécessité de:

Mettez à jour vos certificats SSL / TLS Amazon RDS d'ici le 31 octobre 2019

J'ai une application Rails hébergée avec un équilibreur de charge Elastic Beanstalk classique, qui se connecte à une base de données Postgres à l'aide de RDS.

Les étapes requises selon Amazon sont les suivantes:

  1. Téléchargez le nouveau certificat SSL / TLS depuis Utilisation de SSL / TLS pour crypter une connexion à une instance de base de données.
  2. Mettez à jour vos applications de base de données pour utiliser le nouveau certificat SSL / TLS.
  3. Modifiez l'instance de base de données pour changer l'autorité de certification de rds-ca-2015 à rds-ca-2019.

( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html )

Étant donné que mes équilibreurs de charge sont configurés comme ceci (connexion à mes instances EC2 via le port HTTP 80 (pas SSL), cela signifie-t-il que je n'ai pas besoin de suivre les étapes 1 et 2? Et que de suivre uniquement l'étape 3?

LoadBalancerListeners

Ou dois-je télécharger les certificats mis à jour et les installer / ajouter manuellement à mon équilibreur de charge ou à mes instances EC? Je ne sais pas comment faire ça.


1
qu'avez-vous dû faire à la fin? je ne sais pas quelle était la solution finale.
weber

3
@weber, la principale chose que je devais déterminer était de savoir si les instances EC2 derrière un équilibreur de charge Elastic Beanstalk avec une connexion RDS liée feraient automatiquement confiance au certificat 2019 mis à niveau ou non. Je ne savais pas si j'avais besoin de leur faire confiance manuellement via SSH, ou par exemple en utilisant .ebextensions. À la fin, après l'avoir testé, j'ai pu confirmer qu'ils faisaient automatiquement confiance à la nouvelle connexion RDS. Si l'instance DB RDS a été découplée de l'environnement EB comme décrit ici https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html, je ne suis pas sûr du résultat.
stwr667

Réponses:


8

Les étapes 1 et 2 ne sont nécessaires que si la connexion de votre application avec MySQL est cryptée TLS .

Ne modifiez pas le paramètre LB TLS , cela peut casser votre application, LB TLS est autre chose, alors que RDS TLS est autre chose.

Si votre application vient de créer une connexion simple, vous pouvez effectuer directement l'étape 3 en toute sécurité.

Modifiez l'instance de base de données pour changer l'autorité de certification de rds-ca-2015 à rds-ca-2019.

Normalement, la pratique pour la base de données doit être dans un sous-réseau privé et ne doit pas être accessible au public, TLS est utile lorsque votre connexion à la base de données et au backend est sur Internet, pas dans VPC.

Avec une connexion non cryptée entre le client MySQL et le serveur, une personne ayant accès au réseau peut surveiller tout votre trafic et inspecter les données envoyées ou reçues entre le client et le serveur.


Merci @Adiii. Êtes-vous sûr? Ici docs.aws.amazon.com/AmazonRDS/latest/UserGuide/… il décrit comment voir si votre connexion DB utilise SSL. Lorsque je eb sshme connecte à mon serveur à partir de là à la base de données via psql, puis exécutez select ssl_is_used(), cela renvoie vrai! Mon instance RDS est liée à mon environnement EB comme décrit ici docs.aws.amazon.com/elasticbeanstalk/latest/dg/… . Étant donné qu'EB est automatiquement connecté à RDS, je suis préoccupé par ce qui précède que le changement de CA interrompra la connexion générée.
stwr667

Je parle en général, cela dépend de l'application de la façon dont il crée la connexion, mais du code suggéré par le lien de connexion palin. var mysql = require('mysql'); var connection = mysql.createConnection({ host : process.env.RDS_HOSTNAME, user : process.env.RDS_USERNAME, password : process.env.RDS_PASSWORD, port : process.env.RDS_PORT }); connection.connect(function(err) { if (err) { console.error('Database connection failed: ' + err.stack); return; } console.log('Connected to database.'); }); connection.end();
Adiii

2
Merci @Adii. Pour info, j'utilise Postgres, pas MySQL. La bonne nouvelle est que j'ai pris un instantané et que j'ai essayé l'étape 3 tout à l'heure. Tout fonctionne toujours comme prévu. Même lors de la reconnexion à la base de données à partir du serveur d'applications, il indique toujours qu'il utilise SSL, donc je suppose qu'ElasticBeanstalk gère automatiquement la confiance du certificat lorsque l'instance RDS est liée à l'environnement EB. Merci encore.
stwr667

Alors, comment créez-vous une connexion? Avez-vous spécifié SSL dans la chaîne de connexion?
Adiii

J'ai une application Rails, donc les informations de connexion sont définies dans database.ymllesquelles appellent des variables ENV comme RDS_DB_NAME, RDS_USERNAMEetc. Bien que je pense que le réglage par défaut sur EB doit être quelque chose comme allow, preferou require, configuré via une variable d'environnement ou de quelque chose. cf: postgresql.org/docs/current/… . Ce n'est certainement pas l'un des 3 autres, car disablecela désactiverait SSL, et les autres verifyoptions ont échoué lorsque je les ai testées sur la CLI.
stwr667

2

Il y a une réponse beaucoup plus facile à la question:

Vous n'avez rien à installer dans votre environnement Beanstalk si vous mettez à niveau le certificat CA utilisé par le RDS qui lui est attaché. https://stackoverflow.com/a/59742149/7051819

Suivez simplement le point 3 et ignorez 1 et 2.

(Oui, j'ai écrit cette réponse moi-même).


3
Je pense que la réponse de saut est rejetée parce que la plupart des environnements de production n'utilisent PAS RDS dans le haricot élastique. l'utilisation de RDS à partir de Beanstalk élastique est potentiellement dangereuse car si vous mettez fin à votre instance de Beanstalk élastique, votre base de données est également arrêtée, ce qui n'est pas bon pour la conservation des données. Donc, en général, les gens posent des questions sur les environnements de haricot élastique où l'instance RDS est distincte.
jakeatwork
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.