Cours Aws

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.