AgentPublic/cnil huggingface dataset:
une description détaillée des données partagées, de leur fréquence d’échantillonnage, des opérations réalisées en amont de leur partage, telles que des processus de pseudonymisation ou d’anonymisation ;
des informations concernant les accès aux données réalisés via l’API, telles que leur fréquence, leur volume ou leur profondeur historique ;
les objectifs de sécurité visés.
26. Ces informations devraient être mises à jour au gré de leur évolution, de manière automatisée lorsque le dispositif le permet. Les modifications devraient être portées à la connaissance des personnes concernées de manière individuelle lorsqu’elles changent substantiellement la nature du partage, notamment lorsque les données sont partagées pour une nouvelle finalité ou lorsque les restrictions d’accès les concernant évoluent de façon significative.
27. La Commission recommande que les informations précédemment citées soient a minima présentées sur un site web porté à l’attention des personnes ou qu’elles leur soient communiquées directement, sous un format accessible et compréhensible. Lorsque cela est pertinent au regard du niveau de risque évalué, en particulier au regard du besoin de confidentialité des données concernées, ainsi que de la criticité du traitement, l'accès à ces informations devra être sécurisé au moyen d'une méthode d'authentification conforme aux recommandations de la Commission, telle que FranceConnect dans la sphère publique.
Sur la sélection des données
28. Pour assurer le respect des textes en vigueur encadrant d’ores et déjà le partage de données, et en application du principe de minimisation, la Commission encourage le détenteur de données à mener une réflexion avec les réutilisateurs des données sur les données strictement nécessaires aux réutilisations que chacun d’eux prévoit, pour limiter le partage à ces seules données dans le respect des éventuels textes encadrant le partage, en particulier lorsque celui-ci implique des organismes publics. À cet égard, elle souligne les éléments suivants.
29. Les catégories de données, leur format, leur profondeur historique, leur précision, leur fréquence d'échantillonnage, leur fréquence de mise à jour et les mesures de pseudonymisation ou d'anonymisation qui leur sont appliquées, devront notamment être choisies pour répondre strictement aux besoins relatifs aux réutilisations prévues.
30. Le détenteur de données devrait poursuivre cette réflexion avec les réutilisateurs après l'ouverture des accès, afin de recueillir leurs retours, notamment lorsque ces derniers n'ont pas pu être inclus dans la réflexion initiale.
31. Les données concernées par le partage devraient être fréquemment recensées, afin d'identifier celles dont le partage ne serait plus pertinent et d'y mettre fin. Le format des données choisi devrait être pérenne, univoque et documenté pour limiter les risques liés à une erreur d’interprétation humaine ou logicielle.
32. Afin de garantir que les données partagées par l'API soient au format attendu, l'utilisation d'un outil de validation des données est recommandée.
33. L'infrastructure technique, le format des données et les modalités d’interrogation de l’API, telles que le niveau de précision autorisé dans les requêtes, devraient être choisis pour respecter au mieux les recommandations précédentes et éviter le partage de données non pertinentes vis-à-vis de chacun des réutilisateurs, qu’il s’agisse des organismes ayant à connaître des données ou des personnes physiques appartenant à l’organisme réutilisateur lorsque plusieurs niveaux d’accès sont prévus au sein de cet organisme selon le niveau d’habilitation des personnes. Ces mesures devraient être intégrées directement dans l’API.
34. Enfin, lorsque les catégories de données pertinentes ne peuvent pas être précisément identifiées en amont du traitement, comme cela peut être le cas en matière de recherche, la Commission recommande qu’une phase d’expérimentation préalable soit mise en œuvre afin de vérifier la pertinence de certaines catégories sur des volumes restreints de données. Cette phase d'expérimentation, menée en coopération avec le gestionnaire d’API et les réutilisateurs, devrait permettre de confirmer la pertinence des choix faits et le respect des recommandations énoncées dans les paragraphes précédents. Cette phase d’expérimentation devrait utiliser l’infrastructure technique prévue en conditions réelles dans une version bac à sable et se limiter, autant que possible, à des données fictives ou altérées.
Sur l’exercice des droits sur le partage des données
35. Les droits des personnes concernées par un traitement consistant à partager leurs données au moyen d’une API recouvrent :
le droit d’accès, de rectification, d’effacement et de portabilité sur la base source utilisée par l’API ;
le droit à l’information sur les partages opérés ;
le droit à l’opposition ou au retrait du consentement au partage, ainsi que le droit à la limitation du traitement.
36. Recourir à une API permet d’automatiser un certain nombre d’opérations de traitement et de faciliter les demandes d’exercice des droits sur le partage, participant à leur prise en compte effective. Il est recommandé de limiter les opérations manuelles relatives au traitement de ces demandes.
37. Lorsqu’une personne concernée par le partage retire son consentement, exerce son droit d’opposition ou à la limitation, l’API devrait intégrer un dispositif technique permettant d’exclure automatiquement du champ du partage les données concernées.
38. Dans certains cas, comme lorsque la temporalité du traitement justifie une réponse rapide à une demande d’exercice des droits ou lorsqu’une erreur dans les données pourrait avoir des conséquences graves pour les personnes, l’API devrait également intégrer un dispositif spécifique permettant au détenteur de données d’informer chaque réutilisateur auquel les données ont été communiquées, de toute rectification, effacement de données ou limitation de traitement faisant suite à l’exercice des droits par les personnes concernées, cette information pouvant être obligatoire dans certains cas en vertu de l’article 19 du RGPD. De manière plus générale, ce dispositif devrait aussi permettre au détenteur d’informer activement les réutilisateurs sur les éventuelles restrictions aux réutilisations, qui pourraient notamment résulter de l’exercice des droits (p. ex. : opposition à certaines finalités de réutilisation). Il appartiendrait à ces derniers de les prendre en compte, de préférence de manière automatisée lorsque le dispositif prévu par le détenteur le permet.
39. Ce dispositif spécifique peut notamment reposer sur une API dédiée à la communication d’informations relatives à l’exercice des droits, un balisage des données (voir annexe I) ou sur l’association de métadonnées aux données lors de leur communication. En effet, l’utilisation d’un fichier indiquant les restrictions de réutilisation des données afin que celles-ci soient prises en compte par les réutilisateurs n’est pas à privilégier.
40. Il convient de noter que la base légale qui fonde le traitement de partage de données a des conséquences sur les droits des personnes concernées, certains droits pouvant être écartés en fonction de celle-ci ou en vertu de textes réglementaires.
Sur la gestion des accès
41. Lorsque l'API est soumise à une restriction d'accès ( API en accès restreint ), la Commission recommande que le mécanisme de demande d'accès mis en place exige de chaque réutilisateur qu’il apporte les informations nécessaires à la vérification de la licéité de son accès à l’API. Lorsque ce n’est pas obligatoire, il est généralement recommandé au réutilisateur d’informer le détenteur des données de la finalité pour laquelle il accède aux données, ainsi que des catégories de données nécessaires. La Commission recommande que le réutilisateur informe le détenteur du volume, de la profondeur historique, de la fréquence et du type de requêtes envisagés afin de dimensionner les moyens techniques à mettre en œuvre.
42. Dans le cas d'une API ouverte , la Commission recommande, à titre de bonne pratique, qu'un système de registre public facultatif et ne restreignant pas l’accès à l’API permette de connaître ces mêmes informations et l’identité des destinataires. Ce registre pouvant porter atteinte à la vie privée ou aux données à caractère personnel des destinataires, son opportunité doit être évaluée au cas par cas.
43. Le détenteur de données et le gestionnaire d’API devraient se coordonner pour mettre en œuvre une procédure de gestion des accès et, le cas échéant, d’attribution des habilitations, répondant aux objectifs de sécurité, traçabilité et minimisation. Lorsque l'accès à l'API est soumis à une validation préalable, les procédures correspondantes devraient être formalisées au sein d'une politique de gestion des habilitations précisant les procédures d'attribution des secrets d’authentification, les conditions de leur transmission, de leur sauvegarde, de leur révocation et de leur renouvellement. L’authentification donnant accès à l’API devrait être réalisée par un système robuste et éprouvé de vérification de clé reposant sur des protocoles cryptographiques conformes aux recommandations de la Commission.
44. Les habilitations devraient être accordées selon plusieurs niveaux, ne donnant accès qu’aux données nécessaires au traitement et n’accordant que les permissions nécessaires. Cette différenciation peut avoir lieu par réutilisateur, mais aussi être mise en œuvre en interne par le réutilisateur afin de limiter les accès de ses agents ou employés aux données strictement nécessaires. Les accès devraient être donnés pour une durée déterminée, cohérente avec les besoins du réutilisateur et avec la durée de validité des données (certaines données, comme celles concernant la situation géographique ou encore financière des personnes par exemple, pouvant nécessiter des mises à jour régulières). En particulier, des accès à usage unique ou à très courte durée devraient être fournis pour réaliser des expérimentations ponctuelles. La sécurité du mécanisme d'authentification utilisé devrait être vérifiée et ses instructions d'utilisation rigoureusement suivies. Des mesures de sécurité devraient notamment être mises en place afin de protéger le système d’information des intrusions et des attaques par déni de service, par exemple en bloquant temporairement un accès après un nombre trop important de tentatives de connexions infructueuses. La possibilité devrait également être laissée aux réutilisateurs de révoquer unilatéralement leurs accès, notamment en cas de détection de compromission de leurs secrets d’authentification.
45. Lorsque les détenteurs de données réalisent le partage de leurs données au moyen d’une requête en écriture, les mesures de sécurité décrites dans le paragraphe précédent devraient leur être appliquées. Les droits d’écriture qui leur sont accordés devraient être limités à ce qui est strictement nécessaire, afin d’éviter la compromission de données déjà sauvegardées. Lorsque plusieurs bases coexistent, l’accès ne devrait être fourni qu’aux bases auxquelles le détenteur a besoin d’accéder. Une distinction entre les privilèges de lecture, d’ajout, de modification des données et de l’architecture de la base et d’écriture devrait être faite, afin de limiter les privilèges accordés à ceux strictement nécessaires.
46. Pour garantir la disponibilité des services pour les réutilisateurs de données, ces derniers devraient être notifiés à l’avance quand leur secret d’authentification arrive à expiration et un moyen de le renouveler sans interrompre leur service devrait leur être fourni.
Sur la gestion interne des API
47. La Commission recommande qu'une gouvernance dédiée soit mise en place chez chacun des acteurs pour le partage de données par voie d’API. Cette démarche devrait être documentée et faire l'objet d'un suivi régulier pour garantir son effectivité.
48. Une documentation facilement accessible à tous les intervenants ayant à en connaître devrait formaliser les procédures et, notamment, les protocoles d'urgence à mettre en œuvre en cas de survenance d’un événement concernant la sécurité des données. Cette documentation devrait également comporter une description technique permettant l’intégration, le développement, la mise à jour et l’interruption des systèmes liés aux API.
49. La Commission recommande qu’un outil de gestion des versions (voir annexe I) soit utilisé afin de suivre les modifications apportées au code source du système permettant le partage. Une procédure devrait permettre de revenir à une version antérieure du système lorsqu'un risque est identifié. Une attention particulière devrait être apportée au cloisonnement du code source sauvegardé sur cet outil et des données n'ayant pas à y figurer, telles que les clés de chiffrement, dont la présence peut être détectée grâce à un outil vérifié de recherche des secrets dans le code source (voir annexe I). D’une manière générale, l’écriture pérenne, ou en dur , de secrets dans le code source, devrait être évitée et l’utilisation d’un gestionnaire ou d’un détecteur de secrets devrait être privilégiée pour en éviter la divulgation ou pour la détecter.
50. Plus généralement, la gestion des API devrait s’inscrire dans la politique de sécurité des systèmes d’information de chacun des acteurs. Leur intégration devrait être prise en compte dans les procédures de sécurité existantes et ces dernières devraient être adaptées pour tenir compte des risques spécifiques aux API.
Article 3
Recommandations spécifiques à l'intention des détenteurs de données
Sur l’information des réutilisateurs
51. La Commission recommande que le détenteur de données tienne une documentation à jour à l'intention des réutilisateurs, concernant les données rendues accessibles. Cette documentation devrait fournir en termes clairs des informations générales telles que la provenance des données, la méthode de collecte utilisée, leur fréquence de mise à jour, leur format de transmission, leur profondeur historique, leur fiabilité et les procédés de pseudonymisation ou d'anonymisation utilisés. Le détenteur de données devrait s'assurer que les réutilisateurs ont pris connaissance de cette documentation avant tout accès effectif aux données.
52. La Commission recommande par ailleurs l'utilisation de métadonnées associées aux données ou à un groupe de données, indiquant par exemple la date de collecte des données, leur fiabilité ou encore leur durée de validité. Le détenteur de données devrait s'assurer de la fiabilité des métadonnées, en particulier lorsque celles-ci décrivent la qualité, le statut, la disponibilité de la donnée ou encore ses conditions de réutilisation.
53. Enfin, le détenteur de données devrait mettre en place un canal de communication avec les réutilisateurs de données, afin que ces derniers puissent signaler tout problème technique ou risque relatif à la confidentialité, l’intégrité et la disponibilité des données, notamment les risques de réidentification identifiés a posteriori. À cet égard, plusieurs points de contact devraient exister, en fonction du niveau d’urgence des signalements, permettant ainsi au détenteur de données de prendre connaissance des risques signalés dans les meilleurs délais.
Sur l’exactitude et l’intégrité des données
54. Le détenteur des données, généralement responsable du traitement de mise à disposition, doit accorder une attention particulière à l’exactitude et à l’intégrité des données avant et pendant leur transmission et mettre en place les mesures techniques et organisationnelles permettant de garantir que les réutilisateurs accèdent à des données exactes et à jour. En particulier, une vérification régulière de l’exactitude des données devrait être menée. Lorsqu’un risque particulier relatif à l’intégrité des données existe, des mesures reposant notamment sur des procédés cryptographiques, tels que des empreintes cryptographiques ou condensats (dits hachés ou hash ), devraient être utilisées pour la garantir.
55. Lorsque le détenteur de données réalise lui-même la transmission des données au réutilisateur au moyen d’une requête en écriture, il devrait s’assurer d’avoir suivi la procédure décrite pour garantir leur intégrité et éviter tout risque de compromission d’une partie ou de la totalité de la base existante. Le détenteur de données devrait porter une attention particulière aux messages retournés par le serveur distant, ceux-ci pouvant indiquer qu’une erreur a eu lieu lors d’une requête en écriture.
Sur la sécurité
Objectifs généraux
56. Le détenteur de données doit assurer la sécurité des données qu’il produit et qu’il confie au gestionnaire d’API pour mise à disposition aux réutilisateurs.
57. Le détenteur de données devrait étudier la sécurité du système prévu pour le partage de données en lien avec le gestionnaire d'API et informer ce dernier de tout risque de sécurité identifié. En particulier, la sécurité de l'interface entre l'API et la base de données devrait être rigoureusement vérifiée. En effet, un partage de données par voie d’API, en tant qu’interconnexion entre deux systèmes d’information, notamment lorsqu’un des deux appartient à une entité tierce, constitue une modification significative du système d’information. Ce changement devrait donc entraîner un renouvellement anticipé d’une éventuelle homologation du système d’information pour prendre en compte les menaces et risques résultant de cette interconnexion.
Cloisonnement et disponibilité
58. La Commission recommande que les données dont l'accès est prévu par l'API ( base source de l’API) soient séparées des autres catégories de données lorsque le partage de ces dernières n’est pas prévu et que leur divulgation pourrait entraîner des conséquences graves pour les personnes. En particulier, lorsqu'un procédé de pseudonymisation ou d'anonymisation est prévu, les données brutes devraient être physiquement ou logiquement séparées des données issues de ce procédé. La base source de l'API pourra alors être alimentée par un procédé d'exportation de données automatisé et sécurisé, sous réserve que la latence introduite par ce procédé n’entraîne pas d’indisponibilité des données.
59. Lorsque les réutilisations prévues par les réutilisateurs sont des traitements critiques dont une indisponibilité (même temporaire) pourrait entraîner des conséquences graves, le détenteur de données devrait accorder une importance particulière à la disponibilité des données. Il devrait mettre en place les mesures techniques nécessaires pour éviter une compromission ou une indisponibilité de la base de données et pour en limiter l’impact le cas échéant, comme la redondance des infrastructures ou la mise en œuvre régulière de tests d’intégrité des données et de leurs sauvegardes.
Authentification
60. Lorsque le détenteur de données s’authentifie pour accéder à l’API, ce qui peut être le cas notamment lorsqu’il réalise lui-même l’écriture sur la base du réutilisateur, il devrait mettre en place les mesures techniques et opérationnelles garantissant la sécurité des secrets d’authentification et, notamment, leur intégrité et leur confidentialité. Un système de sécurisation des secrets d’authentification adapté aux risques liés à une compromission de l’accès à l’API, tel qu’un coffre-fort numérique, devrait être utilisé. Lorsqu’un risque relatif à la sécurité des secrets est identifié, le réutilisateur devrait en informer le gestionnaire d’API dans les plus brefs délais, pour que celui-ci procède à leur révocation lorsque c’est nécessaire.
Journalisation
61. Le détenteur de données devrait s'assurer qu'une journalisation effective des accès et actions réalisées sur la base de données a lieu : cette journalisation peut être techniquement réalisée par le détenteur des données et/ou par le gestionnaire d'API. Dans tous les cas, le détenteur des données devrait conserver une copie de ces traces, pour une durée conforme aux recommandations de la Commission.
62. La journalisation des accès externes, par les réutilisateurs autorisés à utiliser l’API, devrait être réalisée avec un niveau de détail dépendant de l'importance du risque que représente une intrusion dans la base de données ou une utilisation détournée du traitement. Dans le cas général, la Commission recommande que les opérations de création, consultation, modification et suppression des données à caractère personnel auxquels la journalisation est appliquée fassent l’objet d’un enregistrement comprenant l’auteur individuellement identifié, l’horodatage, la nature de l’opération réalisée ainsi que la référence des données concernées par l’opération avec un degré de précision adapté à la gravité des conséquences que pourraient entraîner pour les personnes une utilisation détournée de l'API ou un accès illégitime aux données.
63. Une analyse proactive et régulière des journaux internes et externes devrait être menée afin de vérifier la légitimité des actions réalisées. Celle-ci peut être automatisée (générant des alertes revues par des opérateurs) ou bien mise en œuvre par des mesures organisationnelles (par exemple, génération de rapports réguliers et contrôle humain des accès aux données). Plus particulièrement, dans les cas où un comportement inhabituel peut facilement être identifié, une journalisation et une analyse spécifiques devraient avoir lieu et faire l'objet d'un signalement permettant d'en vérifier la légitimité. Lorsqu'un détournement du traitement pourrait entraîner des conséquences importantes pour les personnes, tout accès supposé illégitime aux données devrait leur être signalé dans les plus brefs délais.
64. Les journaux pourraient également être utilisés afin de vérifier que les réutilisateurs ont bien pris en compte une éventuelle mise à jour des données. La précision et la durée de conservation des données doit être adaptée à chacune des finalités de journalisation. Dans ce cas, le détenteur des données pourrait ainsi alerter les réutilisateurs. Les informations issues de la journalisation permettent également d’assurer une traçabilité sur les accès effectifs aux données, dont les résultats pourraient être fournis aux personnes concernées, notamment à des fins de transparence ou dans le cadre de l’exercice de son droit d’accès. Le détenteur des données devrait s’assurer que ces informations leur sont restituées dans un format accessible et aisément compréhensible, notamment par le recours à des procédés statistiques.
Article 4
Recommandations spécifiques à l'intention des gestionnaires d'API
65. Le gestionnaire d'API est le mieux à même d’assurer en pratique la sécurité de la mise en œuvre de l'API, que ce soit en tant que responsable de traitement auquel cette obligation incombe, ou bien en tant que sous-traitant auquel le responsable de traitement confie contractuellement la mise en œuvre de cette obligation. Il réalise le lien entre le détenteur de données et les réutilisateurs et s'assure que le système est conforme à leurs besoins.
Sur la documentation
66. La Commission recommande que le gestionnaire d'API crée une documentation à l'intention des détenteurs de données et des réutilisateurs, suffisamment détaillée et transparente pour réduire les risques liés à une utilisation imprévue de l'outil. Un générateur automatique de documentation (voir annexe I) reconnu pourra être utilisé à cet effet. Cette documentation pour être complète devrait reposer sur plusieurs supports (fichiers readme , site web de type wiki , commentaires apportés au code si celui-ci est ouvert, infolettre informant sur les mises à jour et nouveautés, etc.).
67. Cette documentation devrait décrire en premier lieu la procédure d'accès aux API. Lorsque l'accès à l'API est soumis à une validation préalable, les conditions à remplir pour y accéder devraient être clairement décrites. Lorsque l'accès à l'API peut être donné selon différents niveaux d'habilitation, les accès prévus pour chacun de ces niveaux et les profils de réutilisateurs attendus, par leur finalité notamment, devraient être clairement décrits. Des indications concernant les modalités d'utilisation et de stockage des secrets d'authentification devraient être fournies.