Fiches développeur de la CNIL

From HOMO.PlusMachina
Jump to: navigation, search


fiches-cnil

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 soit 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 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, notamment, à ne pas confondre « anonymisation » et « pseudonymisation » qui ont des définitions très 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és 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.

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é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 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.

Insistez particulièrement sur la gestion des accès et la traçabilité des opérations

  • Pensez à documenter 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.

  • 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°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 « développeur » 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), 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 utilisant des logiciels spécifiques de gestion de secrets ou de gestion de configuration.

    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, par exemple avec LetsEncrypt, 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, seuls les ports 443 et 80 de ce serveur doivent être accessibles, tous les autres ports ayant été 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

  • Suivre la recommandation 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 bcrypt.

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

    • de forcer l’utilisation d’HTTPS via l’HSTS ;

    • d’utiliser l’indicateur Secure ;

    • d’utiliser l’indicateur HttpOnly.

  • Testez les suites cryptographiques installées sur les systèmes et désactivez les suites obsolètes (RC4, MD4, MD5, 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.

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.

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.

  • 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.

Fiche n°09 : 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 ou bibliothèques se rémunèrent par la valorisation de données personnelles collectées depuis les applications ou les sites sur lesquels ils sont intégrés. Assurez-vous que de tels tiers respectent les législations en vigueur en matière de données personnelles, et notamment qu’un mécanisme est prévu pour recueillir le 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.

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é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ésIDE »), é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 :

    • aussi bien en cas de collecte directe des données c’est-à-dire lorsque des données sont recueillies directement auprès des personnes (exemples : formulaire, achat en ligne, souscription d’un contrat, ouverture d’un compte bancaire) ou lorsqu’elles sont recueillies via des dispositifs ou des technologies d’observation de l’activité des personnes (exemples : analyse de la navigation sur Internet, géolocalisation et Wi-Fi analytics/tracking pour la mesure d’audience, etc.) ;

    • qu’en cas de collecte indirecte des données personnelles, lorsque les données ne sont pas recueillies directement auprès des personnes (exemples : données récupérées auprès de partenaires commerciaux, de data brokers, 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.

  • 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.

Ressources utiles

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. 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

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 6 mois.

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

  • 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
  • Les bases légales utilisées doivent toujours figurer dans les informations transmises à la personne.

  • 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.)

  • 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 cas spécifique des cookies et autres traceurs

  • 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.

  • Une exception existe néanmoins lorsque les cookies ont pour finalité exclusive de permettre ou faciliter la communication par voie électronique, ou sont strictement nécessaires à la fourniture d’un service demandé par l’utilisateur.

  • Sous certaines conditions, les cookies relatifs à la mesure d’audience peuvent également être exemptés de consentement.

  • Par ailleurs, le fait d’utiliser un seul traceur pour de multiples finalités n’exonère pas de recueillir le consentement pour les finalités qui le nécessitent. 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é,

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

Les outils de mesures d’audience sont utilisés afin d’obtenir des informations sur la navigation des visiteurs sur un site web ou une application mobile. Ils permettent notamment de comprendre comment les utilisateurs arrivent sur un site et de reconstituer leur parcours. Utilisant des cookies, ils sont soumis à la règle du consentement, sauf dans un cas particulier.

Obtenir le consentement

  • De manière générale, avant de déposer ou lire un cookie ou traceur, les éditeurs de sites ou d’applications doivent :

    • informer les internautes de la finalité des cookies ;

    • obtenir leur consentement ;

    • leur fournir un moyen de les refuser.

  • Sauf à rentrer exactement dans le périmètre défini ci-après, cette obligation s’applique aux traceurs utilisés pour la mesure d’audience.

Bénéficier de l’exemption de consentement

  • Sous réserve d’un certain nombre de conditions, les cookies utilisés pour la mesure d’audience sont dispensés de consentement.

  • Ces conditions, comme précisé dans les lignes directrices sur les cookies et autres traceurs, sont :

    • d’informer les utilisateurs de leur utilisation ;

    • de leur donner la faculté de s’y opposer simplement sur tous systèmes d’exploitation, terminaux et navigateurs, par exemple via un bouton ou une case à cocher présenté lors de l’information utilisateur ;

    • de limiter le dispositif aux seules finalités suivantes :

      • la mesure d’audience,

      • l’A/B testing ;

    • de ne pas recouper les données traitées avec d’autres traitements (fichiers clients, statistiques de fréquentation d’autres sites…) ;

    • de limiter la portée du traceur à un seul éditeur de site ou d’application ;

    • de tronquer le dernier octet de l’adresse IP ;

    • de limiter la durée de vie des traceurs à 13 mois.

  • Dans la mesure où ces conditions sont respectées, on passe donc d’un régime d’opt-in à un régime d’opt-out.

  • Il est par ailleurs possible pour un même tiers (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.

  • Pour pouvoir bénéficier de cette exemption de consentement rapprochez-vous de votre éditeur de solution ou bien utilisez un logiciel libre tel que Matomo (anciennement Piwik) que vous pouvez configurer vous-même.