Amazon DynamoDB assure une performance constante à faible latence et une scalabilité extrême, mais rien de tout cela n’a d’importance si vous ne pouvez pas prouver qui a accédé à vos données, quand ils l’ont fait, et ce qui a exactement été modifié. Comme décrit dans la documentation officielle du service sur https://aws.amazon.com/dynamodb/, DynamoDB est conçu pour la rapidité et l’échelle, mais la visibilité et la traçabilité restent des responsabilités partagées par le client. Dans des secteurs réglementés tels que la finance, la santé et le gouvernement, la piste d’audit devient un élément obligatoire de la sécurité opérationnelle. Les découvertes récentes en matière de sécurité cloud, telles que le rapport AWS Security Maturity Report (https://d1.awsstatic.com/security-center/AWS_Security_Maturity_Model.pdf), soulignent le besoin croissant de surveillance continue et d’une responsabilité d’accès prouvable sur les charges de travail dans le cloud. Bien qu’AWS fournisse plusieurs composants natifs capables de capturer les accès liés à une identité, les modifications de configuration et les changements au niveau des éléments, DynamoDB ne dispose pas d’un sous-système d’audit intégré unique. Au lieu de cela, une piste d’audit complète doit être assemblée à partir des services AWS. Cet article explique comment fonctionne la piste d’audit de DynamoDB et comment DataSunrise propose un cadre d’audit unifié, prêt à la conformité, alimenté par ses capacités de Data Audit.

Qu’est-ce qu’une piste d’audit ?

Une piste d’audit est une narration chronologique décrivant comment les données ont été accédées, modifiées ou utilisées, tout en identifiant l’utilisateur, le rôle ou le service responsable de chaque action. Dans les systèmes de bases de données, la piste d’audit révèle qui a effectué des opérations spécifiques, quel type d’activité a eu lieu — que ce soit une lecture, une mise à jour, une suppression, un balayage ou un autre appel API — quand l’événement s’est produit, incluant le timestamp, la région et le contexte de session, d’où la requête est originaire, comme une adresse IP particulière, une source VPC ou une session de rôle assumé, et comment l’action a affecté le système, y compris les modifications au niveau des éléments, les variations de table ou les mises à jour structurelles.

Une piste d’audit complète soutient les enquêtes et analyses forensiques, fournit des preuves réglementaires pour des cadres comme le RGPD, HIPAA, PCI DSS et SOX, expose des activités internes qui pourraient autrement passer inaperçues et permet la détection de comportements irréguliers ou suspects. Elle aide également à confirmer l’intégrité des données en vérifiant la séquence et la légitimité des opérations. Une discussion plus large sur les fondamentaux des pistes d’audit est disponible dans la base de connaissances de DataSunrise à Audit Trails.

Dans le cas de DynamoDB, cette piste d’audit n’est pas générée par un unique outil. Au lieu de cela, elle est construite en combinant les journaux CloudTrail, DynamoDB Streams, les signaux CloudWatch et les données d’identité AWS IAM pour former une image unifiée de ce qui s’est produit dans le système — similaire aux stratégies multi-sources utilisées dans la surveillance d’activité de base de données traditionnelle (Database Activity Monitoring).

Comprendre la piste d’audit Amazon DynamoDB

Une piste d’audit DynamoDB représente la combinaison des sorties des mécanismes de journalisation natifs AWS qui fournissent collectivement une visibilité complète sur les schémas d’accès, les opérations sur les données et les changements administratifs. Parce que DynamoDB est serverless et flexible au niveau du schéma, la piste d’audit dépend fortement des services AWS connectés qui capturent l’identité, les métadonnées de requête et les changements au niveau des éléments. Ces sources combinées permettent de tracer les opérations sur le plan des données telles que PutItem ou Query, les actions sur le plan de contrôle comme la création de tables, les attributs d’identité, la séquence des événements et les anomalies comportementales à travers les charges de travail. Les organisations complètent souvent cela avec un historique de l’activité des données pour la rétention et l’investigation à long terme.

Services natifs formant la piste d’audit DynamoDB

DynamoDB ne génère pas de piste d’audit unifiée par lui-même, ainsi AWS s’appuie sur plusieurs systèmes de journalisation et de surveillance interconnectés pour fournir une visibilité complète. Chaque service apporte une couche différente de contexte, formant une image complète seulement lorsqu’ils sont combinés. Comprendre ces composants natifs est essentiel pour concevoir une stratégie d’audit fiable et de niveau forensique autour de DynamoDB, de manière similaire à l’explication par DataSunrise de l’audit structuré dans ses matériaux sur la découverte de données sensibles et la gouvernance des informations personnelles identifiables (PII) ici.

1. AWS CloudTrail — source principale d’audit sur le plan de contrôle

AWS CloudTrail journalise les opérations administratives et enregistre comment les identités interagissent avec DynamoDB. Il capture les événements liés à la création de tables, la suppression de tables, les modifications d’index, les actions de sauvegarde et de restauration, l’utilisation des clés de chiffrement et l’accès basé sur IAM. CloudTrail peut aussi capturer les opérations sur le plan des données telles que GetItem ou UpdateItem, mais cela nécessite l’activation explicite des Évènements de Données (Data Events). Sans ceux-ci, les appels API DynamoDB ne sont pas entièrement visibles, ce qui explique pourquoi CloudTrail constitue la base de la piste d’audit mais doit être configuré correctement pour fonctionner comme une source forensique complète.

2. DynamoDB Streams — historique des changements au niveau des éléments

DynamoDB Streams enregistrent les changements détaillés sur les éléments chaque fois qu’ils sont créés, mis à jour ou supprimés. Les Streams peuvent inclure l’image précédente et la nouvelle image de l’élément, ce qui permet aux auditeurs de reconstruire exactement ce qui a changé lors de chaque opération d’écriture. Cette capacité est essentielle pour enquêter sur des modifications inattendues, valider des preuves réglementaires, et conserver un contexte détaillé avant/après. Cependant, les Streams sont éphémères et nécessitent un stockage en aval pour une conservation à long terme des audits.

• Les Streams conservent l’ordre des événements par clé de partition, permettant une reconstruction chronologique.
• Chaque enregistrement de stream contient des métadonnées telles que des numéros de séquence et des identifiants de source d’événement.
• Les Streams s’intègrent nativement avec AWS Lambda pour un traitement automatisé ou un transfert.
• La rétention est limitée (24 heures par défaut, jusqu’à 7 jours), rendant obligatoire l’archivage externe pour usage audit.

3. Amazon CloudWatch — signaux de comportement et de performance

CloudWatch ajoute un contexte comportemental à la piste d’audit. Il suit des métriques telles que la limitation du débit (throttling), les taux d’erreur, les anomalies de volume de requêtes et les schémas de latence. Bien que CloudWatch ne stocke pas indépendamment les enregistrements d’audit, il aide à identifier des tendances ou interactions suspectes qui peuvent nécessiter une analyse approfondie. Les alertes et filtres de métriques peuvent aussi déclencher des réponses automatisées quand un comportement anormal apparaît.

• Les métriques CloudWatch exposent des schémas opérationnels en temps réel (capacité lecture/écriture, limitations).
• Les logs CloudWatch peuvent recevoir des Vended Logs ou des logs applicatifs personnalisés relatifs à l’usage de DynamoDB.
• Les filtres de métriques aident à identifier des modèles d’appels API inhabituels ou des pics d’activité.
• Les alarmes CloudWatch s’intègrent avec SNS, Lambda ou EventBridge pour des notifications automatisées.

4. AWS IAM — contexte d’autorisation

Les journaux IAM et les métadonnées d’identité fournissent le chaînon manquant d’identité dans la piste d’audit DynamoDB. Ces enregistrements révèlent quel utilisateur ou service a assumé un rôle, quelles politiques ont été évaluées, si la requête a été autorisée ou refusée, et quel fournisseur d’identité externe (SAML ou OIDC) a initié la session. Les signaux IAM aident à relier l’activité au principal responsable.

• IAM s’intègre avec CloudTrail pour fournir les ARNs des principaux dans chaque événement d’audit.
• Les détails des sessions STS montrent les identifiants temporaires, les tags de session et les exigences MFA.
• Les logs d’évaluation des politiques IAM identifient quelles permissions ont été utilisées ou bloquées.
• Les conditions basées sur l’identité (restrictions IP, tags de session, règles temporelles) aident à tracer l’intention d’accès.

Comment DataSunrise améliore les pistes d’audit DynamoDB

DataSunrise unifie CloudTrail, DynamoDB Streams, les logs CloudWatch et les métadonnées d’identité en un système d’audit consolidé. Il transforme les logs bruts AWS en pistes d’audit structurées alignées sur la conformité avec des analyses basées sur le machine learning, des alertes en temps réel et le masquage des valeurs sensibles. Plutôt que de dépendre de multiples consoles et flux de logs AWS, DataSunrise fournit une vue centralisée et multiplateforme de toute l’activité DynamoDB — une capacité alignée avec ses familles de produits principales Data Security et Compliance.

Surveillance unifiée de l’activité

DataSunrise corrèle les opérations sur le plan de contrôle, l’activité API sur le plan des données, les changements au niveau des éléments, les attributs d’identité et les anomalies comportementales en un seul enregistrement d’audit. Cela produit une vue complète et ordonnée dans le temps de la façon dont les données ont été accédées et modifiées, plutôt que de fragmenter l’information à travers des sources AWS séparées.

• Il agrège les événements de CloudTrail, Streams, CloudWatch et IAM en une chronologie unifiée.
• Il normalise les formats hétérogènes des logs AWS en un schéma d’audit cohérent.
• Il corrèle les identités, métadonnées de requêtes et deltas au niveau des objets pour une visibilité approfondie.
• Il met en évidence les anomalies via une analyse comportementale combinée sur toutes les sources de logs, en utilisant des techniques similaires à l’analyse du comportement utilisateur.

Règles d’audit granulaires pour DynamoDB

Les administrateurs peuvent créer des règles d’audit très ciblées. Ces règles peuvent enregistrer les opérations sur des tables spécifiques, suivre les mises à jour ou suppressions sur des jeux de données sensibles, surveiller les requêtes Query ou Scan effectuées par des identités inconnues, détecter les pics d’utilisation API, et appliquer le masquage avant l’écriture des logs. Cela apporte un contrôle fin similaire aux sous-systèmes d’audit traditionnels en entreprise, soutenus par le moteur de masquage dynamique des données de DataSunrise.

Alignement sur la conformité et rapports automatisés

DataSunrise associe automatiquement les événements d’audit DynamoDB aux cadres réglementaires tels que RGPD, HIPAA, PCI DSS, SOX, ISO 27001 et SOC 2. Il génère des rapports de conformité centralisés, détecte les dérives de configuration et effectue une validation continue. Ces capacités complètent ses fonctionnalités avancées basées sur LLM et ML pour la sécurité et supportent plusieurs modes de déploiement.

Impact métier

Conclusion

Une piste d’audit DynamoDB n’est pas produite par un unique outil AWS. Elle résulte plutôt de la collaboration des journaux CloudTrail, DynamoDB Streams, CloudWatch et IAM. AWS fournit les événements bruts, mais DataSunrise les transforme en un système d’audit cohérent, prêt à la conformité, avec masquage dynamique, analyses comportementales, visibilité unifiée et rapports réglementaires.