GuardDuty détecte désormais l’exfiltration et la destruction de données dans Aurora et RDS PostgreSQL
Le 8 octobre 2026, AWS étend GuardDuty RDS Protection au-delà des anomalies de connexion pour détecter l’exfiltration et la destruction de données dans Aurora PostgreSQL et RDS for PostgreSQL, via des baselines comportementales sans agent. Activez l’essai gratuit de 30 jours si vous tournez en PostgreSQL — mais sachez que MySQL reste hors du périmètre.
8 octobre 2026. AWS étend GuardDuty RDS Protection au-delà des anomalies de connexion. PostgreSQL. Seules Aurora PostgreSQL et RDS for PostgreSQL sont couvertes par la nouvelle détection. 30 jours. La durée de l’essai gratuit, par compte et par région. Pourquoi c’est important : l’exfiltration de base de données est le point aveugle classique de la défense cloud — elle ressemble à du trafic applicatif légitime — et AWS s’attaque enfin à ce signal, mais seulement pour un moteur de base.
Ce que détecte la nouvelle couche
Jusqu’ici, GuardDuty RDS Protection se limitait aux anomalies de connexion : tentatives de brute force, connexions depuis des emplacements inhabituels, comportements d’authentification suspects. La nouveauté, baptisée RDS Protection for data activity, ajoute la détection de l’exfiltration de données et de la destruction de données. Concrètement, GuardDuty surveille en continu les motifs de requêtes et signale une activité de lecture ou de suppression qui s’écarte de la normale.
Le mécanisme est une détection d’anomalies par machine learning combinée à de la threat intelligence intégrée. GuardDuty établit une baseline comportementale des requêtes normales de chaque base, puis alerte quand une activité s’en éloigne. C’est ce qui rend le signal exploitable : plutôt que de chercher une signature statique, la détection compare le comportement observé à ce que la base fait habituellement.
Le scénario visé est précis. AWS le décrit ainsi : les attaquants obtiennent des identifiants valides par hameçonnage, ingénierie sociale ou mauvaise configuration, puis leur activité malveillante « peut sembler impossible à distinguer du comportement applicatif légitime ». Une requête de lecture massive lancée par un compte compromis ressemble, sur le papier, à un rapport nocturne légitime. La baseline comportementale est précisément là pour repérer l’écart que les outils à signature manquent.
PostgreSQL uniquement, et sans agent
Deux propriétés opérationnelles comptent. D’abord, l’absence d’agent : la détection s’active « sans aucun agent, infrastructure supplémentaire ou modification de la configuration de la base ». C’est le même modèle que le reste de GuardDuty — la télémetrie est collectée côté service, pas injectée dans la base. Pour une équipe qui ne veut pas toucher à une base de production, c’est l’argument décisif.
Ensuite, l’activation est organisationnelle. Le service s’ajoute en add-on à RDS Protection existant, en un clic pour toute l’organisation depuis la console, ou par API, SDK, CLI ou CloudFormation. L’essai gratuit de 30 jours s’applique par compte et par région, ce qui permet de mesurer le taux de faux positifs avant de payer.
Mais la limite de périmètre est franche : seules Amazon Aurora PostgreSQL et Amazon RDS for PostgreSQL sont couvertes. MySQL, MariaDB, SQL Server, Oracle et les autres moteurs restent hors du champ. Si votre parc de bases est hétérogène — ce qui est la norme dans les comptes matures — cette détection ne couvre qu’une partie de la surface. C’est un choix assumé d’AWS, probablement lié à la difficulté d’instrumenter finement les requêtes sur chaque moteur, mais il faut l’intégrer au calcul : la protection ne vaut que pour vos instances PostgreSQL.
Comment les findings se présentent
Le résultat concret, c’est un finding GuardDuty, au même titre qu’un finding de connexion suspecte, mais portant sur l’activité de données. Chaque finding identifie l’instance RDS concernée, le type d’activité détectée — lecture anormale évocatrice d’exfiltration, ou opération destructrice évocatrice de destruction de données — et la sévérité associée. Le triage suit le même circuit que le reste de GuardDuty : EventBridge, Security Hub ou S3 pour l’export, puis vos automatisations existantes.
La distinction entre les deux familles de signaux a une conséquence pratique. Les findings de destruction — drops massifs, suppressions de tables, requêtes qui vident des données — sont francs et justifient une réponse immédiate, souvent une mise en quarantaine des identifiants concernés. Les findings d’exfiltration sont plus ambigus : une lecture volumineuse peut être un dump de sauvegarde légitime. C’est là que la baseline fait la différence, en comparant la requête à l’historique de l’instance plutôt qu’à un seuil absolu.
Il faut aussi calibrer le taux de faux positifs pendant l’essai gratuit. Une détection par anomalie sur des requêtes de base de données va, par construction, produire des alertes sur des pics légitimes — une migration, un rechargement d’entrepôt, un rapport de fin de mois. Mesurer ce bruit avant de généraliser l’activation est exactement ce que la période de 30 jours permet de faire.
Le contexte de marché éclaire aussi la valeur de l’annonce. Les attaques par ransomware et extorsion visant les bases de données cloud se sont multipliées en 2026, et l’exfiltration précède souvent le chiffrement — les attaquants volent d’abord, puis détruisent. Une détection native, intégrée au flux de findings existant, évite d’ajouter un outil tiers de surveillance de l’activité des bases (DSPM) pour couvrir ce scénario précis. En revanche, si vous avez besoin d’une traçabilité au niveau de chaque requête pour la conformité, les Database Activity Streams d’Aurora restent l’outil dédié : GuardDuty détecte, il n’archive pas la requête elle-même. Le déploiement se fait d’ailleurs progressivement, pas d’un bloc : activez d’abord sur un sous-ensemble d’instances hors production, observez les findings une à deux semaines, puis élargissez seulement ensuite.
La fenêtre d’apprentissage, votre angle mort
Le point le moins discuté, et le plus important pour l’usage réel, c’est le temps d’apprentissage. Une détection par baseline comportementale n’est fiable qu’une fois la baseline établie — c’est-à-dire après que GuardDuty a observé suffisamment de trafic normal. Pendant cette période initiale, la ligne de base est encore en construction, et une exfiltration lente peut passer sous le radar parce qu’elle n’a pas encore de « normal » auquel se comparer.
La conséquence est double. D’une part, il ne faut pas activer la détection et considérer le problème réglé le jour même : la valeur se construit sur plusieurs semaines d’observation. D’autre part, la détection d’exfiltration est par nature plus difficile que la détection d’intrusion — l’attaquant qui a déjà des identifiants valides ressemble, par définition, à un utilisateur légitime, et seul l’écart statistique le trahit. Un acteur patient qui exfiltre lentement, en dessous du seuil d’anomalie, restera difficile à capter, quel que soit l’outil.
Cela ne rend pas la fonction inutile — au contraire. La destruction de données (drops massifs, suppressions de tables, ransomware de base de données) est un signal beaucoup plus franc, et la couverture de ce scénario a une valeur immédiate. C’est sur l’exfiltration lente que les attentes doivent rester calibrées : la baseline aide, elle ne remplace pas le chiffrement, la rotation des identifiants et la journalisation des requêtes côté applicatif.
Verdict
Activez RDS Protection for data activity sans attendre si vous exploitez Aurora PostgreSQL ou RDS for PostgreSQL : le coût d’entrée est un essai gratuit de 30 jours, l’activation est sans agent et organisationnelle, et la détection de destruction de données apporte une valeur immédiate. Si votre parc est à dominante MySQL ou multi-moteurs, mesurez d’abord la part réellement couverte avant d’en faire un pilier de votre défense — la détection ne couvre que PostgreSQL. Dans tous les cas, ne traitez pas l’activation comme une clôture : la valeur de la baseline comportementale se construit sur plusieurs semaines d’observation, et l’exfiltration lente restera votre point aveugle résiduel, à combler par le chiffrement et la journalisation applicative.