[go: up one dir, main page]

FR3147901A1 - Système et procédé de stockage de données, en particulier de données personnelles - Google Patents

Système et procédé de stockage de données, en particulier de données personnelles Download PDF

Info

Publication number
FR3147901A1
FR3147901A1 FR2403700A FR2403700A FR3147901A1 FR 3147901 A1 FR3147901 A1 FR 3147901A1 FR 2403700 A FR2403700 A FR 2403700A FR 2403700 A FR2403700 A FR 2403700A FR 3147901 A1 FR3147901 A1 FR 3147901A1
Authority
FR
France
Prior art keywords
data
database
query
target
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2403700A
Other languages
English (en)
Inventor
Aishwarya Alex Namasivayam
Jochen Britz
Stefan Bucheli
Ricardo Cristino
Stanislaw Findeisen
Alper Kocademir
Sudipto Shekhar Roy
Gerhard Sonnenberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HOFFMANN LA ROCHE
F Hoffmann La Roche AG
Original Assignee
HOFFMANN LA ROCHE
F Hoffmann La Roche AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by HOFFMANN LA ROCHE, F Hoffmann La Roche AG filed Critical HOFFMANN LA ROCHE
Publication of FR3147901A1 publication Critical patent/FR3147901A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Bioethics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Medical Informatics (AREA)
  • Data Mining & Analysis (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Computational Linguistics (AREA)
  • Human Computer Interaction (AREA)
  • Mathematical Physics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

L’invention concerne un système de stockage de données, en particulier de données personnelles, comprenant :- une interface (105), en particulier une API REST ;- un module d’authentification (130) ;- au moins une base de données cible (30, 40) pour le stockage des données ;- un module d’accès aux données (110) qui est conçu pour       a) recevoir des requêtes d’un ordinateur client (10) au moyen de l’interface ;       b) interroger des données de l’au moins une base de données cible (30, 40) en réponse à la requête reçue ;       c) déterminer si l’ordinateur client et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et       d) générer un ensemble de données de réponse pour répondre à la requête et le transmettre à l’ordinateur client, au moins certaines données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée. Figure pour l’abrégé : Fig. 2

Description

Système et procédé de stockage de données, en particulier de données personnelles
L’invention concerne un système de stockage de données, comprenant une interface, un module d’authentification, au moins une base de données cible et au moins un module d’accès aux données. De plus, l’invention concerne un procédé de stockage de données correspondantes au moyen d’un système correspondant.
Dans le secteur médical, le stockage de données est très problématique. Les données en question sont souvent personnelles et très sensibles. Dans le même temps, il est nécessaire que les données correspondantes soient disponibles pour divers groupes de personnes et applications. Des données fiables sont requises pour établir un diagnostic précis des maladies et également pour les traiter ensuite avec succès. La poursuite du développement d’algorithmes médicaux nécessite également que les données soient disponibles, en particulier sur le long terme.
Des systèmes complets sont ainsi développés dans le secteur des soins de santé pour mettre à disposition les données pertinentes, en particulier les données personnelles.
La gestion de telles données personnelles est complexe, car il existe différentes règles et lois pour le traitement de ces données. Ces règles et lois se rapportent à la forme du stockage, sa durée de conservation et son utilisation à différentes fins.
En outre, la connexion de différentes applications à de tels systèmes de stockage de données est complexe. Dans de nombreux systèmes et applications existants, des tentatives ont été menées pour implémenter les algorithmes nécessaires au respect de la protection des données au niveau local, c’est-à-dire dans l’application respective, mais cette approche est très complexe. Les systèmes les plus récents reposent sur une gestion centralisée des données, dans lesquels la connexion des applications existantes est techniquement complexe. Dans ce cas, il est souvent nécessaire de réimplémenter complètement les applications existantes.
Le brevet US 10 572 684 B2 décrit un système dans lequel des données personnelles sont stockées dans une base de données distribuée, de préférence dans une chaîne de blocs. Le brevet EP 1 226 524 A2 décrit un système dans lequel des données peuvent être partagées entre des entités. Avec ce système, il est également possible de libérer des données pour le système de soins de santé, la sécurité des données étant garantie au moyen d’un chiffrement et de certificats appropriés.
Le brevet EP 2 656 274 B1 décrit un système d’échange ou de mise à disposition de documents. Le système implémente une restriction d’accès qui permet de protéger les données personnelles.
En se basant sur cette technique antérieure, la présente invention a pour objet de créer un système efficace et sécurisé pour le stockage des données. En particulier, le système doit permettre d’intégrer facilement et efficacement les applications existantes.
L’objet est atteint par un système et par un procédé comme décrits ci-après.
En particulier, l’objet est atteint par un système de stockage de données, en particulier de données personnelles, qui comprend :
- une interface, en particulier une API REST ;
- un module d’authentification ;
- au moins une base de données cible pour le stockage des données ;
- un module d’accès aux données, conçu pour
a) recevoir des requêtes d’un ordinateur client au moyen de l’interface ;
b) interroger des données de l’au moins une base de données cible en réponse à la requête reçue ;
c) déterminer si l’ordinateur client et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et
d) générer un ensemble de données de réponse pour répondre à la requête et le transmettre à l’ordinateur client, au moins certaines données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée.
L’une des idées de la présente invention est de stocker les données dans des bases de données cibles (centrales). Les bases de données cibles possèdent un module d’accès aux données (central) en amont qui gère l’accès aux données. Le module d’authentification régule quelle application peut accéder à quelles données. Grâce à l’invention, il n’est donc plus possible pour les applications d’accéder directement aux données. Au lieu de cela, l’accès doit se faire par l’intermédiaire du module d’accès aux données, qui reçoit des requêtes, par exemple d’ordinateurs clients, par l’intermédiaire d’une interface de préférence prédéterminée. Les données demandées peuvent alors être interrogées, au moins en partie à partir des bases de données cibles. Comme expliqué précédemment, il est vérifié si et dans quelle mesure il existe une autorisation d’accès aux données interrogées ou demandées. Une réglementation d’accès correspondante peut être basée sur les utilisateurs et/ou les rôles et/ou les dispositifs, dans laquelle des applications individuelles peuvent se voir attribuer des comptes utilisateur, comme il est d’usage dans les systèmes d’exploitation courants. Selon l’invention, d’autres concepts d’authentification connus sont également concevables.
Afin de répondre à la requête, le module d’accès aux données est conçu selon l’invention pour générer un ensemble de données de réponse et pour le transmettre à l’ordinateur client, les éléments de données individuels dans l’ensemble de données de réponse étant anonymisés. Une anonymisation correspondante peut être effectuée en ligne - c’est-à-dire au moment de l’interrogation - ou hors ligne - à un moment antérieur à la requête, par exemple lors de la collecte des données ou dans le cadre d’une routine de nuit.
Dans un mode de réalisation de l’invention, l’interface utilisée pour interroger et/ou fournir les données est une interface basée sur un REST (« transfert d’état représentationnel »). Une API REST correspondante peut être implémentée en tant que service Web et permet de traiter les requêtes de manière efficace.
Dans un mode de réalisation, le système comprend un pilote de base de données, installé en particulier sur au moins un ordinateur client, qui est configuré pour communiquer avec l’interface. Un pilote de base de données correspondant peut être un pilote JDBC. Des modules d’accès à des bases de données très sophistiqués existent sur de nombreux systèmes d’exploitation existants. Beaucoup de ces modules d’accès aux bases de données sont basés sur une ODBC. Ainsi, les applications sur les ordinateurs clients n’accèdent pas directement à la source de données, mais utilisent les pilotes ODBC installés pour implémenter l’accès approprié. Par rapport aux pilotes ODBC classiques, les API REST sont relativement récentes. L’invention envisage de fournir des pilotes ODBC, en particulier des pilotes JDBC, qui permettent aux applications de communiquer avec l’interface du système selon l’invention par l’intermédiaire de ces pilotes. Leur accès au système est donc clairement structuré et les applications existantes peuvent communiquer avec le système au moyen du pilote ODBC ou du pilote JDBC. Le coût d’une migration est donc extrêmement faible, en particulier si l’on considère que le système selon l’invention peut se comporter comme une base de données cible classique malgré les fonctionnalités supplémentaires des modules d’authentification et d’accès aux données.
Dans un mode de réalisation, le module d’accès aux bases de données comprend une unité d’analyse qui est conçue pour recevoir une chaîne de caractères avec une expression SQL et pour extraire les noms de champs de l’expression SQL. Les configurations peuvent tout de même être appliquées à l’interrogation SQL dans le module d’accès aux bases de données.
Il est possible d’implémenter le pilote de base de données de manière à ce qu’il traduise en grande partie automatiquement une requête SQL en une requête qui est transmise à l’interface. Par exemple, dans un mode de réalisation, la requête SQL est traduite en une requête qui est conforme à la norme REST. Dans un mode de réalisation, une unité d’analyse est utilisée à cet effet, qui, par exemple, extrait les noms de tables et/ou les noms de colonnes de l’expression SQL ou de la requête ODBC. Ces données peuvent être utilisées pour créer des requêtes de données spécifiques par l’intermédiaire de l’interface. Par exemple, une requête GET peut être envoyée par l’intermédiaire d’un HTTP, les noms de tables et/ou les noms de colonnes indiquant la ressource à interroger.
Dans un (autre) mode de réalisation, la requête SQL est encapsulée sous forme de chaîne de caractères dans une requête REST ou un appel REST qui est envoyé à l’interface.
Dans un mode de réalisation, le système comprend une base de données stockant une pluralité de rôles et/ou d’utilisateurs, des autorisations étant attribuées à chacun des rôles/utilisateurs. Il est possible d’utiliser le concept d’authentification des bases de données cibles individuelles afin de permettre au système, en particulier au module d’authentification, de gérer l’accès. Dans un mode de réalisation préféré, une base de données (distincte) est utilisée pour gérer les rôles et/ou les utilisateurs sur l’ensemble des bases de données cibles et pour leur attribuer des autorisations.
Le module d’authentification peut être conçu pour attribuer au moins une sélection de requêtes reçues au moyen de l’interface à au moins un rôle ou utilisateur de la base de données et, sur la base de l’autorisation attribuée, pour déterminer quelles données sont transmises en réponse à la requête respective au moyen de l’interface.
Dans un mode de réalisation, le module d’authentification peut décider de refuser complètement à un utilisateur ou à un rôle l’accès à certaines données. Dans un (autre) mode de réalisation, les autorisations affectent quelle base de données cible et/ou quels sous-composants (par exemple, tables et/ou vues) d’une base de données cible particulière sont interrogés. Selon l’invention, il est également possible de sélectionner au moins une fonction d’anonymisation, sur la base de l’autorisation, afin d’anonymiser des données spécifiques d’une base de données cible (en ligne).
Dans un mode de réalisation, le système, en particulier un module de gestion de configuration, est conçu pour générer et stocker des bases de données et/ou des vues cibles (par exemple, des vues appelées vues SQL) pour différents utilisateurs et/ou rôles en fonction d’autorisations prédéterminées et/ou attribuées. Dans un mode de réalisation, il existe plusieurs bases de données et/ou vues cibles pour un ensemble de données initiales, les bases de données et/ou vues cibles individuelles étant différentes en ce qu’elles sont anonymisées à des degrés différents. Par exemple, une première vue peut délivrer les données initialement enregistrées par le module de gestion de configuration, tandis qu’une seconde vue ne montre qu’une partie des données initialement enregistrées, des ensembles de données ayant été supprimés et/ou des entrées ayant été anonymisées, par exemple.
L’anonymisation hors ligne est donc réalisée dans ce mode de réalisation, les données étant éventuellement dupliquées ou délivrées différemment sur la base de différentes vues. Cette approche a comme avantage de pouvoir répondre très efficacement aux requêtes. Il est également possible d’enregistrer et donc de documenter les états et donc les différents degrés d’anonymisation des tables/vues/champs individuels.
Comme expliqué précédemment, le système peut être conçu pour sélectionner une base de données cible parmi une pluralité de bases de données cibles pour les requêtes sur l’interface, laquelle base de données contient les données permettant de répondre à la requête.
Dans un mode de réalisation, le module d’authentification est conçu pour
a) attribuer un rôle et/ou un utilisateur à la requête ;
b) déterminer si la base de données cible est une base de données relationnelle ; et
c) si la base de données cible est une base de données relationnelle, utiliser le rôle ou les informations relatives à l’utilisateur pour sélectionner une vue parmi une pluralité de vues ;
d) utiliser la vue sélectionnée pour répondre à la requête.
L’utilisation de vues a comme avantage, du moins en ce qui concerne les bases de données SQL, de ne pas dupliquer les données ad libitum, tandis qu’un concept d’accès efficace peut être implémenté en même temps.
Dans un mode de réalisation, le système, en particulier le module de gestion de configuration, est conçu pour générer et stocker des copies pour différents utilisateurs et/ou rôles pour une base de données de hachage cible (distribuée), qui est utilisée comme base de données cible, en fonction d’autorisations prédéterminées et/ou attribuées. Les bases de données de hachage de copies créées de cette façon peuvent avoir différents degrés d’anonymisation, comparables aux vues ou aux tables SQL déjà expliquées.
Dans un mode de réalisation, il existe une corrélation entre les différentes autorisations et les différentes bases de données de hachage cibles. Dans un mode de réalisation, il existe des corrélations entre les différents rôles et les bases de données de hachage de copies. Il s’agit donc de copies spécifiques aux rôles.
Une base de données non basée sur SQL est appelée base de données de hachage au sens de la présente invention. Il peut s’agir d’une base de données qui stocke des paires clé-valeur. La base de données de hachage peut être une base de données distribuée telle que DynamoDB®d’Amazon. Les bases de données de hachage correspondantes sont très performantes en termes de réponse aux requêtes. Ces performances ne sont pas affectées par la création des copies. Les performances du système peuvent encore être améliorées en répartissant habilement les copies individuelles sur différents serveurs.
Dans un mode de réalisation, le système est conçu pour sélectionner une base de données cible parmi une pluralité de bases de données cibles pour des requêtes sur l’interface, laquelle base de données contient les données permettant de répondre à la requête. Dans ce contexte, le module d’authentification peut également être conçu pour
a) attribuer un rôle et/ou un utilisateur à la requête ;
b) déterminer si la base de données cible est une base de données de hachage ; et
c) si la base de données cible est une base de données de hachage, utiliser le rôle ou les informations relatives à l’utilisateur pour sélectionner une base de données de hachage de copies parmi une pluralité de bases de données de hachage de copies à utiliser pour répondre à la requête.
Dans un mode de réalisation (préféré), les bases de données SQL et les bases de données non SQL, en particulier les bases de données de hachage, coexistent en parallèle. Dans ce contexte, l’anonymisation des bases de données SQL s’effectue selon différentes approches. Par exemple, les bases de données SQL peuvent être anonymisées en fournissant des vues différentes et les bases de données non SQL en dupliquant des données individuelles (cf. bases de données de hachage de copies). Le système connaît au moins ces deux approches d’anonymisation et, lorsqu’il répond à une requête, détermine l’entité (vue ou copie) qui doit être utilisée avec l’autorisation donnée. Ainsi, malgré l’anonymisation nécessaire, différentes implémentations de bases de données peuvent être utilisées. En particulier, les différentes implémentations de bases de données peuvent être adaptées à la manière dont les données peuvent être stockées et interrogées le plus efficacement possible. La protection nécessaire des données peut donc être implémentée indépendamment de l’implémentation spécifique de la base de données respective. La technologie spécifique utilisée pour implémenter les bases de données respectives n’est pas transparente pour un accès externe (par l’intermédiaire des interfaces) afin de permettre un accès uniforme.
Dans un mode de réalisation, le système comprend un module de contexte de collecte de données qui est conçu pour stocker un contexte de collecte de données pour au moins une sélection d’ensembles de données sur l’au moins une base de données cible. Le contexte de collecte de données peut être, par exemple, un moment où les données ont été collectées, un objectif de la collecte de données, une période de conservation des données, une base juridique pour la collecte de données, des informations sur les politiques de conservation associées, etc. En déterminant le contexte de collecte de données, il est possible d’initier différentes formes d’anonymisation sur la base de ces données. Des politiques de conservation partiellement ou totalement automatisées peuvent également être implémentées pour des données individuelles. À cette fin, le système, en particulier le module de gestion de configuration, peut être conçu pour sélectionner des données en fonction du contexte de collecte de données et pour stocker les données sélectionnées sous une forme anonymisée.
Dans un mode de réalisation, au moins une partie des données d’au moins une base de données cible est cryptée, le système étant conçu pour recevoir un jeton de sécurité et, sur la base du jeton de sécurité, pour déterminer si l’ordinateur client émettant l’interrogation est autorisé à communiquer avec le système et/ou à recevoir les données interrogées. Une base de données de clés peut être fournie à cette fin, le système étant conçu pour utiliser la base de données de clés afin de sélectionner une clé qui est utilisée pour décrypter les données cryptées, en particulier de l’au moins une base de données cible.
Le système selon l’invention peut donc également assurer une fonction de gestion de clés, un ordinateur client/utilisateur réalisant l’interrogation étant authentifié et le système sélectionnant les clés pour un accès à des données de chiffrement individuelles dans les bases de données cibles en fonction de son propre concept d’authentification. Au moyen du pilote décrit ci-dessus et du système selon l’invention, il est donc également possible d’implémenter un système d’authentification pour des applications plus anciennes s’exécutant sur les ordinateurs clients, qui est implémenté de manière uniforme sur l’ensemble des requêtes d’accès.
L’objet mentionné au début est également atteint grâce à un procédé permettant de répondre à au moins une requête au moyen d’un ensemble de données de réponse, le procédé comprenant les étapes suivantes :
a) réception d’au moins une requête par l’intermédiaire d’une interface, en particulier d’une API REST ;
b) interrogation des données d’au moins une base de données cible en réponse à la requête reçue ;
c) détermination si l’ordinateur client et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et
d) transmission d’au moins un ensemble de données de réponse pour répondre à la requête, au moins une partie des données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée.
Ce procédé présente des avantages, comme cela a déjà été expliqué en rapport avec le système. Le procédé peut être mis en œuvre sur le système qui a déjà été expliqué. La description du système se traduit par des étapes de procédé implicites pour le procédé selon l’invention, qui le définissent plus en détail dans différents modes de réalisation.
L’objet mentionné au début est également atteint grâce à une mémoire lisible par ordinateur contenant des instructions pour l’implémentation du procédé mentionné ci-dessus, en particulier lorsque les instructions sont exécutées sur au moins une unité de traitement. Les avantages sont ici aussi similaires à ceux déjà décrits en rapport avec le système selon l’invention.
D’autres modes de réalisation avantageux sont obtenus à partir des revendications dépendantes.
L’invention est décrite ci-dessous au moyen de plusieurs exemples de modes de réalisation, qui sont expliqués plus en détail en référence aux illustrations. Dans les figures :
la montre une représentation schématique du système selon l’invention, qui est connecté en communication à un ordinateur client par l’intermédiaire d’Internet ;
la montre une illustration schématique détaillée du système selon l’invention selon la ; et
la montre une représentation schématique de données différemment anonymisées.
Dans la description ci-dessous, les mêmes numéros de référence sont utilisés pour les parties identiques et agissant de la même manière.
La montre un ordinateur client 10 qui est connecté en communication à un exemple de mode de réalisation du système 100 selon l’invention par l’intermédiaire de l’Internet 1. Au niveau d’abstraction indiqué, le système 100 comprend une base de données relationnelle 30 et une base de données de hachage, par exemple une base de données DynamoDB®d’Amazon.
Différentes applications peuvent être installées sur l’ordinateur client 10, qui communique généralement avec une base de données par l’intermédiaire d’une interface ODBC. Dans l'exemple de mode de réalisation présenté, un pilote de base de données 12 est fourni, qui permet aux applications de communiquer avec une API REST 105 (cf. ) du système 100 par l’intermédiaire d’un pilote JDBC.
La montre le système 100, certains composants logiciels étant mis en évidence de manière schématique. Ces composants logiciels comprennent :
Nom du composant Description du composant
Module d’importation de données Composant responsable de la prise en charge de :
- l’authentification de fournisseurs de données externes (par exemple, des systèmes hospitaliers)
- le chiffrement des données fournies par les fournisseurs de données externes
- la réception et lestockagedes données fournies par les fournisseurs de données externes
Module d’exportation de données Composant responsable de la prise en charge de :
- l’authentification des systèmes externes auxquels les données sont mises à disposition
- le chiffrement des données mises à la disposition des systèmes externes,
- la fourniture de données persistantes pour des systèmes externes
Module de flux de données Composant qui est responsable de :
- l’exécution de flux de données entre différents magasins de données
- la prise en charge de la configurabilité de tels flux de données, le cas échéant
- la prise en charge de la surveillance et de la gestion opérationnelles de tels flux de données

Ce composant gère les flux de données entre les magasins de données suivants :
- les magasins de données utilisés par le module d’importation de données
- les magasins de données utilisés par le module d’exportation de données
- la base de données SQL
- la base de données de hachage
Module d’accès aux données Composant qui implémente l’accès aux données et prend en charge l’anonymisation. Ce composant accède aux données en réalisant séquentiellement les mêmes étapes encore et encore, selon un mode de réalisation, en tenant compte des points suivants :
- le contexte de collecte de données de l’accès aux données
- les configurations d’authentification, de sécurité et de confidentialité des données de l’accès aux données
- la logique de sécurité à appliquer à l’accès aux données
- la logique de technologie de protection des données à appliquer à l’accès aux données
- les pistes d’audit à utiliser pour l’accès aux données
- les opérations d’accès physique aux données pour les bases de données SQL et de hachage

Ce composant délègue une grande partie de ses fonctionnalités aux modules appropriés par l’intermédiaire de ses points de terminaison définis.
Proxy de base de données SQL
(Proxy de magasin de données SQL d’applications basées sur FRAPPiD)		 Composant qui intercepte les appels vers la base de données SQL pour acheminer l’accès aux données par le biais de la logique du module d’accès aux données. Ce composant peut créer des dépendances côté client (par exemple, des bibliothèques, des paquets, des modules) requises pour les environnements d’exécution pris en charge (par exemple JVM, .NET, Python) et les systèmes d’exploitation (par exemple « .dll » de Windows, « .so », « .a » de Linux).
Proxy de base de données non SQL
(Proxy de magasin de données NoSQL d’applications basées sur FRAPPiD)		 Composant qui intercepte les appels vers les bases de données non SQL pour acheminer l’accès aux données par le biais de la logique du module d’accès aux données. Ce composant peut créer des dépendances côté client (par exemple, des bibliothèques, des paquets, des modules) requises pour les environnements d’exécution pris en charge (par exemple JVM, .NET, Python) et les systèmes d’exploitation (par exemple « .dll » de Windows, « .so », « .a » de Linux).
Base de données SQL
(magasin de données SQL d’applications basées sur FRAPPiD)		 Composant qui stocke les données des applications dans l’un des magasins de données SQL pris en charge. L’accès à ce composant se fait presque exclusivement par l’intermédiaire du module d’accès aux données.
Base de données de hachage
(magasin de données NoSQL d’applications basées sur FRAPPiD)		 Composant qui stocke les données des applications dans l’un des magasins de données non SQL pris en charge, tel qu’une base de données de hachage. Dans un mode de réalisation, l’accès à ce composant se fait (presque) exclusivement par l’intermédiaire du module d’accès aux données.
Module de contexte de collecte de données Composant qui est responsable de fournir :
- le contexte de collecte de données
- l’IU de gestion pour gérer les données de contexte de collecte de données
- la persistance des informations de contexte de collecte de données

La base juridique pour la collecte de données peut comprendre, mais sans s’y limiter :
- les attributs de données liés au consentement de la personne concernée
- les attributs de données liés à l’accord relatif au traitement des données conclu avec le responsable du traitement des données
- les attributs de données liés à une obligation légale qui requiert la collecte de données
- les attributs de données liés aux intérêts vitaux de la personne concernée
- les attributs de données liés à l’intérêt public
Module de gestion de configuration Composant qui est responsable de fournir :
- la configuration de l’application par l’intermédiaire des points de terminaison définis
- l’IU pour le maintien des données de configuration de l’application
- l’IU pour le maintien des données de configuration de l’application
- la persistance des données de configuration de l’application
Module d’authentification Composant qui est responsable de :
- l’exécution d’une authentification supplémentaire avec des facteurs d’authentification (par exemple, des certificats clients, des mots de passe à usage unique, des notifications push, des courriels de confirmation, des courriels de notification, des questions de sécurité)
- la gestion, l’émission, le déploiement, la vérification de ces facteurs d’authentification supplémentaire
Module d’ingénierie de sécurité Composant qui est responsable de fournir :
- le wrapper pour les procédés de chiffrement pris en charge sur des points de terminaison définis
- le wrapper pour les procédés de hachage pris en charge sur des points de terminaison définis
- la fonctionnalité permettant de gérer, de fournir et d’appliquer les clés de chiffrement
- un ensemble d’API pour mettre les fonctions sélectionnées à la disposition des applications
Système de pistes d’audit Composant qui prend en charge une journalisation de protocole non réfutable de l’accès aux données comprenant l’accès aux points de terminaison et SQL à divers composants le long du chemin d’accès aux données.
Selon un aspect de l’invention, l’ordinateur client 10 communique avec le module d’accès aux données 110 par l’intermédiaire de l’API REST 105. Le module d’accès aux données représente un composant central du système 100 et organise essentiellement la réponse aux requêtes qui sont émises par l’ordinateur client 10. Dans l’exemple de mode de réalisation décrit, il existe des modules de connexion aux bases de données ou des proxys de bases de données entre l’API REST 105 et le module d’accès aux données 110. Ils peuvent être utilisés pour transférer les interrogations au module d’accès aux données 110 d’une manière spécifique à la base de données cible (cf. la base de données relationnelle 30 ou la base de données SQL ou la base de données de hachage 40). Dans l’exemple de mode de réalisation illustré, le module de gauche est un module de connexion à une base de données SQL 140 spécifique et le composant de droite est un module de connexion à une base de données pour les bases de données cibles non SQL.
La montre à titre d’exemple que les interrogations de données ne proviennent initialement pas de l’ordinateur client 10, mais des applications exécutées sur celui-ci.
Dans un mode de réalisation, l’application est une application qui habituellement communiquerait avec une base de données cible appropriée par l’intermédiaire d’une interface ODBC. Selon l’invention, comme expliqué précédemment, l’ordinateur client 10 possède un pilote de base de données 12 qui traduit une requête SQL soumise en une requête REST. Pour ce faire, le nom de table adressée est analysé à partir de la requête et les informations de champs spécifiques sont résolues. Des informations de champs non spécifiques, telles qu’un symbole de remplacement (« * »), peuvent également être traduites en noms de champs individuels, tant que la base de données cible est connue. Ainsi, les conditions typiques de SQL qui sont définies pour une requête spécifique (mot-clé : « WHERE ») peuvent également être traduites. Essentiellement, le pilote de base de données 12 génère une requête REST à partir de l’interrogation SQL et envoie cette requête REST au système 100 par l’intermédiaire de l’interface 105. L’interrogation y est traitée, entre autres, par le module d’accès aux données 110.
Le module d’accès aux données 110 sélectionne une base de données cible, dans l’exemple la base de données relationnelle 30, par exemple sur la base des données fournies par le module de connexion à une base de données 140.
Dans un mode de réalisation, le module d’accès aux données 110 détermine également dans quelle mesure les données initiales ou les données partiellement anonymisées peuvent être fournies en réponse à la requête. Par exemple, un rôle spécifique au sein du système 100 peut être attribué à l’application effectuant la requête sur l’ordinateur client 10 sur la base des informations d’identification. Ce rôle peut être associé à une vue de base de données relationnelle 30 particulière.
La montre deux vues différentes, à savoir une vue de base de données complète 31 et une vue de base de données au moins partiellement anonymisée 32. À titre d’exemple, les tables ou les vues montrées peuvent être des données de patients. Alors que dans la vue de base de données complète 31, le nom, la date de naissance exacte et le groupe sanguin sont indiqués, la vue de base de données anonymisée 32 ne contient que l’année de naissance et aucune information sur le groupe sanguin en plus du nom. Le groupe sanguin a simplement été fixé à une valeur nulle (« NULL ») pour générer la vue de base de données anonymisée 32.
Après sélection de l’une de ces vues, les données appropriées peuvent être renvoyées du module d’accès aux données 110 à l’application sur l’ordinateur client 10 par l’intermédiaire de l’API REST 105. À cet égard, il est facilement possible de fournir des données sous une forme clairement structurée et anonymisée.
L’approche montrée sur la au moyen de différentes vues a comme avantage que les ensembles de données ne doivent exister qu’une seule fois dans la base de données relationnelle 30 et que les fonctions d’anonymisation nécessaires sont exécutées en ligne lors de l’interrogation des ensembles de données.
Une approche nettement différente peut être utilisée pour les bases de données non basées sur SQL. En utilisant la base de données de hachage 40 comme exemple, il est possible de créer des copies d’une base de données de hachage initiale et d’y écraser définitivement certaines valeurs. À ce titre, en fonction du rôle attribué, pour une interrogation adressée à la base de données de hachage 40, le module d’accès aux données 110 sélectionnera la base de données de hachage associée au rôle utilisateur de l’application effectuant l’interrogation. Cette approche présente l’avantage d’obtenir des performances élevées.
Dans l’exemple de mode de réalisation décrit, les deux approches sont poursuivies en parallèle en fonction de l’implémentation technique de la base de données cible respective. Toutefois, selon l’invention, il est également concevable de n’implémenter qu’une seule de ces approches dans un système 100.
Dans un mode de réalisation, le système 100 comprend un module de contexte de collecte de données 150. Ce module de contexte de collecte de données peut être conçu pour collecter des données et les stocker dans les bases de données cibles, par exemple dans la base de données relationnelle 30 ou dans la base de données de hachage 40. Dans le cadre de ce processus de collecte, des informations supplémentaires identifiant le contexte de collecte de données peuvent être stockées. Une base de données séparée peut être fournie à cette fin. Les données contextuelles ou le contexte de collecte de données peuvent comprendre :
- un identifiant unique d’un contexte de collecte de données
- une portée de collecte de données
- une finalité de collecte de données
- une durée de collecte de données
- une base juridique pour la collecte de données
- les règles de conformité en matière de protection des données applicables.
Ces données contextuelles peuvent être utilisées pour déterminer les étapes d’anonymisation nécessaires initialement pour les données stockées. De plus, le contenu des bases de données cibles peut être modifié en fonction de la séquence temporelle. Par exemple, il est concevable que certaines données ne puissent être conservées que pendant une certaine période. À cet égard, le système 100 selon l’invention permet de supprimer des données en fonction du contexte à un moment spécifique. De plus, ou en variante, il peut être prévu que des données spécifiques puissent être mises à la disposition du grand public ou d’applications spécifiques après un moment spécifié. À cet égard, il n’est absolument pas nécessaire que le degré d’anonymisation augmente avec le temps. Théoriquement, des scénarios sont également concevables dans lesquels il y a moins d’informations d’anonymisation à un moment ultérieur.
Les mécanismes décrits ne se limitent pas non plus aux informations purement temporelles. Par exemple, le contexte peut indiquer la finalité pour laquelle certaines données ont été collectées et donc avoir une influence sur quels rôles d’accès sont autorisés à interroger certaines données.
Signes de référence
1 Internet
10 Ordinateur client
12 Pilote de base de données
30 Base de données relationnelle
31 Vue de base de données complète
32 Vue de base de données anonymisée
40 Base de données de hachage
100 Système
105 API REST
110 Module d’accès aux données
120 Module de gestion de configuration
130 Module d’authentification
140 Module de connexion à une base de données
150 Module de contexte de collecte de données

Claims (14)

  1. Système de stockage de données, en particulier de données personnelles,
    comprenant :
    - une interface (105), en particulier une API REST ;
    - un module d’authentification (130) ;
    - au moins une base de données cible (30, 40) pour le stockage des données ;
    - un module d’accès aux données (110) qui est conçu pour
    a) recevoir des requêtes d’un ordinateur client (10) au moyen de l’interface ;
    b) interroger des données de l’au moins une base de données cible (30, 40) en réponse à la requête reçue ;
    c) déterminer si l’ordinateur client et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et
    d) générer un ensemble de données de réponse pour répondre à la requête et le transmettre à l’ordinateur client, au moins certaines données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée.
  2. Système selon la revendication 1,
    comprenant :
    un pilote de base de données (12), installé en particulier sur au moins un ordinateur client (10), en particulier un pilote JDBC, qui est configuré pour communiquer avec l’interface (105).
  3. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    le pilote de base de données (12) comprend une unité d’analyse, qui est conçue pour recevoir une chaîne de caractères avec une expression SQL et pour extraire les noms de champs de l’expression SQL, en particulier des tables de bases de données, afin de créer une interrogation pour une transmission à l’interface (105) en utilisant au moins une sélection des noms de champs et/ou
    le pilote de base de données (12) est conçu pour encapsuler l’expression SQL dans une requête REST, par exemple sous forme de chaîne de caractères, et délivrer la requête sur l’interface (105).
  4. Système selon l’une quelconque des revendications précédentes,
    caractérisé par :
    une base de données, qui stocke une pluralité de rôles et/ou d’utilisateurs, les rôles et/ou utilisateurs se voyant attribuer des autorisations respectives,
    dans lequel le module d’authentification (130) est conçu pour recevoir au moins une sélection de requêtes, qui sont reçues au moyen de l’interface (105) pour attribuer au moins un rôle ou utilisateur de la base de données et, sur la base de l’autorisation attribuée, pour déterminer quelles données sont transmises au moyen de l’interface (105) en réponse à la requête respective.
  5. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    le système, en particulier un module de gestion de configuration (120), est conçu pour différents utilisateurs et/ou rôles en fonction d’autorisations prédéterminées et/ou attribuées, en particulier pour une base de données cible relationnelle (30, 40), pour générer et stocker des vues (31, 32) pour au moins une table cible, la vue (31, 32) étant configurée de préférence en fonction des autorisations de telle manière que les valeurs de la table cible sont remplacées par des valeurs anonymisées.
  6. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    le système est conçu pour sélectionner une base de données cible parmi une pluralité de bases de données cibles (30, 40) pour des requêtes sur l’interface (105), qui contient les données pour répondre à la requête, et/ou
    le module d’authentification est conçu pour
    a) attribuer un rôle et/ou un utilisateur à la requête ;
    b) déterminer si la base de données cible est une base de données relationnelle ; et
    c) si la base de données cible est une base de données relationnelle (30), utiliser le rôle ou les informations relatives à l’utilisateur pour sélectionner une vue parmi une pluralité de vues (31, 32) à utiliser pour répondre à la requête.
  7. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    le système, en particulier un module de gestion de configuration (120), est conçu pour différents utilisateurs et/ou rôles en fonction d’autorisations prédéterminées et/ou attribuées pour une base de données de hachage cible (distribuée), qui est utilisée comme base de données cible, en particulier pour générer et stocker des copies spécifiques aux rôles sous la forme d’une base de données de hachage de copies, la base de données de hachage de copies étant de préférence modifiée en fonction des autorisations, de sorte que les valeurs (sélectives) de la base de données de hachage cible sont remplacées par des valeurs anonymisées.
  8. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    le système est conçu pour sélectionner une base de données cible parmi une pluralité de bases de données cibles (30, 40) pour des requêtes sur l’interface (105), qui contient les données pour répondre à la requête, et/ou
    le module d’authentification est conçu pour
    a) attribuer un rôle et/ou un utilisateur à la requête ;
    b) déterminer si la base de données cible est une base de données de hachage ; et
    c) si la base de données cible est une base de données de hachage, utiliser le rôle ou les informations relatives à l’utilisateur pour sélectionner une base de données de hachage de copies parmi une pluralité de bases de données de hachage de copies à utiliser pour répondre à la requête.
  9. Système selon l’une quelconque des revendications précédentes,
    caractérisé par :
    un module de contexte de collecte de données (150), qui est conçu pour stocker un contexte de collecte de données pour au moins une sélection d’ensembles de données sur l’au moins une base de données cible, par exemple un moment de la collecte de données, un objectif de la collecte de données, une période de conservation des données, une base juridique pour la collecte de données, des détails sur les politiques de conservation associées.
  10. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    le système, en particulier un module de gestion de configuration (120), est conçu pour sélectionner des données en fonction du contexte de collecte de données et pour stocker les données sélectionnées sous une forme anonymisée.
  11. Système selon l’une quelconque des revendications précédentes,
    caractérisé en ce que
    au moins certaines données de l’au moins une base de données cible (30, 40) sont cryptées, le système, en particulier un module d’authentification (en haut à droite) étant conçu pour recevoir un jeton de sécurité et, sur la base du jeton de sécurité, déterminer si l’ordinateur client (30) émettant l’interrogation est autorisé à communiquer avec le système et/ou à recevoir les données interrogées.
  12. Système selon l’une quelconque des revendications précédentes,
    caractérisé par :
    une base de données de clés, le système étant conçu pour utiliser la base de données de clés afin de sélectionner une clé qui est utilisée pour décrypter les données cryptées, en particulier de l’au moins une base de données cible (30, 40).
  13. Procédé permettant de répondre à au moins une requête au moyen d’un ensemble de données de réponse, en utilisant un système selon l’une quelconque des revendications précédentes,
    comprenant les étapes :
    a) réception d’au moins une requête par l’intermédiaire d’une interface (105), en particulier d’une API REST ;
    b) interrogation des données de l’au moins une base de données cible (30, 40) en réponse à la requête reçue ; et
    c) détermination si l’ordinateur client (10) et/ou l’utilisateur a l’autorisation de réaliser l’interrogation ; et
    d) transmission d’au moins un ensemble de données de réponse pour répondre à la requête, au moins certaines données de l’ensemble de données de réponse étant anonymisées si une autorisation restreinte est déterminée.
  14. Mémoire lisible par ordinateur contenant des instructions pour l’implémentation du procédé de la revendication 13) lorsque les instructions sont exécutées sur au moins une unité de traitement.
FR2403700A 2023-04-12 2024-04-10 Système et procédé de stockage de données, en particulier de données personnelles Pending FR3147901A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023109178.6A DE102023109178B3 (de) 2023-04-12 2023-04-12 System und Verfahren zur Speicherung von Daten, insbesondere von personenbezogenen Daten
DE102023109178.6 2023-04-12

Publications (1)

Publication Number Publication Date
FR3147901A1 true FR3147901A1 (fr) 2024-10-18

Family

ID=91023583

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2403700A Pending FR3147901A1 (fr) 2023-04-12 2024-04-10 Système et procédé de stockage de données, en particulier de données personnelles

Country Status (6)

Country Link
US (1) US20240346171A1 (fr)
JP (1) JP2024152693A (fr)
CN (1) CN118796825A (fr)
DE (1) DE102023109178B3 (fr)
FR (1) FR3147901A1 (fr)
GB (1) GB2629254A (fr)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001033936A2 (fr) 1999-10-29 2001-05-17 Privacomp, Inc. Systeme base sur un consentement informe dynamique de donnees assurant la confidentialite des donnees et la securite dans les systemes de base de donnees et dans les communications sur reseau.
US9892279B2 (en) 2010-12-22 2018-02-13 Koninklijke Philips N.V. Creating an access control policy based on consumer privacy preferences
US10572684B2 (en) 2013-11-01 2020-02-25 Anonos Inc. Systems and methods for enforcing centralized privacy controls in de-centralized systems
US20150235049A1 (en) * 2014-02-20 2015-08-20 International Business Machines Corporation Maintaining Data Privacy in a Shared Data Storage System
KR102699431B1 (ko) * 2018-06-07 2024-08-28 콘비다 와이어리스, 엘엘씨 서비스 가입자의 프라이버시를 위한 데이터 익명화

Also Published As

Publication number Publication date
DE102023109178B3 (de) 2024-08-29
GB202404543D0 (en) 2024-05-15
GB2629254A (en) 2024-10-23
CN118796825A (zh) 2024-10-18
JP2024152693A (ja) 2024-10-25
US20240346171A1 (en) 2024-10-17

Similar Documents

Publication Publication Date Title
US11228425B2 (en) Data storage method, data query method and apparatuses
EP3343425B1 (fr) Système et procédé pour la création et la gestion d'autorisations décentralisées pour des objets connectés
CN111316278B (zh) 安全身份和档案管理系统
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
EP2819052B1 (fr) Procédé et serveur de traitement d'une requête d'accès d'un terminal à une ressource informatique
FR3079323A1 (fr) Methode et systeme d'acces a des donnees anonymisees
US20060143189A1 (en) Database access control method, database access controller, agent processing server, database access control program, and medium recording the program
US8464313B2 (en) Methods and apparatus related to transmission of confidential information to a relying entity
US20240220652A1 (en) Data processing apparatus and methods
US11841960B1 (en) Systems and processes for providing secure client controlled and managed exchange of data between parties
US20240177143A1 (en) Intermediary roles in public trust ledger actions via a database system
US20170132738A1 (en) Sexual activity consent tracking
WO2020136206A1 (fr) Plateforme de sécurisation de données
AU2021359309A9 (en) Secure cloud storage and retrieval of client-side encrypted data
FR3147901A1 (fr) Système et procédé de stockage de données, en particulier de données personnelles
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
EP4078893A1 (fr) Procédé et dispositif de contrôle d'accès anonyme à une plateforme collaborative d'anonymisation
FR3031824A1 (fr) Procede de securisation de donnees par anonymisation et serveur associe
FR3147659A1 (fr) Gestion de l’accès à des données de consentement de patients
FR3129504A1 (fr) Procédés, terminal et serveur de gestion de données personnelles
FR3152901A1 (fr) Procédé informatique
FR3044192A1 (fr) Procede de distribution de droits sur un service et plateforme de service
FR2862827A1 (fr) Procede de gestion de donnees de securite