API : les recommandations de la CNIL sur le partage de données

Contexte

L'utilisation des interfaces de programmation applicatives, ou API pour application programming interface en anglais, pour réaliser des partages de données entre administrations, organismes privés ou encore directement avec des particuliers peut parfois permettre parfois d’atteindre un meilleur niveau de sécurité que les autres méthodes existantes. Compte tenu des fonctionnalités offertes par les API en termes de sécurité, de minimisation des données ou de gestion des habilitations, la CNIL souhaite promouvoir l’usage des API lorsqu’il est bénéfique. Pour ce faire, elle a publié une recommandation technique relative à la mise en œuvre et à l'utilisation des API à l'intention de tous les acteurs de la chaîne du partage.

Ces cas sont détaillés dans la recommandation afin de nourrir la réflexion des organismes souhaitant partager des données dans leur choix des solutions techniques à adopter. L’utilisation des API ne doit toutefois pas se faire sans prendre en compte certaines bonnes pratiques lors de la conception, du déploiement et de l’utilisation des API.

Cette recommandation avait fait l’objet d’une consultation publique à l’automne 2022. Tous les types de partages de données personnelles par voie d'API, qu’elles soient ouvertes ou à accès restreint, et tous les types d'organismes, qu’ils soient publics ou privés, sont visés par cette recommandation.

Clarifications générales

Sur le périmètre

Toutes les catégories d’API sont visées par la recommandation dès lors qu’elles sont utilisées par des organismes pour le partage de données personnelles. Trois rôles techniques sont introduits par la recommandation :

• le détenteur de données ;
• le gestionnaire d’API ;
• le réutilisateur de données.

Tous les types d’organismes impliqués dans un partage reposant sur une API sont ainsi visés par la recommandation, quel que soit leur rôle dans le partage et quelle que soit leur nature, publique ou privée. Les partages de données concernés peuvent notamment avoir lieu entre des organismes différents ou au sein d’une même structure, et ce dans le cadre d’une obligation légale, d’une recherche scientifique, à des fins commerciales ou non, avec ou sans restriction d’accès, etc. Dans chacun de ces cas, cette recommandation est utile, sans préjudice des textes pouvant s’appliquer tel que ceux prévoyant spécifiquement le partage de données :  législations sectorielles comme la directive sur les services de paiement (DSP2) pour le secteur bancaire, code des relations entre le public et l'administration (CRPA) pour les partages entre administrations, etc.

Sur la portée juridique

La recommandation API a uniquement pour vocation d’indiquer les mesures techniques préconisées par la CNIL, elle ne vise pas à préciser le cadre juridique général relatif au partage de données par voie d’API.

Les recommandations visent ainsi à préconiser le recours à certaines méthodes dans la mise en œuvre des obligations légales des organismes, sans préjuger des cas où ces obligations s’appliquent. Ainsi, si la CNIL recommande certaines de ces méthodes, il reste à la charge des organismes de s’informer des obligations relatives à leur traitement et d’apprécier l’opportunité de leur mise en œuvre. La CNIL propose également une liste non exhaustive de ses publications pour approfondir, dans la rubrique « Autres ressources utiles ».

Sur la responsabilité juridique

Les trois rôles introduits dans la recommandation sont des rôles fonctionnels permettant d’attribuer les recommandations aux organismes selon leur implication technique dans le partage de données. Ainsi, ces rôles ne préjugent en aucun cas de la responsabilité juridique de chacun des organismes. Cette responsabilité doit être déterminée par une analyse au cas par cas par les organismes participant au partage.

Toutefois, certains cas peuvent d’ores et déjà être distingués :

• lorsque le partage est prévu par un texte, la responsabilité de traitement y est alors attribuée à un organisme ;
• lorsque l’API est accessible sans restriction, ou en open data, les réutilisateurs ne seront généralement responsables que de leurs propres traitements, distincts du traitement d’ouverture des données par le biais de l’API ;
• lorsque l’API est mise en œuvre par un organisme privé qui détient les données, sur son initiative, alors cet organisme sera généralement responsable du traitement consistant à les ouvrir.

Clarification sur la méthodologie

La méthode proposée vise à promouvoir les bonnes pratiques applicables à l’utilisation des API. Elle doit être complétée par une analyse de risques conforme aux recommandations de la CNIL et de l’ANSSI pour sécuriser l’ensemble du traitement. La méthode proposée peut rentrer dans le cadre de la réalisation d’une AIPD qui, dans certains cas, est obligatoire. De plus, il est conseillé qu’elle repose sur des grilles d’analyse tierces, telles que :

• le guide de la sécurité des données personnelles de la CNIL ;
• la méthode EBIOS RM de l’ANSSI ;
• le référentiel général de sécurité (RGS) de l’ANSSI ;
• la doctrine des API dans l’administration de la DINUM ;
• le top 10 des risques liés à la sécurité des API de l’OWASP ;
• les autres bonnes pratiques relatives aux standard, protocole ou format utilisé (REST, SOAP, OAuth 2.0, etc.).

Déterminer le niveau de risque général lié à une API implique de prendre en considération des facteurs de risques divers qui peuvent se conjuguer et ainsi devenir particulièrement vraisemblables et susceptibles d’engendrer de graves conséquences. Pour permettre aux organismes de visualiser comment les risques peuvent se composer, et orienter leurs efforts vers les objectifs prioritaires, la CNIL propose la méthodologie ci-après. L’importance de chaque facteur de risque est à évaluer au cas par cas, et lorsque la méthode proposée montre que l’un des objectifs mentionnés ci-dessous ressort en particulier, les recommandations qui lui sont liées devraient être mises en œuvre de manière prioritaire.

Les facteurs de risques à prendre en compte sont les suivants :

• type d’accès à la base de données : en lecture seule ou en écriture ;
• conditions d’accès aux données : vérifications apportées afin de valider les demandes d’accès, accès granulaire selon les habilitations du personnel ou non, réévaluation régulière des accès, etc. ;
• niveau de sécurité des techniques d’authentification utilisées ;
• nature des organismes impliqués dans le partage : maturité technique, gouvernance européenne ou non, capacités opérationnelles, types de réutilisations, etc. ;
• autres mesures techniques (physiques ou logiques) et organisationnelles prévues pour améliorer le niveau de sécurité du système : conditions de stockage des données, chiffrement, journalisation, etc. ;
• état des connaissances sur les techniques utilisées et les risques associés : robustesse des techniques d’anonymisation, maîtrise des systèmes d’informations utilisés, etc. ;
• catégories de données accessibles par l’API : données sensibles au sens de l’article 9 du RGPD, données hautement personnelles comme des données bancaires, etc. ;
• granularité des données et des requêtes : quantité de données sur une même personne fournies pour chaque requête, caractère identifiant des données, risque de réidentification par recoupement des résultats de plusieurs requêtes, etc.

Les mesures applicables doivent être considérées selon ces facteurs de risque, le contexte du traitement et les contraintes pesant sur les organismes impliqués.

Mise en œuvre pratique des recommandations

La liste – non exhaustive – ci-dessous donne quelques pistes concernant des outils pouvant aider à mettre en œuvre les mesures recommandées, ainsi que des exemples d’implémentation des mesures dont il est possible de s’inspirer :

• Les outils de validation des données permettant de contrôler le format des données envoyées via l’API (tel que Validata par exemple) ;
• Les outils d’analyse du code source permettant d’y détecter la présence de secrets (tel que GitGuardian par exemple) ;
• Les outils permettant d’automatiser la génération de la documentation de l’API (tel que Swagger par exemple) ;
• Les outils de gestion des demandes d’accès (tel que DataPass conçu par beta.gouv.fr) ;
• Les outils généralistes, ou outils d’ « API Management » (tels qu’API Umbrella, Gravitee.io, ou APIMan.io par exemple) ;
• Les licences de réutilisation des données (telle que la Licence Ouverte 2.0 conçue par Etalab par exemple) ;
• Les API visant à faciliter l’exercice des droits (telle que la Privacy API d’Atlassian par exemple).

Ces outils ne sont toutefois pas adaptés à toutes les situations, et leur utilisation devrait être appréciée au cas par cas.

Quelques exemples concrets

Ces exemples sont à retrouver en annexe de la recommandation.

Exemple 1 : Partage restreint de données entre plusieurs organismes avec contractualisation

Les API sont aujourd’hui fréquemment utilisées afin de partager des données entre organismes de manière restreinte. Ces partages de données facilités par les API ne devraient toutefois pas se faire au détriment des droits des personnes. Bien au contraire, les API peuvent être utilisées pour faciliter la mise en œuvre de mesures protectrices de la vie privée.

Exemple 2 : Partage de données entre réseaux sociaux et chercheurs

L’analyse des données des réseaux sociaux est une pratique courante en recherche, notamment afin d’étudier l’impact des algorithmes sur la recommandation de contenus ou pour étudier la propagation de contenus haineux. Les chercheurs et réseaux sociaux doivent toutefois respecter certaines règles lors du partage de données.

Exemple 3 : L’ouverture de données de l’administration

L’ouverture des données, ou open data, dans le secteur public a vocation à se généraliser afin de faciliter l’utilisation de ces données par des tiers et dans une démarche de transparence de l’État. Bien que ces partages soient généralement prévus par des textes, certaines bonnes pratiques peuvent être recommandées tant aux administration publiant les données qu’aux tiers utilisateurs.

Exemple 4 : Partage fermé de données entre services d’un organisme

La centralisation des données au sein d’un même organisme est courante et peut permettre une valorisation interne ou un partage des données à des tiers. Lors de cette centralisation, chaque service au sein de l’organisme tient un rôle technique comportant des risques et des possibilités pour la mise en œuvre de mesures protectrices de la vie privée.

Exemple 5 : Partage de données impliquant la personne concernée

Les usages des API sont très diversifiés. Ces outils sont parfois utilisés pour donner accès à des services en ligne, et notamment pour l’accès à certains services particulièrement importants pour les individus. Dans ces cas, certaines mesures, concernant notamment la transparence envers les individus, devraient être mises en œuvre.

Autres ressources utiles

En ce qui concerne l’attribution de la responsabilité du traitement, la charge de la mise en œuvre des obligations légales (la réalisation d’une AIPD, l’exercice des droits, l’information des personnes, etc.), ou encore la contractualisation, pourront être pertinents :

• les lignes directrices du CEPD concernant les notions de responsable de traitement et de sous-traitant dans le RGPD ;
• le guide du sous-traitant ;
• la page « Responsable de traitement et sous-traitant : 6 bonnes pratiques pour respecter les données personnelles » sur le site de la CNIL.

En ce qui concerne la réponse à apporter aux demandes d’exercice des droits :

• la page « Respecter les droits des personnes » sur le site de la CNIL.

En ce qui concerne l’authentification :

• la page « Sécurité : authentifier les utilisateurs » sur le site de la CNIL ;
• la page « Les jetons individuels de connexion ou token access » sur le site de la CNIL ;
• la recommandation relative aux mots de passe et autres secrets partagés.

En ce qui concerne la journalisation :

• la recommandation relative aux mesures de journalisation.

En ce qui concerne le rôle des délégués à la protection des données :

• les fiches pratiques du site de la CNIL, accessibles depuis la page d’accueil « le délégué à la protection des données (DPO) ».

En ce qui concerne la sécurité des systèmes d’information :

• le guide de sécurité de la CNIL ;
• le référentiel général de sécurité (RGS) de l’ANSSI.