Le 14 octobre 2026, des milliers d’équipes DevOps en France et en Europe gèrent encore des bases Amazon RDS exposées sur Internet, sans chiffrement au repos ou sans TLS forcé sur les connexions. Amazon RDS héberge des données clients, des identifiants et des historiques de transactions pour une part massive des applications cloud du marché. Un défaut de configuration suffit à transformer une base de production en cible facile. Ce tutoriel détaille 13 étapes concrètes pour verrouiller une instance RDS PostgreSQL ou MySQL, de l’isolation réseau jusqu’à l’automatisation complète avec Terraform, avec des commandes testées et un projet livrable en fin d’article.

Pourquoi sécuriser Amazon RDS est devenu urgent en 2026

Amazon RDS reste le service de base de données managée le plus utilisé chez les clients AWS, qu’il s’agisse de PostgreSQL, MySQL, MariaDB, Oracle ou SQL Server. Cette popularité en fait une cible de choix. AWS publie régulièrement des correctifs via son programme Extended Support pour PostgreSQL. Les notes de version documentées par AWS mentionnent des correctifs pour plusieurs failles remontées en 2026, dont CVE-2026-2004, CVE-2026-6477 et CVE-2026-6478, ainsi que des correctifs hérités de CVE-2025-12817 et CVE-2025-12818. Ces vulnérabilités touchent le moteur PostgreSQL lui-même, pas seulement la couche AWS, ce qui veut dire qu’une instance RDS mal entretenue hérite aussi des failles amont.

Pour les équipes basées en France ou ailleurs en Europe, la pression réglementaire ajoute une couche supplémentaire. Le RGPD impose un chiffrement et un contrôle d’accès proportionnés au risque pour toute donnée personnelle stockée en base. La directive NIS2, transposée progressivement dans les droits nationaux, étend ces obligations aux opérateurs de services essentiels et importants. Une base RDS exposée publiquement, sans authentification forte, expose directement l’entreprise à une non-conformité documentée en cas d’audit ou d’incident.

La bonne nouvelle : AWS fournit nativement tous les mécanismes nécessaires pour fermer ces angles d’attaque. Chiffrement avec AWS KMS, isolation réseau via VPC, authentification IAM, rotation des secrets, audit continu. Rien de tout cela n’est activé par défaut lors de la création rapide d’une instance RDS depuis la console. Ce guide suit un ordre logique, de la fondation réseau jusqu’au monitoring, pour que chaque étape s’appuie sur la précédente.

La documentation officielle AWS détaille, moteur par moteur et région par région, quelles fonctionnalités de sécurité sont réellement disponibles pour votre configuration (grille des fonctionnalités RDS par région et moteur). C’est la première page à consulter avant de concevoir une architecture de sécurité, car toutes les options ne sont pas disponibles partout au même moment, notamment sur les authentifications IAM et certains types de réplication chiffrée.

Prérequis : comptes, versions et outils nécessaires

Avant de commencer, réunissez les éléments suivants. Le tutoriel part du principe que vous disposez déjà d’un compte AWS actif avec facturation configurée, et que vous travaillez dans une région européenne comme eu-west-1 (Irlande) ou eu-west-3 (Paris) pour limiter les transferts de données hors UE.

Comptes et permissions AWS

  • Un utilisateur ou rôle IAM avec les droits rds:*, ec2:*, kms:*, secretsmanager:* et cloudwatch:* sur le périmètre du projet (idéalement via une politique dédiée, pas AdministratorAccess)
  • Un budget de test : une instance db.t4g.micro suffit pour suivre ce tutoriel sans dépasser quelques euros
  • Un accès à la console AWS et au CLI depuis un poste autorisé, de préférence avec MFA activé sur le compte racine

Outils et versions logicielles

  • AWS CLI v2 (dernière version stable disponible via le gestionnaire de paquets officiel AWS)
  • Terraform, dernière version stable de la branche 1.x, pour la partie infrastructure as code
  • Un client PostgreSQL (psql) ou MySQL compatible avec le moteur choisi
  • PostgreSQL 17 comme moteur cible pour ce tutoriel : Amazon RDS prend en charge les versions majeures 11 à 17 selon la documentation officielle des moteurs par région, avec une fin de support progressive des versions les plus anciennes
  • Un éditeur de code et un terminal Bash ou Zsh

Comptez environ 90 minutes pour suivre l’intégralité des 13 étapes, en incluant les temps d’attente propres à la création d’une instance RDS (10 à 15 minutes) et à un test de failover Multi-AZ (1 à 2 minutes de coupure simulée).

Étape 1 : isoler RDS dans un VPC privé sans accès public

La première erreur à éviter consiste à laisser une base de données accessible depuis Internet. Amazon RDS doit vivre dans des sous-réseaux privés, sans route vers une passerelle Internet, et accepter uniquement les connexions venant de vos serveurs applicatifs ou de votre VPN d’entreprise. Créez d’abord un groupe de sous-réseaux dédié à la base.

aws rds create-db-subnet-group \
  --db-subnet-group-name rds-prod-subnets \
  --db-subnet-group-description "Sous-reseaux prives pour RDS production" \
  --subnet-ids subnet-0a1b2c3d4e subnet-0f6g7h8i9j \
  --region eu-west-3 \
  --tags Key=Environnement,Value=production

Vérifiez que les deux sous-réseaux appartiennent à des zones de disponibilité différentes : c’est un prérequis obligatoire pour activer le Multi-AZ plus tard. Ensuite, lors de la création de l’instance, placez le paramètre –no-publicly-accessible pour garantir qu’aucune adresse IP publique ne soit attribuée à la base.

Un point souvent oublié : même dans un VPC privé, une mauvaise table de routage peut exposer un sous-réseau censé être privé. Vérifiez systématiquement, dans la console VPC, que la table de routage associée ne contient aucune règle 0.0.0.0/0 pointant vers une passerelle Internet (igw-xxxxx). Seule une route vers un NAT Gateway, si besoin de sorties sortantes, doit apparaître.

Si votre organisation gère plusieurs comptes AWS via AWS Organizations, allez plus loin qu’un simple VPC privé par compte. Mettez en place une politique de contrôle de service (SCP) qui bloque, au niveau de l’organisation entière, toute tentative de rendre une instance RDS accessible publiquement, quelle que soit l’équipe qui déploie. Cette barrière organisationnelle protège contre l’erreur humaine même quand un développeur presse de livrer une fonctionnalité contourne les revues de code habituelles. Pour les architectures multi-comptes, pensez aussi au peering VPC ou à AWS Transit Gateway plutôt qu’à l’ouverture d’un accès public, afin que les applications d’un compte voisin atteignent la base sans jamais transiter par Internet.

Étape 2 : verrouiller l’accès réseau avec les security groups

Le security group attaché à votre instance RDS fonctionne comme un pare-feu stateful. Par défaut, le security group “default” d’un VPC autorise souvent des flux internes trop larges. Créez un security group dédié qui n’autorise que le port du moteur (5432 pour PostgreSQL, 3306 pour MySQL et MariaDB) depuis le security group de vos serveurs applicatifs, jamais depuis une plage IP ouverte.

aws ec2 create-security-group \
  --group-name rds-prod-sg \
  --description "Acces restreint a RDS PostgreSQL" \
  --vpc-id vpc-012345abcdef

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 5432 \
  --source-group sg-0fedcba9876543210

Évitez absolument d’autoriser 0.0.0.0/0 sur le port de la base, même temporairement pour un test. C’est l’erreur la plus fréquente observée sur les instances compromises : une règle ouverte “juste pour déboguer” qui reste en place pendant des mois. Documentez chaque règle avec une description explicite pour faciliter les audits de sécurité ultérieurs.

Pensez aussi à limiter les flux sortants de l’instance elle-même via un security group d’egress restrictif, surtout si le moteur exécute des extensions capables d’initier des connexions réseau. Une base compromise qui ne peut pas communiquer vers l’extérieur limite fortement la capacité d’un attaquant à exfiltrer des données ou à télécharger un second outil malveillant. Enfin, automatisez la revue périodique des security groups avec AWS Config ou un script planifié qui liste toutes les règles ouvertes sur 0.0.0.0/0 dans le compte, et faites remonter une alerte dès qu’une nouvelle règle de ce type apparaît en dehors d’un changement validé.

Étape 3 : chiffrer les données au repos avec AWS KMS

Le chiffrement au repos protège vos données si un support de stockage physique venait à être compromis, et il devient obligatoire pour de nombreux référentiels de conformité. Amazon RDS s’appuie sur AWS KMS pour chiffrer le stockage, les sauvegardes automatiques, les snapshots manuels et les réplicas en lecture. Créez une clé KMS gérée par le client plutôt que d’utiliser la clé par défaut AWS, pour garder le contrôle total sur la rotation et les politiques d’accès.

aws kms create-key \
  --description "Cle de chiffrement RDS production" \
  --region eu-west-3

aws rds create-db-instance \
  --db-instance-identifier rds-prod-pg17 \
  --db-instance-class db.t4g.micro \
  --engine postgres \
  --engine-version 17.4 \
  --master-username dbadmin \
  --manage-master-user-password \
  --allocated-storage 50 \
  --storage-encrypted \
  --kms-key-id alias/rds-prod-key \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-subnet-group-name rds-prod-subnets \
  --no-publicly-accessible \
  --backup-retention-period 7

Remarquez l’option –manage-master-user-password : elle délègue la génération et la rotation du mot de passe maître à AWS Secrets Manager dès la création, au lieu de transmettre un mot de passe en clair dans la commande. C’est la pratique recommandée depuis que cette fonctionnalité est disponible sur RDS.

Point d’attention critique : le chiffrement au repos ne peut pas être activé après coup sur une instance existante non chiffrée. Si votre base de production tourne aujourd’hui sans chiffrement, la seule voie de migration passe par un snapshot, une copie chiffrée du snapshot, puis une restauration vers une nouvelle instance chiffrée. Planifiez une fenêtre de maintenance pour cette opération.

La politique de clé KMS mérite une attention particulière, car une clé mal configurée peut soit bloquer un redémarrage d’instance en cas de révocation accidentelle, soit au contraire rester accessible à des rôles IAM qui n’en ont plus besoin. Limitez l’action kms:Decrypt aux rôles strictement nécessaires au fonctionnement de l’instance et activez la rotation automatique annuelle de la clé, prise en charge nativement par KMS sans interruption de service côté RDS. Gardez aussi une trace écrite de l’alias de clé utilisé pour chaque instance, car une suppression accidentelle de clé KMS rend définitivement illisibles tous les snapshots qui en dépendent.

Étape 4 : déployer en Multi-AZ pour la haute disponibilité

Le déploiement Multi-AZ classique maintient une instance de secours synchronisée dans une autre zone de disponibilité et bascule automatiquement en cas de panne. Ce n’est pas qu’une question de disponibilité : une base qui tombe en panne pendant une fenêtre de maintenance mal anticipée pousse souvent les équipes à ouvrir des accès d’urgence non sécurisés pour rétablir le service au plus vite. Le Multi-AZ réduit cette pression opérationnelle.

Modèle de déploiementRésilienceImpact sur le coûtCas d’usage recommandé
Single-AZAucun basculement automatiqueRéférence (1x)Environnements de développement et de test
Multi-AZ instance de secoursBascule automatique vers une instance de secoursEnviron 2x le coût compute d’une instance Single-AZ équivalenteProduction standard avec exigence de continuité
Multi-AZ en cluster (DB cluster)Un primaire plus deux répliques lisibles, bascule plus rapideTarification distincte, à vérifier via la calculatrice AWS selon la régionProduction à forte charge de lecture et faible tolérance à la latence de basculement

Pour activer le Multi-AZ sur une instance existante, une seule option suffit dans l’appel de modification, sans interruption de service côté application grâce au mécanisme de bascule transparente géré par AWS. Ajoutez simplement –multi-az lors de la création ou –apply-immediately lors d’une modification ultérieure.

Gardez en tête que le Multi-AZ protège contre une panne d’infrastructure (zone de disponibilité, matériel sous-jacent, coupure réseau localisée), pas contre une erreur de requête qui supprimerait des lignes par erreur : l’instance de secours réplique fidèlement tout ce qui arrive sur le primaire, y compris les erreurs humaines. C’est précisément pour cette raison que les étapes suivantes sur les sauvegardes et les snapshots restent indispensables en complément, jamais en remplacement du Multi-AZ.

Étape 5 : forcer TLS pour chiffrer les données en transit

Le chiffrement au repos ne protège rien si les requêtes SQL circulent en clair entre votre application et la base. Amazon RDS propose des certificats TLS pour chaque moteur, mais ne force pas leur usage par défaut. Pour PostgreSQL, modifiez le groupe de paramètres afin d’imposer rds.force_ssl. Pour MariaDB, le paramètre équivalent s’appelle require_secure_transport, documenté par AWS comme un moyen natif d’exiger des connexions SSL/TLS sur toutes les sessions.

aws rds create-db-parameter-group \
  --db-parameter-group-name rds-force-ssl-pg17 \
  --db-parameter-group-family postgres17 \
  --description "Force TLS sur toutes les connexions"

aws rds modify-db-parameter-group \
  --db-parameter-group-name rds-force-ssl-pg17 \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot"

Testez ensuite la connexion depuis votre client pour vérifier que le mode strict fonctionne et que les connexions non chiffrées sont bien rejetées.

psql "host=rds-prod-pg17.xxxxxxxx.eu-west-3.rds.amazonaws.com \
  port=5432 dbname=postgres user=dbadmin sslmode=verify-full \
  sslrootcert=eu-west-3-bundle.pem"

Téléchargez le bundle de certificats racine correspondant à votre région directement depuis la documentation AWS avant ce test, et renouvelez-le selon le calendrier de rotation publié par AWS pour éviter toute coupure surprise le jour où un certificat expire.

Étape 6 : activer l’authentification IAM à la base de données

Les mots de passe statiques partagés entre plusieurs services restent une des causes les plus fréquentes de fuite de données. L’authentification IAM pour bases de données remplace le mot de passe par un jeton temporaire généré via les identifiants IAM, valable 15 minutes. Cette fonctionnalité varie selon le moteur et la région, vérifiez sa disponibilité pour votre configuration précise dans la grille officielle des fonctionnalités RDS par moteur.

-- Cote SQL : creer un utilisateur mappe a un role IAM
CREATE USER app_iam_user;
GRANT rds_iam TO app_iam_user;
# Cote application : generer le jeton d'authentification
aws rds generate-db-auth-token \
  --hostname rds-prod-pg17.xxxxxxxx.eu-west-3.rds.amazonaws.com \
  --port 5432 \
  --username app_iam_user \
  --region eu-west-3

Ce jeton remplace le mot de passe dans la chaîne de connexion. Combinez cette approche avec une politique IAM restreignant rds-db:connect à une seule ressource précise, pour éviter qu’un rôle applicatif compromis ne puisse se connecter à toutes les bases du compte.

L’authentification IAM convient particulièrement bien aux charges applicatives qui tournent déjà sur des rôles IAM natifs, comme des fonctions Lambda ou des tâches ECS. Elle supprime purement et simplement la question de la rotation manuelle du mot de passe applicatif, puisque le jeton expire de lui-même au bout de 15 minutes et se régénère à chaque nouvelle connexion. La limite pratique à connaître : le nombre de connexions par seconde authentifiées via IAM reste plafonné par AWS, un détail qui compte pour les applications à très fort débit de connexions courtes. Dans ce cas précis, un pool de connexions applicatif qui réutilise les sessions ouvertes reste préférable à une authentification IAM systématique à chaque requête.

Étape 7 : centraliser les secrets avec AWS Secrets Manager

Pour les comptes de service qui ne peuvent pas utiliser l’authentification IAM (outils tiers, scripts de migration, connecteurs BI), stockez les identifiants dans AWS Secrets Manager plutôt que dans un fichier de configuration ou une variable d’environnement en clair. Secrets Manager gère nativement la rotation automatique pour RDS via une fonction Lambda fournie par AWS.

aws secretsmanager create-secret \
  --name rds-prod-pg17/app-service \
  --description "Identifiants service applicatif RDS" \
  --secret-string '{"username":"app_service","password":"CHANGE_ME"}'

aws secretsmanager rotate-secret \
  --secret-id rds-prod-pg17/app-service \
  --rotation-rules AutomaticallyAfterDays=30

Fixez une rotation à 30 jours maximum pour les comptes de service sensibles, et activez les alertes CloudTrail sur les appels GetSecretValue pour détecter toute récupération anormale d’un secret en dehors des heures habituelles de déploiement.

Évitez de dupliquer le même secret dans plusieurs espaces de noms applicatifs juste par confort d’accès. Chaque duplication multiplie les points où une fuite peut survenir et complique la révocation en cas d’incident, puisqu’il faut alors retrouver toutes les copies avant de considérer l’identifiant comme réellement neutralisé. Préférez une référence centralisée au secret, consommée au démarrage de l’application, plutôt qu’une valeur recopiée dans plusieurs fichiers de configuration qui finiront par diverger les uns des autres au fil du temps.

Étape 8 : configurer sauvegardes automatiques et snapshots chiffrés

Amazon RDS propose des sauvegardes automatiques quotidiennes avec une période de rétention réglable entre 1 et 35 jours, la valeur par défaut étant fixée à 7 jours selon la documentation AWS. Ces sauvegardes permettent une restauration à un instant précis (point-in-time recovery), utile en cas d’erreur applicative ou de suppression accidentelle de données, pas seulement en cas d’attaque.

aws rds modify-db-instance \
  --db-instance-identifier rds-prod-pg17 \
  --backup-retention-period 30 \
  --preferred-backup-window "02:00-03:00" \
  --apply-immediately

Pour les environnements soumis à des exigences de conformité strictes, le guide FedRAMP publié par AWS recommande une rétention portée jusqu’à 35 jours, combinée à une réplication des snapshots vers une seconde région pour couvrir un scénario de sinistre régional. Chaque snapshot hérite automatiquement du chiffrement de l’instance source : il est impossible de produire un snapshot non chiffré à partir d’une base chiffrée, ce qui simplifie l’application cohérente de la politique de chiffrement.

Étape 9 : activer l’audit et la journalisation

Sans journalisation, un incident de sécurité devient presque impossible à reconstituer après coup. Activez l’export des journaux RDS vers CloudWatch Logs pour conserver une trace des connexions, des requêtes lentes et des erreurs. Activez également Performance Insights pour visualiser la charge et repérer des requêtes suspectes générant un volume anormal d’appels.

aws rds modify-db-instance \
  --db-instance-identifier rds-prod-pg17 \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","upgrade"]}' \
  --enable-performance-insights \
  --performance-insights-retention-period 7 \
  --apply-immediately

Couplez cette journalisation applicative à AWS CloudTrail, qui enregistre tous les appels d’API effectués sur votre instance RDS : création, modification, suppression, changement de security group. CloudTrail répond à la question “qui a fait quoi et quand” au niveau du compte AWS, tandis que les logs RDS répondent à la question “que s’est-il passé dans la base elle-même”.

Exportez ces journaux vers un compte de logs centralisé, séparé du compte de production, pour qu’un attaquant qui obtiendrait un accès administrateur sur le compte applicatif ne puisse pas également effacer ses traces. Cette séparation des comptes de logs, courante dans les architectures multi-comptes AWS Organizations, transforme la journalisation en véritable preuve légale exploitable après incident, au lieu d’un simple historique consultable uniquement par celui qui pourrait justement vouloir le faire disparaître.

Étape 10 : appliquer le principe du moindre privilège avec IAM

Un rôle IAM qui possède rds:* sur l’ensemble du compte peut supprimer n’importe quelle base de production en une seule commande. Découpez les permissions par environnement et par action : un pipeline CI/CD n’a besoin que de rds:ModifyDBInstance et rds:CreateDBSnapshot sur les ressources taguées “staging”, jamais de rds:DeleteDBInstance sur la production.

  • Séparez les politiques par environnement grâce aux conditions de tag (aws:ResourceTag)
  • Interdisez explicitement rds:DeleteDBInstance et rds:DeleteDBCluster hors d’un rôle d’administration dédié avec approbation manuelle
  • Activez la protection contre la suppression (–deletion-protection) sur toutes les instances de production
  • Exigez le MFA pour toute action IAM sensible via une condition aws:MultiFactorAuthPresent

Étape 11 : surveiller en continu avec CloudWatch et AWS Config

La configuration sécurisée d’une instance RDS ne suffit pas si elle dérive silencieusement au fil des modifications manuelles. AWS Config propose des règles managées qui vérifient en continu qu’une instance reste chiffrée, que le Multi-AZ reste actif, et qu’aucune instance ne redevient accessible publiquement. Ces règles sont listées par région dans la documentation officielle des règles managées AWS Config.

Côté CloudWatch, créez des alarmes sur les métriques CPUUtilization, FreeStorageSpace et DatabaseConnections. Un pic soudain de connexions simultanées peut signaler une attaque par force brute sur les identifiants, tandis qu’une chute brutale de l’espace disque libre peut trahir une exfiltration massive de données en cours via un export non autorisé.

Étape 12 : tester le failover Multi-AZ et le plan de reprise

Une configuration Multi-AZ jamais testée en conditions réelles reste une hypothèse, pas une garantie. Déclenchez un basculement manuel en environnement de pré-production au moins une fois par trimestre pour valider que votre application encaisse la coupure (généralement 60 à 120 secondes) sans erreur fatale côté utilisateur.

aws rds reboot-db-instance \
  --db-instance-identifier rds-prod-pg17 \
  --force-failover

Documentez le temps de reprise observé et comparez-le à votre objectif de temps de récupération (RTO) contractuel. Si l’écart est trop important, le problème vient rarement de RDS lui-même mais du comportement de reconnexion de votre application, souvent mal géré côté pool de connexions.

Profitez de ce test trimestriel pour vérifier aussi le comportement de vos alertes CloudWatch pendant la coupure. Un basculement Multi-AZ génère normalement une ou plusieurs alarmes transitoires, qui doivent se résorber d’elles-mêmes dans les minutes suivant le retour à la normale. Si une alarme reste bloquée en état d’échec bien après la fin du basculement, cela indique souvent une mauvaise configuration du endpoint applicatif, qui continue de pointer vers l’ancienne instance de secours au lieu de suivre automatiquement le nouveau primaire.

Étape 13 : industrialiser le déploiement avec Terraform

Pour éviter que chaque configuration manuelle ne finisse par diverger entre les environnements, transformez l’ensemble des étapes précédentes en code Terraform versionné. Voici un exemple condensé reprenant l’isolation réseau, le chiffrement, le Multi-AZ, la rétention des sauvegardes et la protection contre la suppression dans une seule ressource.

resource "aws_db_instance" "rds_prod" {
  identifier              = "rds-prod-pg17"
  engine                  = "postgres"
  engine_version          = "17.4"
  instance_class          = "db.t4g.micro"
  allocated_storage       = 50
  storage_encrypted       = true
  kms_key_id              = aws_kms_key.rds_prod.arn
  multi_az                = true
  publicly_accessible     = false
  deletion_protection     = true
  backup_retention_period = 30
  db_subnet_group_name    = aws_db_subnet_group.rds_prod.name
  vpc_security_group_ids  = [aws_security_group.rds_prod.id]
  manage_master_user_password = true

  enabled_cloudwatch_logs_exports = ["postgresql", "upgrade"]

  parameter_group_name = aws_db_parameter_group.force_ssl.name

  tags = {
    Environnement = "production"
    GereParTerraform = "true"
  }
}

Lancez terraform plan avant tout terraform apply pour vérifier qu’aucune modification non désirée ne s’applique à une ressource existante, en particulier sur storage_encrypted qui ne peut pas être modifié sans recréer l’instance. Ce projet complet, une fois versionné dans un dépôt Git avec une revue obligatoire des changements, devient la source de vérité unique pour toutes vos instances RDS.

Ajoutez un verrou d’état distant (backend S3 chiffré avec verrouillage DynamoDB, ou équivalent géré) pour éviter que deux membres de l’équipe n’appliquent des changements concurrents sur le même fichier d’état Terraform. Intégrez enfin un contrôle automatisé dans votre pipeline CI, par exemple avec tfsec ou Checkov, qui bloque la fusion d’une pull request si une ressource aws_db_instance est déclarée sans storage_encrypted ou avec publicly_accessible à true. Ce garde-fou automatisé évite de dépendre uniquement de la vigilance humaine lors des revues de code, qui finit toujours par laisser passer une exception un jour de rush.

Les erreurs les plus fréquentes à éviter

  • Laisser publicly_accessible à true “pour le debug” : cette exception temporaire dure en moyenne bien plus longtemps que prévu et reste la cause numéro un des bases RDS trouvées exposées par les scanners automatisés.
  • Oublier que storage_encrypted ne se modifie pas a posteriori : la migration vers une instance chiffrée exige un cycle complet snapshot/copie/restauration, pas un simple paramètre à basculer.
  • Ignorer la fin du support standard d’une version majeure : rester sur une version PostgreSQL ancienne au-delà de la fenêtre de support standard bascule automatiquement l’instance en Extended Support, facturé plus cher et synonyme de correctifs de sécurité retardés par rapport à la dernière version majeure.
  • Partager un seul security group entre plusieurs applications : un service compromis donne alors un accès réseau direct à toutes les autres applications qui partagent ce même groupe.
  • Ne jamais tester le failover Multi-AZ : une configuration non testée masque souvent un bug de reconnexion côté application qui ne se révèle que lors d’un vrai incident en production.
  • Stocker le mot de passe maître en clair dans un script de déploiement : utilisez manage_master_user_password ou Secrets Manager dès le premier jour, pas après un audit de sécurité qui le signale.

Dépannage : résoudre les problèmes courants

La connexion échoue avec “timeout expired” : vérifiez d’abord le security group (règle d’entrée manquante sur le port du moteur), puis la table de routage du sous-réseau, puis les ACL réseau (NACL) qui peuvent bloquer silencieusement un flux pourtant autorisé par le security group.

psql refuse la connexion avec “SSL error: certificate verify failed” : le bundle de certificats racine téléchargé ne correspond pas à la région de l’instance, ou il a expiré après une rotation programmée par AWS. Retéléchargez le bundle correspondant exactement à votre région.

Le jeton d’authentification IAM est rejeté : vérifiez que l’horloge du serveur qui génère le jeton n’est pas désynchronisée de plus de quelques secondes, et que la politique IAM autorise bien rds-db:connect sur l’ARN exact de l’utilisateur de base de données, format sensible à la casse.

Le basculement Multi-AZ prend plus de deux minutes : un volume de transactions non validées élevé au moment de la coupure allonge le temps de récupération, car l’instance de secours doit rejouer les journaux avant d’accepter de nouvelles connexions. Réduisez la taille des transactions longues en production.

“storage_encrypted” ne peut pas être modifié dans Terraform : Terraform refuse ce changement en place par conception, car AWS ne le permet pas non plus. Passez par un snapshot chiffré puis une nouvelle ressource aws_db_instance pointant vers ce snapshot.

Les logs PostgreSQL n’apparaissent pas dans CloudWatch : vérifiez que le groupe de paramètres associé active bien log_statement et log_min_duration_statement, en plus de l’export CloudWatch activé côté instance. Les deux réglages sont indépendants.

La rotation automatique du secret échoue dans Secrets Manager : la fonction Lambda de rotation doit résider dans le même VPC que l’instance RDS, ou disposer d’une route réseau vers elle. Vérifiez les logs CloudWatch de la fonction Lambda pour voir l’erreur exacte de connexion.

Une règle AWS Config signale une instance non conforme après coup : les règles managées s’évaluent périodiquement, pas en temps réel. Un délai de quelques minutes à une heure entre une modification non conforme et sa détection reste normal.

L’application ne se reconnecte pas après un failover : la plupart des pools de connexions ne détectent pas automatiquement un changement d’adresse IP derrière un nom DNS stable. Réduisez le TTL de résolution DNS côté application et validez que le driver utilisé respecte bien ce TTL au lieu de mettre en cache l’adresse indéfiniment.

Astuces avancées et coûts réels à anticiper

Au-delà des 13 étapes de base, quelques réglages supplémentaires font la différence sur une instance qui tourne depuis plusieurs mois. Activez les réplicas en lecture chiffrés pour décharger les requêtes analytiques du primaire, en vous assurant que le réplica hérite bien de la même politique de security group que l’instance source. Mettez en place une politique de rotation automatique du mot de passe maître tous les 90 jours via Secrets Manager, même en l’absence d’incident, pour limiter la fenêtre d’exploitation d’un identifiant qui aurait fuité sans que vous le sachiez encore.

Pensez également à activer la suppression automatique des snapshots manuels obsolètes via une règle de cycle de vie, pour éviter une accumulation de copies de données sensibles oubliées dans un coin du compte AWS, chacune représentant une surface d’attaque supplémentaire si elle venait à être partagée par erreur avec un autre compte.

Sur le plan financier, le contrôle plan standard d’une instance RDS reste facturé à l’heure selon la classe d’instance et la région choisie, sans frais fixe de contrôle séparé comme sur certains services Kubernetes managés. Le tableau suivant résume les ordres de grandeur à anticiper pour une instance PostgreSQL de petite taille en configuration Single-AZ et Multi-AZ, des chiffres indicatifs à reconfirmer via l’AWS Pricing Calculator pour votre région exacte au moment de la mise en production.

Poste de coûtConfiguration minimale sécuriséeConfiguration production Multi-AZRemarque
Instance computedb.t4g.micro, Single-AZdb.r6g.large, Multi-AZLe Multi-AZ facture environ deux fois le coût compute d’une instance équivalente en Single-AZ
Stockage chiffré50 Go gp3100 Go gp3 ou plusLe chiffrement KMS n’ajoute pas de surcoût de stockage direct
SauvegardesRétention 7 jours (valeur par défaut)Rétention jusqu’à 35 jours maximumLe stockage de sauvegarde au-delà du volume alloué est facturé séparément
Réplication secretsSecrets Manager, un secretSecrets Manager avec rotation automatiséeFacturation par secret stocké et par appel d’API au-delà du palier gratuit
Transfert de donnéesInterne au VPC, généralement gratuitRéplication inter-région pour le PRALe transfert sortant inter-région reste le poste le plus variable selon les volumes

Gardez à l’esprit que le coût d’une base mal sécurisée ne se limite jamais au prix de l’instance. Une fuite de données déclenche des obligations de notification sous 72 heures auprès de la CNIL en France, des coûts de remédiation, et un risque réputationnel qui dépasse largement l’écart de prix entre une configuration Single-AZ non chiffrée et une configuration Multi-AZ chiffrée correctement dimensionnée dès le départ.

Un dernier réflexe à prendre avant de clore ce tutoriel : programmez une revue de sécurité RDS au moins deux fois par an, pas seulement lors de la mise en service initiale. Les versions mineures évoluent, de nouveaux correctifs sortent sur le programme Extended Support, et une règle de security group ajoutée six mois plus tôt pour un besoin ponctuel finit souvent par être oubliée alors qu’elle reste active. Cette revue périodique coûte quelques heures d’ingénierie et évite très largement les incidents les plus coûteux à traiter en urgence.

Questions fréquentes sur la sécurisation d’Amazon RDS

Peut-on activer le chiffrement au repos sur une instance RDS déjà en production sans la recréer ?
Non. AWS ne permet pas de basculer storage_encrypted sur une instance existante. La seule méthode consiste à créer un snapshot, copier ce snapshot en version chiffrée, puis restaurer une nouvelle instance à partir de cette copie chiffrée.

Le Multi-AZ remplace-t-il les sauvegardes automatiques ?
Non, ce sont deux mécanismes complémentaires. Le Multi-AZ protège contre une panne d’infrastructure en basculant vers une instance de secours synchronisée, tandis que les sauvegardes et snapshots protègent contre une erreur humaine ou applicative qui corromprait les données elles-mêmes sur les deux instances à la fois.

L’authentification IAM est-elle disponible pour tous les moteurs RDS ?
Sa disponibilité varie selon le moteur et la région. Vérifiez systématiquement la grille officielle des fonctionnalités par moteur et région avant de concevoir votre architecture d’authentification autour de ce mécanisme.

Quelle rétention de sauvegarde choisir pour une base soumise au RGPD ?
La plage technique autorisée va de 1 à 35 jours. Au-delà de cette contrainte technique, la durée doit surtout refléter votre politique de conservation des données documentée, en cohérence avec les durées déclarées à vos utilisateurs et votre registre de traitement.

Faut-il forcer TLS même pour du trafic interne au VPC ?
Oui. Un VPC compromis par un mouvement latéral reste un scénario documenté dans de nombreux incidents. Chiffrer le trafic interne limite l’impact d’une telle intrusion au lieu de l’accepter comme un risque résiduel non traité.

Comment savoir si mon instance RDS est concernée par une CVE récente ?
Consultez les notes de version Extended Support publiées par AWS pour votre moteur et comparez votre version mineure actuelle à la version corrigée. Les correctifs de sécurité backportés par AWS n’apparaissent pas toujours dans les annonces générales, seulement dans ces notes de version détaillées.

Terraform peut-il gérer la rotation du mot de passe maître ?
Terraform peut activer manage_master_user_password, qui délègue ensuite la rotation effective à Secrets Manager et AWS directement, en dehors du cycle de vie Terraform. Évitez de stocker un mot de passe statique dans une variable Terraform, même chiffrée dans un state distant.