Conformité RGPD du stockage cloud : guide des bonnes pratiques

Un stockage cloud conforme au RGPD repose sur cinq couches de contrôles : (1) chiffrement au repos avec AES-256 et en transit avec TLS 1.3, idéalement complété par un chiffrement côté client pour les données sensibles ; (2) un contrat de sous-traitance avec le fournisseur conforme à l'article 28(3) ; (3) résidence documentée des données — généralement UE/EEE pour les données personnelles européennes — avec transparence sur les sous-traitants ultérieurs ; (4) contrôles d'accès granulaires avec MFA, permissions basées sur les rôles et journaux d'audit conservés au moins six mois ; (5) détection des violations capable de satisfaire au délai de 72 heures de l'article 33. Négliger l'une de ces couches fait de la couche de stockage le maillon faible de votre dispositif de conformité.

Choisir un fournisseur conforme à l'article 28

Le marché européen des DPA classe les fournisseurs en niveaux distincts. Les hyperscalers (AWS, Azure, Google Cloud) proposent des CST complets et des régions UE, mais sont exposés au Cloud Act américain. Les acteurs souverains européens (OVHcloud, Scaleway, Infomaniak, Hetzner, IONOS) évitent la juridiction américaine et détiennent souvent les certifications C5, SecNumCloud ou ISO 27001. Les fournisseurs spécialisés dans la confidentialité (Tresorit, Proton Drive, Internxt, Nextcloud hébergé) ajoutent une architecture zéro connaissance. Choisissez en fonction de la sensibilité des données : les dossiers médicaux et les données de défense nécessitent des fournisseurs souverains ou zéro connaissance ; les fichiers professionnels courants fonctionnent sur des hyperscalers correctement configurés.

Chiffrement côté serveur versus côté client

Le chiffrement côté serveur — AWS S3 SSE-KMS, Azure Storage Service Encryption, clés gérées par le client dans Google Cloud — protège contre le vol physique de disques, mais pas contre les employés du fournisseur disposant d'un accès aux clés, ni contre la contrainte légale exercée sur le fournisseur. Le chiffrement côté client avec des clés que le fournisseur ne voit jamais (XChaCha20-Poly1305 chez Tresorit, AES-256-GCM avec dérivation de clé PBKDF2-SHA-256 chez HexaTransfer) offre une protection zéro connaissance. Pour les données hautement sensibles relevant de l'article 9 (santé, biométrie, opinions politiques), le chiffrement côté client est la valeur par défaut conforme ; le chiffrement côté serveur seul est limite.

Configurer AWS S3 pour le RGPD

S3 n'est pas conforme par défaut. Pour les données personnelles européennes, choisissez la région eu-central-1 (Francfort), eu-west-1 (Irlande), eu-west-3 (Paris) ou eu-south-1 (Milan). Activez le chiffrement par défaut avec SSE-KMS en utilisant une CMK gérée par le client avec rotation des clés. Bloquez l'accès public au niveau du compte. Activez Object Lock pour le stockage de conformité immuable lorsque la conservation est légalement obligatoire. Activez les journaux d'accès S3 et AWS CloudTrail pour l'audit. Utilisez des points de terminaison VPC pour que le trafic ne transite jamais par l'internet public. Désactivez S3 Transfer Acceleration, sauf si vous pouvez prouver que les caches de périphérie CloudFront restent dans l'UE.

Équivalents Azure et Google Cloud

Azure : choisissez West Europe (Amsterdam) ou North Europe (Dublin), activez Storage Service Encryption avec des clés gérées par le client via Key Vault, configurez des Private Endpoints, définissez une Azure Policy refusant les déploiements hors UE, et activez Microsoft Defender for Storage. Google Cloud : choisissez europe-west1 (Belgique), europe-west3 (Francfort) ou europe-west9 (Paris), activez les clés de chiffrement gérées par le client via Cloud KMS, utilisez VPC Service Controls pour prévenir l'exfiltration, et activez Cloud Audit Logs. Les deux hyperscalers publient des guides de configuration spécifiques au RGPD ; suivez-les à la lettre, sans improviser.

Contrôles d'accès au titre de l'article 32(1)(b)

Les contrôles d'accès basés sur les rôles constituent le niveau de référence. Chaque identité — humaine ou applicative — doit disposer du moindre privilège, limité à un bucket, préfixe ou dossier spécifique. Le MFA est obligatoire pour l'accès à la console et recommandé pour les clés API via des tokens de session. Des workflows d'entrée, de mobilité et de départ intégrés à votre fournisseur d'identité (Okta, Azure AD, Google Workspace) préviennent les accès obsolètes. Des revues d'accès trimestrielles détectent les dérives de périmètre. Pour les fichiers hautement sensibles, un accès d'urgence avec double approbation et expiration automatique des privilèges élevés après 4 à 8 heures limite les dommages en cas de compromission d'un compte administrateur.

Politiques de conservation adaptées à la finalité

L'article 5(1)(e) (limitation de la conservation) vous oblige à supprimer les données lorsque la finalité du traitement expire. Le stockage cloud rend la conservation indéfinie tentante — le stockage est bon marché. Construisez des politiques de cycle de vie qui imposent une conservation liée à la finalité : 30 jours pour les zones de dépôt de transfert, 13 mois pour les pièces jointes au support client, 7 ans pour les factures (droit fiscal), 10 ans pour les dossiers médicaux dans certaines juridictions. Les règles S3 Lifecycle, Azure Blob Lifecycle Management et GCS Object Lifecycle automatisent tout cela. Combinez-les avec Object Lock pour la conformité WORM lorsque la conservation est légalement imposée.

Gestion des clés de chiffrement

Les clés sont au cœur du sujet. Celui qui détient la clé détient les données. Au regard du RGPD, la garde des clés détermine si le fournisseur de stockage est un sous-traitant (il peut déchiffrer) ou simplement un vecteur de données (il ne détient que des données chiffrées). Utilisez des coffres de clés adossés à des HSM (AWS KMS, Azure Key Vault Managed HSM, Google Cloud HSM) pour les scénarios gérés côté serveur. Pour une architecture zéro connaissance, dérivez les clés dans le navigateur via l'API Web Crypto (PBKDF2 ou Argon2id via libsodium's crypto_pwhash) et ne les transmettez jamais. Renouvelez les clés annuellement ou lors du départ de personnel ayant accès aux clés. Documentez la garde des clés dans votre registre des activités de traitement au titre de l'article 30.

Chiffrement et résidence des sauvegardes

Les sauvegardes brisent souvent les engagements de résidence et de chiffrement. Un bucket en eu-central-1 avec une règle de réplication inter-régions vers us-east-1 pour des raisons de « résilience » vient de déplacer chaque fichier aux États-Unis sans mise à jour du CST. Vérifiez les configurations de réplication inter-régions et définissez des destinations dans l'EEE — eu-west-1 (Irlande) et eu-central-1 (Francfort) forment une paire naturelle. Chiffrez les sauvegardes avec une clé distincte de celle du stockage principal afin que la compromission d'une clé ne révèle pas les deux copies. Testez la restauration chaque trimestre ; une sauvegarde non restaurable est pire qu'aucune sauvegarde du point de vue de la reprise après sinistre.

Détection des violations pour respecter les 72 heures

Le délai de 72 heures de l'article 33 commence lorsque vous « prenez connaissance » de la violation. Les outils de détection réduisent l'écart entre la violation et la prise de connaissance. CloudTrail + GuardDuty sur AWS, Microsoft Defender for Cloud sur Azure, et Security Command Center Premium sur GCP signalent tous les schémas d'accès anormaux — téléchargements massifs, accès depuis de nouvelles localisations géographiques, clés utilisées en dehors des heures ouvrables. Acheminez les alertes vers un SOC 24h/24 ou au moins vers une permanence tournante. Pour les organisations de taille réduite, des services gérés de détection et de réponse (Arctic Wolf, Red Canary) comblent le manque. Documentez le plan d'action : qui notifie la CNIL, qui rédige le formulaire de l'article 33, qui communique avec les personnes concernées au titre de l'article 34.

Liste de contrôle pour l'évaluation des fournisseurs

Avant de signer un contrat de stockage cloud, exigez : (1) un CST conforme à l'article 28 couvrant les huit sujets obligatoires ; (2) un certificat ISO 27001 avec déclaration de périmètre ; (3) un rapport SOC 2 Type 2 (le SOC 2 Type 1 est insuffisant — il teste la conception, pas le fonctionnement) ; (4) un engagement de résidence UE avec centres de données nommés ; (5) un registre des sous-traitants ultérieurs avec leurs juridictions ; (6) un délai de notification des violations publié (≤24 heures de préférence) ; (7) une documentation du chiffrement incluant la gestion des clés ; (8) des droits d'audit au titre de l'article 28(3)(h). HexaTransfer publie les huit sur sa page de confiance ; les alternatives réputées (Tresorit, Proton, Infomaniak) font de même.

Traitez la page de confiance du fournisseur comme un contrat — si elle est absente, le fournisseur n'est pas sérieux. Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.