6.68 RDS Chiffrement et sécurité AWS

La sécurité de RDS se décline sur plusieurs axes. Pour le chiffrement at rest, AWS permet de chiffrer le master et ses répliques via AWS KMS avec un AES-256. Important : le chiffrement doit être défini à la création de l'instance, car si le master n'est pas chiffré, ses répliques ne peuvent pas l'être. Pour Oracle et SQL Server, le TDE (Transparent Data Encryption) est également disponible nativement.

Pour le chiffrement in-transit, RDS utilise SSL/TLS entre le client et la base. Pour MySQL/PostgreSQL on télécharge le certificat de confiance RDS et on le passe à la chaîne de connexion. Pour forcer SSL sur PostgreSQL, on édite le parameter group et on met rds.force_ssl = 1. Sur MySQL, on accorde l'accès à l'utilisateur (par exemple christian) avec la clause REQUIRE SSL dans le GRANT.

Chiffrer une base déjà non chiffrée

Créer un snapshot du master non chiffré.
Faire une Copy Snapshot en cochant l'option de chiffrement (clé KMS).
Restaurer une nouvelle instance RDS à partir du snapshot chiffré.
Mettre à jour la chaîne de connexion de l'application vers la nouvelle base.
Supprimer l'ancienne base non chiffrée.

Côté réseau, les bases RDS sont déployées dans des sous-réseaux privés par défaut, et leur accès est régulé par des security groups — exactement comme pour les EC2. Côté IAM, les stratégies contrôlent qui peut administrer le service RDS via la console / API / CLI, mais l'accès aux données peut aussi se faire par authentification IAM token (MySQL/PostgreSQL uniquement) : on récupère un token court (15 min) via un appel API, ce qui élimine les mots de passe en clair. Le canal reste chiffré en SSL, les utilisateurs/rôles sont gérés par IAM, et l'EC2 peut s'authentifier via un rôle attaché.

Côté partage des responsabilités, l'architecte AWS est responsable de : règles entrantes des security groups, création/gestion des users via IAM, choix de la Public access, configuration des parameter groups pour n'autoriser que les opérations nécessaires. AWS est responsable de l'instance EC2 sous-jacente, du système d'exploitation, des patches OS et de la base de données managée — l'utilisateur n'a pas d'accès SSH et n'a aucun moyen de modifier l'OS sous-jacent. C'est tout l'intérêt du modèle managé : on se concentre sur la donnée et l'application, AWS gère le socle.

En résumé

Cette leçon couvre les trois piliers de la sécurité RDS sur AWS : le chiffrement des données au repos via AWS KMS avec AES-256 (à activer lors de la création de l'instance), le chiffrement en transit via SSL/TLS (en modifiant le paramètre `rds.force_ssl` pour PostgreSQL), et le chiffrement des sauvegardes et snapshots. Elle explique qu'une base de données non chiffrée ne peut être chiffrée directement : il faut créer un snapshot, le copier en activant le chiffrement, puis restaurer une nouvelle instance à partir de celui-ci. Enfin, elle détaille le contrôle d'accès par groupes de sécurité, l'authentification IAM sans mot de passe via token 15 minutes, et le modèle de responsabilité partagée entre AWS (infrastructure, patching) et le client (configuration des groupes, paramètres, gestion des utilisateurs).

Points clés

Le chiffrement RDS au repos utilise AWS KMS avec AES-256 et doit être activé obligatoirement lors de la création de l'instance RDS
En transit, SSL/TLS sécurise les données ; pour PostgreSQL, modifier le paramètre `rds.force_ssl` à 1 dans les groupes de paramètres RDS
Les snapshots héritent du chiffrement de la base source ; pour chiffrer une base existante non chiffrée, copier le snapshot en activant le chiffrement
Les groupes de sécurité AWS contrôlent l'accès réseau à RDS selon les règles de ports (inbound/outbound)
L'authentification IAM permet une connexion sans mot de passe en utilisant un token d'authentification valide 15 minutes, obtenu via appel API RDS
AWS gère les mises à jour, les correctifs et la sécurité physique ; le client reste responsable de la configuration des groupes de sécurité, groupes de paramètres et gestion des utilisateurs

Questions fréquentes

Puis-je chiffrer une base de données RDS déjà créée sans chiffrement ?

Non, pas directement. Le chiffrement doit être défini à la création de l'instance. Pour chiffrer une base existante non chiffrée, vous devez créer un snapshot de celle-ci, copier le snapshot en activant le chiffrement au moment de la copie, puis restaurer une nouvelle instance RDS à partir de ce snapshot chiffré.

Quelle est la différence entre le chiffrement au repos et le chiffrement en transit ?

Le chiffrement au repos protège les données stockées sur le disque avec AWS KMS (AES-256) ainsi que les snapshots. Le chiffrement en transit protège les données lors de leur transmission vers RDS en utilisant des certificats SSL/TLS, requis pour les connexions sécurisées.

Pourquoi utiliser l'authentification IAM plutôt qu'un mot de passe RDS ?

L'authentification IAM offre plusieurs avantages : pas de mot de passe à gérer, token d'authentification éphémère valide 15 minutes, intégration avec les rôles et politiques IAM d'AWS, meilleure traçabilité des accès, et pas besoin de stocker des identifiants directement dans RDS.