Bucket public, IAM trop permissif : quand votre design viole le RGPD

Quand on parle de fuite de données dans le cloud, on imagine un attaquant sophistiqué exploitant une vulnérabilité logicielle de pointe. La réalité est bien plus prosaïque. La grande majorité des violations de données cloud découlent d'erreurs de configuration d'architecture — c'est-à-dire de décisions de conception, votre cœur de métier.

Trois classiques reviennent en permanence dans les rapports d'incident :

• Le bucket de stockage public : un espace de stockage objet (S3, Blob, Cloud Storage) laissé en accès lecture publique, exposant des sauvegardes, des exports clients ou des journaux contenant des données personnelles.
• L'IAM trop permissif : des rôles aux droits excessifs, des clés d'accès à privilèges étendus, un principe de moindre privilège ignoré, transformant une simple compromission en accès total.
• Le VPC mal cloisonné : une segmentation réseau insuffisante qui permet à un attaquant ayant pris pied sur une ressource exposée de se déplacer latéralement vers les bases de données sensibles.

Aucune de ces failles n'est un bug applicatif. Ce sont des choix d'architecture — ou des oublis de conception. Et c'est précisément ce qui place l'architecte dans la ligne de mire quand l'incident survient.

Le RGPD ne se contente pas de protéger les données : il impose une méthode. L'article 25 consacre le principe de protection des données dès la conception (privacy by design) et de protection par défaut (privacy by default). Concrètement, la sécurité ne doit pas être ajoutée après coup : elle doit être intégrée à l'architecture dès sa conception. Le cloisonnement réseau, le chiffrement, le moindre privilège et la minimisation des accès deviennent des obligations juridiques, pas des bonnes pratiques facultatives.

Qui répond de quoi ? La chaîne mérite d'être clarifiée :

• Le responsable de traitement (votre client) est seul redevable envers la CNIL. C'est lui qui notifie, lui qui peut être sanctionné, lui qui doit informer les personnes concernées.
• L'hébergeur cloud opère selon un modèle de responsabilité partagée : il sécurise l'infrastructure « du cloud », le client reste responsable de la sécurité « dans le cloud ».
• L'architecte n'est ni l'un ni l'autre au sens du RGPD. Mais s'il a conçu l'architecture défaillante, le client sanctionné peut se retourner contre lui en responsabilité civile pour récupérer tout ou partie de son préjudice.

Vous n'êtes pas responsable devant la CNIL. Vous êtes responsable devant votre client, qui lui, a été sanctionné par la CNIL. C'est cette responsabilité-là qui doit être assurée.

Une fois la violation détectée, un compte à rebours s'enclenche. Le responsable de traitement dispose de 72 heures pour notifier la CNIL (article 33 du RGPD), et doit informer les personnes concernées si le risque pour leurs droits est élevé. Cette fenêtre courte déclenche une cascade de coûts.

Dans l'ordre, le client doit généralement :

1. Mobiliser une équipe de réponse à incident pour contenir la fuite et préserver les preuves.
2. Réaliser une investigation forensique pour déterminer l'ampleur de l'exposition : quelles données, combien de personnes, sur quelle durée.
3. Notifier la CNIL et, le cas échéant, les personnes concernées, avec les coûts d'information associés.
4. Engager une remédiation de l'architecture, souvent en urgence et hors budget.
5. Gérer le risque de sanction administrative et le risque réputationnel.

Lorsque l'investigation établit que la cause racine est une erreur de configuration d'architecture, le client dispose d'un rapport technique qui pointe directement vers votre conception. Le litige est alors documenté avant même qu'il ne vous contacte. La protection de votre architecture data passe aussi par une bonne couverture de vos systèmes, qu'aborde notre page assurance cyber.

La meilleure protection reste de ne pas produire la faille. Mais comme le risque zéro n'existe pas, l'objectif est de concevoir une architecture défendable — techniquement et juridiquement.

• Moindre privilège systématique : aucun rôle, aucune clé ne dispose de plus de droits que strictement nécessaire. Documentez la matrice des accès.
• Cloisonnement par défaut : segmentez les réseaux, isolez les données sensibles, fermez les accès publics par principe et ouvrez par exception justifiée.
• Revue de configuration tracée : intégrez des contrôles automatisés (politiques de sécurité, scans de posture cloud) et conservez les rapports.
• Recommandations de sécurité écrites : si le client refuse une mesure que vous préconisez (par coût ou délai), formalisez la réserve. Elle vous protège.
• Périmètre clair sur le run : précisez si la surveillance de la configuration en exploitation vous incombe ou non, car une dérive post-livraison change la donne.

Ces pratiques relèvent directement de l'obligation de privacy by design. Tracées dans vos livrables, elles transforment un sinistre où vous êtes présumé fautif en un litige où la responsabilité se discute.

Le modèle de responsabilité partagée du cloud est l'une des sources de litige les plus sournoises pour l'architecte, parce qu'il est constamment mal interprété. Le fournisseur cloud sécurise l'infrastructure « du cloud » (datacenters, hyperviseurs, réseau physique). Le client — et son architecte — reste responsable de la sécurité « dans le cloud » : les configurations, les accès, le chiffrement, le cloisonnement.

Le malentendu classique consiste à croire que « héberger chez un grand fournisseur certifié » suffit à être conforme. C'est faux, et dangereux. La certification de l'hébergeur (ISO 27001, HDS, SOC 2) ne couvre que sa moitié du modèle. Un bucket laissé public sur une infrastructure parfaitement certifiée reste une faille intégrale : le fournisseur a fait son travail, le client n'a pas fait le sien — et l'architecte, qui a conçu la configuration, est en première ligne.

Ce point devient critique quand l'architecture implique une chaîne de sous-traitance. Si votre design intègre des services tiers (CDN, services managés, briques SaaS), chacun introduit ses propres conditions de traitement des données et ses propres zones d'hébergement. Un service qui réplique discrètement des données hors UE, ou un sous-traitant non conforme dans la chaîne, peut suffire à transformer une architecture « propre » en violation du RGPD. L'architecte qui a choisi et assemblé ces briques doit avoir vérifié et documenté leurs garanties de localisation et de conformité.

Choisir un hébergeur certifié ne vous rend pas conforme : cela vous donne une infrastructure conforme à mal configurer. La conformité « dans le cloud » reste entièrement votre responsabilité de conception.

Documenter explicitement la répartition des responsabilités dans votre dossier d'architecture — qui sécurise quoi, quelle donnée est hébergée où, quel sous-traitant traite quoi — n'est pas une formalité administrative. C'est la cartographie qui, le jour du litige, montrera que vous avez exercé votre obligation de diligence.

Face à ce risque, la RC Pro seule ne suffit pas. La RC Pro IT senior couvre votre faute de conception et les dommages immatériels causés au client. Mais une violation de données ouvre des postes spécifiques que seule l'option Cyber prend en charge.

L'option Cyber d'une RC Pro IT couvre typiquement les frais de notification CNIL et d'information des personnes concernées, l'investigation forensique, les frais de remédiation et de gestion de crise, et les frais de défense en cas de mise en cause. C'est l'écart entre « être déclaré responsable » et « pouvoir financer la réponse à l'incident sans y laisser sa trésorerie ».

Pour un architecte qui conçoit des infrastructures manipulant des données personnelles — et c'est le cas de presque tous — la combinaison RC Pro IT + Cyber n'est pas un luxe : c'est la couverture qui correspond à la nature réelle de votre exposition. Découvrez le détail de la protection cyber sur notre page assurance cyber, et calibrez votre contrat sur la page assurance architecte systèmes, réseaux et cloud.