AgentPublic/cnil huggingface dataset:
68. En deuxième lieu, le format des données et des métadonnées et les décisions spécifiques prises concernant leur représentation devraient être décrits dans la documentation. Le gestionnaire d'API devrait indiquer la signification de chacune des variables décrivant les données, et en proposer des exemples d'utilisation clairs. Le gestionnaire d'API devrait décrire précisément les variables relatives à la sécurité des données ou décrivant leurs conditions techniques d'utilisation telles que leur durée de validité ou leur fiabilité. De plus, la documentation devrait préciser les catégories de requêtes et leur format. Elle devrait également décrire les paramètres devant ou pouvant être passés dans ces requêtes. Des exemples représentatifs des usages prévus de l'API devraient être fournis pour illustrer les informations précédentes.
69. En troisième lieu, la Commission recommande que la documentation décrive les aspects relatifs à la sécurité du système. Les limites de l'API devraient y être indiquées, en particulier le volume et la fréquence maximale des requêtes. Les capacités du système, notamment en cas de forte demande, devraient y être également décrites et, lorsque des périodes de forte demande peuvent être anticipées, les périodes à privilégier devraient être indiquées. Les standards, normes et certifications auxquels se conforme l'API devraient également être décrits.
70. En dernier lieu, la documentation devrait indiquer plusieurs points de contact permettant à quiconque de signaler un problème concernant la sécurité de l'API. Un moyen de communication réactif devrait être choisi pour traiter les demandes urgentes.
Sur la minimisation
71. Le gestionnaire, en ce qu’il réalise l’implémentation technique de l’API, est le mieux à même de mettre en œuvre les mesures techniques de minimisation décidées lors de la concertation entre le détenteur de données et le réutilisateur détaillée au paragraphe 33.
Expérimentations dans un "bac à sable"
72. La Commission recommande qu’une version jumelle de l’API, donnant accès à des données fictives, soit proposée afin de permettre aux réutilisateurs de données de réaliser des expérimentations et de sélectionner plus précisément les données nécessaires au traitement. L’accès à cette version devrait être facilité et une aide technique devrait être proposée aux réutilisateurs.
Limitations
73. La Commission recommande que le gestionnaire d'API mette en œuvre des limitations au traitement des requêtes afin d'assurer la disponibilité du système et de prévenir toute utilisation détournée de l'API. Ces limitations devraient s'appliquer à chacune des requêtes, ainsi que par réutilisateur de données. Les limitations pourraient porter sur le volume, la profondeur historique et la précision des données. Ces limitations devraient prendre en compte les besoins réels des réutilisateurs et ne devraient pas empêcher l’accès à des données à jour, faute de quoi les réutilisateurs risqueraient d’utiliser des données inexactes.
74. Pour les usages d’API dont l’objectif est de ne pas révéler de données à caractère personnel (données anonymisées ou agrégées), des méthodes visant à préserver la confidentialité des données de chacune des personnes enregistrées dans la base devraient être mises en œuvre par le gestionnaire d’API. La robustesse de ces méthodes devrait être vérifiée, en particulier vis-à-vis de méthodes de réidentification telles que les attaques par corrélation. En effet, même lorsque les données ne sont pas directement identifiantes, un réutilisateur pourrait être en capacité de réidentifier une personne en réalisant des requêtes croisées sur la base de données, en effectuant un suivi longitudinal sur des données temporelles, ou en utilisant des informations tierces accessibles en dehors de cette base.
Sur l’exercice des droits concernant le partage de données
75. La Commission recommande que le gestionnaire d'API mette en œuvre les mesures techniques nécessaires afin de permettre aux détenteurs de données et aux réutilisateurs, le cas échéant, de répondre aux demandes d'exercice des droits comme prévu aux paragraphes 35 à 40.
76. Ces mesures devraient être précisées dans les documents décrivant les modalités de coordination entre détenteur de données, gestionnaire d’API et réutilisateur.
Sur la sécurité
Objectifs généraux
77. Le gestionnaire d'API s'assure du respect des obligations de sécurité résultant de l’article 32 du RGPD, en s’appuyant notamment sur les recommandations de la CNIL en vigueur, telles que son guide de la sécurité des données à caractère personnel. Pour la mise en œuvre des API, la Commission recommande que le gestionnaire d’API se conforme aux normes techniques communément admises, telles que le référentiel général de sécurité (RGS)[4] de l’Agence nationale de sécurité des systèmes d’information et ses recommandations applicables au type de système considéré, les références RFC (pour requests for comments en anglais) relatives à des protocoles standardisés, ainsi que des solutions éprouvées.
Communications
78. En particulier, dans le cas d’une API en accès restreint, le chiffrement appliqué aux communications devrait garantir un haut niveau de confidentialité. Pour rappel, la Commission considère que les règles et recommandations décrites dans les annexes B1 et B2 du RGS sont la référence en ce qui concerne l’état de l’art de la cryptographie. Le gestionnaire d'API devrait mettre en œuvre les mesures nécessaires afin que ce niveau de chiffrement soit appliqué à toutes les communications, quel que soit le niveau de maturité technique du détenteur de données ou des réutilisateurs. En particulier, le gestionnaire d’API devrait définir et imposer des mesures de chiffrement minimales aux réutilisateurs.
Sécurité des systèmes d’information
79. Le gestionnaire d'API devrait assurer la sécurité du système d’information dans sa globalité et dans le temps, en appliquant les normes et pratiques à l’état de l’art dans le domaine, telles que les normes ISO 9001 et ISO 27001. Le gestionnaire d’API devrait mettre en œuvre les mesures nécessaires pour se prémunir contre les attaques les plus connues et pouvant vraisemblablement être anticipées, telles que les injections de code ou les attaques exploitant des vulnérabilités entre sites de type cross-site request forgery (CSRF). La Commission recommande à cet égard l’utilisation de requêtes préparées et de mesures visant à prémunir contre les attaques de type CSRF. Les outils tiers devraient faire l'objet d'une analyse a priori afin de garantir leur sécurité et leur pérennité. Les composants logiciels tiers mettant en œuvre des API liées au traitement devraient être analysés et les instructions relatives à leur utilisation, et en particulier à leur sécurité, connues et appliquées. Les points d'accès non utilisés devraient être identifiés et révoqués. Lors de la mise à jour d'un outil logiciel, la version antérieure devrait être conservée pendant une période permettant d'assurer la compatibilité des accès pendant une période de recouvrement. Lors de la fermeture d'une API ou d’une de ses versions, une attention particulière devrait être apportée à la révocation effective des accès afin de garantir que les réutilisateurs n’ont accès qu’aux seules versions des API dont
l’ouverture est effectivement prévue.
80. Le gestionnaire d'API devrait s'assurer de la fiabilité et de la robustesse des métadonnées et autres informations relatives à la sécurité du système. Des informations décrivant la qualité, la validité, et la disponibilité des données et des indications concernant le statut de l'API, telles que la charge instantanée ou des statistiques relatives à son utilisation, devraient être fournies aux réutilisateurs.
81. Les interruptions de la disponibilité de l’API devraient être prévues longtemps à l’avance, et les réutilisateurs de l’API devraient en être informés. Cette information devrait inclure les éléments nécessaires à l’information des personnes concernées, dans l’hypothèse où cette indisponibilité programmée aurait un impact sur celles-ci.
82. Lorsque les réutilisations prévues par les réutilisateurs sont des traitements critiques dont une indisponibilité, qu’elle résulte d’un acte malveillant ou accidentel, pourrait entraîner des conséquences graves, le gestionnaire d’API devrait accorder une importance particulière à la disponibilité de l’API et prévoir un dispositif alternatif à celle-ci garantissant un niveau de sécurité similaire. Il devrait prioriser les traitements en question et mettre en place les mesures techniques permettant de mesurer le niveau de disponibilité de l’API et de garantir que celui-ci reste suffisant.
Journalisation
83. La Commission recommande vivement que le gestionnaire d'API mette en œuvre des outils permettant une journalisation des accès à l'API par les réutilisateurs conforme à la recommandation de la CNIL. Les fonctionnalités des API facilitant la traçabilité devraient être exploitées. Selon le niveau de risque évalué, la quantité d'information journalisée devrait être adaptée, selon le cadre général décrit aux paragraphes 61 à 64.
84. Ainsi, une analyse régulière et proactive devrait pouvoir être réalisée par les outils mis en œuvre par le gestionnaire d’API, afin de vérifier la légitimité des actions réalisées. Les procédures prévues devraient permettre de détecter les surcharges du système et l'indisponibilité des données. Ces analyses devraient donner lieu à des signalements internes ou au détenteur de données. Il est recommandé que des informations statistiques relatives à la disponibilité du système et à son utilisation soient fournies au détenteur de données et aux réutilisateurs.
Article 5
Recommandations spécifiques à l'intention des réutilisateurs
85. Il appartient au réutilisateur de données d’appliquer rigoureusement les instructions à sa disposition concernant l’utilisation et la sécurité de l’API et de s'assurer de la licéité des usages qu’il fait des données. Lorsque le réutilisateur constate que certaines instructions sont obsolètes, inadaptées, incomplètes ou non conformes à l’état de l’art en matière de sécurité, il devrait en informer le détenteur de données ou le gestionnaire d'API.
86. Lorsqu'une charte ou licence de réutilisation est fournie, le réutilisateur devrait en prendre connaissance et la diffuser à chacun de ses agents ou employés ayant accès aux données.
Sur l’information des personnes concernées
87. L’information des personnes concernées sur le partage de leurs données avec les réutilisateurs relève de la ou des entités qui endossent la responsabilité de traitement de ce partage, ce qui est en principe toujours le cas du détenteur, et peut être, dans certaines hypothèses, celui du réutilisateur. Outre les catégories de données et les finalités de leur accès par le réutilisateur, la Commission recommande que ce dernier informe les personnes concernées sur les mesures de minimisation prises et le niveau de sécurité appliqué aux données, et, à titre de bonne pratique, sur la volumétrie et la fréquence attendues des requêtes.
Sur la minimisation
88. Lorsqu'un accès temporaire ou restreint est proposé dans le cadre d’une expérimentation de l’API, le réutilisateur devrait en profiter pour déterminer les données strictement nécessaires à ses besoins.
89. Pour des besoins ponctuels ou concernant des données peu volumineuses, le réutilisateur de données devrait interroger l’API chaque fois qu’il entend traiter les données partagées, c’est-à-dire sans les conserver dans ses propres systèmes informatiques. En requêtant systématiquement au moyen de l’API les données dont il a besoin, il s'assure ainsi d’obtenir les données les plus à jour, limite leur surface d'exposition et prend en compte au plus tôt toute modification faisant suite à une demande d’exercice des droits. Lorsque la duplication des données est inévitable, le réutilisateur doit notamment limiter celle-ci au strict nécessaire, définir une durée de conservation maximale et s’assurer que les conditions de sécurité des données sont adéquates. Lorsque la flexibilité de l'API ne permet pas une sélection suffisamment fine des données pertinentes, ou lorsque les données dont l’accès est donné par l’API sont utilisées pour réaliser un traitement permettant d’obtenir la donnée pertinente requise, les données sources non pertinentes ou devenues inutiles doivent en principe être supprimées sous les plus brefs délais.
90. Le réutilisateur doit utiliser les informations à sa disposition afin de s'assurer que les données traitées sont à jour et, le cas échéant, n'ont pas fait l'objet d'une opposition par les personnes pour la finalité correspondant à leur traitement.
Sur la sécurité
Gestion des risques
91. Lorsque le réutilisateur identifie un risque relatif à la confidentialité des données ou un risque de sécurité de l'API, il devrait en informer le détenteur de données et le gestionnaire d'API dans les plus brefs délais.
Sécurisation des clés
92. Lorsque l’accès à l’API est sécurisé au moyen d’une technique d’authentification reposant sur un échange de clés, le réutilisateur de données devrait sécuriser les clés lui permettant d'accéder aux données en hébergeant ces dernières dans un répertoire sécurisé, voire un système de sécurisation des clés, tel qu’un coffre-fort numérique sécurisé, lorsque la gravité des risques liés à une compromission de l’accès à l’API le justifie. Lorsqu’il détecte ou suspecte une compromission de ses clés d’accès, il les révoque immédiatement et demande la génération de nouvelles clés au gestionnaire d’API.
Journalisation
93. Dans le cas où le réutilisateur de données (que ce soit avec l’aide d’un gestionnaire d’API ou qu’il endosse également ce rôle) met à disposition l’API permettant aux détenteurs de données de partager activement leurs données par une requête en écriture, il doit mettre en œuvre les recommandations figurant aux paragraphes 61 à 64 pour assurer une journalisation des modifications découlant de l’usage de l’API par le détenteur. Cette journalisation devrait permettre d’identifier en particulier les actions ou tentatives d’action visant à porter atteinte à l’intégrité des données ou de la base de données.
La présente délibération sera publiée au Journal officiel de la République française.
La Présidente
Marie-Laure DENIS
_____________________________
ANNEXE I : Définitions
Interface de programmation applicative, ou application programming interface (API) : tout ensemble abstrait de fonctions, de procédures, de définitions et de protocoles qui permet la communication de machine à machine et la transmission de données dans un format structuré.
Détenteur de données : tout organisme ou personne public ou privé qui détient des données, ici à caractère personnel, c’est-à-dire qui en contrôle le cycle de vie et les modalités d’accès, ces données ayant vocation à être partagées à des tiers via l'utilisation d'une API, sous leur forme originale ou après l'application d'une transformation telle qu'un procédé d'anonymisation.
Gestionnaire d'API : tout organisme ou personne public ou privé en charge de l’opération et/ou du développement des composants techniques permettant le partage des données via l'API. Le rôle de gestionnaire d’API peut être tenu par plusieurs organismes lorsque la gestion et le développement des outils techniques implique plusieurs acteurs. En particulier, lorsque l'API est mise en œuvre au moyen d’un outil développé par un tiers, l'organisme qui détient la licence sur cet outil est gestionnaire d’API, tout comme celui qui est en charge du déploiement de cet outil dans le système d'information permettant le partage des données.
Réutilisateur des données : tout organisme ou personne public ou privé ayant accès aux données partagées par l'API.
Fournisseur d’API : tout organisme ou personne qui expose une API ouvrant la possibilité pour un consommateur d’utiliser un service que le fournisseur met à disposition, tel qu’un accès à des données.
Consommateur d’API : tout organisme utilisant l’API exposée par un fournisseur afin d’utiliser le service qu’il met à disposition, comme pour accéder à des données ou pour les transmettre.
Plateforme de partage de données : service reposant sur serveur partagé auquel le détenteur de données et le réutilisateur ont accès afin de partager des données. Les données sont généralement contenues dans des fichiers.
Service de télécommunication : service permettant l’échange d’informations par des procédés numériques, tel qu’un service de messagerie électronique.
Requête à l’API : toute demande reposant sur une interrogation de l’API et contenant des instructions décrivant l’action à réaliser. Les requêtes les plus fréquentes, dans le protocole HTTP, sont GET, POST (qui sont respectivement des exemples de requêtes en lecture et en écriture) ou encore PATCH, qui permet de mettre à jour partiellement des ­­­données, et DELETE, qui permet d’en supprimer.
Requête en lecture : interrogation de l’API permettant d’obtenir des données. Ce type de requête s’accompagne généralement de l’identifiant des données recherchées ou de règles permettant de les retrouver, et le cas échéant de paramètres destinés à sélectionner l’information retournée et nécessite un droit de lecture sur la base de données sous-jacente.
Requête en écriture : message envoyé via l’API contenant des instructions telles que l’inscription de données contenues dans le message. Ce type de requête nécessite un droit d’écriture sur la base de données.
Métadonnée : information permettant de décrire une donnée ou un ensemble de données (telle que sa date de création, son type, des informations relatives à sa provenance ou à sa validité, etc.).
Différenciation des accès et permissions par niveau : limitation des accès aux données à caractère personnel à celles strictement nécessaires pour chacun des agents ayant à en connaître et limitation des permissions (lecture, écriture, suppression, etc.) aux seules actions nécessaires pour chacun des agents. Il s’agit d’une mise en pratique du principe de moindre privilège.
Balisage : information annexe (ou métadonnée ) liée à une donnée et indiquant un statut particulier, tel que sa validité, son origine, ou encore les conditions limitant sa réutilisation. Pour être pertinente, l’indication apportée doit être sans ambigüité et transparente.
Outil de gestion de versions : moyens techniques permettant de conserver les modifications successives d’un logiciel ou d’un document et leur historique, ainsi que d’en restituer toute version antérieure.
Outil de validation des données : outil permettant de vérifier la conformité des données échangées par API au format attendu (tel que la correspondance à la description de l’API, la correspondance au type de donnée attendu, l’appartenance à un ensemble de valeurs admises, etc.).
Générateur automatique de documentation : outil permettant de générer la documentation d’une API de manière automatique, à partir du code source de l’API. Ces outils permettent de mettre à jour automatiquement la documentation lors d’une modification apportée à l’API, et peuvent intégrer une gestion des versions. L’utilisation de ces outils permet d’éviter que les réutilisateurs ne se réfèrent à une documentation inexacte.
Outil de recherche des secrets dans le code source : outil permettant de détecter la présence de secrets (jetons d’accès, clés de chiffrement, mots de passe, etc.) par analyse du code source d’un logiciel. Les outils fonctionnant localement (ou on premise) et générant une alerte lors de la présence d’un secret dans le code, avant que celui-ci ne soit publié sur un serveur au moyen d’un outil de gestion des versions par exemple, devraient être privilégiés.
Requests for comments : série de documents de standardisation décrivant les spécifications techniques des protocoles mis en œuvre au sein de l'Internet et des matériels informatiques sous-jacents, comme la RFC 2068 sur le protocole HTTP.
_____________________________
ANNEXE II : Cas d’usage particuliers
Exemple #1 : Partage restreint de données entre plusieurs organismes avec contractualisation
Description du contexte :
Lors de ce partage, un premier organisme privé (le détenteur de données) collecte des données personnelles auprès de ses clients. Il met ensuite les données de ses clients y ayant consenti à disposition de tiers agréés (les réutilisateurs de données). Ces derniers réutilisent les données pour proposer un nouveau service à ces mêmes clients. Interviennent alors des organismes apporteurs de solutions techniques (les gestionnaires d’API), dont le cœur de métier est la valorisation de ces catégories de données, par des méthodes d’analyse ou d’agrégation, et leur partage avec des organismes réutilisateurs. Le rôle de ces derniers sera de proposer des services personnalisés aux personnes reposant sur les données valorisées par l’apporteur de solution.
La quantité de données collectée concernant les clients est relativement importante. De plus, les catégories de données concernées par ce partage sont diverses et permettent de déduire de nombreuses informations à propos des personnes, par exemple sur leurs préférences dans un domaine ou encore leurs habitudes de consommation. Les apporteurs de solution proposent leur service à de nombreux détenteurs de données, et à de nombreux réutilisateurs. Les détenteurs de données peuvent par ailleurs avoir recours à différents apporteurs de solutions techniques.
Recherche des facteurs de vulnérabilité :
De par la nature de ce traitement, plusieurs facteurs de vulnérabilité sont identifiés :
Sur les catégories de données accessibles : les données des personnes sont en volume important et peuvent parfois révéler des informations particulièrement intrusives sur leurs habitudes de vie. Les objectifs à atteindre sont la minimisation et la sécurité des données.
Sur la granularité des données et des requêtes : les réutilisateurs souhaitent accéder à un certain niveau de granularité des données pour mieux cibler les services qu’ils proposent. Les objectifs à atteindre sont la minimisation et la sécurité des données.
Sur les conditions d’accès aux données : plusieurs gestionnaires d’API peuvent avoir accès à la base de données d’un détenteur, puis proposer leur API à plusieurs réutilisateurs. Les objectifs à atteindre sont l’information des personnes, la traçabilité, la gouvernance, la sécurité des données et le respect des droits des personnes.
Sur la nature des organismes : les organismes réutilisateurs peuvent être nombreux, et parmi ces derniers figurent des entreprises de maturité variable, dont la compréhension de leurs obligations liées au RGPD peut être insuffisante et les moyens en ce qui concerne la sécurité des données limités. Les objectifs à atteindre sont l’exactitude, l’information des personnes, la traçabilité, la gouvernance, la sécurité des données et le respect des droits des personnes
Recommandations applicables :
D’après les facteurs de vulnérabilité identifiés, plusieurs objectifs sont à prioriser.
Objectif #1 : la minimisation des données.