La question revient régulièrement lors de mes missions : “Est-ce qu’on a le droit de mettre nos données clients sur AWS ?” La réponse courte est oui — à condition de le faire correctement. La réponse longue, c’est cet article.

AWS est un sous-traitant au sens du RGPD. À ce titre, vous avez des obligations précises envers vos utilisateurs, et AWS a des obligations précises envers vous. Comprendre cette répartition est la première étape d’une conformité réelle.

Le modèle de responsabilité partagée, vu sous l’angle RGPD

AWS distingue deux zones de responsabilité :

La sécurité “du” cloud : les datacenters, l’infrastructure physique, les hyperviseurs, les services managés. C’est la responsabilité d’AWS.
La sécurité “dans” le cloud : vos données, vos configurations, vos accès, votre chiffrement. C’est votre responsabilité.

Du point de vue RGPD, vous êtes le responsable de traitement et AWS est votre sous-traitant. Cela signifie que vous devez vous assurer qu’AWS présente des garanties suffisantes — ce qui est formalisé dans le Data Processing Addendum (DPA) d’AWS, que vous pouvez accepter dans votre console AWS sous Account > Agreements.

Action immédiate si ce n’est pas fait : acceptez le DPA AWS. Sans ce document signé, votre utilisation d’AWS pour des données personnelles n’est pas conforme, quelles que soient vos autres précautions techniques.

Le choix de la région : rester en Europe

Le RGPD impose des règles strictes sur les transferts de données hors UE/EEA. Pour simplifier, hébergez vos données personnelles dans une région AWS européenne :

eu-west-3 (Paris) : idéal pour les entités françaises, données qui ne quittent jamais le territoire français
eu-west-1 (Irlande) : option valide, toujours en UE
eu-central-1 (Francfort) : alternative solide

Évitez d’activer des services AWS qui répliquent des données vers des régions américaines sans l’avoir vérifié. Certains services globaux d’AWS (CloudFront, Route 53, IAM) traitent des métadonnées aux États-Unis — ce n’est pas interdit, mais c’est à documenter dans votre registre des traitements.

Point de vigilance : si vous utilisez des services managés AWS (Rekognition, Comprehend, Bedrock…) pour traiter des données personnelles, vérifiez la disponibilité régionale et les conditions d’utilisation spécifiques à ces services.

Le chiffrement : nécessaire mais pas suffisant seul

Le chiffrement est une mesure technique recommandée par la CNIL et l’ANSSI pour protéger les données personnelles. Sur AWS, deux niveaux :

Chiffrement au repos

Activez le chiffrement sur tous vos services de stockage :

S3 : chiffrement SSE-S3 (géré par AWS) ou SSE-KMS (avec vos propres clés)
RDS/Aurora : option à cocher à la création de l’instance (non activable après coup)
EBS : volumes chiffrés par défaut, activable au niveau du compte
DynamoDB : chiffrement activé par défaut

Chiffrement en transit

Utilisez uniquement des connexions TLS. Sur AWS, c’est le cas par défaut pour la plupart des services managés. Vérifiez néanmoins que vos applications n’acceptent pas de connexions HTTP non chiffrées.

KMS et gestion des clés

AWS Key Management Service vous permet de gérer vos propres clés de chiffrement. Pour les données très sensibles (données de santé, données financières), utilisez des clés KMS gérées par vous (CMK) plutôt que les clés gérées par AWS. Cela vous donne un contrôle total : si vous révoquez la clé, les données deviennent inaccessibles même pour AWS.

Les droits des personnes : comment les implémenter techniquement

Le RGPD accorde aux personnes des droits sur leurs données. Voici comment les honorer techniquement sur AWS :

Droit d’accès et portabilité : vos bases de données doivent permettre l’export des données d’un utilisateur spécifique. Sur RDS, cela passe par des requêtes SQL adaptées. Sur DynamoDB, par des requêtes filtrées sur l’identifiant utilisateur.

Droit à l’effacement (“droit à l’oubli”) : sur S3 avec versioning activé, supprimer un objet ne supprime que la version courante — les versions précédentes persistent. Pour un effacement complet, vous devez supprimer toutes les versions de l’objet. Anticipez cela dans votre architecture.

Durées de conservation : S3 Lifecycle Rules et les politiques de rétention RDS permettent d’automatiser la suppression des données après leur durée légale de conservation. C’est l’outil AWS pour matérialiser vos engagements RGPD dans votre infrastructure.

La journalisation : savoir qui a accédé à quoi

Le RGPD exige de pouvoir démontrer la conformité — ce qu’on appelle la responsabilisation (accountability). Sur AWS, cela passe par :

AWS CloudTrail : journalise tous les appels d’API sur votre compte. Qui a accédé à quel bucket S3, quelle base de données, quand. Activez CloudTrail dans toutes les régions utilisées, avec stockage dans un bucket dédié et protégé.
S3 Server Access Logging : journalise les accès aux objets S3 au niveau du fichier. Plus granulaire que CloudTrail pour les données stockées dans S3.
RDS Enhanced Monitoring et Audit Log : pour les accès aux bases de données.

Ces journaux doivent être conservés suffisamment longtemps pour répondre à un contrôle CNIL ou à un incident. 12 mois est une durée raisonnable.

Les notifications de violation de données

Le RGPD impose de notifier la CNIL dans les 72 heures en cas de violation de données personnelles. Sur AWS, les outils pour détecter ces incidents :

Amazon GuardDuty : détection des comportements anormaux (exfiltration de données, accès depuis des IP inhabituelles, compromission d’identifiants)
AWS Security Hub : agrégation des alertes de sécurité de tous vos services
Amazon Macie : détection automatique des données personnelles dans vos buckets S3 (numéros de carte, emails, numéros de sécurité sociale)

Macie est particulièrement utile pour les PME qui ne savent pas précisément où se trouvent les données personnelles dans leur infrastructure — un problème plus fréquent qu’on ne le croit.

Ce qu’il faut documenter

La conformité RGPD, c’est aussi de la documentation. Les éléments spécifiques à AWS à tenir à jour :

Registre des traitements : lister chaque service AWS utilisé pour traiter des données personnelles, avec la nature des données, la finalité, la durée de conservation
DPA signé : conserver la preuve d’acceptation du DPA AWS
Architecture de chiffrement : documenter quelles clés chiffrent quelles données
Procédure de réponse aux incidents : qui fait quoi si GuardDuty lève une alerte à 2h du matin

La conformité RGPD sur AWS n’est pas un état qu’on atteint une fois pour toutes — c’est un processus continu. Mais les outils AWS le facilitent vraiment, à condition de savoir les utiliser.

Vous hébergez des données personnelles sur AWS et vous n’êtes pas sûr de votre conformité ? Je propose des audits techniques ciblés sur ce sujet, avec un livrable actionnable en moins de deux semaines.

Sources : CNIL — Guide sécurité des données personnelles ; AWS GDPR Center ; EDPB — Recommandations sur les mesures supplémentaires pour les transferts.