👁 Logo Guide RGPD CNIL pour l'équipe de développement

Guide RGPD de l'équipe de développement

La CNIL publie un guide RGPD pour les développeuses et développeurs

Afin de vous accompagner dans la mise en conformité de vos développements projet web ou applicatif, la CNIL a élaboré un guide de bonnes pratiques des développements en open source.

Ce guide est publié sous licence GPLv3 et sous licence ouverte 2.0 (explicitement compatible avec CC-BY 4.0 FR). Vous pouvez donc librement contribuer à son enrichissement.

Ce guide s’adresse-t-il uniquement aux développeuses et développeurs ?

Que vous travailliez seul(e) ou en équipe au développement d'un projet, que vous soyez amené(e) à gérer une équipe de développement, que vous soyez un prestataire, ou simplement curieux, ce guide contient une première approche des grands principes du RGPD et des différents points d’attention à prendre en compte dans le déploiement d’applications respectueuse de la vie privée de ses utilisateurs.

Il propose des conseils et des bonnes pratiques, et offre ainsi des clés de compréhension du RGPD utiles pour tous les acteurs, quelle que soit la taille de leur structure. Il peut également faire l’objet d’échanges au sein des services et dans la relation avec vos clients.

Que contient le guide ?

Ce guide est découpé en 18 fiches thématiques et complété par des exemples de codes qui couvrent la plupart des besoins des développeuses et développeurs pour les accompagner à chaque étape de leur projet, de la préparation du développement au déploiement de nouveaux services.

Le règlement général sur la protection des données (ou RGPD) précise que la protection des droits et libertés des personnes physiques exige de prendre des « mesures techniques et organisationnelles appropriées afin de garantir que les exigences du présent règlement sont respectées » (considérant 78).

La détermination de ces mesures est forcément liée au contexte des traitements mis en place, et le responsable de traitement (l'entité publique ou privée qui traite des données personnelles) doit à ce titre assurer la sécurité des données qu'il est amené à traiter.

Les bonnes pratiques de ce guide n’ont donc pas vocation à couvrir l’ensemble des exigences des règlementations ni à être à prescriptives, elles apportent un premier niveau de mesures permettant de prendre en compte les problématiques de protection de la vie privée dans les développements informatiques qui ont vocation à être appliquées à tous les projets traitant des données. En fonction de la nature des traitements opérés, des mesures complémentaires devront être mises en œuvre dans certains cas afin de respecter pleinement la réglementation.

Tables des matières

0. Développer en conformité avec le RGPD

1. Identifier les données à caractère personnel

2. Préparer son développement

3. Sécuriser son environnement de développement

4. Gérer son code source

5. Faire un choix éclairé de son architecture

6. Sécuriser vos sites web, vos applications et vos serveurs

7. Minimiser les données collectées

8. Gérer les profils utilisateurs

9. Maîtriser vos bibliothèques et vos SDK

10. Veiller à la qualité de votre code et sa documentation

11. Tester vos applications

12. Informer les utilisateurs

13. Préparer l'exercice des droits des personnes

14. Gérer la durée de conservation des données

15. Prendre en compte les bases légales dans l’implémentation technique

16. Analyser les pratiques en matière de traceurs sur vos sites et vos applications

17. Mesurer la fréquentation de vos sites web et de vos applications

18. Se prémunir contre les attaques informatiques

Comment contribuer à ce guide ?

Ce guide est disponible en deux versions :

• Une version web sur le site de la CNIL, et un export PDF dans l'onglet "Releases" de ce repository ;
• Cette version GitHub, qui offre la possibilité à tous d’y contribuer.

La contribution se fait en quelques étapes :

• Inscrivez-vous sur la plateforme Github ;
• Rendez-vous sur la page du projet ;
• Vous pouvez :
  • Utiliser l’onglet "Issue" pour ouvrir des commentaires ou participer à la discussion
  • Utiliser l'option "Fork" pour faire vos propres modifications et proposer leur inclusion via le bouton "Pull Requests"

Votre proposition de contribution sera examinée par la CNIL avant sa publication. La version web du guide RGPD de l'équipe de développement sera régulièrement mise à jour.

Usage

Pour faire vous-même une « release » de ce repository, vous pouvez utiliser l’outil Pandoc. Cet outil vous permettra de convertir les fiches en un fichier docx ou bien un document HTML.

Vous pouvez retrouver les instructions pour installer cet outil ici

• Pour générer un fichier .docx :

  pandoc -s --toc --toc-depth=1 -o Guide_RGPD_developpeur.docx [0-9][0-9]*.md

• Pour générer un fichier .html :

  pandoc -s --template="templates/mytemplate.html" -H templates/pandoc.css -o index.html README.md [0-9][0-9]*.md

Fiche n°0 : Développer en conformité avec le RGPD

Que vous travailliez seul⋅e ou en équipe au développement d’un projet, que vous soyez amené⋅e à gérer une équipe de développement, ou que vous soyez un prestataire réalisant des développements pour des tiers, il est indispensable de s’assurer durant toute la vie du projet que les données de vos utilisateurs ainsi que toutes les opérations effectuées sur celles-ci soient protégées en permanence.

Les étapes suivantes vous aideront dans le développement d’applications ou de sites web respectueux de la vie privée :

1. Sensibilisez-vous aux grands principes du RGPD. Si vous travaillez en équipe, nous vous recommandons d’identifier une personne chargée du pilotage de sa conformité. Si votre entreprise dispose d’un délégué à la protection des données (DPO), celui-ci constitue alors un atout majeur pour comprendre et respecter les obligations du RGPD. Sa désignation peut par ailleurs être obligatoire dans certains cas, notamment si vos programmes ou vos applications traitent des données dites « sensibles » (cf. les exemples) à grande échelle ou réalisent un suivi régulier et systématique à grande échelle.

2. Cartographiez et catégorisez les données et les traitements de votre système. Recenser de façon précise les traitements réalisés par votre programme ou votre application vous aidera à vous assurer qu’ils respectent bien les obligations légales en la matière. La tenue d’un registre des activités de traitement (dont vous trouvez un exemple sur le site de la CNIL), vous permet d’avoir une vision globale sur ces données, d’identifier et de hiérarchiser les risques associés. En effet, des données personnelles peuvent être présentes dans des endroits inattendus comme dans les journaux de serveurs, les fichiers de cache, les fichiers Excel, etc. Sa tenue est obligatoire dans la plupart des cas.

3. Priorisez les actions à mener. Sur la base du registre des activités de traitement, identifiez en amont du développement les actions à mener pour vous conformer aux obligations du RGPD et priorisez les points d’attention au regard des risques pour les personnes concernées par la collecte de données. Ces points d’attention concernent notamment la nécessité et les types de données collectées et traitées par votre programme, la base légale sur laquelle se fonde vos traitements de données, les mentions d’information de votre programme ou de votre application, les clauses contractuelles vous liant à vos sous-traitants, les modalités d’exercice des droits, les mesures mises en place pour sécuriser vos traitements.

4. Gérez les risques. Lorsque vous identifiez que des traitements de données personnelles sont susceptibles d’engendrer des risques élevés pour les personnes concernées, assurez-vous que vous gérez ces risques de façon appropriée au regard du contexte. Une analyse d’impact relative à la protection des données (AIPD) peut vous accompagner dans la maîtrise de ces risques. La CNIL a élaboré une méthode, des modèles de documents et un outil qui vous aideront à identifier ces risques ainsi qu’un catalogue de bonnes pratiques qui vous accompagnera dans la mise en place de mesures permettant de traiter les risques identifiés. Par ailleurs, la réalisation d’une analyse d’impact relative à la protection des données est obligatoire pour tous les traitements susceptibles d’engendrer des risques élevés pour les droits et libertés des personnes concernées. La CNIL propose, sur son site web, une liste des types d’opérations de traitement pour lesquelles une AIPD est requise ou, au contraire, non requise.

5. Organisez des processus internes pour vous assurer d’être en conformité durant toutes les étapes du développement, veillez à ce que des procédures internes garantissent la prise en compte de la protection des données sur tous les aspects de votre projet et prenant en compte l’ensemble des événements qui peuvent survenir (ex. : faille de sécurité, gestion des demandes de rectification ou d’accès, modification des données collectées, changement de prestataire, violation de données, etc.). Les exigences du label gouvernance (même si celui-ci n'est plus octroyé par la CNIL depuis l’entrée en application du RGPD) peuvent constituer une base d’inspiration utile pour vous aider à mettre en place l’organisation nécessaire.

6. Documentez la conformité de vos développements pour prouver votre conformité au RGPD à tout moment : les actions réalisées et les documents produits à chaque étape du développement doivent être maîtrisés. Cela implique notamment un réexamen et une actualisation réguliers de la documentation de vos développements afin qu’elle soit en permanence en cohérence avec les fonctionnalités déployées sur votre programme.

Le site de la CNIL fournit de nombreuses fiches pratiques qui vous accompagneront dans la mise en place de traitements respectueux de la loi suivant votre secteur d’activité.

Fiche n°1 : Identifier les données à caractère personnel

Comprendre les notions de « données personnelles », de « finalité » et de « traitement » est indispensable pour le développement d’une application respectueuse de la loi et des données des utilisateurs. Attention, à ne pas confondre « anonymisation » et « pseudonymisation » qui ont des définitions précises dans le RGPD.

Définition

• La notion de données à caractère personnel (couramment désignées comme “données personnelles”) est définie dans le règlement général sur la protection des données (RGPD) comme « toute information se rapportant à une personne physique identifiée ou identifiable (dénommée “personne concernée”) ». Elle couvre un large périmètre qui comprend à la fois des données directement identifiantes (nom et prénom par exemple) et indirectement identifiantes (numéro de téléphone, plaque d’immatriculation, identifiant de terminal, etc.).

• Toute opération sur ce type de données (collecte, enregistrement, transmission, modification, diffusion, etc.) constitue un traitement au sens du RGPD et doit donc répondre aux exigences fixées par ce règlement. Ces traitements doivent être licites et avoir un objectif (une « finalité ») déterminée. Les données personnelles collectées et traitées doivent être pertinentes et limitées à ce qui est strictement nécessaire pour atteindre la finalité.

Exemples de données à caractère personnel

• Lorsqu’elles sont relatives à des personnes physiques, les données suivantes sont des données à caractère personnel :
  • nom, prénom, pseudonyme, date de naissance ;
  • photos, enregistrements sonores de voix ;
  • numéro de téléphone fixe ou portable, adresse postale, adresse e-mail ;
  • adresse IP, identifiant de connexion informatique ou identifiant de cookie ;
  • empreinte digitale, réseau veineux ou palmaire de la main, empreinte rétinienne ;
  • numéro de plaque d’immatriculation, numéro de sécurité sociale, numéro d’une pièce d’identité ;
  • données d’usage d’une application, des commentaires, etc.
• L’identification des personnes physiques peut se réaliser :
  • à partir d’une seule donnée (exemples : nom et prénom) ;
  • à partir du croisement d’un ensemble de données (exemple : une femme vivant à telle adresse, née tel jour et membre de telle association).

• Certaines données sont considérées comme particulièrement sensibles. Le RGPD interdit de recueillir ou d’utiliser ces données, sauf, notamment, si la personne concernée a donné son consentement exprès (démarche active, explicite et de préférence écrite, qui doit être libre, spécifique, et informée).

• Ces exigences concernent les données suivantes :
  • les données relatives à la santé des individus ;
  • les données concernant la vie sexuelle ou l’orientation sexuelle ;
  • les données qui révèlent une prétendue origine raciale ou ethnique ;
  • les opinions politiques, les convictions religieuses, philosophiques ou l’appartenance syndicale ;
  • les données génétiques et biométriques utilisées aux fins d’identifier une personne de manière unique.

L’anonymisation des données à caractère personnel

• Un processus d’anonymisation de données à caractère personnel vise à rendre impossible toute identification des individus au sein de jeux de données. Il s’agit donc d’un processus irréversible. Lorsque cette anonymisation est effective, les données ne sont plus considérées comme des données personnelles et les exigences du RGPD ne sont plus applicables.

• Par défaut, nous vous recommandons de ne jamais considérer des jeux de données brutes comme anonymes. Un jeu de données anonyme doit nécessairement résulter d’un processus d’anonymisation qui éliminera toute possibilité de ré-identification des individus, que ce soit par :
  • individualisation : il n’est pas possible d’isoler une partie ou la totalité des enregistrements relatifs à un individu ;
  • corrélation : le jeu de données ne permet pas de relier deux enregistrements se rapportant à une même personne ou à un groupe de personnes ;
  • inférence : il est impossible de déduire la valeur d’un attribut d’une personne depuis des informations internes ou externes au jeu de données.

• Ces traitements de données impliquent dans la plupart des cas une perte de qualité sur le jeu de données produit. L’avis G29 sur les techniques d’anonymisation décrit les principales techniques d’anonymisation utilisées aujourd’hui, ainsi que des exemples de jeux de données considérés à tort comme anonymes. Il est important de signaler qu’il n’existe pas de solution universelle pour l’anonymisation des données à caractère personnel. Le choix d’anonymiser ou non les données ainsi que la sélection d’une technique d’anonymisation doit se faire au cas par cas selon les contextes d’usage et de besoin (nature des données, utilité des données, risques pour les personnes, etc.).

La pseudonymisation des données à caractère personnel

• La pseudonymisation constitue un compromis entre la conservation de données brutes et la production de jeux de données anonymisées.

• Elle se réfère à un traitement de données personnelles réalisé de manière à ce qu’on ne puisse plus attribuer les données relatives à une personne physique sans avoir recours à des informations supplémentaires. Le RGPD insiste sur le fait que ces informations supplémentaires doivent être conservées séparément et être soumises à des mesures techniques et organisationnelles afin d’éviter la ré-identification des personnes concernées. Contrairement à l’anonymisation, la pseudonymisation est un processus réversible.

• En pratique, un processus de pseudonymisation consiste à remplacer les données directement identifiantes (nom, prénom, etc.) d’un jeu de données par des données indirectement identifiantes (alias, numéro dans un classement, etc.) afin d’en réduire leur sensibilité. Elles peuvent résulter d’un hachage cryptographique des données des individus, tels que son adresse IP, son identifiant utilisateur, son adresse e-mail.

• Les données résultant d’une pseudonymisation sont considérées comme des données à caractère personnel et restent donc soumises aux obligations du RGPD. Toutefois, le règlement européen encourage l’utilisation de la pseudonymisation dans le cadre du traitement des données à caractère personnel. Par ailleurs le RGPD considère que la pseudonymisation permet de réduire les risques pour les personnes concernées et de contribuer à la mise en conformité au règlement.

Fiche n°2 : Préparer son développement

Les principes de la protection des données à caractère personnel doivent être intégrés aux développements informatiques dès les phases de conception afin de protéger la vie privée des personnes dont vous allez traiter les données, et de leur offrir une meilleure maîtrise de leurs données et de limiter les erreurs, pertes, modifications non autorisées, ou mauvais usages de celles-ci dans les applications.

Choix méthodologiques

• Mettez la protection de la vie privée au cœur de vos développements en adoptant une méthodologie de Privacy By Design.

• Si vous utilisez des méthodes agiles pour vos développements, pensez à intégrer la sécurité au cœur de votre processus. L’ANSSI a rendu disponible un guide « sécurité & agilité numériques » qui indique comment conduire vos développements dans le cadre d’une méthode agile tout en prenant en compte les aspects sécurité. N’hésitez pas à vous en inspirer.

• Pour tout développement à destination du grand public, menez une réflexion sur les paramètres relatifs à la vie privée, et notamment sur le paramétrage par défaut, par exemple les caractéristiques et les contenus des utilisateurs visibles par défaut.

• Réalisez une analyse d’impact sur la protection des données (AIPD). Pour certaines opérations de traitement, elle est obligatoire. Dans les autres cas c’est une bonne pratique qui vous permettra d’identifier et de traiter tous les risques en amont de vos développements. La CNIL dispose d’une section spéciale sur son site et elle met à disposition un logiciel gratuit consacré à ce type d’analyse.

Choix technologiques

Architecture et fonctionnalités

• Intégrez la protection de la vie privée, y compris les exigences de sécurité des données, dès la conception de l’application ou du service. Ces exigences doivent influer sur les choix d’architecture (par exemple décentralisée vs centralisée) ou de fonctionnalités (par exemple anonymisation à bref délai, minimisation des données). Le paramétrage par défaut de l’application doit respecter les exigences minimales de sécurité et être en conformité avec la loi. Par exemple, la complexité par défaut des mots de passe doit respecter à minima la recommandation de la CNIL relative aux mots de passe.

• Gardez la maîtrise de votre système. Il est important de garder la maîtrise de votre système, autant afin d’en assurer le bon fonctionnement que de garantir un haut niveau de sécurité. Garder un système simple permet d’en comprendre précisément les rouages et d’identifier ses points de fragilité. Dans le cas où une certaine complexité est nécessaire, il est conseillé de démarrer d’un système simple, correctement conçu et sécurisé. Ensuite, il est possible d’en augmenter la complexité petit à petit, tout en continuant de sécuriser les nouveautés qui s’ajoutent.

• Ne vous reposez pas sur une seule ligne de défense. Malgré toutes les dispositions prises pour concevoir un système sécurisé, il peut arriver que certains composants rajoutés ultérieurement ne soient pas suffisamment sécurisés. Pour minimiser les risques sur les utilisateurs finaux, il est conseillé de défendre le système en profondeur. Exemple : contrôler les données entrées dans un formulaire en ligne fait partie des défenses de périphérie. Dans le cas où cette défense est détournée, une protection des requêtes en base de données pourra prendre le relais.

Outils et pratiques

• Utilisez des normes de programmation prenant en compte la sécurité. Souvent, des listes de normes, bonnes pratiques ou guides de codage améliorant la sécurité de vos développements sont déjà disponibles. Des outils annexes peuvent également être intégrés dans vos environnements de développement intégrés (« IDE » en anglais) afin de vérifier automatiquement que votre code respecte les différentes règles faisant partie de ces normes ou bonnes pratiques. Vous trouverez facilement sur internet des listes de bonnes pratiques pour votre langage de programmation favori. Par exemple ici pour C, C++ ou Java. Pour le développement d’application web, des guides de bonnes pratiques spécifiques existent, tels que ceux publiés par l’OWASP.

• Le choix des technologies utilisées est crucial. Un certain nombre de points sont à prendre en compte :

  • En fonction du domaine d’application ou de la fonctionnalité développée, un langage ou une technologie peut être plus approprié qu’une autre.

  • Les langages et technologies éprouvés sont plus sûrs. Ils ont fait, en général, l’objet d’audits afin de corriger les vulnérabilités les plus connues. Il faut cependant faire attention à utiliser les dernières versions de chacune des briques technologiques que vous utiliserez.

  • Il faut à tout prix éviter de coder sa solution définitive dans un langage tout juste appris et pas encore maîtrisé. Dans le cas contraire, vous vous exposez à un risque accru de faille de sécurité du fait du manque d’expérience.

• Mettez en place un environnement de développement sécurisé et permettant le versionnage du code, en suivant la fiche dédiée de ce guide.

Fiche n°3 : Sécuriser son environnement de développement

La sécurité des serveurs de production, de développement, d'intégration continue ainsi que les postes de travail des développeuses et développeurs doit être une priorité car ils centralisent l'accès à un grand nombre de données.

Évaluez vos risques et adoptez les mesures de sécurité adéquates

• Évaluez les risques dans les outils et les processus utilisés pour vos développements. Recensez vos mesures de sécurité existantes et définissez un plan d'action permettant d'améliorer la couverture de vos risques. Désignez une personne responsable de sa mise en œuvre.

• Pensez à prendre compte les risques sur tous les outils que vous utilisez, notamment les risques liés aux outils SaaS (Software as a Service) et collaboratifs dans le cloud (type Slack, Trello, GitHub, etc.).

Sécurisez vos serveurs et vos postes de travail d'une façon homogène et reproductible

• Des listes de recommandations concernant la sécurisation des serveurs, postes de travail et réseaux internes sont disponibles dans les fiches n°5 à 8 du guide sécurité des données personnelles de la CNIL.

• Rédigez un document regroupant ces mesures et expliquant leur configuration : il permet de s'assurer d'une mise en place homogène des mesures de sécurité sur les serveurs et les postes de travail. Afin de réduire la charge de travail, des outils de gestion de configuration, tels qu'Ansible, Puppet ou Chef, peuvent être utilisés.

• Mettez à jour les serveurs et postes de travail, si possible de manière automatique. Vous pouvez vous constituer une liste de veille recensant les vulnérabilités les plus importantes, par exemple les alertes de sécurité, avis de sécurité et les bulletins d'actualité du CERT-FR.

Maîtrisez vos accès et tracez les opérations

• Documentez la gestion de vos clés SSH (utilisation d'algorithmes de cryptographie et de longueur de clés à l'état de l'art, protection des clés privées par une passphrase, rotation des clés). Pour des exemples de bonnes pratiques, consulter le document sur l'usage sécurisé d'(open)SSH.

• Favorisez une authentification forte sur les services utilisés par l'équipe de développement.

• Tracez les accès à vos machines et, si possible, mettez en place une analyse automatique des journaux. Afin de conserver des traces fiables, l'usage de compte générique est à proscrire.

• La plupart des services centralisés (Gitlab ou Jenkins par exemple) nécessite la création de jetons individuels pour authentifier les requêtes (“Webhook”). Il est recommandé d'associer une durée de vie limitée à ces jetons et de les révoquer lorsqu'ils ne sont plus utilisés.

Fiche n°4 : Gérer son code source

Quelle que soit l’ampleur de votre projet, il est très fortement recommandé d’utiliser un outil de gestion de code source pour suivre dans le temps ses différentes versions.

Paramétrez efficacement votre gestionnaire de code source, en pensant à sa sécurité

• Un gestionnaire de code source est un logiciel permettant de stocker l’ensemble de votre code source et des fichiers associés, tout en conservant la chronologie de toutes les modifications qui ont été apportées. Un simple serveur FTP ne constitue pas un gestionnaire de code source.

• Paramétrez correctement votre environnement en utilisant les fonctionnalités proposées par votre gestionnaire de code source. Il est recommandé de mettre en place une authentification forte et/ou une authentification par clés SSH dès le début de votre projet.

• Par ailleurs, attribuez aux utilisateurs de votre gestionnaire de code source des niveaux d’accès à votre projet et définissez pour chacun des niveaux les permissions correspondantes (par exemple, un niveau « invité » avec des droits limités en lecture, un niveau « équipe de développement » avec des droits en écriture, etc.).

• Faites des sauvegardes régulières de votre système de gestion de code source. En particulier, pensez à sauvegarder votre serveur principal où toutes les modifications sont enregistrées.

• Mettez en place des procédures de développement pour travailler efficacement même si plusieurs personnes développent en même temps. Par exemple, vous pouvez décider de ne pas travailler sur la même branche (master ou main), mais de mettre en place des branches par fonctionnalité, qui seront fusionnées dans la branche principale au fur et à mesure du développement. De telles stratégies de développement sont déjà bien documentées, par exemple dans Git Flow. Par ailleurs, certains gestionnaires de code source proposent de configurer des branches protégées qui empêchent des modifications non autorisées sur les fichiers contenus dans ces branches.

Soyez vigilant sur le contenu de votre code source

• Mettez en œuvre des outils de métriques de qualité de code qui scanneront votre code dès son commit pour vérifier sa bonne qualité. Vous pouvez également ajouter des scripts de contrôle de ces métriques dans la configuration du gestionnaire de code source : le commit sera alors annulé si le code source n’est pas d’une qualité suffisante.

• Conservez vos secrets et mots de passe en dehors de votre dépôt de code source :

  • dans des fichiers à part, qui n’ont pas fait l’objet d’un commit. Pensez à utiliser les fichiers spéciaux de votre gestionnaire de code source (tels que .gitignore pour Git) afin de ne pas commiter les fichiers sensibles par erreur.

  • dans des variables d’environnement, en prenant soin de vérifier que les variables d’environnement ne sont pas accidentellement écrites dans des logs ou affichées lors d’une erreur de l’application.

  • en les stockant dans des enclaves sécurisées ou des dépots séparés avec accès restreint que vous pourrez appeler comme dépendance externe de votre projet.

  • en utilisant des logiciels spécifiques de gestion de secrets ou de gestion de configuration (par exemple Vault de la société HashiCorp, Keywhiz de la société Square ou Knox de la société Pinterest).

  • Enfin, si vous devez inclure de telles données dans votre dépôt, pensez à chiffrer/déchiffrer automatiquement les fichiers en utilisant un greffon de votre gestionnaire de code source (par exemple git-crypt).

• Après un commit qui contient des données personnelles ou d’autres données critiques, n’oubliez pas de purger complètement le dépôt de code source : même après modification, les données peuvent rester disponibles dans l’historique de votre dépôt.

• Faites preuve de prudence avant de publier en ligne votre code source. Passez en revue l’intégralité de son contenu afin de vous assurer qu’aucune donnée personnelle, mot de passe ou autre secret n’est présent, y compris dans tout l’historique des modifications.

Exemples d’outils

• À l’inverse d’outils tels que Subversion, qui ont besoin d’un serveur central pour fonctionner, les principaux gestionnaires de code source (Git, Mercurial par exemple) sont décentralisés.

• Pour la plupart de ces outils, une interface web et des outils annexes (gestion des bugs, wiki pour votre documentation, etc.) sont proposés. Ces solutions peuvent soit être accessibles par internet (GitHub, Bitbucket, etc.), soit être installées en interne sur vos serveurs (GitLab).

Fiche n°5 : Faire un choix éclairé de son architecture

Lors de la conception de l’architecture de votre application, vous devez identifier les données personnelles qui seront collectées et définir un parcours et un cycle de vie pour chacune d’entre elles. Le choix des supports de données (stockage local, serveur, service cloud) est une étape cruciale, qui doit être adaptée à vos besoins, mais aussi à vos connaissances techniques. Le registre des activités de traitement et une analyse d’impact peuvent vous accompagner dans ce choix.

Étudier le parcours de ses données

• Représentez et décrivez en amont du projet le fonctionnement attendu de votre projet, avec un schéma des flux de données et la description détaillée des processus mis en œuvre et des supports utilisés.

• Lorsque les données sont uniquement stockées sur le terminal de l’utilisateur (stockage local) ou restent confinées sur des réseaux de communication intégralement sous la maîtrise de l’utilisateur (par exemple, le Wi-Fi ou autre réseau local), le principal point d’attention est celui de la sécurité des données. Les durées de conservation sur ces données peuvent être déterminées par la personne elle-même ; elle doit cependant être en mesure de supprimer ces données à tout moment.

• Lorsque les données doivent transiter par un service en ligne, le choix d’héberger soi-même ces données ou de passer par un prestataire doit se faire en fonction de vos connaissances en sécurité et de la qualité de service attendue. Les offres de cloud reconnues peuvent présenter des niveaux de sécurité supérieurs. Cependant, elles génèrent de nouveaux risques qui doivent être maîtrisées. Pour vous aider, vous pouvez vous appuyer sur la recommandation de la CNIL sur le Cloud computing.

En cas de recours à un prestataire pour l’hébergement

• Choisir un prestataire garantissant la mise en place de mesures de sécurité et de confidentialité appropriées, et suffisamment transparentes. La CNIL vous propose des modèles de clauses de confidentialité.

• S’assurer de connaître la localisation géographique des serveurs qui vont héberger vos données. Vous pouvez être amené⋅e à effectuer des transferts de données hors de l’Union européenne (UE) et de l’espace économique européen (EEE). Si les données peuvent circuler librement dans l’UE/EEE, les transferts hors de cet espace sont possibles, à condition d’assurer un niveau de protection des données suffisant et approprié. La CNIL fournit sur site une carte permettant de visualiser les différents niveaux de protection des données des pays dans le monde.

• Si vous devez recourir à un prestataire pour héberger des données de santé, assurez-vous que celui-ci est certifié ou agréé pour cette activité.

• Les autres points de vigilance sont notamment :
  • l’existence d’une politique de sécurité accessible ;
  • les mesures de sécurité et sûreté physique sur le site d’hébergement ;
  • le chiffrement des données et les autres procédés garantissant que le prestataire n’a pas accès aux données qui lui sont confiées ;
  • la gestion des mises à jour, la gestion des habilitations, l’authentification des personnels et la sécurité des développements applicatifs ;
  • la réversibilité/portabilité aisée des données dans un format structuré et couramment utilisé, sur demande et à tout moment.

Fiche n°6 : Sécuriser vos sites web, vos applications et vos serveurs

Tout site web, application ou serveur doit intégrer les règles élémentaires de sécurité à l’état de l’art, tant sur les communications que sur les authentifications ou son infrastructure.

Sécuriser les communications

• Mettez en œuvre le protocole TLS version 1.2 ou 1.3 (en remplacement de SSL) sur tous les sites web et pour les transmissions de données de vos applications mobiles en utilisant uniquement les versions les plus récentes et en vérifiant sa bonne mise en œuvre.

• Rendez l’utilisation de TLS obligatoire pour toutes les pages de votre site et pour vos applications mobiles.

• Limitez les ports de communication strictement nécessaires au bon fonctionnement des applications installées. Si l’accès à un serveur web n’est possible qu’à l’aide du protocole HTTPS, seul le ports 443 de ce serveur, et éventuellement le port 80 afin de rediriger vers le protocole HTTPS, doit être accessible sur Internet. Les autres ports doivent alors être bloqués au niveau du pare-feu.

• L’ANSSI a publié sur son site des recommandations spécifiques pour mettre en œuvre TLS ou pour sécuriser un site web.

Sécuriser les authentifications

• Suivez les recommandations de la CNIL sur les mots de passe. Pensez notamment à limiter le nombre de tentatives d’accès.

• Ne stockez jamais les mots de passe en clair. Stockez-les sous forme de hachage (hash) au moyen d’une librairie éprouvée, comme Argon2, yescrypt, scrypt, balloon, bcrypt et, dans une moindre mesure, PBKDF2.

• Dans le cas où des cookies sont utilisés pour permettre l’authentification, il est recommandé :

  • de protéger les cookies contre des lectures via des canaux de non chiffrées, en forcant l’utilisation d’HTTPS via l’HSTS, ainsi que par l'utilisation des indicateurs Secure et HttpOnly ;

  • d'utiliser des protections contre des injections de requêtes illégitimes par rebond (cross-site request forgery ou CSRF) en utilisant des mesures de protection comme le CSRF Token et l'indicateur SameOrigin sur les requêtes. L'indicateur SameSite des cookies doit avoir la valeur Strict lorsque c'est possible ;

  • d'utiliser un sous-domaine spécifique pour déposer le token d'authentification avec l'indicateur domain des cookies laissés vides pour exclure les domaines tiers dans le cas où de la délégation de sous-domaine est utilisée (par exemple à travers l'usage de CNAME), ou bien des serveurs avec un faible niveau de sécurité sont destinataires des requêtes HTTP sur le domaine principal.

• Testez les suites cryptographiques installées sur les systèmes et désactivez les suites obsolètes (RC4, MD4, MD5, SHA1, etc.). Favorisez l’utilisation de l’AES256. Lire la note de l’ANSSI sur le sujet.

• Adoptez une politique spécifique de mots de passe pour les administrateurs. Changez les mots de passe, au moins, lors de chaque départ d’un administrateur et en cas de suspicion de compromission. Favorisez l’authentification forte lorsque c’est possible.

• Limitez l’accès aux outils et interfaces d’administration aux seules personnes habilitées. Favoriser l’usage des comptes de moindres privilèges pour les opérations courantes.

• L’accès depuis Internet aux interfaces d’administration doit faire l’objet de mesures de sécurité renforcées. Par exemple, pour les serveurs internes, la mise en œuvre d’un VPN avec authentification forte de l’utilisateur ainsi que du poste qu’il utilise peut être une bonne solution.

Limiter la divulgation d’information sur les comptes existants

Concevoir les processus d'authentification, de réinitialisation des mots de passe et de création de compte de manière à ce qu'un attaquant ne puisse savoir si une adresse mail spécifique possède un compte utilisateur.

• Généraliser les messages d'erreurs d'authentification pour ne pas divulguer d'information sur l'existence d'un compte : "ce couple identifiant/mot de passe est inconnu".
• Ne pas confirmer l'existence d'un compte utilisateur en cas d'utilisation de la fonctionnalité de réinitialisation des mots de passe : "Si un compte existe avec cette adresse un mail de réinitialisation lui a été envoyé"
• Faire valider l'adresse mail du compte utilisateur en tant que première étape de la création d'un compte utilisateur avant toute collecte d'autres données personnelles, et envoyer soit un mail de validation de l'adresse si celle-ci ne dispose pas encore d'un compte, soit un mail de réinitialisation du mot de passe si l'adresse existe, en n'affichant qu'un message générique sur le service : "un mail de validation de votre adresse ou de réinitialisation de votre mot de passe vous a été envoyé"

Sécuriser les infrastructures

• Effectuez des sauvegardes, si possible chiffrées et vérifiées régulièrement. C’est particulièrement utile en cas d’attaque d’un rançongiciel sur vos systèmes, le fait de disposer de sauvegardes pour tous vos systèmes sera la seule mesure qui pourra vous permettre de remettre en état vos systèmes.

• Limitez le nombre de composants mis en œuvre, et pour chacun de ces composants :

  • installez les mises à jour critiques sans délai en programmant une vérification automatique hebdomadaire ;

  • automatisez une veille des vulnérabilités par exemple en s’inscrivant au bulletin CERT-FR.

• Utilisez des outils de détection des vulnérabilités pour les traitements les plus critiques afin de détecter d’éventuelles failles de sécurité. Des systèmes de détection et prévention des attaques sur des systèmes ou serveurs critiques peuvent aussi être utilisés. Ces tests doivent être menés régulièrement et avant toute mise en production d’une nouvelle version logicielle.

• Restreignez ou interdisez l’accès physique et logique aux ports de diagnostic et de configuration à distance. Vous pouvez par exemple lister l’ensemble des ports ouverts au moyen de l’outil netstat.

• Protégez les bases de données que vous rendez accessibles sur Internet, au moins en restreignant au maximum les accès (par exemple par filtrage IP) et en changeant le mot de passe par défaut du compte administrateur.

• En matière de gestion de bases de données, les bonnes pratiques sont notamment de :

  • utiliser des comptes nominatifs pour l’accès aux bases de données et créer des comptes spécifiques à chaque application ;

  • révoquer les privilèges d’administration des comptes nominatifs ou applicatifs pour empêcher la modification de la structure de la base de données des applications (tables, vues, procédures, etc.) ;

  • mettre en œuvre des mesures contre les attaques par injection de code SQL, de scripts, etc. ;

  • favoriser le chiffrement des données sur les disques de stockage et dans les bases de données.

• Compartimentez vos différents environnements d’exécution afin d'être en mesure d'appliquer le principe de moindre privilège sur chaque sous-partie des ces environnements.

Fiche n°7 : Minimiser les données collectées

Vous ne devez collecter que les données personnelles qui sont adéquates, pertinentes et nécessaires au regard des finalités de votre traitement telles que définies au moment de la collecte.

Avant la collecte, pensez aux différents types de données que vous devez collecter et essayez de restreindre votre collecte au strict nécessaire

• Réfléchissez aux différents types de données qui devront être collectées avant la mise en place d’une application et documentez cette réflexion.

• Si des données spécifiques ne sont pas nécessaires pour une certaine catégorie de personnes, ne les collectez pas.

• Traitez et stockez les données de façon à réduire leur précision (à l’instar de la pseudonymisation). Par exemple, stockez seulement l’année de naissance au lieu d’une date de naissance complète si l’application n’a besoin que de l’année.

• En cas de collecte de données particulièrement sensibles, par exemple celles relatives à la santé ou à des condamnations pénales, veillez bien à ne collecter que le minimum requis. En raison de ces contraintes réglementaires, le plus simple est encore de ne pas les collecter si vous pouvez vous en passer.

• Minimisez la quantité de données collectées également dans les données de journalisation et n’y stockez pas de données sensibles ou critiques (données de santé, mots de passe, etc.).

• Certaines fonctionnalités peuvent permettre d’améliorer l’expérience utilisateur, mais ne sont pas strictement nécessaires au bon fonctionnement de votre application (par exemple la géolocalisation afin de simplifier une recherche géographique). Dans ce cas, l’utilisateur final doit pouvoir choisir d’utiliser ou non cette fonctionnalité. Dans le cas où il l’utilise, les données que vous êtes amené à collecter pour son fonctionnement ne doivent être conservées que pendant la durée strictement nécessaire à son fonctionnement et ne jamais être utilisées à d’autres fins.

• Pensez à associer des durées de conservation pour chaque catégorie de données, en fonction de la finalité du traitement et des obligations légales ou réglementaires relative à leur conservation. Les journaux doivent également avoir une durée de conservation. Documentez les durées de conservation définies. Vous devrez être en mesure de les justifier.

Une fois les données collectées, mettez en place des mécanismes d’effacement automatique

• Mettez en œuvre un système de purge automatique à l’expiration de la durée de conservation. Vous pouvez également mettre en place des revues manuelles des données stockées de façon périodique.

• Afin de garantir un effacement complet, effacez physiquement toutes les données qui ne sont plus nécessaires grâce à des outils spécialisés ou en détruisant les supports physiques.

• Si les données sont encore utiles, vous pouvez réduire leur sensibilité en les pseudonymisant, voire en les anonymisant. En cas de pseudonymisation, ces données restent soumises à la réglementation sur les données personnelles (voir la fiche 1).

• Journalisez les procédures d’effacement automatique. Les journaux correspondants pourront être utilisés comme preuve d’effacement d’une donnée.

Fiche n°8 : Gérer les utilisateurs

La manière de gérer les profils de vos collaborateurs et de vos utilisateurs finaux doit être pensée en amont de vos développements. Elle consiste à définir différents profils d’accès et d’habilitation afin que chaque personne ne puisse accéder qu’aux seules données dont il a effectivement besoin.

Les bonnes pratiques de gestion des utilisateurs

• Tout commence par l’utilisation d’identifiants uniques et propres à chaque individu, qu’ils soient utilisateurs de votre application ou collaborateurs dans le développement.

• Veillez à imposer une authentification avant tout accès à des données personnelles, conformément aux recommandations de la CNIL.

• Pour vous assurer que chaque personne (utilisateur ou collaborateur) ne puisse accéder qu’aux données dont il a effectivement besoin, votre système doit prévoir dès la conception des politiques de gestion d’accès aux données différenciées (lecture, écriture, suppression, etc.) suivant les personnes et les besoins. Un mécanisme de gestion des profils utilisateurs global vous permettra de regrouper différents droits en fonction d’un rôle exercé par un groupe d’utilisateurs au sein de l’application.

• La gestion des profils utilisateurs peut s’accompagner d’un système de journalisation (c’est-à-dire un enregistrement dans des « fichiers journaux » ou « logs ») afin de tracer les activités, et détecter toutes anomalies ou évènements liés à la sécurité, comme les accès frauduleux et les utilisations abusives de données personnelles. L’utilisation de ces dispositifs ne doit en aucun cas servir à d’autres fins que celles de garantir le bon usage du système informatique et les logs ne doivent pas être conservés plus longtemps que nécessaire. Ces systèmes de journalisation ne doivent pas amener à stocker des données au-delà de leur durée de conservation. De manière générale, une durée de six mois est adéquate. Assurez-vous enfin que ces traces ne comportent aucune donnée sensible.

• Vous pouvez également prévoir des audits de code ou des tests d’intrusion au sein de votre environnement de développement afin de vous assurer de la robustesse de votre système de gestion des profils.

Fluidifier la gestion des profils d’habilitation

• Prévoyez de documenter ou automatiser les procédures de mouvement de vos collaborateurs, d’inscription et de désinscription de vos utilisateurs. Par exemple, ces procédures doivent encadrer les actions à mener lorsque les personnes ne sont plus habilitées à accéder à un local ou à une ressource informatique, ou à la fin de leur contrat.

• La gestion de vos utilisateurs et collaborateurs implique une revue régulière des droits accordés suivant l’évolution des usages et des mouvements organisationnels au sein de votre projet. L’utilisation de services d’annuaire, comme Lightweight Directory Access Protocol (LDAP), vous aidera à suivre ces évolutions et vous permettra d’affiner vos stratégies d’accès, par exemple en attribuant des rôles suivant les profils d’usage. Cela vous permet de mieux respecter le principe de moindre privilège.

• L’utilisation de compte "suprême" (type root, administrateur, etc.) est à proscrire pour les opérations conventionnelles, car elle constitue la clé de voute de votre système et une cible privilégiée pour un éventuel attaquant externe. Nous vous recommandons d’y associer une politique de mot de passe fort (suite de 10 à 20 caractères ou multifacteur) et de limiter à son plus strict nécessaire le nombre de personnes ayant connaissance de celui-ci.

• Favorisez l’usage d’un gestionnaire de mots de passe au sein de votre projet et privilégiez le passage à une authentification forte lorsque c’est possible. Évitez également les comptes génériques partagés entre plusieurs personnes.

Ressources utiles

• La recommandation relative à la journalisation de la CNIL qui délivre des conseils pour déterminer les mesures à prendre selon le type de traitement de données.

Fiche n°9 : Maîtriser vos bibliothèques et vos SDK

Vous utilisez des bibliothèques, kits de développement (« SDK » en anglais), ou d’autres composants logiciels écrits par des tiers ? Voici quelques conseils pour intégrer ces outils tout en gardant la maîtrise de vos développements.

Faire un choix éclairé

• Évaluez l’intérêt de l’ajout de chaque dépendance. Certaines briques logicielles couramment utilisées ne font que quelques lignes. Cependant chaque élément rajouté est une augmentation de la surface d’attaque de vos systèmes. Dans le cas où une seule bibliothèque propose plusieurs fonctionnalités, n’intégrez que les fonctionnalités dont vous avez effectivement besoin : en activant le minimum de fonctionnalités, vous réduisez le nombre de bugs potentiels qui pourraient survenir.

• Choisissez des logiciels, bibliothèques et SDK maintenus :

  • Si vous souhaitez utiliser du logiciel libre ou open source, essayez de choisir des projets ou des solutions avec une communauté active, des mises à jour régulières et une bonne documentation ;

  • Si vous utilisez d’autres types de solutions avec un support commercial, assurez-vous contractuellement que le code sera maintenu et mis à jour pendant toute la durée de vie de votre projet.

• Prenez en compte la question de la vie privée. Certains SDK et certaines bibliothèques collectent des données personnelles depuis les applications et les sites sur lesquels ils sont intégrés. Vérifiez les engagements pris par le fournisseur de ces solutions, les directives mise en œuvre fournies. Assurez-vous enfin que l'intégration respecte les conditions suivantes :

  • l’utilisateur final est informé de ces opérations de traitements ;

  • un mécanisme est prévu pour recueillir le consentement des utilisateurs lorsqu’une collecte de données non strictement nécessaires pour la fourniture du service est mis en œuvre depuis son terminal ;

  • les éventuels transferts de données hors de l’union européenne sont correctement encadrés ;

  • la relation avec le tiers est encadré par un contrat de sous-traitance conforme à l’article 28 du RGPD.

• Ces obligations s'appliquent particulièrement aux « SDK » permettant d’afficher de la publicité ciblée sur les terminaux. Ils s'appliquent également à certains outils de sécurisation des terminaux et des sites web, tel que le système de détection d'utilisateurs reCAPTCHA de Google, qui indique dans ses conditions d’utilisation qu’en raison des traitements mise en œuvre, son usage est soumis au consentement des utilisateurs.

• Si vous utilisez des mécanismes cryptographiques, il est fortement déconseillé d’implémenter des algorithmes ou des protocoles cryptographiques vous-mêmes. Essayez plutôt de choisir des bibliothèques cryptographiques maintenues, reconnues et faciles d’utilisation.

Évaluer les éléments choisis

• Lisez leur documentation et changez leur configuration par défaut. Il est important de connaître le fonctionnement de vos dépendances. Les bibliothèques et SDK tiers sont souvent fournis avec des fichiers de configuration par défaut, qui ne sont que trop rarement modifiés par manque de temps, ce qui provoque de nombreuses failles de sécurité ;

• Auditez vos bibliothèques et SDK. Savez-vous vraiment ce que font toutes les bibliothèques et SDK que vous intégrez ? Quelles sont les données qui sont envoyées à travers ces dépendances et quelles sont les destinataires de ces données ? Cet audit vous permettra de déterminer les obligations à respecter en matière de protection des données et d’établir la responsabilité des acteurs ;

• Cartographiez vos dépendances. Les bibliothèques et SDK tiers peuvent également intégrer d’autres composants : auditer leur code vous permettra de mieux cartographier toutes vos dépendances et de mieux agir si un problème affecte l’une d’elles. Il est aussi recommandé de faire des audits sécurité de vos composants tiers et d’effectuer une veille sur ceux-ci ;

• Faites attention aux tentatives de typosquattage et autres techniques malveillantes. Vérifiez les noms des dépendances, ainsi que de leurs propres dépendances pour éviter des attaques. Ne copiez-collez pas de lignes de commandes depuis des sites inconnus.

Maintenir les bibliothèques et SDK

• Utilisez des systèmes de gestion de dépendances (tels que yum, apt, maven, pip, etc.) afin de maintenir une liste à jour de vos dépendances.

• Gérez les mises à jour de vos dépendances, particulièrement dans le cas de mises à jour de sécurité qui corrigent des vulnérabilités. Vous devez mettre en place une procédure documentée pour les gérer et les déployer le plus vite possible ;

• Faites attention aux versions des bibliothèques et SDK en fin de support qui ne seront plus maintenues : essayez de trouver une autre solution (choisir une nouvelle bibliothèque, renouveler un support commercial) ;

• Surveillez les statuts des projets open-source, notamment le changement de propriétaire du domaine ou du package, certaines attaques utilisant des mises à jour malicieuses de dépendances populaires.

Ressources utiles

• La base de données des faiblesses du code CWE, maintenue par l'organisme MITRE, liste les vulnérabilités que l'on peut rencontrer dans les logiciels et les dépendances.

Fiche n°10 : Veiller à la qualité de votre code et sa documentation

Il est indispensable d’adopter au plus tôt une bonne hygiène d’écriture de code. Une bonne lisibilité de votre code permettra de réduire l’effort de maintenance, d’audit et de corrections des bogues dans le temps, que vous, vos collaborateurs ou vos futurs contributeurs devront fournir.

Documentez le code et l’architecture

• La documentation est parfois laissée de côté au moment du développement, par manque de temps ou de visibilité sur l’ensemble du projet. Elle est pourtant cruciale pour la maintenabilité de votre projet : elle permet de comprendre globalement le fonctionnement du code, et de savoir quelles parties du code sont affectées par une modification.

• Documentez l’architecture, pas uniquement le code : vous devez être en capacité de garder une vision d’ensemble lorsque vous écrivez votre documentation et d’aider les développeuses et développeurs à comprendre de manière globale le fonctionnement de tous vos composants. En conséquence, privilégiez les schémas et des explications claires lorsque vous documentez votre projet.

• Maintenez la documentation en même temps que le code : la meilleure façon d’avoir une documentation à jour est de la modifier au fil de l’eau en même temps que le code.

• « Versionnez » la documentation avec le code : si vous utilisez un gestionnaire de code source vous pouvez pour chaque « commit » modifiant votre code inclure également les changements de documentation (voir notamment la fiche « Gérer son code source »).

• Pensez à aborder la sécurité dans votre documentation : n’oubliez pas d’envisager la dimension sécurité dans la documentation utilisateur ou développeur. Vous pouvez notamment documenter les différents choix de configuration de votre application, et expliquer quels sont les réglages les plus sécurisés.

Contrôlez la qualité de votre code et de sa documentation

• Un code de qualité passe par l’adoption de bonnes pratiques et de conventions de codage appliquées de manière cohérente sur l’ensemble de votre programme. Pour choisir votre convention de codage, le mieux est de se référer à des conventions existantes. Voici quelques exemples de bonnes pratiques supplémentaires :

  • utiliser des noms de variables et de fonctions explicites permet de comprendre plus facilement ce qu’il se passe au premier regard ;

  • correctement indenter son code permet de percevoir la structure du code plus rapidement ;

  • éviter la redondance de code permet de réduire les efforts de correction qui doivent être apportés en plusieurs endroits. Un oubli est vite arrivé.

• Des outils peuvent vous aider à contrôler la qualité de votre code. Une fois correctement paramétrés, ils éviteront de relire le code pour vérifier la bonne mise en place des conventions de codage. En voici quelques exemples :

  • les environnements de développement intégrés (« IDE »), éventuellement à l’aide de greffons (« plugins »), peuvent être configurés pour respecter les règles d’indentation du code, les sauts de ligne entre les différentes portions de code ou encore la position des accolades et autres parenthèses ;

  • les logiciels de mesure de la qualité du code source peuvent signaler les duplications de code, le respect des règles de programmation ou des bugs potentiels.

Fiche n°11 : Tester vos applications

Tester son produit permet de vérifier son bon fonctionnement, de s’assurer d’une bonne expérience utilisateur ainsi que de trouver et prévenir des défauts avant sa mise en production. Tester son produit permet également de réduire les risques d’atteinte aux données personnelles.

Automatisez les tests

• Les tests de développement (unitaires, fonctionnels, etc.) vont vérifier l’adéquation entre les spécifications et le fonctionnement du produit. Les tests de sécurité (tests à données aléatoires aussi appelés « fuzzing », scan de vulnérabilités, etc.), vont vérifier que le produit continue d’avoir un fonctionnement acceptable quand on s’éloigne de son utilisation normale et qu’il ne présente pas de vulnérabilité qui pourrait permettre à des tiers de compromettre sa sécurité. Ces deux types de tests sont importants pour le bon fonctionnement de votre application.

• Mettez en place un système d’intégration continue afin de lancer les tests automatiquement après chaque modification dans votre code source.

Intégrez les tests dans votre stratégie d’entreprise

• Dans la mise en place de l’environnement de tests dans la stratégie de l’entreprise, les métriques acceptables doivent être définies conjointement par toutes les parties avant le développement.

• Les métriques auxquelles il faut réfléchir sont par exemple :

  • le taux de couverture des tests et leur type ;

  • le taux de réplication du code ;

  • le nombre de vulnérabilités (au sens de ce que détectent les outils) et leur type, etc.

Attention aux données de test !

• Les données « réelles » de production ne doivent pas être utilisées pendant la phase de développement et de test. Utiliser les données personnelles issues de votre base de production à des fins de tests revient à les détourner de leur finalité initiale ;

• En cas d’utilisation de données personnelles hors production, il faut souligner que les risques de sécurité sont également augmentés : accès aux données par des personnes qui n’ont pas le besoin d’en connaître, multiplication des lieux de stockage, etc. ;

• Construisez donc un jeu de données fictives qui ressemblera aux données qui seront traitées par votre application. Un jeu de données fictives permettra de s’assurer qu’une divulgation de ces données n’entraînera aucun impact pour les personnes ;

• Si vous avez besoin d’importer des configurations existantes depuis la production dans vos scénarios de test, pensez à anonymiser les données personnelles qui peuvent être présentes.

Fiche n°12 : Informer les personnes

Le principe de transparence du RGPD exige que toute information ou communication relative au traitement de données à caractère personnel soit concise, transparente, compréhensible et aisément accessible en des termes simples et clairs.

Qui informer et quand le faire ?

• Il faut informer les personnes concernées :

  • en cas de collecte directe des données c’est-à-dire lorsque des données sont recueillies directement auprès des personnes. Par exemple, ce type de collecte concerne : les formulaires, les achats en ligne, la souscription d’un contrat, ouverture d’un compte bancaire.

  • lorsqu’elles sont recueillies via des dispositifs ou des technologies d’observation de l’activité des personnes. Par exemple, l' analyse de la navigation sur Internet, géolocalisation et Wi-Fi analytics/tracking pour la mesure d’audience ;

  • en cas de collecte indirecte des données personnelles, lorsque les données ne sont pas recueillies directement auprès des personnes. Par exemple, les données récupérées auprès de partenaires commerciaux, de courtiers en données, de sources accessibles au public ou d’autres personnes.

• Les moments où cette information est nécessaire :

  • au moment du recueil des données en cas de collecte directe ;

  • dès que possible en cas de collecte indirecte (notamment lors du premier contact avec la personne) et au plus tard, dans le délai d’un mois (sauf exceptions) ;

  • en cas de modification substantielle ou d’événement particulier. Par exemple : nouvelle finalité, nouveaux destinataires, changement dans les modalités d’exercice des droits, violation de données.

Quelles informations dois-je donner ?

• Dans tous les cas, il faut préciser :

  • l’identité et les coordonnées de l’organisme qui collecte les données (qui traite les données ?) ;

  • les finalités (à quoi vont servir les données collectées ?) ;

  • la base légale sur laquelle repose le traitement des données (retrouvez toutes les informations sur les bases légales) ;

  • le caractère obligatoire ou facultatif du recueil des données (ce qui suppose une réflexion en amont sur l’utilité de collecter ces données au vu de l’objectif poursuivi – principe de « minimisation » des données) et les conséquences pour la personne en cas de non-fourniture des données ;

  • les destinataires ou catégories de destinataires des données (qui a besoin d’y accéder ou de les recevoir au vu des finalités définies, y compris les sous-traitants ?) ;

  • la durée de conservation des données (ou critères permettant de la déterminer) ;

  • l’existence des droits des personnes concernées ainsi que les moyens de les exercer (les droits d’accès, de rectification, d’effacement et à la limitation sont applicables pour tous les traitements) ;

  • les coordonnées du délégué à la protection des données de l’organisme, s’il a été désigné, ou d’un point de contact sur les questions de protection des données personnelles ;

  • le droit d’introduire une réclamation auprès de la CNIL.

• Dans certains cas particuliers, il faut fournir des informations supplémentaires, comme dans le cas de transferts de données hors UE, de prise de décision entièrement automatisée ou de profilage, ou encore lorsque la base légale du traitement est l’intérêt légitime poursuivi par l’organisme qui collecte les données (voir le site de la CNIL pour en savoir plus).

• En cas de collecte indirecte, il faut ajouter :

  • les catégories de données recueillies ;

  • la provenance des données (en indiquant notamment si elles sont issues de sources accessibles au public).

Sous quelle forme dois-je fournir ces informations ?

• L’information doit être facile d’accès : l’utilisateur doit la trouver sans difficultés.

• Elle doit être fournie de manière claire et compréhensible, c’est-à-dire avec un vocabulaire simple (phrases courtes, sans termes juridiques ou techniques, sans ambiguïtés) et une information adaptée au public visé (avec une attention particulière à l’égard des enfants et personnes vulnérables).

• Elle doit être écrite de manière concise. Afin d’éviter l’écueil du déluge d’informations noyant l’utilisateur, il faut amener les informations les plus pertinentes au bon moment. Vous pouvez adopter une approche à plusieurs niveaux, en veillant à ce que les personnes bénéficient d’un aperçu clair des informations qui leur sont accessibles sur le traitement de ses données à caractère personnel et du moyen de trouver les informations détaillées.

• Elle doit être adaptée au support d'usage. Par exemple, pour des dispositifs sans écran comme des enceintes connectées, vous pouvez vous reposer sur un dispositif externe ("application compagnon") pour délivrer une information exhaustive aux utilisateurs. Un premier niveau d’information doit également être accessible par l’interface d’usage du dispositif.

• Les informations en rapport avec la protection des données doivent pouvoir être distinguées de celles qui ne sont pas spécifiquement liées à la vie privée (comme les clauses contractuelles ou les conditions générales d’utilisation).

Quelle communication effectuer lorsque la sécurité des données est compromise ?

• Un organisme peut par erreur ou par négligence subir, de manière accidentelle ou malintentionnée, une violation de données personnelles, c’est à dire une atteinte à la sécurité des données, autrement dit la destruction, la perte, l’altération ou la divulgation non autorisée de données. Dans ce cas, l’organisme doit signaler la violation à la CNIL dans les 72 heures si celle-ci est susceptible de représenter un risque pour les droits et libertés des personnes.

• Si ces risques sont élevés, l’organisme doit également en informer les personnes concernées le plus rapidement possible et leur adresser des conseils pour protéger leurs données (ex. annulation d’une carte bancaire compromise, modification d’un mot de passe, modification des paramétrages vie privée…).

• La notification de la violation à la CNIL doit se faire via le site web de la CNIL. La fiche 18 Se prémunir contre les attaques informatiques donne quelques exemples d'attaques qui peuvent conduire à devoir notifier la CNIL et, le cas échéant, les personnes concernées.

Ressources utiles

• Le site Données & Design développé par le Laboratoire d’Innovation Numérique de la CNIL.
• Le site de la CNIL contient également de nombreux exemples de notices d’information.
• La page Violations de données personnelles sur le site de CNIL.

Fiche n°13 : Préparer l’exercice des droits des personnes

Les personnes dont vous traitez les données ont des droits sur ces données : droit d’accès, de rectification, d’opposition, d’effacement, à la portabilité et à la limitation du traitement. Vous devez leur donner les moyens d’exercer effectivement leurs droits et prévoir dans vos systèmes informatiques les outils techniques qui permettront la bonne prise en compte de leurs droits.

Préparer en amont la façon dont ils vous contacteront et dont vous traiterez leurs demandes vous permettra de gérer efficacement l’exercice de ces droits.

Les mesures minimales à mettre en place

• Tous les organismes qui utilisent des données personnelles ont l’obligation d’indiquer où et comment les personnes peuvent exercer leurs droits relatifs à ces données. Vous pouvez par exemple mentionner une adresse e-mail ou un formulaire web au moment de l’information des personnes, ainsi que dans votre politique de vie privée.

• Afin de faciliter l’exercice des droits des personnes, ceux-ci peuvent être aussi implémentés, totalement ou en partie, directement dans l’application ou le logiciel que vous développez ou sur des dispositifs associés par exemple sur des objets connectés sans écran. Cette implémentation spécifique n’est pas obligatoire, mais elle permet de répondre aux attentes des utilisateurs et de réduire le temps et la complexité de traitement de ce type de demandes.

• Avant tout, en cas d’accès ou d’opérations directement effectuées par une personne pour exercer ses droits, n’oubliez pas de gérer son authentification de façon sécurisée. De manière générale, tracez également toutes les opérations ayant un impact sur ses données personnelles.

Voici quelques exemples de droits et leur possible implémentation

• Droit d’accès : les personnes ont le droit d’obtenir une copie de toutes les informations que vous avez à leur sujet. Cela permet, entre autres, à une personne de savoir si des données la concernant sont traitées et d’en obtenir une copie lisible dans un format compréhensible. Il permet notamment de contrôler l’exactitude des données.
  Possible implémentation : prévoyez une fonctionnalité permettant d’afficher toutes les données relatives à une personne. S’il y a beaucoup de données, vous pouvez scinder ses données en plusieurs affichages. Si les données sont trop volumineuses, proposez à la personne de télécharger une archive contenant toutes ses données.

• Droit à l’effacement : les personnes ont le droit de demander l’effacement de l’intégralité des données que vous détenez sur elles.
  Possibles implémentations :

  1. Prévoyez une fonctionnalité permettant d’effacer toutes les données relatives à une personne.

  2. Prévoyez aussi une notification automatique des sous-traitants afin qu’ils effacent eux aussi les données relatives à cette personne.

  3. Prévoyez un effacement des données également dans les sauvegardes, ou une autre solution permettant de ne pas restaurer les données effacées relatives à cette personne.

• Droit d’opposition : les personnes ont le droit de s’opposer dans certains cas à ce que leurs données soient utilisées pour un objectif précis.
  Possible implémentation : prévoyez une fonctionnalité permettant à la personne concernée de s’opposer au traitement. Lorsque la personne exerce son droit d’opposition par ce biais, le responsable de traitement doit supprimer les données déjà collectées, et ne doit par la suite plus collecter de données associées à cette personne.

• Droit à la portabilité : les personnes ont le droit de récupérer leurs données dans un format lisible par machine, pour leur propre usage ou pour les fournir à un autre organisme.
  Possible implémentation : prévoyez une fonctionnalité permettant à la personne concernée de télécharger ses données dans un format standard lisible par un ordinateur (CSV, XML, JSON, etc.)

• Droit à la rectification : Les personnes ont le droit de demander la modification de leurs données lorsque celles-ci sont incorrectes afin de limiter l’utilisation ou la diffusion d’informations erronées.
  Possible implémentation : permettez de pouvoir modifier directement les données dans le compte utilisateur.

• Droit à la limitation du traitement : les personnes ont le droit de demander à ce que le traitement de leurs données soit bloqué pendant un certain temps, par exemple le temps d’examiner une contestation de sa part sur l’utilisation de ses données ou une demande d’exercice de droits.
  Possible implémentation : permettez à des administrateurs de mettre des données relatives à une personne en « quarantaine » : ces données ne pourront alors plus être lues ou modifiées.

En conclusion

• Le site Données & Design développé par le Laboratoire d’Innovation Numérique de la CNIL (LINC).

• Enfin, soyez inventifs ! (En cas de doute, demandez conseil à la CNIL.)

Fiche n°14 : Gérer la durée de conservation des données

Les données personnelles ne peuvent pas être conservées pour une durée indéfinie : celle-ci doit être définie en fonction des objectifs poursuivis par le traitement. Une fois cet objectif atteint, ces données devraient être archivées, supprimées ou anonymisées (par exemple afin de produire des statistiques).

Les cycles de conservation des données

• Le cycle de conservation des données à caractère personnel peut être divisé en trois phases successives distinctes :

  • la base active ;

  • l’archivage intermédiaire ;

  • l’archivage définitif ou la suppression.

• Les mécanismes de suppression de données personnelles des bases actives permettent de garantir que les données sont conservées et accessibles par les services opérationnels uniquement le temps nécessaire à l’accomplissement de l’objectif poursuivi par le traitement.

• Veillez à ne pas conserver les données en base active en les notant simplement comme étant archivées. Les données archivées (archive intermédiaire) ne doivent être accessibles qu’à un service spécifique chargé d’y accéder et de les sortir des archives le cas échéant.

• Veillez également à prévoir des modalités d’accès spécifiques aux données archivées du fait que l’utilisation d’une archive doit intervenir de manière ponctuelle et exceptionnelle.

• Si possible, utilisez la même implémentation lors de la mise en œuvre de la purge ou l’anonymisation des données que celle gérant le droit à l’effacement (cf. fiche sur l’exercice des droits), afin de garantir un fonctionnement homogène de votre système.

Quelques exemples de durée de conservation

• Les données relatives à la gestion de la paie ou au contrôle des horaires des salariés peuvent être conservées pendant 5 ans.

• Les données figurant dans un dossier médical doivent être conservées 20 ans.

• Les coordonnées d’un prospect ne répondant à aucune sollicitation peuvent être conservées pendant 3 ans.

• Les données de journalisation peuvent être conservées entre 6 mois et un an. Cette durée peut être allongée dans des cas spécifiques, lorsque la loi l'impose sur certaines catégories de traitements et suivant le risque de détournement de la finalité de l’utilisation des données.

Fiche n°15 : Prendre en compte les bases légales dans l’implémentation technique

Pour pouvoir être mis en œuvre, les traitements de données personnelles doivent se fonder sur l’une des « bases légales » mentionnées à l’article 6 du RGPD. La base légale d’un traitement est en quelque sorte la justification de l’existence même du traitement. Le choix d’une base légale va directement impacter les conditions de mise en œuvre du traitement et les droits des personnes. Ainsi, prévoir en amont d’un développement les bases légales des traitements prévus dans le projet vous permettra d’intégrer au mieux les fonctions nécessaires à la conformité à la loi de ces traitements et au respect des droits des personnes.

Définition des bases légales prévues par le RGPD

• Dans le cadre d’un développement pour un organisme privé (entreprises, associations, etc.), les bases légales les plus souvent utilisées sont :

  • le contrat : le traitement est nécessaire à l’exécution ou à la préparation d’un contrat entre la personne concernée et l’organisme mettant en place le traitement ;

  • l’intérêt légitime : l’organisme mettant en place le traitement poursuit un intérêt "légitime" à mettre en place le traitement et celui-ci n’est pas susceptible d’affecter les droits et libertés des personnes concernées ;

  • le consentement : la personne concernée a explicitement consenti au traitement.

• Si vous êtes une autorité publique ou un organisme poursuivant des missions d’intérêt public, d’autres bases légales peuvent également être utilisées :

  • l’obligation légale : le traitement est imposé par des textes réglementaires;

  • la mission d’intérêt public : le traitement est nécessaire à l’exécution d’une mission d’intérêt public.

• Vous trouverez sur le site de la CNIL un ensemble de fiches pratiques qui vous permettra de vous accompagner dans le choix des bases légales les plus adaptées à vos traitements.

• Enfin, dans des cas très spécifiques, la sauvegarde des intérêts vitaux peut être retenue comme base légale, par exemple lorsque le traitement est nécessaire pour suivre la propagation d’épidémies ou dans les cas d’urgence humanitaire.

• Dans un premier temps, vérifiez sur le site de la CNIL qu’un texte n’impose pas des contraintes particulières (par exemple : prospection commerciale par voie électronique, certains cookies et autres traceurs, etc.).

Choisir la base légale adéquate

• Une seule base légale doit être choisie pour une finalité donnée. Les bases légales ne peuvent être cumulées pour une même finalité. Un même traitement de données peut poursuivre plusieurs finalités, c’est-à-dire plusieurs objectifs, et une base légale devra alors être définie pour chacune d’elles.

• Comme évoqué ci-dessus, si vous êtes un organisme public, l’obligation légale et la mission d’intérêt public seront les plus pertinentes dans la majorité des cas.

• Si votre traitement s’inscrit dans une relation contractuelle et que sa finalité est objectivement et strictement nécessaire à la fourniture du service de l’utilisateur (par exemple, le nom, le prénom et l’adresse pour créer un compte sur un site de e-commerce) alors la base légale du contrat devrait être appropriée.

• Si votre traitement ne s’inscrit pas dans une relation contractuelle avec l’utilisateur, alors les bases légales du consentement ou de l’intérêt légitime peuvent être mobilisées. Si votre traitement est potentiellement intrusif (profilage, collecte de données de géolocalisation, etc.), le consentement est susceptible d’être la base légale appropriée.

• Lorsque votre traitement contient des données sensibles (données de santé, données relatives à la vie ou à l’orientation sexuelle, etc.), alors vous devrez identifier, en plus de la base légale, une exception prévue par l’article 9 du RGPD.

Les exercices des droits et les modalités d’information à prévoir suivant la base légale

• Les bases légales utilisées doivent toujours figurer dans les informations transmises à la personne.

• Il est recommandé de documenter le choix de vos bases légales. Ces choix peuvent par exemple être indiqués dans une cartographie des traitements ou associés à votre documentation technique.

• Le tableau suivant récapitule les exercices des droits à prévoir suivant les bases légales choisies :

	Droit d’accès	Droit de rectification	Droit à l’effacement	Droit à la limitation du traitement	Droit à la portabilité	Droit d’opposition
Consentement	✔	✔	✔	✔	✔	retrait du consentement
Contrat	✔	✔	✔	✔	✔	✘
Intérêt légitime *	✔	✔	✔	✔	✘	✔
Obligation légale	✔	✔	✔**	✔	✘	✘
Intérêt public	✔	✔	✘	✔	✘	✔
Intérêts vitaux	✔	✔	✔	✔	✘	✘

* Lorsque votre traitement est fondé sur l’intérêt légitime, vous devrez également indiquer les intérêts légitimes poursuivis (lutte contre la fraude, sécurité du système, etc.)

** Lorsque votre traitement est fondé sur l’obligation légale, le droit à l’effacement peut s’appliquer si le traitement répond aux conditions suivantes :

1. les données à caractère personnel ne sont plus nécessaires au regard des finalités pour lesquelles elles ont été collectées ou traitées d'une autre manière; ou

2. les données à caractère personnel ont fait l'objet d'un traitement illicite; ou

3. les données à caractère personnel doivent être effacées pour respecter une obligation légale qui est prévue par le droit de l'Union ou par le droit de l'État membre auquel le responsable du traitement est soumis.

Fiche n°16 : Analyser les pratiques en matière de traceurs sur vos sites et vos applications

La directive européenne ePrivacy requiert le consentement de l’utilisateur avant toute action visant à stocker des informations - via des cookies, identifiants ou autres traceurs (empreintes logiciels, pixels) - ou à accéder à des informations stockées dans l’équipement terminal de l’utilisateur. Afin de se conformer à ses obligations, tout éditeur de site ou d'application doit analyser ses pratiques en terme d'usage des traceurs selon les principes présentés ci-après.

Les traceurs visés par l'obligation du recueil du consentement préalablement à leur usage

• Cette obligation s’applique à toutes les solutions techniques reposant sur des opérations de lecture ou écriture dans le terminal et désignées par la CNIL sous le terme de « traceur ». Elles s'appliquent notamment aux cookies, mais aussi aux « local shared objects » appelés parfois les « cookies Flash », le « local storage » mis en œuvre au sein du standard HTML 5, les identifications par calcul d’empreinte du terminal ou « fingerprinting », les identifiants générés par les systèmes d’exploitation (qu’ils soient publicitaires ou non : IDFA, IDFV, Android ID, etc.) ou les navigateurs (identifiants de cohorte,etc.), les identifiants matériels (adresse MAC, numéro de série ou tout autre identifiant d’un appareil), etc.

• La CNIL a identifié cinq catégories de finalité qui nécessitent obligatoirement un consentement préalable de l'utilisateur avant leur dépôt:
  • la publicité personnalisée ;
  • la mesure de la publicité (non ciblée) ;
  • la publicité geolocalisée ;
  • la personnalisation du contenu (éditorial ou en termes de produits) ;
  • le partage sur les réseaux sociaux.

Les traceurs qui ne sont pas visés par ces obligations

• Certains traceurs peuvent être exemptés du recueil de consentement : les traceurs destinés à l’authentification auprès d’un service, ceux destinés à garder en mémoire le contenu d’un panier d’achat sur un site marchand, certains traceurs visant à générer des statistiques de fréquentation, ou encore ceux permettant aux sites payants de limiter l’accès gratuit à un échantillon de contenu demandé par les utilisateurs.

• Le fait d'utiliser un seul traceur pour de multiples finalités n’exonère pas de recueillir le consentement pour chacune des finalités qui le nécessite. Par exemple, si un cookie d’authentification est également utilisé à des fins de ciblage publicitaire, le consentement de l’internaute devra être recueilli pour cette dernière finalité, de la même manière que pour un site non « loggué ».

• Sous certaines conditions, les cookies relatifs à la mesure d'audience peuvent être exempté du recueil de consentement. La CNIL a mis en place un programme permettant de connaître les configurations à suivre pour différents outils.

• Qu'ils soient exemptés ou non du recueil de consentement, les traitements mis en œuvre avec les informations collectées grâce à ces cookies doivent être intégralement conformes au RGPD. Ils doivent notamment disposer d'une base légale adéquate, d'une information et des droits associés. La fiche Prendre en compte les bases légales dans l’implémentation technique vous accompagnera dans la bonne mise en oeuvre de ces traitements.

• Le chargement de ressources statiques sans traceurs, c'est-à-dire les images, les scripts et les feuilles de styles, n’est pas considéré en tant que tel comme un accès ou une inscription de données dans le terminal d’utilisateur au sens de ePrivacy, et n’est pas soumis à des obligations spécifiques à ce titre.

En pratique

• Si vous utilisez des traceurs visées par ces obligations, il vous faut suivre les étapes suivantes :

  1- Lister les traceurs utilisés (tous les types de traceurs) et les classer par finalité en fonction des catégories identifiées.

  2- Lister les tiers qui déposent ces traceurs.

  3- Mettre en place un blocage des scripts ou appels HTTP déposant et accédant aux traceurs nécessitant le consentement afin de s'assurer de l'absence d'opération avant tout consentement ou bien mettre en place une solution technique permettant de garantir l’absence d’opération de lecture ou écriture tant que l’utilisateur n’a pas consenti..

  4- Mettre en place une interface qui propose à l'utilisateur de consentir au dépôt de ces traceurs.

  5- Sur chaque page, intégrer une icône ou lien pour faire réapparaitre l'interface afin de permettre le retrait du consentement.

  6- Régulièrement, tester votre site ou votre application pour bien s'assurer qu'aucun traceur non nécessaire n'est déposé sans consentement et documentez votre conformité.

• Les finalités choisies doivent être formulées de manière intelligible et dans un langage adapté et suffisamment clair pour permettre aux utilisateurs de comprendre précisément ce à quoi ils consentent.

• Il est fortement recommandé de hiérarchiser les informations délivrées à l'utilisateur sur plusieurs niveaux pour plus de clarté.

• Le premier niveau de l'interface doit comprendre :
  • une liste des finalités poursuivies,
  • un lien vers la liste les tiers,
  • une explication des conséquences qui s'attachent à une acceptation ou un refus,
  • un bouton pour accepter et refuser (refuser les traceurs devant être aussi aisé que de les accepter).

👁 Exemple de bannière cookie détaillant l'utilisation faite par le site web, la durée de consevation et le partage à des tiers. Trois boutons : Personnaliser mes choix, Tout refuser, Tout accepter

• Le second niveau d'interface doit permettre à l'utilisateur de faire un choix sur la finalité de traceurs:

  👁 Exemple de bannière cookie permettant de donner son consentement avec des cases à cocher pour chaque finalité. Boutons Tout accepter et Tout refuser ainsi que Valider mes choix
  👁 Même bannière cookie que l'image précédente mais avec l'affichage de plus d'informations concernant la finalité Publicité personnalisée
  

• D'autres exemples d'interface, notamment pour les applications, sont disponibles dans la recommandation de la CNIL proposant des modalités pratiques de mise en conformité en cas de recours aux "cookies et autres traceurs".

• Des sociétés proposent également des outils de Consent Management Platform (CMP) ou des Tag Managers pour faciliter la mise en conformité des sites.

Fiche n°17 : Mesurer la fréquentation de vos sites web et de vos applications

La gestion d’un site web ou d’une application mobile requiert généralement l’utilisation de statistiques de fréquentation ou de performance. Utilisant des cookies ou d’autres traceurs, ils peuvent être exemptés de consentement sous certaines conditions.

Bénéficier de l’exemption de consentement

• Pour bénéficier de l'exemption de consentement sur les traceurs de mesure d’audience, et afin de limiter à ce qui est strictement nécessaire à la fourniture du service, la CNIL demande de respecter les conditions suivantes :

  • avoir une finalité strictement limitée à la seule mesure de l’audience du site ou de l’application (mesure des performances, détection de problèmes de navigation, optimisation des performances techniques ou de son ergonomie, estimation de la puissance des serveurs nécessaires, analyse des contenus consulté), pour le compte exclusif de l’éditeur ;

  • ne pas permettre le suivi global de la navigation de la personne sur différents sites web ou applications. Toute solution utilisant un même identifiant à travers plusieurs sites (via par exemple des cookies déposés sur un domaine tiers chargé par plusieurs sites) ou applications pour croiser, dédoubler ou mesurer un taux de couverture (« reach ») unifié d’un contenu est exclue du bénéfice de l’exemption ;

  • servir uniquement à produire des données statistiques anonymes ;

  • ne pas conduire à un recoupement des données avec d’autres traitements ou à ce que les données soient transmises à des tiers.

• La CNIL recommande par ailleurs que :

  • les utilisateurs soient informés de la mise en œuvre de ces traceurs et puissent s'opposer à ce dépôt, par exemple via la politique de confidentialité du site ou de l’application mobile ;

  • la durée de vie des traceurs soit limitée à une durée permettant une comparaison pertinente des audiences dans le temps, comme c’est le cas d’une durée de treize mois, et qu’elle ne soit pas prorogée automatiquement lors des nouvelles visites ;

  • les informations collectées par l'intermédiaire de ces traceurs soient conservées pour une durée maximale de vingt-cinq mois ;

  • les durées de vie et de conservation ci-dessus mentionnées fassent l’objet d’un réexamen périodique afin d’être limitées au strict nécessaire.

• Il est par ailleurs possible pour un sous-traitant de fournir un service de mesure d’audience comparatif à de multiples éditeurs, sous réserve que les données soient collectées, traitées et stockées de manière indépendante pour chaque éditeur et que les traceurs soient indépendants les uns des autres.

En pratique

• Les offres de mesure d’audience n’entrent pas dans le périmètre de l’exemption notamment lorsque les fournisseurs indiquent réutiliser les données pour leur propre compte. C’est le cas notamment de plusieurs grandes offres de mesure d’audience disponibles sur le marché (voir notamment les politiques de confidentialité de Google Analytics, de Quantcast Analytics ou encore de Facebook Analytics). Dans certains cas il peut être possible de configurer ces outils pour désactiver la réutilisation des données, vérifiez auprès du fournisseur de votre outil qu’il s’engage contractuellement à ne pas réutiliser les données collectées. Soyez également attentifs aux éventuels transferts de données hors de l’Union Européenne qui pourraient être réalisés par votre fournisseur de solution.

• La CNIL liste sur son site un ensemble de solutions identifiées comme pouvant être configurées pour rentrer dans le périmètre de l’exemption au recueil de consentement. Ces solutions sont systématiquement accompagnées d'un guide afin de permettre la bonne configuration par les éditeurs de site souhaitant les utiliser. Il n’est bien sûr pas exclu que d’autres solutions puissent respecter le critère de stricte nécessité au bon fonctionnement et aux opérations d’administration courante du site web ou de l’application, mais c’est alors à l'éditeur de documenter son analyse.

Fiche n°18 : Se prémunir contre les attaques informatiques

La destruction, la perte, l'altération, ou la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées par un organisme constituent une violation de données personnelles. En tant que développeuse ou développeur, vous êtes tenu•e•s de mettre en œuvre toutes les mesures nécessaires dans vos applications pour prévenir les attaques ou les négligences pouvant entrainer de telles violations.

Cette fiche dresse une liste non-exhaustive de vulnérabilités ayant conduit à des violations de données notifiées à la CNIL. Elle liste des exemples de mesures qui auraient permis de les éviter.

Manipulation d'URL

• La manipulation d’URL consiste à modifier les éléments d’une URL dans le navigateur en vue d’accéder à une ressource non ou mal sécurisée et auquel l’internaute ne devrait normalement pas avoir accès (page web, document accessible en ligne…).

• Différents modes opératoires existent :

  • modification d’un ou de plusieurs paramètres apparaissant dans l’URL. Elle est facilitée lorsque les paramètres permettant d’accéder à une ressource sont numériques ou alphanumériques et consécutifs (suite de chiffres ou de lettres), on parle alors « d’URL incrémentale » ;

  • test des noms de répertoires (/phpmyadmin/, /admin, /.git) ou de fichiers (.bak) connus dans les configurations par défaut, voire dans les informations provenant du fichier robots.txt ;

  • test du chemin de l’arborescence affichée dans l’URL (« path traversal ») en remontant celui-ci en vue d’obtenir du serveur un accès à des répertoires non protégés du site.

• Des mesures permettent de limiter ce risque :

  • vérifier que l’émetteur de cette requête est autorisé à accéder à la ressource associée ;

  • valider et vérifier la bonne construction des paramètres reçus en entrée au sein de l’URL (coté serveur) ;

  • utiliser des identifiants de ressource qui ne soient ni uniquement numériques, ni consécutifs, et ayant une construction aléatoire, impossible à découvrir pour les attaquants ;

  • rendre le « path traversal » inopérant par la mise en place d’un mécanisme de « chroot », la restriction de l’utilisation des caractères utilisés par les attaquants tels que « ../ », désactiver la fonction de « directory browsing », neutraliser les messages d'erreur en affichant un message générique de type « erreur 404" » ;

Ressources :

• OWASP: Path traversal
• Webappsec: Predictable Resource Location

Bourrage d’identifiants (“Credential stuffing”)

• Le bourrage d’identifiants (“credential stuffing”) consiste à réaliser des tentatives d’authentification massives sur des sites et services web à partir de couples identifiants/mots de passe. Il est le plus souvent la conséquence de violations de données ayant préalablement affecté d’autres sites web, par le biais desquelles des listes de couples d’identifiants/mots de passe sont alors disponibles en très grande quantité au sein du web caché (« dark web »).

• Il est rendu possible par la réutilisation par les utilisateurs de couples d'identifiants/mots de passe communs pour des services en ligne différents, et permet aux attaquants de prendre le contrôle de comptes utilisateurs parfois sensibles (emails, banque, réseaux sociaux)

• Des mesures permettent de limiter ce risque :

  • sensibiliser régulièrement les utilisateurs aux risques d’utiliser un même mot de passe pour plusieurs comptes ;

  • proposer un mécanisme de double authentification ;

  • limiter la capacité des robots à multiplier les requêtes, en utilisant un captcha, en limitant la fréquence des requêtes par IP et autre mesures adéquates ;

  • prévenir les utilisateurs par courriel en cas de connexion à leur compte à partir d’un nouvel appareil. Pour les traitements les plus sensibles, une notification pourra être envoyée à l’utilisateur à chaque connexion.

Ressources :

• OWASP: Credential Stuffing Attack, Credential Stuffing Prevention Cheat Sheet
• Retailers: Protecting Against Credential Stuffing Attacks

Attaques par force brute et par dictionnaire

• L’attaque par force brute (bruteforce attack) consiste à tester, l’une après l’autre, les combinaisons possibles d’un mot de passe ou d’une clé associé à un utilisateur sur un service en ligne, sur un fichier protégé. L’attaque par dictionnaire optimise cette recherche en utilisant des dictionnaires thématiques (par exemple, le dictionnaire des mots de passe les plus courants). Elle repose ainsi sur le postulat que les personnes utilisent majoritairement des mots de passe des mots ayant une signification (par exemple : un prénom, une couleur, un lieu).

• Des mesures permettent de limiter ce risque :

  • forcer l'utilisateur à utiliser des mots de passe conformes aux recommandations en vigueur et empêcher l’utilisation de données fréquentes (noms, prénoms et dates de naissance) et les mots de passes les plus courants (password, 12345678,…) ;

  • limiter le nombre de tentatives successives sur une période de temps données et bloquer l'accès après un trop grand nombre d’essais infructueux ;

  • inviter voire contraindre l'utilisateur à utiliser une authentification multi-facteurs (OTP, clé USB, carte à puce,…) suivant la sensibilité des données accédées ;

  • prévenir les utilisateurs par courriel en cas de en cas de connexion à leur compte à partir d’un nouvel appareil. Pour les traitements les plus sensibles, une notification pourra être envoyée à l’utilisateur à chaque connexion ;

  • afficher la date et l’heure de la dernière connexion sur l’interface de l’utilisateur.

Ressources :

• ANSSI : Recommandations relatives à l'authentification multifacteur et aux mots de passe - v2.0 du 08/10/2021
• OWASP: Bruteforce attack

Injection de code indirecte (“Cross-Site Scripting”/XSS)

• Les attaques par « injection de code indirecte » (de l'anglais Cross-Site Scripting, abrégé XSS) consistent à insérer un contenu malveillant dans une page d'un serveur de confiance afin qu’il soit affiché sur le navigateur de la victime.

• Ces injections peuvent permettrent l’exécution de scripts malveillants sur le navigateur de l'internaute. Elle peuvent notamment donner lieu : à l’affichage d’une fausse fenêtre d’authentification afin de dérober les identifiants et le mot de passe de l’utilisateur, à l’exécution de commandes système, à la redirection vers un site malveillant, à la récupération des cookies présents sur la machine (ex : cookie d’authentification), au téléchargement de programmes malveillants ou encore à l’enregistrement des frappes clavier (key logging), etc.

• Ces injections peuvent prendre plusieurs formes :

  • le contenu malveillant peut être injecté directement sur le site par l'attaquant, par exemple dans ses champs de commentaires ;

  • le contenu malveillant peut être inclus dans les paramètres des requêtes envoyées aux serveurs afin d'exploiter ses vulnérabilités, par exemple pour obtenir un accès complet à sa base de données ;

  • le contenu malveillant peut être injecté dans les paramètres d'une URL et affiché sur le navigateur de l’utilisateur comme un contenu "légitime" du site.

• Des mesures permettent de limiter ces risques :

  • mettre à jour les composants logiciels régulièrement ;

  • diligenter des audits de sécurité (tests de pénétration) de façon périodique et après chaque mise à jour significative ;

  • neutraliser les caractères utilisés pour l’insertion de script (> < /) lorsque c’est possible (cf. nettoyage « HTML escape ») ;

  • vérifier les éléments récupérés en paramètre et rejeter tous ceux qui ne sont pas attendus par l’application ;

  • vérifier que les téléversements (upload) légitimes (photos de profil, par exemple) sur le serveur soient au format attendu et placés dans un répertoire ne permettant pas leur exécution ;

  • exécuter des outils automatisés de détection de failles et de flux « anormaux » (présence de scripts dans les journaux et requêtes serveurs).

Ressources :

• CAPEC-63: Cross-Site Scripting
• CERT-FR: Cross-Site Scripting
• OWASP: Cross-Site Scripting (XSS)
• ANSSI: Recommandations pour la sécurisation des sites web (XSS)

Injection SQL (SQLi)

• L’injection SQL est une technique permettant d’injecter du code de type SQL (langage utilisé pour manipuler certaines bases de données) dans les données envoyées au serveur web au lieu de données valides. Par exemple, un attaquant peut injecter du code SQL dans les champs des formulaires HTML ou dans les URL des pages web.

• De cette façon, les attaquants outrepassent les contrôles de sécurité et peuvent consulter ou modifier des éléments présents dans une base de données. D'autres types d'injection de code sont également possibles (par exemple : les injections LDAP, si le serveur web contacte un annuaire via une requête LDAP, ou du code bash si le serveur appelle une commande externe en passant les paramètres à un shell).

• Des mesures permettent de limiter ce risque :

  • utiliser des requêtes préparées (Prepared Statements) exclusivement, lorsque cela est possible ;

  • échapper les caractères susceptibles de provoquer une injection, en utilisant des fonctions spécialisées ;

  • restreindre et contrôler les entrées externes autant que possible. Par exemple, si l’identifiant est un chiffre, n’accepter que des chiffres ;

  • vérifier les données externes (notamment lorsqu’il est impossible de les restreindre ou lorsque certains caractères spéciaux utilisés en SQL sont des données acceptables en entrée) ;

  • mettre en œuvre une gestion fine des droits d’accès à la base de données. Par exemple, il est inutile d’accorder un accès total en lecture et écriture à un service qui ne fait que lire des données. Il est également possible de restreindre les droits de l'utilisateur à une seule table ou une seule base de données ;

  • neutraliser les messages d’erreur afin d’éviter la divulgation d’informations techniques recherchées par les attaquants (en affichant un message de type « erreur 403 », par exemple).

Ressources :

• CAPEC-66: SQL Injection
• CERT-FR: Injection de données
• OWASP: Injection
• OWASP: Prévention des injections SQL)

Les programmes malveillants et les rançongiciels

• Un malware, ou logiciel malveillant, est un terme générique utilisé pour caractériser tout type de logiciel ayant pour but de nuire à un système informatique et le plus souvent à voler, modifier ou supprimer les données qui s’y trouvent. Parmi les programmes malveillants connus figurent notamment les chevaux de Troie (Trojan horse), les virus, les vers et les « espiogiciels » (spyware). Les programmes malveillants les plus fréquents ces dernières années sont les rançongiciels (“ransomware” ou “cryptolocker”).

• Ainsi, tout téléchargement ne provenant pas d’une source fiable est potentiellement un programme malveillant. Dans la majorité des cas, il est téléchargé en :

  • ouvrant la pièce jointe d’un email provenant d’une source inconnue ;

  • ou en téléchargeant un logiciel mis à disposition sur un site inconnu (ou n’étant pas de confiance) ;

  • ou en téléchargeant des logiciels associés à un logiciel connu ou provenant d’une source non fiable ;

  • ou en visitant un site web malveillant.

• Le rançongiciel (ransomware, cryptolocker) se transmet souvent via une pièce jointe de courriel ou via des liens permettant le téléchargement de logiciels ou de contenus. Une fois présent sur son hôte, ce programme va progressivement chiffrer tous les fichiers qui lui sont accessibles afin de les rendre illisibles par les utilisateurs. Dans le cas d’un réseau d’entreprise, le logiciel va chercher à se propager sur les ressources accessibles via le réseau en utilisant des failles connues, des mots de passe faibles ou réutilisés. L’attaquant demande alors une rançon à la personne ou à l’organisme victime en échange de la clé permettant de déchiffrer les fichiers.

• Le rançongiciel est un malware très répandu car très rentable pour les attaquants. En effet, celui-ci exige une rançon rapide et le plus souvent en cryptomonnaie. Si ce type d’attaque est parfois opportuniste, pour des rançons correspondant généralement à quelques centaines d’Euros, certains attaquants ciblent également depuis plusieurs années des entités de tailles importantes (grandes entreprises, collectivités, etc.) pour des montants pouvant atteindre plusieurs dizaines de millions d’Euros.

• Les mesures à mettre en œuvre afin de réduire le risque d’attaque sont surtout d’ordre organisationnel :

  • maintenir à jour ses systèmes et logiciels (antivirus, équipements pare-feu, etc.) ;

  • faire des sauvegardes régulières des données, les tester régulièrement et en conserver au moins une copie hors du réseau de l’organisme ;

  • sensibiliser les utilisateurs aux risques et aux bonnes pratiques : ne pas ouvrir les pièces jointes, ni cliquer sur les liens présents dans les courriels dont la provenance n’est pas fiable (surtout lorsque les pièces jointes ont une extension suspecte), ne pas installer d’application ou de programme dont l’origine n’est pas de confiance, éviter les sites non sûrs ou illicites ;

  • ne pas utiliser de compte ayant des droits « administrateur » pour l’usage quotidien (le recours aux droits « administrateur » doit être limité aux seules actions le nécessitant) ;

  • ne pas installer de logiciels piratés ou issus de sources non fiables ;

  • cloisonner son réseau interne, notamment au moyen de VLAN afin de limiter la propagation de l’attaquant, le cas échéant ;

  • utiliser un proxy web permettant de bloquer les sites pouvant diffuser de tels logiciels.

Ressources :

• Cybermalveillance : Les rançongiciels (ransomwares)
• ANSSI: Alerte – campagne de rançongiciels
• ANSSI: Etat de la menace rançongiciel
• NoMoreRansom!