RGPD : exigences d’architecture et contrôles techniques

Le RGPD (Règlement général sur la protection des données) ne prescrit ni un cloud, ni un chiffrement particulier, ni une marque de coffre-fort à secrets. Il impose en revanche de pouvoir limiter, protéger, retrouver, corriger, exporter et supprimer des données personnelles sans casser le système ni raconter une fable au moment de l’audit.

→ Lire l’explication complète de la marmotte

Le RGPD impose une architecture orientée finalité

Une donnée personnelle est toute information se rapportant à une personne identifiée ou identifiable. Une adresse électronique professionnelle, un identifiant de connexion, une adresse IP (Internet Protocol), un journal d’accès ou un identifiant publicitaire peuvent entrer dans ce périmètre selon le contexte et les moyens raisonnablement disponibles pour réidentifier la personne.

L’erreur la plus chère consiste à modéliser les données par application plutôt que par finalité. Une base « clients » partagée entre support, facturation, prospection, analyse comportementale et produit devient rapidement indéfendable : les accès s’élargissent, les durées de conservation divergent et l’effacement se transforme en chasse au trésor dans quinze schémas SQL (Structured Query Language).

L’architecture doit donc rattacher chaque flux à quatre attributs persistants :

la finalité documentée ;
la catégorie de personnes concernées ;
la durée de conservation active et la règle d’archivage ou de purge ;
le responsable fonctionnel capable de valider un accès ou une exception.

Ces attributs ne doivent pas finir dans un tableur décoratif. Ils doivent influencer les contrôles techniques : classe de stockage, politique d’accès, règles de rétention, indexation des sauvegardes et journalisation. Un registre de traitements sans inventaire des jeux de données, des API (Application Programming Interface), des exports et des sous-traitants ne décrit pas un système. Il décrit une intention administrative.

Le compromis central est là : segmenter les données par finalité augmente le coût d’intégration, de synchronisation et d’exploitation. En échange, on limite la portée d’une compromission, on rend l’effacement réalisable et on évite qu’un entrepôt de données devienne un marais réglementaire. La recommandation est nette : séparer logiquement et, pour les données les plus sensibles ou aux politiques incompatibles, physiquement les domaines de données. Centraliser les capacités de sécurité, pas forcément les données elles-mêmes.

La minimisation ne signifie pas « collecter peu » au sens esthétique. Elle signifie ne stocker que les attributs nécessaires à la finalité déclarée, avec une granularité et une précision proportionnées. Conserver une date de naissance quand une tranche d’âge suffit crée une dette immédiate. Les données superflues ne deviennent pas inoffensives parce qu’elles dorment dans un stockage objet, bien au chaud sous une étiquette « data lake ».

Les pages gouvernance et données doivent servir de points d’ancrage : la première pour la responsabilité et les décisions, la seconde pour le cycle de vie et la classification. Sans cette jonction, l’architecture applique des contrôles à des objets dont personne ne sait expliquer l’usage.

Privacy by design : rendre les droits réalisables

L’article 25 du RGPD impose la protection des données dès la conception et par défaut. Techniquement, cela impose surtout de concevoir les opérations de droits avant d’industrialiser la collecte. Une application incapable d’identifier toutes les copies associées à une personne ne sait pas répondre proprement à une demande d’accès, de rectification ou d’effacement.

Un identifiant interne stable, non réutilisé entre finalités incompatibles, est la pièce maîtresse. Il doit relier les données opérationnelles, les index de recherche, les événements asynchrones, les fichiers déposés et les exports. Sans cet identifiant, l’effacement repose sur des recherches textuelles fragiles. Chercher « Martin » dans des journaux est une stratégie de conformité à peu près aussi fiable qu’un détecteur de fumée alimenté par optimisme.

La pseudonymisation remplace un identifiant direct par un identifiant indirect, la table de correspondance restant séparée et protégée. Elle réduit l’exposition opérationnelle, notamment dans les environnements de développement, d’analyse ou de support. Elle ne rend pas la donnée anonyme et ne retire pas le traitement du champ du RGPD. Un hachage déterministe d’adresse électronique reste généralement réidentifiable par dictionnaire ou corrélation, surtout quand le domaine fonctionnel est prévisible.

L’anonymisation exige qu’aucune réidentification ne soit raisonnablement possible, y compris par recoupement avec des données externes. Cette propriété dépend du jeu de données, des attributs publiés et de l’état de l’art, pas d’un bouton nommé anonymize=true. Pour les environnements non productifs, la position défendable est plus stricte : ne pas y copier de données personnelles de production, sauf besoin exceptionnel approuvé, pseudonymisé et limité dans le temps.

Les droits doivent être exposés par un workflow contrôlé, pas par un accès direct aux bases. Ce workflow doit authentifier le demandeur, vérifier les délégations, collecter les données dans tous les systèmes déclarés, appliquer les exceptions légitimes documentées et produire une preuve d’exécution. L’export doit éviter les journaux techniques, les données d’autres personnes et les secrets accidentellement collés dans un champ libre. Les champs libres sont des zones humides : tout finit par y pousser, y compris ce qui n’aurait jamais dû être saisi.

Contrôle d’accès et cloisonnement des données personnelles

Le chiffrement protège une donnée contre certains accès non autorisés. Il ne décide pas quel utilisateur métier a le droit de la lire. Le RGPD attend une combinaison de contrôle d’accès, de séparation des rôles, de journalisation et de réduction des privilèges.

L’IAM (Identity and Access Management) doit fournir des identités nominatives, des groupes ou rôles gouvernés, une authentification forte pour les accès sensibles et une révocation effective. Les comptes partagés détruisent l’imputabilité : un journal indiquant support-admin n’explique pas qui a exporté un dossier ni pourquoi. Une MFA (Multi-Factor Authentication), authentification reposant sur plusieurs facteurs indépendants, réduit le risque de compromission d’identifiants mais ne protège ni contre un poste déjà compromis ni contre une autorisation excessive.

L’autorisation doit être évaluée au plus près de la donnée. Filtrer l’interface web sans appliquer le même filtre dans l’API, les tâches asynchrones et les exports est une fuite en attente. Dans une architecture multi-tenant, chaque requête vers une donnée partagée doit porter un contexte de tenant vérifié côté serveur. Le tenant fourni par un navigateur, un en-tête HTTP (Hypertext Transfer Protocol) ou un jeton non validé n’est pas une frontière de sécurité.

Les accès d’administration méritent une séparation explicite : administration de plateforme, administration applicative, support métier et consultation de données personnelles sont des privilèges distincts. Le compte capable de modifier une règle d’autorisation ne devrait pas aussi pouvoir lire toutes les données. Sinon, l’attaquant n’a qu’une serrure à crocheter, ce qui est très commode. Pour lui.

La surface d’attaque principale inclut les erreurs d’autorisation horizontale, où une personne accède aux données d’une autre, les erreurs verticales, où un rôle faible obtient un privilège élevé, les exports non contrôlés, les liens de téléchargement persistants et les sauvegardes accessibles avec les mêmes identifiants que la production. Les contre-mesures sont connues : tests d’autorisation négatifs, politiques centralisées, jetons à durée courte, URLs signées limitées, revue périodique des droits et journalisation immuable des accès à haut risque.

Exemple : isolation multi-tenant avec PostgreSQL

PostgreSQL propose la RLS (Row-Level Security), un mécanisme qui filtre les lignes accessibles selon le contexte de session. Elle convient pour renforcer l’isolation applicative, à condition que le rôle utilisé par l’application ne possède pas la table et ne dispose pas de l’attribut BYPASSRLS. La RLS ne remplace pas la validation du tenant dans l’application, elle ajoute une barrière indépendante.

-- Table contenant des données personnelles rattachées à une organisation.
CREATE TABLE customer_profile (
  id uuid PRIMARY KEY,
  tenant_id uuid NOT NULL,
  email text NOT NULL,
  display_name text NOT NULL
);

-- Active le filtrage au niveau des lignes, y compris pour le propriétaire.
ALTER TABLE customer_profile ENABLE ROW LEVEL SECURITY;
ALTER TABLE customer_profile FORCE ROW LEVEL SECURITY;

-- Le tenant est fourni par le serveur applicatif après validation du jeton.
CREATE POLICY tenant_isolation ON customer_profile
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- À exécuter au début de chaque transaction, jamais depuis une entrée HTTP brute.
BEGIN;
SET LOCAL app.tenant_id = '7d6c2644-630e-4ca6-b9a9-6bcfa89a95f1';
SELECT id, email, display_name FROM customer_profile;
COMMIT;

Le piège classique est le pool de connexions. Une variable de session non réinitialisée peut contaminer la requête suivante si elle est fixée avec SET au lieu de SET LOCAL dans une transaction. Le résultat est une fuite inter-tenant intermittente, donc particulièrement agréable à diagnostiquer à 02:17. Les tests doivent vérifier qu’une connexion réutilisée ne conserve aucun contexte précédent.

Chiffrement, clés et sauvegardes : ce que le RGPD ne garantit pas

Le RGPD exige un niveau de sécurité approprié au risque, notamment par l’article 32. Le chiffrement est souvent justifié, mais il ne constitue ni une conformité automatique ni une réponse à tous les scénarios. Une base chiffrée au repos protège surtout contre le vol du support ou certains accès à l’infrastructure. Elle ne protège pas contre une application compromise qui lit légitimement les données déchiffrées.

Pour les champs à forte sensibilité, le chiffrement applicatif permet de réduire l’exposition des administrateurs de bases et des copies techniques. Une DEK (Data Encryption Key) chiffre les données, tandis qu’une KEK (Key Encryption Key) chiffre ou enveloppe les DEK. La KEK doit résider dans un service de gestion de clés distinct de la base, avec des droits d’usage séparés. Une clé stockée dans le même dépôt, le même coffre applicatif et la même sauvegarde que les données n’est pas une séparation : c’est un lot promotionnel.

La rotation doit être conçue dès le format de chiffrement : stocker avec chaque valeur l’identifiant de clé, l’algorithme et les paramètres nécessaires au déchiffrement. La rotation de KEK peut souvent réenvelopper les DEK sans rechiffrer toutes les données. La rotation de DEK exige généralement un rechiffrement complet. Il faut planifier la capacité, la reprise sur erreur et la coexistence temporaire de plusieurs versions de clés.

Les sauvegardes sont dans le périmètre. Une suppression en production ne supprime pas instantanément les copies historiques, ce qui est acceptable seulement si la politique documente une expiration finie et si la restauration ne réinjecte pas silencieusement des données effacées. Une restauration doit donc rejouer le registre des suppressions ou restaurer vers un environnement isolé avant réconciliation. La rétention infinie des sauvegardes est une machine à remonter le temps, rarement une politique de protection des données.

La supervision doit détecter les exports inhabituels, les lectures massives, les échecs répétés d’autorisation, les élévations de privilèges, les désactivations de journalisation et les usages anormaux de clés. Les journaux eux-mêmes contiennent fréquemment des données personnelles : masquer les valeurs sensibles, limiter leur accès et définir leur rétention. Consulter aussi les principes de cryptographie et d’identités évite de traiter la protection des données comme une couche de peinture posée après le câblage.

Limites d’architecture et obligations hors système

Une architecture ne décide pas de la base légale, ne rédige pas une information loyale et ne qualifie pas seule une violation de données. Ces sujets relèvent de la gouvernance, des métiers, du délégué à la protection des données et, selon le cas, d’un conseil juridique. L’architecture doit toutefois fournir les preuves et les capacités nécessaires à ces décisions : inventaire, journaux, périmètre des accès, chronologie des événements, localisation des copies et efficacité des suppressions.

Le mécanisme ne garantit pas non plus qu’un sous-traitant respecte ses engagements. Il faut évaluer les interfaces, les régions de traitement, les clauses contractuelles, les procédures de notification et la capacité à extraire ou supprimer les données à la fin du contrat. Un connecteur SaaS (Software as a Service) qui reçoit des données personnelles devient un flux à inventorier, même si son tableau de bord est pastel et promet de « réinventer la collaboration ».

La recommandation finale est opérationnelle : faire du cycle de vie des données une contrainte d’architecture dès la première version. Toute nouvelle collecte doit déclarer sa finalité, son propriétaire, sa durée, ses destinataires, son niveau de sensibilité et sa stratégie d’effacement. En l’absence de ces réponses, ne pas ouvrir le flux. La fonctionnalité peut attendre, la copie incontrôlée ne sait jamais repartir seule.

🐝 Ce qui arrive si on s’en passe

Sans ces contrôles, la porte reste ouverte et ce qui entre dans la ruche ne se compte plus. Aucune chronologie exploitable n’est reconstituable lors d’un incident : le périmètre des personnes touchées, la volumétrie exportée et les copies concernées restent des estimations, ce qui rend toute notification tardive, approximative ou impossible à documenter dans les délais réglementaires. La charge de la preuve bascule : il faut démontrer qu’une donnée a disparu partout, sans index ni identifiant pour l’attester. Les demandes des personnes concernées se traitent à la main, requête par requête, avec un risque de réponse incomplète ou de divulgation croisée. La sortie d’un sous-traitant devient invérifiable : rien ne prouve que l’extraction fut exhaustive ni que la suppression finale a eu lieu. Enfin, une fuite inter-tenant intermittente passe inaperçue faute de journalisation permettant de la corréler.

🦫 Explication de la marmotte 🍫

Le règlement demande de protéger les informations liées à des personnes et de pouvoir expliquer pourquoi elles sont utilisées. Avant de créer un formulaire, une base de données ou un échange avec un service externe, il faut définir ce qui est collecté, pour quelle raison, qui peut le consulter et quand cela doit disparaître.

Le système doit garder un identifiant interne pour retrouver les informations d’une même personne dans les différents outils. Cet identifiant permet de répondre à une demande d’accès, de correction ou de suppression. Si les informations sont copiées sans lien entre elles, il devient impossible de vérifier que tout a été traité.

Les accès doivent être limités selon le travail de chaque personne. Une personne du support ne doit pas automatiquement pouvoir lire toutes les informations, et une personne qui modifie les droits ne doit pas forcément pouvoir consulter les dossiers. Les actions sensibles doivent laisser une trace consultable.

Le chiffrement transforme les données pour empêcher leur lecture sans clé. Il réduit les dégâts en cas de vol d’un support ou d’une copie, mais il ne protège pas contre une application autorisée qui a été piratée. Les clés doivent être séparées des données et remplacées selon une règle prévue.

Enfin, les sauvegardes et les journaux doivent aussi être gérés. Une donnée supprimée peut encore exister dans une sauvegarde pendant une durée limitée, mais cette durée doit être connue et appliquée.

Pages voisines

La citent

RGPD : exigences d’architecture et contrôles techniques

Elle cite

RGPD : exigences d’architecture et contrôles techniques

RGPD : exigences d’architecture et contrôles techniques

Le RGPD impose une architecture orientée finalité

Privacy by design : rendre les droits réalisables

Contrôle d’accès et cloisonnement des données personnelles

Exemple : isolation multi-tenant avec PostgreSQL

Chiffrement, clés et sauvegardes : ce que le RGPD ne garantit pas

Limites d’architecture et obligations hors système

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines