Sécuriser les bases de données managées cloud

Une base managée réduit la charge d’exploitation du moteur, pas la responsabilité sur les données ni les chemins d’accès. RDS (Relational Database Service), Cloud SQL et leurs équivalents retirent des tâches pénibles, mais une exposition réseau initiale, un identifiant figé ou un instantané partagé suffisent à transformer ce confort en fuite complète.

→ Lire l’explication complète de la marmotte

Frontière de responsabilité d’une base managée

Le compromis central est net : le fournisseur opère le moteur, l’organisation conserve le contrôle des accès, des données et des décisions de configuration. Ce compromis est généralement favorable pour une charge métier classique, à condition de ne pas confondre exploitation déléguée et sécurité déléguée. Une base auto-hébergée reste justifiée lorsqu’il faut contrôler le système d’exploitation, les extensions du moteur, le matériel cryptographique ou le calendrier exact des correctifs. Dans les autres cas, opérer PostgreSQL ou MySQL à la main pour « garder la maîtrise » revient souvent à garder surtout les astreintes.

Le service managé applique les correctifs du système et du moteur selon le modèle du fournisseur, remplace certains nœuds défaillants, automatise les sauvegardes et chiffre généralement le stockage au repos. Le chiffrement repose sur une clé gérée par le fournisseur ou sur une clé cliente dans un KMS (Key Management Service). Ces garanties ne protègent ni une requête DROP TABLE exécutée avec un compte légitime, ni une extraction par l’application, ni un instantané rendu lisible publiquement.

Le chiffrement au repos protège le support physique, les disques retirés et certaines opérations internes du fournisseur. Il ne chiffre pas les résultats renvoyés à une application autorisée. Le présenter comme une protection contre l’exfiltration applicative est une erreur de catégorie, très populaire dans les présentations où un cadenas suffit à remplir une slide.

Avant de créer une instance, il faut disposer d’un compte cloud séparé par environnement, d’un réseau privé routable depuis les charges autorisées, d’un journal d’audit centralisé et d’une politique de clés. Les versions de moteur doivent être explicitement supportées par le fournisseur et par les bibliothèques applicatives. Une version majeure arrivée en fin de support ne devient pas fréquentable parce qu’elle est empaquetée dans un joli service managé.

Le contrôle des identités cloud relève de l’IAM cloud, mais l’identité IAM (Identity and Access Management) ne remplace pas automatiquement les rôles du moteur. Il faut administrer les deux plans : qui peut modifier l’instance, ses sauvegardes et ses règles réseau ; qui peut se connecter au serveur SQL (Structured Query Language), lire, écrire ou administrer un schéma.

Réseau privé, chiffrement en transit et identités applicatives

Une instance ne doit pas être accessible publiquement, sauf exception documentée où un client externe ne peut réellement pas passer par un réseau privé, un tunnel ou un proxy d’accès. « Accessible publiquement » ne signifie pas seulement que le moteur écoute une adresse : cela combine une adresse routable, une route, un pare-feu permissif et parfois une règle créée lors de l’assistant de déploiement. La valeur par défaut de l’interface n’est pas une politique de sécurité.

Limiter les sources à des groupes de sécurité, sous-réseaux ou identités réseau dédiés est préférable à une liste d’adresses IP (Internet Protocol) de postes humains. Une application doit joindre la base depuis un sous-réseau privé, sans passerelle Internet nécessaire vers le moteur. Les accès d’administration passent par un bastion contrôlé, une session d’administration du fournisseur ou un proxy authentifié. Exposer PostgreSQL sur Internet avec une liste d’IP « temporaire » est rarement temporaire. La poussière cosmique de l’infrastructure est faite de règles temporaires.

TLS (Transport Layer Security) doit être imposé côté serveur et vérifié côté client. Accepter n’importe quel certificat ou désactiver la vérification du nom d’hôte protège seulement contre la nostalgie des années 1990. La rotation du certificat serveur doit être testée : les clients qui pinent un certificat racine obsolète cessent de se connecter lors du basculement, tandis que ceux qui n’en vérifient aucun continuent avec beaucoup trop d’enthousiasme.

Les identifiants applicatifs doivent être distincts par application, environnement et fonction. Un compte partagé entre cinq services rend l’attribution d’une fuite impossible et la révocation destructrice. Les privilèges sont accordés au niveau minimal : compte de migration séparé du compte d’exécution, droits d’écriture séparés des droits de lecture, aucun rôle superutilisateur dans une chaîne de déploiement applicative.

L’authentification éphémère fondée sur l’identité cloud est préférable quand le moteur et le fournisseur la prennent correctement en charge. Elle réduit la durée de vie du secret, mais n’annule pas le besoin de contrôler les autorisations SQL. Lorsque des mots de passe restent nécessaires, leur stockage relève d’un gestionnaire de secrets, jamais d’une variable injectée en dur dans une image de conteneur. Les mécanismes voisins de gestion des clés sont détaillés dans cryptographie.

Instantanés de base de données et copies oubliées

L’instantané est la surface d’attaque la plus mal auditée des bases managées. Un snapshot contient une copie cohérente de la base à une date donnée. S’il est partagé publiquement, un tiers qui connaît ou énumère son identifiant peut le copier dans son propre compte et restaurer l’intégralité des données, sous réserve des contraintes du fournisseur et du chiffrement. La base active peut être parfaitement privée : la fuite est déjà partie par la sortie de secours.

Interdire tout partage public par une politique d’organisation est la mesure de base. Il faut aussi détecter les instantanés partagés avec des comptes externes, les snapshots manuels orphelins et les copies inter-régions. Une sauvegarde automatique rétentionnée puis supprimée avec l’instance ne présente pas la même persistance qu’un instantané manuel : le second survit souvent à la ressource et à son propriétaire opérationnel.

Le chiffrement d’un instantané ne suffit pas à régler le partage. Avec une clé gérée par le fournisseur, certaines plateformes limitent ou empêchent le partage selon le produit. Avec une clé cliente, le partage de l’instantané impose souvent le partage de la clé ou la création d’une copie chiffrée différemment. Accorder l’usage de cette clé à un compte externe revient à étendre le périmètre de confiance à ce compte. Une autorisation de déchiffrement est une autorisation de lecture potentielle, même si le ticket parle pudiquement de « transfert ».

Les sauvegardes doivent suivre une durée de conservation alignée sur le besoin de reprise, pas une conservation infinie « au cas où ». Vérifier régulièrement qu’une restauration fonctionne, que les données sensibles restent chiffrées et que les comptes applicatifs de production ne sont pas recréés aveuglément dans l’environnement de restauration. Restaurer une base réactive des données, pas le discernement.

Détection, rotation et reprise opérationnelle

Les journaux d’administration doivent couvrir la création, la modification réseau, les changements de chiffrement, les exports, les restaurations, les copies et les partages d’instantanés. Une alerte sur un partage public ou externe doit être immédiate. Auditer uniquement les connexions à la base active rate le chemin le plus rentable pour un attaquant : prendre une copie et travailler loin des alarmes.

Les journaux SQL doivent enregistrer les échecs d’authentification, les changements de privilèges et les commandes administratives, sans journaliser les valeurs sensibles ni les requêtes contenant des secrets. Les logs sont eux-mêmes une base de données gratuite, avec une rétention catastrophique par défaut si personne ne les regarde.

La rotation d’un mot de passe applicatif exige une période de chevauchement : créer un nouvel identifiant ou mot de passe, déployer les consommateurs, vérifier les connexions, puis révoquer l’ancien. Changer le secret dans le coffre avant le déploiement casse les applications ; le changer après une période de tolérance infinie ne le change jamais réellement. La rotation d’une clé de chiffrement au repos est distincte : elle protège les nouveaux objets selon le service, mais ne révoque aucune session ni aucun export déjà obtenu.

Le plan de reprise doit inclure une restauration dans un compte ou projet isolé, la rotation immédiate des identifiants restaurés, la vérification des règles réseau et la suppression des accès d’administration temporaires. Une restauration dans le même périmètre compromis fournit surtout une deuxième occasion de compromettre la même chose.

Exemple de contrôle d’instantanés AWS

L’exemple suivant liste les instantanés Amazon RDS partagés publiquement. Il requiert AWS CLI (Command Line Interface) version 2, des droits rds:DescribeDBSnapshots et un profil configuré. Le résultat vide est attendu ; un résultat non vide déclenche une investigation, pas une réunion sur la sémantique de « public ».

# Lister les snapshots manuels accessibles publiquement dans la région choisie.
aws rds describe-db-snapshots \
  --snapshot-type public \
  --region eu-west-3 \
  --query 'DBSnapshots[].{Identifiant:DBSnapshotIdentifier,Source:DBInstanceIdentifier,Date:SnapshotCreateTime}' \
  --output table

# Vérifier les attributs de partage d'un snapshot connu.
# La présence de "all" dans restore indique un partage public.
aws rds describe-db-snapshot-attributes \
  --db-snapshot-identifier production-snapshot-2026-01-15 \
  --region eu-west-3 \
  --query 'DBSnapshotAttributesResult.DBSnapshotAttributes'

Ce contrôle doit être exécuté dans chaque région et pour chaque compte, puis complété par les journaux d’événements. Une politique préventive est supérieure à la détection, mais les deux sont nécessaires : les permissions héritées, les exceptions et les interfaces graphiques ont une créativité que les schémas d’architecture ne consignent jamais.

🐝 Ce qui arrive si on s’en passe

Sans ces protections, une base exposée sur Internet offre son authentification à des essais répétés sans limite, car PostgreSQL et MySQL ne proposent pas nativement de verrouillage progressif comparable à celui d’un portail web. Un instantané partagé publiquement, une fois copié dans un compte tiers, ne se rappelle plus : supprimer le partage ou le snapshot source n’efface aucune copie déjà restaurée, et aucun journal du compte d’origine ne voit les requêtes exécutées sur cette copie. Les empreintes de mots de passe des utilisateurs deviennent attaquables hors ligne, sans limitation de tentatives. Les jetons d’API, clés de services tiers et identifiants de session stockés en table restent utilisables contre les systèmes de production tant qu’ils ne sont pas révoqués. La fuite dépasse donc la base : elle s’étend à tout ce que la base permet d’authentifier.

🦫 Explication de la marmotte 🍫

Une base de données managée est hébergée et entretenue par un fournisseur. Le fournisseur met à jour le logiciel, remplace certains éléments défaillants, crée des sauvegardes et chiffre généralement les données enregistrées sur ses disques. L’organisation choisit toutefois qui peut atteindre la base, avec quel compte et quelles actions chaque compte peut effectuer.

La première protection consiste à placer la base sur un réseau non accessible directement depuis Internet. Seules les applications prévues et les personnes autorisées peuvent établir une connexion. Cette connexion doit être chiffrée afin qu’une personne placée sur le trajet réseau ne puisse pas lire les échanges. Chaque application reçoit son propre compte avec le minimum de droits.

Les mots de passe et autres secrets doivent être conservés dans un système prévu pour cela, puis remplacés régulièrement. Le remplacement doit se faire dans un ordre précis : créer le nouveau secret, modifier les applications, contrôler leur fonctionnement, puis supprimer l’ancien. Sinon, les applications s’arrêtent ou l’ancien accès reste valide indéfiniment.

Les copies de sauvegarde demandent une surveillance particulière. Une copie peut contenir toute la base, y compris les données personnelles et les secrets métiers. Si elle est rendue publique ou partagée avec le mauvais compte, une autre personne peut la restaurer et lire son contenu. Les journaux doivent donc signaler toute création, copie, restauration ou modification de partage, et les essais de restauration doivent vérifier que la reprise fonctionne réellement.

Pages voisines

La citent

Sécuriser les bases de données managées cloud

Elle cite

: les deux pages se citent l’une l’autre.

Sécuriser les bases de données managées cloud

Sécuriser les bases de données managées cloud

Frontière de responsabilité d’une base managée

Réseau privé, chiffrement en transit et identités applicatives

Instantanés de base de données et copies oubliées

Détection, rotation et reprise opérationnelle

Exemple de contrôle d’instantanés AWS

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines