GDPR-EA : canevas d’architecture de conformité

Vers une cible d’Architecture de Conformité

Le Club Urba-EA, dans le cadre du Laboratoire de la Flexibilité, a mené des travaux pour étudier l’impact de la réglementation sur les données personnelles (GDPR, RGPD) sur l’architecture des systèmes d’information. Le Club prolonge ces travaux par la proposition concrète d’une architecture de système d’information répondant aux exigences de conformité.

Au titre de l’Architecture d’Entreprise, alias Urbanisme du SI, cette architecture fournit une vision cohérente du patrimoine applicatif impacté par la réglementation, quel que soit ce patrimoine. L’architecture proposée organise les fonctions de conformité, et règle les interfonctionnements avec les traitements existants ou futurs qui utilisent des données personnelles.

Cette approche « data centric » utilise les figures de style de l’Architecture Flexible (puits d’événements, Data Hub).

Objectifs d’une Architecture de Conformité

Une telle Architecture a de nombreux avantages :

  • permettre l’enrichissement progressif du système par composants synchronisés dynamiquement grâce à des API standards,

par exemple les nouvelles fonctions nécessaires au Data Protection Officer sont créées et mises en ligne rapidement en mode agile,

  • proposer, pour les nouveaux traitements, un composant central, appelé « plateforme de conformité« , qui garantit la licéité (en relation avec les consentements, les contrats, les oppositions, la nature des données, …),

cette plateforme est, en cible, le lieu unique de vérification et d’attribution de la licéité (articles 5 et 6 du Règlement)

  • une introduction progressive et opportuniste au sein du patrimoine applicatif, adaptée au cas particulier de l’Entreprise et de sa stratégie de mise en conformité,

par exemple la plateforme de conformité, composant central de l’architecture, est insérée de façon non intrusive, par étape successives

  • tracer le détail et l’historique des traitements réalisés (ou rejetés) en lien avec les données d’une personne,

la plateforme de conformité peut attribuer, en cible, les droits de traitement des données, mais, sans attendre de modification importante des applicatifs, elle peut tracer et historiser tous les traitements exécutés sur les données personnelles (surtout s’il s’agit de données sensibles), au niveau du « grain » le plus fin nécessaire,

  • de la même manière, conserver les traces des traitements de protection demandés par la personne (portabilité, droit à l’oubli, droit de correction),

les traitements de protection, quels qu’ils soient, sont aussi activés, et tracés en un lieu unique, par l’Architecture

  • fournir aux responsables de traitement et au Data Protection Officer (DPO) les outils d’audit de démonstration et de pilotage, basés sur les traces détaillées des événements captées au fil de l’eau des traitements,

les outils du DPO exploitent les informations transversales historisées par la plateforme

  • de paramétrer les règles décrites par la réglementation, et leurs enrichissements et amendements, de façon formelle, flexible, et historisée,

ainsi les évolutions réglementaires ou de jurisprudence ont un impact mineur sur l’architecture et peuvent être prises en compte rapidement à peu de frais. De même, la stratégie de mise en conformité de l’entreprise peut être adaptée facilement.

Une Architecture générique

Cette architecture est générique, comme l’est la réglementation, et peut être adoptée par toute Entreprise et Organisation, selon ses particularités (données sensibles article 9, traitements d’intérêt général, finalités alignées sur la réglementation d’un secteur professionnel, particularités nationales, …) : le modèle est unique, et constitué de composants très fortement standards répartis par zone fonctionnelle (voir ci-après).

C’est une opportunité rare, dans le contexte des disparités nationales et sectorielles, de bénéficier d’importantes économies d’échelle basées sur une Réglementation qui, de fait, a un impact global (Européen, et, de fait, au delà).

L’architecture place la conformité au cœur du SI et de son fonctionnement opérationnel, ce qui est bien plus sécurisant et efficace que des systèmes de cartographie ou de documentation.

Le modèle, par sa flexibilité, répond aussi au besoin de sécurité par rapport aux évolutions structurelles de la réglementation : jurisprudence, levée de contradictions, précisions sur des modalités… En effet, le système peut croiser au niveau le plus fin les dimensions « personne », « données », « consentements », « traitements » et « finalités », même si un tel croisement n’est, actuellement pour la majorité des traitements, nécessaire que par exception.

Mises à part les contraintes de sécurité qui ont bien sûr un impact sur l’architecture, le modèle peut être instancié sur n’importe quelle architecture technique, centralisée, synchronisée, voire en partie basée sur la blockchain.

Le modèle proposé par le Club Urba-EA, a été partagé et validé dans ses principes, au sein du groupe de travail, par de grandes entreprises et organisations. Sa vocation est de devenir un standard pour la gestion des données personnelles, reconnu par les Entreprises utilisatrices et les éditeurs, contribuant ainsi à la transformation numérique de la société et à l’efficacité des opérateurs.

Le schéma de principe du zonage prévu pour l’architecture de référence GDPR-EA, proposée aux Entreprises et aux Editeurs, est reproduit ci-dessous.

La structuration de ce zonage reprend l’articulation en différents cycles, articulation décrite dans l’article « le polygone de Mandel de la protection des données personnelles« , à savoir :

  • Exercice des droits des personnes physiques
  • Administration de la protection
  • Lots de traitements de protection GDPR
  • Plateforme de conformité
  • Traitements SI

 

 

Ces zones sont expliquées ci-après :

Exercice des Droits des personnes physiques

Cette zone gère la relation avec les personnes : recueil de leurs desiderata concernant leurs données personnelles et les finalités et traitements. Elle est en quelques sortes le « canal » d’interaction et d’information, point de passage obligé pour les accès des personnes, sur les questions de protection des données. En ce sens elle peut être intégrée à des fonctionnalités plus générales de gestion de canal ou omni-canal.

Cette intégration règle les questions d’identification, de sécurité d’accès, de cryptage, … qui sont de portée plus globale et n’ont pas nécessairement à être traitées à ce niveau. Toutefois les contraintes du « Privacy by default » doivent être respectées.

Les instructions indiquées par les personnes, recueillies au niveau de cette zone, n’y sont pas nécessairement mémorisées. Deux cas de figure se présentent :

  • Les desiderata des personnes impliquent une action globale sur le patrimoine SI, nécessitant un lot de traitement : portabilité, changement des consignes d’effacement, transfert, … La gestion de ces demandes et le suivi de leur exécution seront mémorisés par cette zone.
  • Les desiderata des personnes nécessitent une action ponctuelle immédiate, en particulier pour être appliquées lors des traitements qui se présentent. La gestion de ces demandes et leur suivi sera partagée avec la zone « plateforme de conformité », qui assurera un suivi fin de l’exécution des desiderata confrontés aux traitements et finalités.

Cette zone correspond essentiellement aux articles 7, 12, 13, … du Règlement.

Administration de la Protection

Cette zone est destinée aux professionnels de la Protection : responsables de traitement, DPO, et à leurs relations avec les autorités spécialisées.

Elle permet donc le suivi et la gestion des procédures obligatoires, ou internes, de protection : PIA, tenue des registres, comptes rendus, …

Elle est le point central de gestion des incidents et crises : intrusions, incidents techniques, …

Elle inclut la gestion des traitements, telle que décrite dans l’obligation de Registre des traitements. Elle historise ce registre et en suit les évolutions en relation avec le portefeuille de projets. Un lien peut aussi être fait avec la gestion des composants assurée par une « CMDB ».

Elle dispose de tableau de bord de suivi des activités liées à la GDPR, à partir d’informations en provenance des 3 autres zones spécifiques à la GDPR.

Cette zone correspond essentiellement aux articles 24, 26, 30 du Règlement

Lots de traitement de protection GDPR

Comme indiqué ci-dessus, certains desiderata des personnes nécessitent des interventions dans tout le patrimoine SI : portabilité, transfert, effacement…, impliquant à un moment donné des traitements par lot sur tout ou partie du patrimoine.

Ces fonctionnalités nécessitent des « moteurs » spécialisés, et éventuellement des modifications applicatives spécifiques à certains composants du patrimoine SI.

L’exécution et la supervision de ces lots de traitements est à prévoir dans cette zone.

Cette zone correspond aux articles 20, 44, … du Règlement

Plateforme de conformité

Cette zone correspond à l’application fine des desiderata des personnes, dans la mise en œuvre des contrats, consentements, oppositions au regard des finalités.
Un modèle d’architecture flexible permet :

  • d’enregistrer les desiderata de façon fine et historisée,
  • d’attribuer les autorisations de traitement en application des desiderata et des règles définies

Cette architecture est basée d’une part sur des « puits d’événements », et d’autre part sur des référentiels de données. La datation en est rigoureuse, comme recommandé par les principes de « tri-datation ».

Le fonctionnement de ce modèle est basé sur plusieurs composants « Data Centric », dont les données sont gérées soit au sein de la plateforme, soit externalisées, voire réparties entre plusieurs plateformes, selon le scénario d’implémentation.

En effet les règles, pour les plus exigeantes en termes de détail et de combinaison d’informations, nécessitent de confronter desiderata et traitements au niveau le plus fin.

L’autorisation, ou l’invalidation, d’un traitement se fait ainsi au niveau d’un « grain fin » confrontant ces desiderata face aux demandes de traitement. La plateforme réalise cette confrontation en temps immédiat, ce qui permet de l’invoquer dans n’importe quel contexte de latence.

Selon le cas, les règles impliquent un niveau de confrontation plus ou moins détaillé. Le niveau de confrontation est donc variable et adapté au cas d’espèce.

La plateforme trace les autorisations accordées, ou demandes invalidées, au niveau adéquat (fin dans le cas de consentements par exemple, mais plus global dans d’autres cas).

Le réglage de ce niveau de détail est fonction de plusieurs paramètres :

  • Catégorie de personnes, nature d’information, type de desiderata (consentement, opposition, …), type de règle (obligation contractuelle, légale, …), nature du traitement…
  • Un moteur de règle peut être utilisé pour formaliser ces confrontations.

L’administration de la plateforme permet de gérer et historiser les règles, les nomenclatures et meta-données :

  • Dictionnaire des informations personnelles et leur criticité et regroupements (meta-données)
  • Nomenclature des événements de confrontation (autorisation, invalidation, mode traçage, ….)
  • Nomenclature des consignes (consentement, opposition,… ) (cette nomenclature doit être étendue à l’ensemble des consignes, en particulier celles concernant les traitements par lot)
  • Table des criticités
  • Nomenclature des événements (tracés dans les « puits d’événements » voir ci-après)
  • Table des flux et interactions internes et externes…

Par ailleurs, l’accès au Registre des traitements est nécessaire à la plateforme, pour l’exécution des règles.

A ces figures de style (patterns d’architecture), est adjoint la figure du « Puits d’événements » avec :

  • Le puits d’événement des consigne de protection, dit « puits des consentements », qui trace les diverses demandes des personnes (consentements, oppositions, …)
  • Le puits des traces de protection et d’autorisations de traitement (et de licéité), qui trace les autorisations ou invalidations

Dans le cas d’un groupe de sociétés, la plateforme doit pouvoir être instanciée en différentes configurations afin de séparer, ou au contraire coordonner, différents espaces de conformité, en adaptant cette configuration aux divers impératifs juridiques des secteurs professionnels, et de la GDPR.

La plateforme correspond aux articles 5, 6, 9 du Règlement.

Traitements SI

 

Cette zone comprend l’ensemble des traitements qui sont, de près ou de loin, concernés par la GDPR.

Il s’agit :

  • d’une part de traitements « historiques » qui doivent progressivement être mis en conformité,
  • d’autre part de nouveaux traitements qui doivent être nativement conforme, selon le principe dit « Privacy by Design »

Un des objectifs de la cible est de rendre le « Privacy by Design » de moindre coût, les nouveaux services automatisés s’appuyant sur la plateforme pour vérifier la licéité des traitements.

En ce qui concerne les anciennes applications, voire les ERP, plusieurs stratégies peuvent être employées :

  • Réaliser des évolutions applicatives pour rendre le recours aux fonctions de la cible GDPR-EA systématique, comme prévu en cible,
  • Différencier ce transfert aux fonctions de la plateforme, fonction par fonction, et selon les applications,
  • Admettre un fonctionnement partiel et dégradé pour telle ou telle application. Par exemple, telles applications historiques continuent d’interpréter les desiderata des personnes, mais informent cependant la plateforme des décisions prises,
  • Même si les autorisations sont délivrées par une application, dans une période de transition, recharger ces autorisations sur la plateforme à partir d’un fichier batch produit par l’application.

On peut ainsi envisager une évolution sans rupture, au gré des priorités, opportunités et difficultés rencontrées.

Flux, interactions, inter-applicatifs, internes à la cible GDPR-EA

 

Le bon fonctionnement de l’ensemble de la cible suppose de nombreuses interactions entre ses composants.

L’essentiel n’est pas dans le choix d’implantation de chaque composant :

  • Périmètre d’activité (par exemple le référentiel des personnes peut être plus ou moins centralisé ou éclaté en référentiels subsidiaires, le registre des traitements peut être organisé par société, ou regroupé, etc…),
  • Choix d’architecture technique comme support de tel ou tel composant, et en particulier solutions technologiques pour obtenir la scalabilité (augmentation du volume de données, inflation des interactions) et garantir l’intégrité de l’ensemble dans un contexte d’architecture éclatée, voire atomisée en micro-services,
  • Externalisation ou non du service.

La définition rigoureuse des interfaces, sous forme d’API, permet de s’abstraire en grande partie de ces choix. On veillera bien sûr à garantir le niveau de sécurité adéquat sur l’ensemble de la chaîne, d’autant plus renforcé que les données sont plus sensibles.

Flux entre la cible GDPR-EA et les autres composants du patrimoine SI

 

La définition d’API normant les interactions entre la cible GDPR-EA et les autres applications et composants est indispensable à l’évolutivité du système.

Parmi ces API, celles qui concernent les demandes d’autorisation de traitement, et le dialogue d’autorisation, sont une des clés du dispositif.

Les données de ces API comprennent :

  • Données de contexte : domaine, flux, …,
  • Les éléments de tri-datation, le type d’événement,
  • Les identifications (personne, données, traitement),
  • Un numéro unique identifiant l’autorisation ou le refus,
  • La requête, la réponse,
  • Toute information complémentaire nécessaire à l’enregistrement d’une trace.

Ces données sont génériques et pourraient être définies dans le cadre de la GDPR, comme applicables à toute entreprise.

Les principaux échanges sont :

  • Trace d’exécution d’un traitement de protection (oubli, portabilité, …),
  • Demande d’autorisation,
  • Accord ou refus,
  • Compte-rendu de traitement suite à autorisation,
  • Avis de traitement (cas où l’autorisation n’est pas gérée par la plateforme).

Une étude plus détaillée serait nécessaire pour valider ce protocole et le compléter (cas de test, cas d’erreur, …).

Pour aller plus loin

Dans le cadre de cette Architecture et de ses standards (définitions fonctionnelles, APIs) le Club Urba-EA envisage la contribution de plusieurs acteurs intéressés par la démarche.

Plusieurs questions peuvent être approfondies :

  • trame d’un programme de mise en conformité à la GDPR

Sujet traité ici.

  • cas d’usage de l’architecture GDPR-EA

Sujet traité ici.

  • définition des APIs

Sur la base des principes exposés ci-dessus, choix des APIs les plus caractéristiques et proposition de définitions.

  • moteur de règles

Choix d’un sous-ensemble de règles, et mise en forme des règles. Implémentation d’une version de démonstration sur un moteur de règles du marché.

  • démonstrateur d’architecture pour la plateforme de conformité

Etude des scénarios alternatifs d’architecture technique. Identifier les avantages et inconvénients :

  • des solutions classiques (type BD SQL) : intégrité (qualification ACID), mais faible scalabilité, évolutivité réduite, forte dépendance entre les composants,
  • des solutions du monde Hadoop (Kafka …) : approximations de la « consistance à terme », complexité de l’architecture logicielle, forte technicité nécessaire, résilience.

Quel compromis choisir dans l’empire du triangle du théorème CAP ?

Au final, réalisation d’un démonstrateur illustrant la faisabilité et le caractère opérationnel du concept.

Dans cette perspective, nous proposons par ailleurs l’architecture d’un démonstrateur, basée sur la solution Kafka et l’utilisation d’un « log d’événements » entre Legacy et une plateforme de conformité.