Recommandations spécifiques à l'intention des gestionnaires d'API

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 :
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.).
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.
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.
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.
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 :
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 à l'article 2.
Expérimentations dans un « bac à sable » :
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 :
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.
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 :
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 à l'article 2.
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 :
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 :
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 :
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.
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.
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.
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 :
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 à l'article 3.
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.