Aller au contenu

AWS Mis à jour le 2026-07-04

Authentification IAM des bases RDS : la configuration qui fonctionne, et quand les mots de passe restent plus simples

Comment configurer l'authentification IAM des bases RDS de bout en bout — indicateur d'instance, utilisateur de base, politique IAM, jeton — plus les cas honnêtes où un mot de passe dans Secrets Manager reste le meilleur outil.

L’authentification IAM des bases RDS remplace le mot de passe de base de données par un jeton signé de courte durée : le rôle IAM de votre application génère un jeton valide 15 minutes et le présente comme mot de passe sur TLS. Elle élimine complètement les identifiants de base stockés, un vrai gain de sécurité — mais elle exige trois pièces câblées correctement (indicateur d’instance, utilisateur de base, politique IAM), elle ne fonctionne que sur MySQL, MariaDB et PostgreSQL, et pour les patrons de connexions à fort roulement ou les outils tiers, un mot de passe avec rotation dans Secrets Manager reste la réponse plus simple et meilleure.

Ce qui se passe

Avec l’authentification IAM activée, RDS accepte deux types de connexions côte à côte : les utilisateurs à mot de passe normaux, et les utilisateurs marqués pour IAM. Pour un utilisateur marqué, le « mot de passe » est un jeton produit en signant une requête avec des identifiants AWS — la même machinerie SigV4 que n’importe quel appel d’API. RDS valide la signature, vérifie que l’identité IAM de l’appelant a le droit de se connecter comme cet utilisateur de base, et exige que la connexion utilise SSL/TLS.

Les trois pièces :

  1. L’indicateur sur l’instance ou le cluster — l’authentification IAM est désactivée par défaut et s’active par instance/cluster.
  2. L’utilisateur de base de données — sur PostgreSQL, un rôle avec rds_iam accordé; sur MySQL/MariaDB, un utilisateur créé avec le AWSAuthenticationPlugin. L’utilisateur n’a pas de mot de passe utilisable; le plugin/rôle est la barrière.
  3. La politique IAM — rds-db:connect sur un ARN de ressource qui nomme le DbiResourceId de l’instance et le nom d’utilisateur de base. Notez que l’ARN utilise l’identifiant de ressource, pas le nom de l’instance — l’erreur de configuration la plus courante.

Deux vérités opérationnelles à connaître d’avance. La durée de vie de 15 minutes du jeton s’applique à l’établissement de la connexion, pas à la connexion elle-même — une session ouverte reste ouverte. Et les recommandations AWS plafonnent le patron à environ 200 nouvelles connexions authentifiées IAM par seconde; la génération et la validation du jeton ajoutent un coût par connexion, donc les applications qui roulent leurs connexions ont besoin d’un pool devant — c’est exactement là que RDS Proxy se marie bien, puisque le proxy peut authentifier les clients via IAM tout en gardant des connexions chaudes vers la base. Les détails par moteur vivent dans la documentation RDS sur https://docs.aws.amazon.com/rds/.

Quoi vérifier en premier

  • Moteur et version — MySQL, MariaDB ou PostgreSQL seulement; Oracle et SQL Server sont exclus.
  • Si l’indicateur est déjà activé — IAMDatabaseAuthenticationEnabled sur l’instance/cluster.
  • Taux de roulement des connexions — des centaines de nouvelles connexions par seconde sans pool : arrêtez et ajoutez d’abord un pool.
  • Posture TLS — l’authentification IAM exige SSL; les clients doivent transporter le paquet de CA RDS.
  • Qui se connecte — les rôles applicatifs sont un ajustement propre; les humains et les outils BI tiers sont là où la friction commence.

Comment vérifier

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[IAMDatabaseAuthenticationEnabled,DbiResourceId,Engine]'

Générez un jeton et testez une connexion (PostgreSQL montré) :

TOKEN=$(aws rds generate-db-auth-token \
  --hostname prod-db.abc123xyz.ca-central-1.rds.amazonaws.com \
  --port 5432 --username app_user --region ca-central-1)

PGPASSWORD="$TOKEN" psql \
  "host=prod-db.abc123xyz.ca-central-1.rds.amazonaws.com port=5432 dbname=app user=app_user sslmode=verify-full sslrootcert=global-bundle.pem"

Une connexion rejetée avec PAM authentication failed ou password authentication failed signifie presque toujours que l’ARN de la politique IAM ou le rôle côté base est incorrect, pas le jeton. Dans la console, l’indicateur vit sous RDS > Databases > (instance) > Configuration, et les tentatives de connexion échouées apparaissent dans le journal d’erreurs du moteur sous Logs & events.

La marche à suivre

  1. Activez l’indicateur. aws rds modify-db-instance --db-instance-identifier prod-db --enable-iam-database-authentication --apply-immediately (pour Aurora, modify-db-cluster). Cela ne redémarre pas l’instance sur les moteurs récents, mais confirmez dans les modifications en attente avant de le tenir pour acquis.

  2. Créez l’utilisateur de base. PostgreSQL : CREATE USER app_user LOGIN; GRANT rds_iam TO app_user;. MySQL : CREATE USER 'app_user'@'%' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';. N’accordez que les privilèges de schéma dont l’application a besoin.

  3. Écrivez la politique IAM avec l’identifiant de ressource.

    {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "rds-db:connect",
    "Resource": "arn:aws:rds-db:ca-central-1:123456789012:dbuser:db-ABCDEFGHIJKL123/app_user"
  }]
}

    Attachez-la au rôle de l’application — le rôle de tâche ECS, le rôle d’exécution Lambda ou le profil d’instance EC2.

  4. Câblez la génération de jeton dans l’application. La plupart des SDK AWS exposent un générateur de jeton; traitez le jeton comme le mot de passe et régénérez-le à chaque nouvelle connexion, car les pools qui cachent un mot de passe échoueront aux reconnexions après 15 minutes.

  5. Imposez TLS avec vérification de certificat. Livrez le paquet de CA RDS avec l’application et utilisez sslmode=verify-full (PostgreSQL) ou les indicateurs MySQL équivalents — l’authentification IAM sans vérification de certificat garde le jeton mais abandonne la garantie sur l’endpoint.

  6. Retirez l’ancien chemin par mot de passe. Une fois la connexion IAM prouvée, retirez le mot de passe de Secrets Manager ou faites-en un identifiant réservé aux urgences, avec une alarme sur son utilisation.

Quand c’est la mauvaise approche

Les outils tiers qui ne savent que stocker un mot de passe statique — tableaux de bord BI, ETL hérités, certains outils de migration — vous combattent à chaque étape. Les charges à très fort roulement de connexions sans couche de pool frapperont le coût de génération de jetons et la limite indicative d’environ 200 connexions par seconde. L’accès inter-comptes et humain peut fonctionner mais multiplie la complexité IAM. Dans tous ces cas, un mot de passe fort dans Secrets Manager avec rotation automatique livre l’essentiel de l’hygiène sans la friction d’intégration — la décision Secrets Manager vs Parameter Store couvre où cet identifiant devrait vivre. Mélanger les modèles est correct : IAM pour vos services, mots de passe avec rotation pour les outils.

Erreurs courantes

  • Utiliser le nom de l’instance au lieu du DbiResourceId dans l’ARN de la politique — la politique se valide, s’attache, et ne correspond silencieusement jamais.
  • Cacher le jeton dans un pool de connexions comme si c’était un mot de passe, puis échouer chaque reconnexion après la quinzième minute.
  • Sauter le paquet de CA et soit échouer la vérification TLS, soit la désactiver « temporairement » pour toujours.
  • Accorder rds-db:connect sur dbuser:*/*, ce qui autorise discrètement chaque principal IAM portant la politique à être n’importe quel utilisateur de base.

Prévention

  • Gardez la politique IAM, le script de création de l’utilisateur de base et la configuration applicative dans le même dépôt pour que les trois pièces ne dérivent pas.
  • Alarme sur les échecs d’authentification dans le journal d’erreurs de la base — c’est votre premier signal de bogues de jeton expiré.
  • Standardisez un patron par environnement : IAM pour les services maison, rotation Secrets Manager pour tout le reste.
  • Re-testez le chemin du jeton après les mises à niveau majeures du moteur et les rotations de CA; les deux touchent la couche TLS dont il dépend.

Bien fait, l’authentification IAM des bases élimine une classe entière d’incidents d’identifiants fuités pour vos propres services — mais ne l’imposez pas à des outils qui n’ont jamais été bâtis pour elle. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.