├── 00-Développer en conformité avec le RGPD.md ├── 01-Identifier les données personnelles.md ├── 02-Préparer son developpement.md ├── 03-Sécuriser son environnement de développement.md ├── 04-Gérer son code source.md ├── 05-Faire un choix éclairé de son architecture.md ├── 06-Sécuriser vos sites web, vos applications et vos serveurs.md ├── 07-Minimiser les données collectées.md ├── 08-Gérer les profils utilisateurs.md ├── 09-Maîtriser vos bibliothèques et vos SDK.md ├── 10-Veiller à la qualité de votre code et sa documentation.md ├── 11-Tester vos applications.md ├── 12-Informer les utilisateurs.md ├── 13-Préparer l'exercice des droits des personnes.md ├── 14-Gérer la durée de conservation des données.md ├── 15-Prendre en compte les bases légales dans l’implémentation technique.md ├── 16-Analyser les traceurs.md ├── 17-Mesurer la fréquentation.md ├── 18-Se prémunir contre les attaques informatiques.md ├── LICENSE ├── README.md ├── annexes ├── .gitkeep ├── Bandeau-Cookie-Niveau-1.jpg ├── Bandeau-Cookie-Niveau-2-details.jpg ├── Bandeau-Cookie-Niveau-2.jpg ├── conf_tls_apache.txt └── conf_tls_nginx.txt ├── index.html └── templates ├── BANNIERE.JPG ├── mytemplate.html └── pandoc.css /00-Développer en conformité avec le RGPD.md: -------------------------------------------------------------------------------- 1 | # Fiche n°0 : Développer en conformité avec le RGPD 2 | 3 | #### 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. 4 | 5 | Les étapes suivantes vous aideront dans le développement d’applications ou de sites web respectueux de la vie privée : 6 | 7 | 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)](https://www.cnil.fr/fr/designer-un-pilote), celui-ci constitue alors un atout majeur pour [comprendre et respecter les obligations du RGPD](https://www.cnil.fr/fr/designation-dpo). 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](#Fiche_n°1%c2%a0:_Identifier_les_données_à_caractère_personnel)) à grande échelle ou réalisent un suivi régulier et systématique à grande échelle. 8 | 9 | 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](https://www.cnil.fr/fr/RGDP-le-registre-des-activites-de-traitement) (dont vous trouvez un exemple sur le [site de la CNIL](https://www.cnil.fr/sites/default/files/atoms/files/registre-traitement-simplifie.ods)), 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. 10 | 11 | 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](#Fiche_n°7%c2%a0:_Minimiser_les_données_collectées) par votre programme, [la base légale](#Fiche_n°7%c2%a0:_Minimiser_les_données_collectées) sur laquelle se fonde vos traitements de données, [les mentions d’information](#Fiche_n°12%c2%a0:_Informer_les_personnes) de votre programme ou de votre application, [les clauses contractuelles](#Fiche_n°5%c2%a0:_Faire_un_choix_éclairé_de_son_architecture) vous liant à vos sous-traitants, les modalités d’[exercice des droits](#Fiche_n°13%c2%a0:_Préparer_l’exercice_des_droits_des_personnes), les mesures mises en place pour [sécuriser vos traitements](#Fiche_n°6%c2%a0:_Sécuriser_vos_sites_web,_vos_applications_et_vos_serveurs). 12 | 13 | 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)](https://www.cnil.fr/fr/RGPD-analyse-impact-protection-des-donnees-aipd) peut vous accompagner dans la maîtrise de ces risques. La CNIL a élaboré une [méthode](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-1-fr-methode.pdf), des [modèles de documents](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-2-fr-modeles.pdf) et un [outil](https://www.cnil.fr/fr/outil-pia-telechargez-et-installez-le-logiciel-de-la-cnil) qui vous aideront à identifier ces risques ainsi qu’un [catalogue de bonnes pratiques](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-3-fr-basesdeconnaissances.pdf) 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](https://www.cnil.fr/sites/default/files/atoms/files/liste-traitements-aipd-requise.pdf), une liste des types d’opérations de traitement pour lesquelles une AIPD est requise ou, au contraire, non requise. 14 | 15 | 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](https://www.cnil.fr/sites/default/files/atoms/files/formulaire_de_demande_labels-gouvernance-re.docx) (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. 16 | 17 | 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](https://www.cnil.fr/fr/documenter-la-conformite). 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. 18 | 19 | Le site de la CNIL fournit de nombreuses [fiches pratiques](https://www.cnil.fr/fr/mediatheque) qui vous accompagneront dans la mise en place de traitements respectueux de la loi suivant votre secteur d’activité. 20 | -------------------------------------------------------------------------------- /01-Identifier les données personnelles.md: -------------------------------------------------------------------------------- 1 | # Fiche n°1 : Identifier les données à caractère personnel 2 | 3 | #### 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. 4 | 5 | ## Définition 6 | * 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](https://www.cnil.fr/fr/comprendre-le-rgpd) (RGPD) comme « [toute information se rapportant à une personne physique identifiée ou identifiable (dénommée “personne concernée”)](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre1#Article4) ». 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.). 7 | 8 | * 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é. 9 | 10 | ## Exemples de données à caractère personnel 11 | 12 | * Lorsqu’elles sont relatives à des personnes physiques, **les données suivantes sont des données à caractère personnel** : 13 | * nom, prénom, pseudonyme, date de naissance ; 14 | * photos, enregistrements sonores de voix ; 15 | * numéro de téléphone fixe ou portable, adresse postale, adresse e-mail ; 16 | * adresse IP, identifiant de connexion informatique ou identifiant de cookie ; 17 | * empreinte digitale, réseau veineux ou palmaire de la main, empreinte rétinienne ; 18 | * numéro de plaque d’immatriculation, numéro de sécurité sociale, numéro d’une pièce d’identité ; 19 | * données d’usage d’une application, des commentaires, etc. 20 | 21 | * **L’identification des personnes physiques peut se réaliser** : 22 | * à partir d’une seule donnée (exemples : nom et prénom) ; 23 | * à partir du croisement d’un ensemble de données (exemple : une femme vivant à telle adresse, née tel jour et membre de telle association). 24 | 25 | * 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). 26 | 27 | * Ces exigences concernent les données suivantes : 28 | * les données relatives à la **santé des individus** ; 29 | * les données concernant la **vie sexuelle** ou l’**orientation sexuelle** ; 30 | * les données qui révèlent une prétendue **origine raciale** ou **ethnique** ; 31 | * les **opinions politiques**, les **convictions religieuses**, **philosophiques** ou l’**appartenance syndicale** ; 32 | * les **données génétiques** et **biométriques utilisées aux fins d’identifier une personne de manière unique**. 33 | 34 | ## L’anonymisation des données à caractère personnel 35 | 36 | * 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. 37 | 38 | * 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 : 39 | * _individualisation_ : il n’est pas possible d’isoler une partie ou la totalité des enregistrements relatifs à un individu ; 40 | * _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 ; 41 | * _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. 42 | 43 | * 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](https://www.cnil.fr/fr/le-g29-publie-un-avis-sur-les-techniques-danonymisation) 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.). 44 | 45 |
46 | En savoir plus sur les techniques d'anonymisation 47 |
48 | 49 | Le [projet CabAnon](https://linc.cnil.fr/fr/cabanon-un-projet-dexploration-et-de-visualisation-de-donnees-anonymisees), développé par le Laboratoire d'Innovation Numérique de la CNIL en 2017, évalue les performances de différentes techniques d’anonymisation sur des trajets des taxis tels que rendus publics par la New-York TLC. Ce projet présente [différents scénarios d’usages](https://linc.cnil.fr/fr/cabanon-quels-usages-pour-les-donnees-anonymisees) pour lesquels les techniques d'anonymisation utilisées n’altèrent pas significativement la qualité du résultat final. Le code utilisé pour anonymiser ces données est également publié sous [licence libre](https://github.com/LINCnil/Cabanon/tree/master/Anon). 50 |
51 | 52 | ## La pseudonymisation des données à caractère personnel 53 | 54 | * La **pseudonymisation constitue un compromis entre la conservation de données brutes et la production de jeux de données anonymisées**. 55 | 56 | * 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. 57 | 58 | * 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](https://www.cnil.fr/fr/comprendre-les-grands-principes-de-la-cryptologie-et-du-chiffrement) des individus, tels que son adresse IP, son identifiant utilisateur, son adresse e-mail. 59 | 60 | * 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. 61 | -------------------------------------------------------------------------------- /02-Préparer son developpement.md: -------------------------------------------------------------------------------- 1 | # Fiche n°2 : Préparer son développement 2 | 3 | #### 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. 4 | 5 | ## Choix méthodologiques 6 | 7 | * **Mettez la protection de la vie privée au cœur de vos développements** en adoptant une méthodologie de [Privacy By Design](https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2019/guidelines-42019-article-25-data-protection-design_en). 8 | 9 | * 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 »](https://www.ssi.gouv.fr/uploads/2018/11/guide-securite-numerique-agile-anssi-pa-v1.pdf) 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. 10 | 11 | * 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. 12 | 13 | * **Réalisez une [analyse d’impact sur la protection des données (AIPD)](https://www.cnil.fr/fr/RGPD-analyse-impact-protection-des-donnees-aipd)**. Pour [certaines opérations de traitement](https://www.cnil.fr/sites/default/files/atoms/files/liste-traitements-avec-aipd-requise-v2.pdf), 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](https://www.cnil.fr/fr/outil-pia-telechargez-et-installez-le-logiciel-de-la-cnil) consacré à ce type d’analyse. 14 | 15 | 16 | ## Choix technologiques 17 | 18 | #### Architecture et fonctionnalités 19 | 20 | * **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](#Fiche_n°5%c2%a0:_Faire_un_choix_éclairé_de_son_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](https://www.legifrance.gouv.fr/affichCnil.do?oldAction=rechExpCnil&id=CNILTEXT000033929210&fastReqId=1726469546&fastPos=3). 21 | 22 | * **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. 23 | 24 | * **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. 25 | 26 | #### Outils et pratiques 27 | 28 | * **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](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) 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.](https://www.owasp.org/index.php/Main_Page) 29 | 30 | * **Le choix des technologies utilisées est crucial**. Un certain nombre de points sont à prendre en compte : 31 | 32 | * 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. 33 | 34 | * 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. 35 | 36 | * 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. 37 | 38 | * **Mettez en place un environnement de développement sécurisé et permettant le versionnage du code**, en suivant la [fiche dédiée](#Fiche_n°3%c2%a0:_Sécuriser_son_environnement_de_développement) de ce guide. 39 | -------------------------------------------------------------------------------- /03-Sécuriser son environnement de développement.md: -------------------------------------------------------------------------------- 1 | # Fiche n°3 : Sécuriser son environnement de développement 2 | 3 | #### 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. 4 | 5 | ## Évaluez vos risques et adoptez les mesures de sécurité adéquates 6 | 7 | * **É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. 8 | 9 | * 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](https://slack.com), [Trello](https://trello.com), [GitHub](https://github.com), etc.). 10 | 11 | ## Sécurisez vos serveurs et vos postes de travail d'une façon homogène et reproductible 12 | 13 | * 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](https://www.cnil.fr/fr/principes-cles/guide-de-la-securite-des-donnees-personnelles) du **guide sécurité des données personnelles** de la CNIL. 14 | 15 | * 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](https://github.com/ansible/ansible), [Puppet](https://github.com/puppetlabs/puppet) ou [Chef](https://github.com/chef/chef), peuvent être utilisés. 16 | 17 | * 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é](https://www.cert.ssi.gouv.fr/alerte/), [avis de sécurité](https://www.cert.ssi.gouv.fr/avis/) et les [bulletins d'actualité](https://www.cert.ssi.gouv.fr/actualite/) du CERT-FR. 18 | 19 | ## Maîtrisez vos accès et tracez les opérations 20 | 21 | * 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](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf). 22 | 23 |
24 | La gestion de clés SSH en pratique 25 |
26 | 27 | Si vous devez vous connecter à un service en ligne ou à l'un de vos serveurs, faites le choix d'algorithme asymétriques, ECDSA ou bien RSA. 28 | 29 | Par exemple en utilisant l'outil ssh-keygen (disponible sous linux et OSX), utiliser les commandes : 30 | ```bash 31 | ssh-keygen -t ed25519 32 | ``` 33 | Cette commande va créer ou utiliser votre répertoire de clés SSH, par exemple sur Linux `/home/username/.ssh/`), et y écrire deux éléments : une clé privée et une clé publique. 34 | 35 | Vous pouvez alors soit envoyer la clé publique au serveur pour le configurer (si vous avez un moyen d'authentification préexistant), soit la copier dans votre presse-papier pour la fournir au service que vous souhaitez utiliser : 36 | 37 | ```bash 38 | #Pour envoyer : 39 | ssh-copy-id -i ~/.ssh/key.pub user@host 40 | #Pour copier sur des systèmes Debian ou Ubuntu: 41 | sudo apt install xclip 42 | xclip -sel clip < ~/.ssh/key.pub 43 | ``` 44 | La clé privée ne doit jamais être envoyée ou partagée avec un tiers. Pour plus d'info sur les mesures organisationnelles à mettre en place pour une bonne gestion des clés, voir la norme [NISTIR 7966](https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.7966.pdf). 45 | 46 |
47 |
48 | 49 | * Favorisez une **authentification forte** sur les services utilisés par l'équipe de développement. 50 | 51 | * **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. 52 | 53 | * 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. 54 | -------------------------------------------------------------------------------- /04-Gérer son code source.md: -------------------------------------------------------------------------------- 1 | # Fiche n°4 : Gérer son code source 2 | 3 | #### 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. 4 | 5 | ## Paramétrez efficacement votre gestionnaire de code source, en pensant à sa sécurité 6 | 7 | * 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. 8 | 9 | * 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. 10 | 11 |
12 | Mise en place d'une authentification forte sur les services de gestion de développement de logiciels 13 |
14 | 15 | * Le logiciel libre [GitLab](https://docs.gitlab.com/) offre des fonctionnalités de [double authentification](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) et [d'accès par jeton d'authentification avec gestion des droits](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html). Ces deux fonctionnalités se retrouvent également sur des services web comme [GitHub](https://help.github.com/en/github/authenticating-to-github/configuring-two-factor-authentication). 16 | 17 | * **Pensez à sauvegarder vos codes de récupération dans un endroit sûr**, par exemple un gestionnaire de mot de passe ou conservez leur impression dans un endroit sécurisé. 18 | 19 |
20 |
21 | 22 | * 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.). 23 | 24 | * 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. 25 | 26 | * 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](https://nvie.com/posts/a-successful-git-branching-model/). 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. 27 | 28 | 29 | ## Soyez vigilant sur le contenu de votre code source 30 | 31 | * 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](https://git-scm.com/book/uz/v2/Customizing-Git-Git-Hooks) : le _commit_ sera alors annulé si le code source n’est pas d’une qualité suffisante. 32 | 33 | * Conservez vos secrets et mots de passe en dehors de votre dépôt de code source : 34 | 35 | * 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. 36 | 37 | * 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. 38 | 39 | * 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. 40 | 41 | * en utilisant des **logiciels spécifiques de gestion de secrets ou de gestion de configuration** (par exemple [Vault](https://github.com/hashicorp/vault) de la société HashiCorp, [Keywhiz](https://square.github.io/keywhiz) de la société Square ou [Knox](https://github.com/pinterest/knox) de la société Pinterest). 42 | 43 | * 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_](https://github.com/AGWA/git-crypt)). 44 | 45 | * Après un _commit_ qui contient des données personnelles ou d’autres données critiques, n’oubliez pas de [purger](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) [complètement](https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository#purging-a-file-from-your-repositorys-history) 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. 46 | 47 | * 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. 48 | 49 | ## Exemples d’outils 50 | 51 | * À l’inverse d’outils tels que [Subversion](https://subversion.apache.org/), qui ont besoin d’un serveur central pour fonctionner, les principaux gestionnaires de code source ([Git](https://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) par exemple) sont **décentralisés**. 52 | 53 | * 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](https://github.com/), [Bitbucket](https://bitbucket.org/), etc.), soit être installées en interne sur vos serveurs ([GitLab](https://about.gitlab.com/)). 54 | -------------------------------------------------------------------------------- /05-Faire un choix éclairé de son architecture.md: -------------------------------------------------------------------------------- 1 | # Fiche n°5 : Faire un choix éclairé de son architecture 2 | 3 | #### 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. 4 | 5 | ## Étudier le parcours de ses données 6 | 7 | * 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. 8 | 9 | * 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. 10 | 11 | * **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](https://www.cnil.fr/sites/default/files/typo/document/Recommandations_pour_les_entreprises_qui_envisagent_de_souscrire_a_des_services_de_Cloud.pdf). 12 | 13 |
14 | Quelques exemples d'étude du parcours de la donnée par la CNIL 15 |
16 | 17 | Les packs de conformité sectoriels sur les [compteurs communicants](https://www.cnil.fr/sites/default/files/typo/document/Pack_de_Conformite_COMPTEURS_COMMUNICANTS.pdf), [les véhicules connectés](https://www.cnil.fr/sites/default/files/atoms/files/pack_vehicules_connectes_web.pdf) et [la silver économie](https://www.cnil.fr/sites/default/files/atoms/files/pack_silver_economie_v4.pdf), ainsi que le [livre blanc sur les assistants vocaux](https://www.cnil.fr/sites/default/files/atoms/files/cnil_livre-blanc-assistants-vocaux.pdf) peuvent vous accompagner dans l'identification des parcours de données de votre produit. 18 | 19 | Chaque cas d'usage met ainsi en œuvre des parcours distincts pour lesquels la création d'un compte et l'intervention d'un ou plusieurs acteurs externes peuvent être nécessaires. 20 | 21 | La conformité de ces parcours est étudiée suivant 3 étapes : 22 | 23 | * l'identification du traitement, du responsable et de sa base légale, 24 | * l'identification des données collectées ainsi que de leur durée de conservation, 25 | * l'information et la garantie des droits des personnes concernées. 26 | 27 | 28 | Ces analyses peuvent vous accompagner dans l'identification des développements à prévoir, suivant les caractéristiques du traitement, la base juridique applicable et l'identification des données qui nécessitent une attention particulière du fait de leur caractère sensible. 29 | 30 |
31 | 32 | ## En cas de recours à un prestataire pour l’hébergement 33 | 34 | * **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é](https://www.cnil.fr/sites/default/files/typo/document/Recommandations_pour_les_entreprises_qui_envisagent_de_souscrire_a_des_services_de_Cloud.pdf). 35 | 36 | * **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é](https://www.cnil.fr/fr/transferer-des-donnees-hors-de-lue). La CNIL fournit sur site une carte permettant de visualiser les [différents niveaux de protection des données des pays dans le monde](https://www.cnil.fr/fr/la-protection-des-donnees-dans-le-monde). 37 | 38 | * **Si vous devez recourir à un prestataire pour héberger des données de santé**, assurez-vous que celui-ci est [certifié](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-certifies) ou [agréé](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-agrees) pour cette activité. 39 | 40 | * Les autres points de vigilance sont notamment : 41 | - l’existence d’une politique de sécurité accessible ; 42 | - les mesures de sécurité et sûreté physique sur le site d’hébergement ; 43 | - 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 ; 44 | - la gestion des mises à jour, la gestion des habilitations, l’authentification des personnels et la sécurité des développements applicatifs ; 45 | - la réversibilité/portabilité aisée des données dans un format structuré et couramment utilisé, sur demande et à tout moment. 46 | -------------------------------------------------------------------------------- /06-Sécuriser vos sites web, vos applications et vos serveurs.md: -------------------------------------------------------------------------------- 1 | # Fiche n°6 : Sécuriser vos sites web, vos applications et vos serveurs 2 | 3 | #### 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. 4 | 5 | ## Sécuriser les communications 6 | 7 | * **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. 8 | 9 | * **Rendez l’utilisation de TLS obligatoire** pour toutes les pages de votre site et pour vos applications mobiles. 10 | 11 | * **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. 12 | 13 | * **L’ANSSI a publié sur son site des [recommandations spécifiques](https://www.ssi.gouv.fr/entreprise/bonnes-pratiques/)** pour [mettre en œuvre TLS](https://www.ssi.gouv.fr/entreprise/guide/recommandations-de-securite-relatives-a-tls/) ou [pour sécuriser un site web](https://www.ssi.gouv.fr/uploads/2013/05/anssi-guide-recommandations_mise_en_oeuvre_site_web_maitriser_standards_securite_cote_navigateur-v2.0.pdf). 14 | 15 |
16 | En savoir plus sur la mise en place de TLS 17 |
18 | 19 | La sécurisation des communications des sites et applications mobiles nécessite d'utiliser le protocole "TLS". La combinaison de ce protocole avec le protocole "HTTP" permet un échange par "HTTPS". Certains algorithmes cryptographiques employés dans TLS, et ses versions précédentes "SSL", sont réputées vulnérables à différentes attaques. Vous pouvez vous faire accompagner dans le choix de ces algorithmes au moyen de **générateurs de configuration TLS**. Celui de [Mozilla](https://ssl-config.mozilla.org/) supporte par exemple de très nombreux serveurs. 20 | 21 | Deux exemples de configuration [Apache](annexes/conf_tls_apache.txt) et [Nginx](annexes/conf_tls_nginx.txt) commentés sont disponibles en annexe de ce guide. Vous pouvez vous référer au [Wiki Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS) pour plus de détails. 22 | 23 |
24 | 25 | ## Sécuriser les authentifications 26 | 27 | * **Suivez [les recommandations de la CNIL sur les mots de passe](https://www.cnil.fr/fr/mots-de-passe-des-recommandations-de-securite-minimales-pour-les-entreprises-et-les-particuliers)**. Pensez notamment à limiter le nombre de tentatives d’accès. 28 | 29 |
30 | Voir une implémentation Frontend de vérification de force de mot de passe 31 |
32 | 33 | Dans sa délibération du 10 janvier 2017 portant adoption d'une recommandation relative aux mots de passe, la CNIL spécifie que si le mot de passe n'est pas utilisé en conjonction avec un second facteur, et sans blocage de fréquence ("frequency capping"), un mot de passe devrait être constitué de 12 caractères et comprendre majuscule, minuscule, chiffres et caractères spéciaux. 34 | 35 | En conséquence, pour vérifier l'adhérence à ces règles, le code suivant est adéquat : 36 | ```javascript 37 | function checkPassword(pass) { 38 | if (!pass) 39 | return false; 40 | var expectations = [ 41 | /\d/.test(pass), 42 | /[a-z]/.test(pass), 43 | /[A-Z]/.test(pass), 44 | /\W/.test(pass), 45 | pass.length>=12 46 | ]; 47 | return !expectations.includes(false); 48 | } 49 | ``` 50 | Cela doit également s'accompagner d'une vérification backend de la force du mot de passe. 51 | 52 |
53 | 54 | * **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_. 55 | 56 |
57 | Voir des modalités pratiques de hashage des mots de passe 58 |
59 | 60 | Il ne faut jamais stocker les mots de passe des utilisateurs en clair dans vos bases de données, il faut systématiquement les hasher, avec un sel specifique. En pratique, bcrypt est sans doute la solution la plus simple d'utilisation. Elle utilise un sel aléatoire pour chaque hash et l'inclue dans le hash résultant pour la vérification d'un mot de passe. 61 | 62 | Par exemple en node.js : 63 | 64 | ```javascript 65 | #Pour installer: 66 | npm install bcrypt 67 | #Pour utiliser: 68 | const bcrypt = require('bcrypt'); 69 | const saltRounds = 10; // Niveau de difficulté de bcrypt 70 | #Enregistrer un mot de passe en DB 71 | const passwordAStocker = '*********'; 72 | bcrypt.genSalt(saltRounds, function(err, salt) { 73 | bcrypt.hash(passwordAStocker, salt, function(err, hash) { 74 | // stockez le résultat 'hash' en DB 75 | }); 76 | }); 77 | #Verifier un mot de passe 78 | const passwordAVerifier = '*********'; 79 | bcrypt.compare(passwordAVerifier, hash, function(err, result) { 80 | // 'result' vaut true si le mot de passe est le bon 81 | }); 82 | ``` 83 | 84 |
85 | 86 |
87 | En savoir plus sur les fonctions de hachage à clé 88 |
89 | 90 | * Les fonctions de hachage permettent d’assurer **l’intégrité des données**. Elles doivent reposer sur un algorithme **reconnu et sûr**. La famille de fonctions _SHA-2_ (par exemple _SHA-256_ et _SHA-512_) comporte des fonctions de hachage génériques qu’il ne faut pas utiliser directement pour certaines tâches spécifiques.En revanche, elles sont tout à fait acceptables comme fonction de base pour des fonctions de hachage spécialisées. Par exemple, la fonction HMAC utilisée avec SHA-256 ou SHA-512 est adaptée à la signature numérique. 91 | 92 | * Pour stocker les mots de passe, les fonctions adaptées sont les suivantes : _Argon2_, _yescrypt_, _scrypt_, _balloon_, _bcrypt_ et, dans une moindre mesure, _PBKDF2_. À noter que les fonctions _balloon_ et _PBKDF2_ peuvent êtres utilisées avec plusieurs fonctions de hachage sous-jacentes, le choix devant donc être fait sur une fonction reconnue (par exemple une fonction des familles _SHA-2_, _SHA-3_, _Blake2_ ou _Blake3_). 93 | 94 | * N'utilisez jamais d'algorithmes obsolètes, comme les chiffrements DES et 3DES ou les fonctions de hachage MD5 et SHA1. Leur utilisation peut permettre à un attaquant ayant connaissance du mot de passe haché de déchiffrer celui-ci sans difficulté et en un temps très court. 95 | 96 | * Les fonctions de hachage à clé permettent de rendre le calcul de l’empreinte différent en fonction de la clé utilisée. Pour deux clés différentes **l’empreinte obtenue sur un même message sera différente**. 97 | 98 | * Utilisez **des tailles de clés suffisantes**, _au minimum de 128 bits_ suivant l'algorithme utilisé. Protégez ces clés secrètes, au minimum par la **mise en œuvre de droits d’accès restrictifs** et d’**un mot de passe sûr**. 99 | 100 | * Rédiger une procédure indiquant la manière dont les clés vont être gérés en prenant en compte **les cas d’oubli de mot de passe de déverrouillage**. 101 | 102 | * Par exemple, le code Python suivant permet de **générer un sel aléatoire et un haché d'un mot de passe ainsi que de vérifier la validité de celui-ci** depuis la bibliothèque [bcrypt](https://pypi.org/project/bcrypt/) : 103 | 104 | ```python 105 | import bcrypt #importation de la bibliothèque bcrypt 106 | 107 | sel = bcrypt.gensalt() #Génération d'un sel aléatoire à conserver de manière sécurisée 108 | 109 | hache_du_mot_de_passe = bcrypt.hashpw(mot_de_passe, sel) #Génération du hachage du mot de passe avec le sel généré 110 | 111 | mot_de_passe_valide = bcrypt.checkpw(mot_de_passe, hache_du_mot_de_passe) #Test de la validité du mot de passe depuis son haché 112 | ``` 113 | 114 |
115 | 116 | * **Dans le cas où des cookies sont utilisés pour permettre l’authentification**, il est recommandé : 117 | 118 | * de protéger les cookies contre des lectures via des canaux de non chiffrées, en forcant l’utilisation d’HTTPS via l’[HSTS](https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security), ainsi que par l'utilisation des indicateurs `Secure` et `HttpOnly` ; 119 | 120 | * d'utiliser des protections contre des [injections de requêtes illégitimes par rebond](https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003) (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 ; 121 | 122 | * 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. 123 | 124 | * **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](https://www.ssi.gouv.fr/uploads/2021/03/anssi-guide-selection_crypto-1.0.pdf). 125 | 126 | * **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. 127 | 128 | * **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. 129 | 130 | * **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. 131 | 132 | ## Limiter la divulgation d’information sur les comptes existants 133 | 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. 134 | 135 | * **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"_. 136 | * **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é"_ 137 | * **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é"_ 138 | 139 | 140 | ## Sécuriser les infrastructures 141 | 142 | * **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. 143 | 144 | * **Limitez le nombre de composants mis en œuvre,** et pour chacun de ces composants : 145 | 146 | * **installez les mises à jour critiques** sans délai en programmant une vérification automatique hebdomadaire ; 147 | 148 | * **automatisez une veille des vulnérabilités** par exemple en s’inscrivant au bulletin [CERT-FR](https://www.cert.ssi.gouv.fr/). 149 | 150 | * **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. 151 | 152 |
153 | Choisir et utiliser des outils de détection des vulnérabilités 154 |
155 | 156 | Les **outils de détection des vulnérabilités**, comme [OpenVAS](https://github.com/greenbone/openvas) et [Metasploit](https://github.com/rapid7/metasploit-framework), permettent d'identifier certaines vulnérabilités connus au sein d'applications. Certaines solutions se spécialisent sur des services particuliers, par exemple [Wordpress](https://github.com/wpscanteam/wpscan) ou [Joomla](https://github.com/rezasp/joomscan). 157 | 158 | Il est recommandé de vérifier l'état et la fraicheur des bases de données des vulnérabilités. Ces analyses peuvent également nuire au bon fonctionnement des serveurs, elles sont donc plutôt à réaliser sur des environnements en préproduction. 159 |
160 | 161 | * **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*](https://fr.wikipedia.org/wiki/Netstat). 162 | 163 |
164 | Auditer les ports ouverts en pratique 165 |
166 | 167 | La commande _netstat_ permet de lister les ports TCP ou UDP ouverts sur un serveur. Sur l'exemple suivant, les ports standards HTTP, HTTPS et SSH d'un serveur sont ouverts vers l'extérieur, un serveur de base de données (MariaDB) est en écoute local et des tentatives connexions sont en cours sur les ports SSH et HTTPS : 168 | 169 | ``` 170 | $ netstat -alpe --ip 171 | Active Internet connections (servers and established) 172 | Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name 173 | tcp 0 0 localhost:mysql 0.0.0.0:* LISTEN mysql 14492 - 174 | tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN root 50278 - 175 | tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN root 12948 - 176 | tcp 0 0 0.0.0.0:https 0.0.0.0:* LISTEN root 50280 - 177 | tcp 0 0 mon-serveur.fr:https adresse1.fr:38056 TIME_WAIT root 0 - 178 | tcp 0 0 mon-serveur.fr:ssh adresse2.com:45302 TIME_WAIT root 0 - 179 | tcp 0 0 mon-serveur.fr.:https adresse3.eu:56277 FIN_WAIT2 root 0 - 180 | tcp 0 0 mon-serveur.fr:https adresse4.be:56306 ESTABLISHED www-data 380689 - 181 | tcp 0 524 mon-serveur.fr:ssh adresse1.fr:65137 ESTABLISHED root 382490 - 182 | ``` 183 | 184 | 185 | 186 | Le logiciel [Nmap](https://nmap.org/) permet de réaliser cette analyse depuis un réseau de communication. Sur l'exemple suivant, le protocole d'administration SSH du serveur est accessible sur Internet. 187 | 188 | ``` 189 | $ nmap mon-serveur.fr 190 | Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-11 18:13 CEST 191 | Nmap scan report for mon-serveur.fr 192 | Host is up (0.011s latency). 193 | Not shown: 997 filtered ports 194 | PORT STATE SERVICE 195 | 22/tcp open ssh 196 | 80/tcp open http 197 | 443/tcp open https 198 | 199 | Nmap done: 1 IP address (1 host up) scanned in 4.99 seconds 200 | ``` 201 | Il nécessite donc une attention particulière, comme l'utilisation d'une authentification forte et/ou d'un filtrage par IP. 202 | 203 |
204 |
205 | 206 | * **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. 207 | 208 | * En matière de gestion de bases de données, les bonnes pratiques sont notamment de : 209 | 210 | * **utiliser des comptes nominatifs** pour l’accès aux bases de données et créer des comptes spécifiques à chaque application ; 211 | 212 | * **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.) ; 213 | 214 | * mettre en œuvre des mesures contre les attaques par injection de code SQL, de scripts, etc. ; 215 | 216 | * favoriser le chiffrement des données sur les disques de stockage et dans les bases de données. 217 | 218 | * 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](https://www.ssi.gouv.fr/uploads/2017/12/guide_cloisonnement_systeme_anssi_pg_040_v1.pdf). 219 | -------------------------------------------------------------------------------- /07-Minimiser les données collectées.md: -------------------------------------------------------------------------------- 1 | # Fiche n°7 : Minimiser les données collectées 2 | 3 | #### 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. 4 | 5 | ## 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 6 | 7 | * 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. 8 | 9 | * Si des données spécifiques ne sont pas **nécessaires pour une certaine catégorie de personnes**, ne les collectez pas. 10 | 11 | * 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. 12 | 13 | * 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. 14 | 15 | * 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.). 16 | 17 | * 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. 18 | 19 | * 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. 20 | 21 | ## Une fois les données collectées, mettez en place des mécanismes d’effacement automatique 22 | 23 | * 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. 24 | 25 |
26 | Exemple d'implémentation de purge automatique en MySQL 27 |
28 | 29 | En MySQL, l'_event scheduler_ permet de supprimer les données périmées automatiquement. Par exemple : 30 | 31 | ```sql 32 | CREATE EVENT e_mensuel 33 | ON SCHEDULE 34 | EVERY 30 DAY 35 | COMMENT 'supprime automatiquement les lignes inscrites de plus d un an' 36 | DO 37 | BEGIN 38 | DELETE from votreTable 39 | WHERE datediff(now(), votreTable.votreColonneDate) > 365; 40 | END 41 | ``` 42 | Son pré-requis est d'associer une date d'inscription à chacune des lignes de la base de données afin de permettre le calcul de sa date de péremption. 43 | 44 |
45 |
46 | 47 | * 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. 48 | 49 | * 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](#Fiche_n°1%c2%a0:_Identifier_les_données_à_caractère_personnel)). 50 | 51 | * Journalisez les **procédures d’effacement automatique**. Les journaux correspondants pourront être utilisés comme **preuve d’effacement** d’une donnée. 52 | -------------------------------------------------------------------------------- /08-Gérer les profils utilisateurs.md: -------------------------------------------------------------------------------- 1 | # Fiche n°8 : Gérer les utilisateurs 2 | 3 | #### 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. 4 | 5 | 6 | ## Les bonnes pratiques de gestion des utilisateurs 7 | 8 | * 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. 9 | 10 | * Veillez à **imposer une authentification** avant tout accès à des données personnelles, conformément aux [recommandations de la CNIL](https://www.cnil.fr/fr/mots-de-passe-des-recommandations-de-securite-minimales-pour-les-entreprises-et-les-particuliers). 11 | 12 | * 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. 13 | 14 | * 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. 15 | 16 | * 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**. 17 | 18 | ## Fluidifier la gestion des profils d’habilitation 19 | 20 | * 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. 21 | 22 | * 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. 23 | 24 | 25 | * **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. 26 | 27 | 28 | * **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. 29 | 30 |
31 | Les gestionnaires de mot de passe en pratique 32 |
33 | 34 | * Les gestionnaires de mots de passe permettent de **centraliser l'ensemble des identifiants et des mots de passe** dans une base de données unique. Certains d'entres permettent également de tester la robustesse des mots de passe et d'en générer automatiquement et de manière aléatoire tout en répondant aux contraintes imposées par les systèmes. Assurez-vous avant tout usage que les mots de passes conservées par le logiciel sont chiffrés et protégés par un mot de passe suffisamment robuste. 35 | 36 | * Le gestionnaire de mots de passe libre [KeePass](https://keepass.info/), dans sa en version 2.10, a obtenu la [Certification de Sécurité de Premier Niveau](https://www.ssi.gouv.fr/administration/produits-certifies/cspn/) (CSPN) de l'ANSSI. 37 | 38 | * Les gestionnaires de mots de passe intégrés aux navigateurs sont particulièrement **exposés aux vulnérabilités des sites**, par exemple les attaques de type [Cross Site Scripting](https://www.cert.ssi.gouv.fr/information/CERTA-2002-INF-001/) (XSS) ou [Cross-Site Request Forgery](https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/) (CSRF). La fiche 18 [Se prémunir contre les attaques informatiques](#Fiche_n°18%c2%a0:_Se_prémunir_contre_les_attaques_informatiques) illustre en détail le fonctionnement de cette attaque. 39 | 40 |
41 | 42 | ## Ressources utiles 43 | 44 | * La [recommandation relative à la journalisation](https://www.cnil.fr/fr/la-cnil-publie-une-recommandation-relative-aux-mesures-de-journalisation) de la CNIL qui délivre des conseils pour déterminer les mesures à prendre selon le type de traitement de données. 45 | 46 | -------------------------------------------------------------------------------- /09-Maîtriser vos bibliothèques et vos SDK.md: -------------------------------------------------------------------------------- 1 | # Fiche n°9 : Maîtriser vos bibliothèques et vos SDK 2 | 3 | #### 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. 4 | 5 | ## Faire un choix éclairé 6 | 7 | * **É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. 8 | 9 | 10 | * **Choisissez des logiciels, bibliothèques et SDK maintenus :** 11 | 12 | * 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 ; 13 | 14 | * 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. 15 | 16 | * **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 : 17 | 18 | * l’utilisateur final est informé de ces opérations de traitements ; 19 | 20 | * 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 ; 21 | 22 | * les éventuels transferts de données hors de l’union européenne sont correctement encadrés ; 23 | 24 | * la relation avec le tiers est encadré par un contrat de sous-traitance conforme à l’article 28 du RGPD. 25 | 26 | * **Ces obligations s'appliquent particulièrement aux « SDK » permettant [d’afficher de la publicité ciblée sur les terminaux](https://www.cnil.fr/fr/applications-mobiles-mise-en-demeure-absence-de-consentement-geolocalisation-ciblage-publicitaire-2)**. 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](https://www.google.com/about/company/user-consent-policy/). 27 | 28 | * **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. 29 | 30 | ## Évaluer les éléments choisis 31 | 32 | * **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é ; 33 | 34 | * **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 ; 35 | 36 | * **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 ; 37 | 38 |
39 | Les outils de visualisation des dépendances des applications 40 |
41 | 42 | Les gestionnaires de dépendances intègrent des fonctionnalités de suivi et d'audit. A titre d'exemple, la commande `npm audit` affiche un rapport des vulnérabilités connues de chaque dépendance d'un projet _node.js_. 43 | 44 | La visualisation des dépendances des applications compilées, ou "packagées", nécessitent des outils plus élaborés. En voici quelques exemples : 45 | 46 | * L'[association Exodus Privacy](https://exodus-privacy.eu.org/fr/) met librement à disposition la plateforme d'analyse des applications Android εxodus. 47 | 48 | * L'outil [otool](https://www.unix.com/man-page/osx/1/otool/) liste les dépendances des bibliothèques d'applications macOS et iOS. 49 | 50 | * L'outil [dependency-cruiser](https://github.com/sverweij/dependency-cruiser) affiche sous forme de graphique les dépendances de projet _javascript_. 51 | 52 | 53 |
54 |
55 | 56 | * **Faites attention aux tentatives de [*typosquattage*](https://fr.wikipedia.org/wiki/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. 57 | 58 | 59 | ## Maintenir les bibliothèques et SDK 60 | 61 | * **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. 62 | 63 | * **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 ; 64 | 65 | * **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) ; 66 | 67 | * **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. 68 | 69 | ## Ressources utiles 70 | 71 | * La [base de données des faiblesses du code CWE](https://cwe.mitre.org), maintenue par l'organisme MITRE, liste les vulnérabilités que l'on peut rencontrer dans les logiciels et les dépendances. 72 | 73 | -------------------------------------------------------------------------------- /10-Veiller à la qualité de votre code et sa documentation.md: -------------------------------------------------------------------------------- 1 | # Fiche n°10 : Veiller à la qualité de votre code et sa documentation 2 | 3 | #### 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. 4 | 5 | 6 | ## Documentez le code et l’architecture 7 | 8 | * 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. 9 | 10 | * **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. 11 | 12 | * **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. 13 | 14 | * **« 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 »](#Fiche_n°4%c2%a0:_Gérer_son_code_source)). 15 | 16 |
17 | Les outils de documentation intégrés au code 18 |
19 | 20 | Certains systèmes de documentation utilisent le **code lui-même** comme support. La documentation est ainsi écrite directement dans les commentaires du programme. 21 | 22 | [Doxygen](https://www.doxygen.nl/index.html), par exemple, offre une syntaxe permettant de générer de la documentation, qui est compatible avec les langages de programmation les plus utilisés. L'exemple suivant est une classe C++ commentée suivant son paradigme : 23 | 24 | ``` 25 | //! Une classe d'exemple 26 | /*! 27 | Description plus approfondie de la classe. 28 | (Et n'oubliez pas de documenter sans mettre de descriptions génériques dans votre projet.) 29 | */ 30 | 31 | class Example 32 | { 33 | public: 34 | 35 | //! Le constructeur de la classe 36 | /*! 37 | Description plus approfondie du constructeur. 38 | */ 39 | Example(); 40 | 41 | //! Le destructeur de la classe. 42 | /*! 43 | Description plus approfondie du destructeur. 44 | */ 45 | virtual ~Example(); 46 | 47 | //! Une méthode qui fait quelque chose 48 | /*! 49 | \param param1 un paramètre important 50 | \param param2 un deuxième paramètre aussi important 51 | \return le résultat qui dépend des deux paramètres et de l'état interne de l'instance 52 | */ 53 | int doSomething(int param1, const char *param2); 54 | 55 | //! Une variable membre publique 56 | /*! 57 | Description plus approfondie de la variable membre. 58 | */ 59 | int attr_; 60 | }; 61 | ``` 62 | 63 | Certains langages de programmation supportent également nativement l'utilisation des commentaires pour documenter du code. Par exemple, les "docstrings" en Python : 64 | 65 | ``` 66 | class Example: 67 | """Une classe d'exemple 68 | Description plus approfondie de la classe. 69 | """ 70 | 71 | def __init__(self): 72 | """Le constructeur de la classe 73 | Description plus approfondie du constructeur. 74 | """ 75 | self.attr = None 76 | 77 | def do_something(self, param1, param2): 78 | """Une méthode qui fait quelque chose 79 | param1: un paramètre important 80 | param2: un deuxième paramètre aussi important 81 | return: le résultat qui dépend des deux paramètres et de l'état interne de l'instance 82 | """ 83 | [...] 84 | return result 85 | 86 | help(Example) 87 | # affiche la documentation complète de la classe, qui est générée en partie à partir des docstrings 88 | help(Example.do_something) 89 | # affiche uniquement la documentation de la méthode 90 | ``` 91 |
92 | 93 | * **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. 94 | 95 | ## Contrôlez la qualité de votre code et de sa documentation 96 | 97 | * 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](https://github.com/Kristories/awesome-guidelines). Voici quelques exemples de bonnes pratiques supplémentaires : 98 | 99 | * **utiliser des noms de variables et de fonctions explicites** permet de comprendre plus facilement ce qu’il se passe au premier regard ; 100 | 101 | * **correctement indenter son code** permet de percevoir la structure du code plus rapidement ; 102 | 103 | * **é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é. 104 | 105 | * **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 : 106 | 107 | * 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 ; 108 | 109 | * 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. 110 | 111 |
112 | Les outils de mesure de la qualité d'un code 113 |
114 | 115 | Certains langages de programmation disposent d'un **style de programmation standard**, par exemple [PEP8](https://www.python.org/dev/peps/pep-0008/) pour le langage Python. Des outils automatiques peuvent contrôler le respect de ces styles, par exemple [pep8.py](https://pep8.readthedocs.io/en/release-1.7.x/intro.html) pour la PEP8. Pour les langages ne disposant pas de styles de programmation standard, différents styles ont été créés, avec des outils automatiques permettant de les vérifier, par exemple [SonarQube](https://github.com/SonarSource/sonarqube) ou [checkstyle](https://checkstyle.org/) pour Java. 116 | 117 | Des **outils de qualité de code plus généraux** peuvent détecter un certain nombre de problèmes : variables non utilisées ou non définies, duplication de code, etc. Par exemple [ESLint](https://eslint.org) pour Javascript ou [Clippy](https://github.com/rust-lang/rust-clippy) pour Rust. 118 | 119 | Enfin, des **outils d'analyse statique** permettent une analyse plus fine du code, afin d'évaluer son comportement sans pour autant exécuter le programme, par exemple [SpotBugs](https://spotbugs.github.io/) pour Java ou [Frama-C](http://frama-c.com/) pour le C. 120 |
121 | -------------------------------------------------------------------------------- /11-Tester vos applications.md: -------------------------------------------------------------------------------- 1 | # Fiche n°11 : Tester vos applications 2 | 3 | #### 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. 4 | 5 | ## Automatisez les tests 6 | 7 | * 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. 8 | 9 | * Mettez en place un **système d’intégration continue** afin de lancer les tests automatiquement après chaque modification dans votre code source. 10 | 11 |
12 | Mise en œuvre de systèmes d'intégration continue 13 |
14 | 15 | * Les logiciels d'intégration continue permettent d'automatiser les vérifications de code et d'y associer des métriques à chaque modification de code source. Cette pratique vise à détecter les problèmes d'intégration au plus tôt dans le stade de développement comme des modifications à la mise en production. 16 | 17 | * Des solutions propriétaires et libres existent pour interfacer cette automatisation avec les outils de gestion de code source, entre autres [Jenkins](https://www.jenkins.io/) et [GitLab CI/CD](https://docs.gitlab.com/ee/ci/). 18 | 19 | * Une attention particulière doit être portée sur la sécurisation de ce type de solution. Veillez notamment à ce que la solution dispose pas d'accès privilégiés au gestionnaire de code source ou aux systèmes les hébergeant. 20 | 21 |
22 |
23 | 24 | ## Intégrez les tests dans votre stratégie d’entreprise 25 | 26 | * 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. 27 | 28 | * Les métriques auxquelles il faut réfléchir sont par exemple : 29 | 30 | * le **taux de couverture** des tests et leur type ; 31 | 32 | * le **taux de réplication** du code ; 33 | 34 | * le **nombre de vulnérabilités** (au sens de ce que détectent les outils) et leur type, etc. 35 | 36 | ## Attention aux données de test ! 37 | 38 | * 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** ; 39 | 40 | * 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. ; 41 | 42 | * 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 ; 43 | 44 |
45 | Les outils de génération de données fictives 46 |
47 | 48 | Lors du développement de votre service, il est toujours préférable d'utiliser des données fictives. A défaut, les environnement des tests doivent faire l’objet des mêmes mesures de sécurité que l’environnement de production. 49 | 50 | La génération de données fictives peut se faire au travers d'outils construits pour tester vos services en générant des données variées et parfois inattendues. Par exemple, en python, la librairie [**Faker**](https://pypi.org/project/Faker/) permet simplement de générer de nombreux types de données : 51 | 52 | ```python 53 | from faker import Faker 54 | # Définit une instance localisée en France 55 | fake = Faker("fr_FR") 56 | # Numéro de téléphone 57 | fake.phone_number() 58 | # '+33 3 38 24 21 94' 59 | # Adresse email 60 | fake.ascii_email() 61 | # 'lorraineboutin@live.com' 62 | # Numéro de carte de crédit 63 | fake.credit_card_number() 64 | # '180009753513939' 65 | # IBAN 66 | fake.iban() 67 | # 'FR05660487647593824219489241' 68 | ``` 69 | 70 |
71 |
72 | 73 | * 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. 74 | -------------------------------------------------------------------------------- /12-Informer les utilisateurs.md: -------------------------------------------------------------------------------- 1 | # Fiche n°12 : Informer les personnes 2 | 3 | #### 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. 4 | 5 | ## Qui informer et quand le faire ? 6 | 7 | * Il faut informer les personnes concernées : 8 | 9 | * **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. 10 | 11 | * 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 ; 12 | 13 | * **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. 14 | 15 | * Les moments où cette information est nécessaire : 16 | 17 | * **au moment du recueil des données** en cas de collecte directe ; 18 | 19 | * **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](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre3#art14-5)) ; 20 | 21 | * **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](#Fiche_n°1%c2%a0:_Identifier_les_données_à_caractère_personnel). 22 | 23 | ## Quelles informations dois-je donner ? 24 | 25 | * Dans tous les cas, il faut préciser : 26 | 27 | * **l’identité et les coordonnées de l’organisme** qui collecte les données (qui traite les données ?) ; 28 | 29 | * **les finalités** (à quoi vont servir les données collectées ?) ; 30 | 31 | * **la base légale** sur laquelle repose le traitement des données (retrouvez toutes les [**informations sur les bases légales**](https://www.cnil.fr/fr/les-bases-legales)) ; 32 | 33 | * **le caractère obligatoire ou facultatif du recueil des données** (ce 34 | qui suppose une réflexion en amont sur l’utilité de collecter ces 35 | données au vu de l’objectif poursuivi – principe de « minimisation » des 36 | données) et les **conséquences pour la personne** en cas de non-fourniture des 37 | données ; 38 | 39 | * **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 ?) ; 40 | 41 | * **la durée de conservation des données** (ou critères permettant de la déterminer) ; 42 | 43 | * **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](https://www.cnil.fr/fr/les-droits-pour-maitriser-vos-donnees-personnelles) sont applicables pour tous les traitements) ; 44 | 45 | * **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 ; 46 | 47 | * **le droit d’introduire une réclamation auprès de la CNIL.** 48 | 49 | * 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](https://www.cnil.fr/fr/conformite-rgpd-information-des-personnes-et-transparence)). 50 | 51 | * En cas de collecte indirecte, il faut ajouter : 52 | 53 | * **les catégories de données** recueillies ; 54 | 55 | * **la provenance des données** (en indiquant notamment si elles sont issues de sources accessibles au public). 56 | 57 | ## Sous quelle forme dois-je fournir ces informations ? 58 | 59 | * L’information doit être **facile d’accès** : l’utilisateur doit la trouver sans difficultés. 60 | 61 | * **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). 62 | 63 | * **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. 64 | 65 | * **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. 66 | 67 | * 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). 68 | 69 |
70 | Forme et contenu de l'information à délivrer 71 |
72 | 73 | * L’information des personnes est fondamentale car **elle permet aux personnes de comprendre l’objectif du traitement et l’utilisation de leurs données**. La transparence ainsi offerte sur le traitement est l’un des principaux vecteurs pour **instaurer une relation de confiance** avec les personnes, en leur permettant notamment d’exercer leurs autres droits. 74 | 75 | * **Les méthodes et techniques choisies** pour rendre l’information accessible peuvent varier en fonction du contexte et des modalités d’interaction avec les personnes : pop-in, bulles, pages dédiées, QR code, messages audio, vidéos, panneaux d’affichage, documentation papier, campagne d’information, etc. 76 | 77 | * De plus, le moment de présentation de l’information est crucial : il faut veiller à faire en sorte qu’elle soit délivrée « à froid » pour que la personne en prenne pleinement connaissance. Une information claire donnée en amont d’un acte d’achat ou de souscription et, à l’inverse, en aval après un temps d’appropriation du service sont ainsi généralement plus accessibles et mieux prises en compte qu’une information placée au moment où la personne vient de décider d’acheter ou de souscrire car elle est généralement soumise à un biais de confirmation à ce moment-là. 78 | 79 | * Le site [Données & Design](https://design.cnil.fr) développe ces concepts et fournit des [exemples d’interfaces et d'informations permettant de faciliter la compréhension du traitement](https://design.cnil.fr/concepts/information/). Le site de la CNIL comprend également [des exemples de notices d’information à plusieurs niveaux d'information](https://www.cnil.fr/fr/rgpd-exemples-de-mentions-dinformation) à adapter ou à adapter suivant le contexte de votre traitement. 80 | 81 |
82 | 83 | ## Quelle communication effectuer lorsque la sécurité des données est compromise ? 84 | 85 | * **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. 86 | 87 | * 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…). 88 | 89 | * La notification de la violation à la CNIL doit se faire via le [site web de la CNIL](https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles). La fiche 18 [Se prémunir contre les attaques informatiques](#Fiche_n°18%c2%a0:_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. 90 | 91 | ## Ressources utiles 92 | 93 | * Le site [Données & Design](https://design.cnil.fr) développé par le Laboratoire d’Innovation Numérique de la CNIL. 94 | * Le site de la CNIL contient également [de nombreux exemples de notices d’information](https://www.cnil.fr/fr/rgpd-exemples-de-mentions-dinformation). 95 | * La page [Violations de données personnelles](https://www.cnil.fr/fr/les-violations-de-donnees-personnelles) sur le site de CNIL. 96 | -------------------------------------------------------------------------------- /13-Préparer l'exercice des droits des personnes.md: -------------------------------------------------------------------------------- 1 | # Fiche n°13 : Préparer l’exercice des droits des personnes 2 | 3 | #### 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. 4 | 5 | #### 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. 6 | 7 | 8 | ## Les mesures minimales à mettre en place 9 | 10 | * 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. 11 | 12 | * 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. 13 | 14 | * 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. 15 | 16 | ## Voici quelques exemples de droits et leur possible implémentation 17 | 18 | * **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. 19 | **_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. 20 | 21 | * **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. 22 | **_Possibles implémentations_** : 23 | 1. Prévoyez une fonctionnalité permettant d’effacer toutes les données relatives à une personne. 24 | 25 | 2. Prévoyez aussi une notification automatique des sous-traitants afin qu’ils effacent eux aussi les données relatives à cette personne. 26 | 27 | 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. 28 | 29 | * **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. 30 | **_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. 31 | 32 | * **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. 33 | **_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.) 34 | 35 | * **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. 36 | **_Possible implémentation_** : permettez de pouvoir modifier directement les données dans le compte utilisateur. 37 | 38 | * **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. 39 | **_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. 40 | 41 |
42 | L'exercice de droit en pratique 43 |
44 | 45 | * Lorsqu’une personne souhaite exercer un droit, elle doit pouvoir **savoir vers qui s’adresser** de façon simple. Les informations de contact doivent être **facilement accessibles** et être localisées à des endroits paraissant logiques, par exemple dans le compte utilisateur, dans des informations contextuelles, les politiques de confidentialité, les politiques de vie privée, une FAQ, etc. 46 | 47 | * L’exercice d’un droit peut constituer un événement exceptionnel dans le parcours utilisateur classique d’un service. De fait, il est d’autant plus important de bien la guider dans cette démarche qui peut paraître intimidante : **proposer des étapes simples** pour formuler une demande, rappeler l’**utilité des droits et des résultats attendus**, mettre à disposition des **modèles de demande pour faciliter les démarches**. 48 | 49 | * **L’exercice d’un droit** peut s’effectuer par **différentes modalités et différents formats**: formulaire, mail, comptes en ligne, courrier. Le site Données & Design fournit des [exemples d’interfaces pour faciliter les exercices de droits](https://design.cnil.fr/concepts/exercice-des-droits/). 50 | 51 | * Tout au long du processus d’exercice des droits, il est important de veiller à ce que la personne soit informée de l’évolution de sa demande. Lui faire des retours régulièrement, pour **attester de la bonne réception** de sa demande ou encore pour lui faire des **retours sur les décisions prises** suite à celle-ci, dans un **format accessible** et correspondant à celui avec lequel elle vous a contacté est donc nécessaire. 52 | 53 | * Afin d’assurer à la personne une bonne continuité dans sa démarche d’exercice de droit, ou en cas de contestation de sa part de la décision que vous prenez auprès d’une autorité de protection, il est recommandé de permettre à la personne de pouvoir garder facilement une **trace de sa démarche**. Un système d’impression de demandes, d’archivage ou de téléchargements des échanges, etc. peuvent ainsi être mis en place. 54 | * 55 |
56 | 57 | ## En conclusion 58 | 59 | * Le site [Données & Design](https://design.cnil.fr) développé par le Laboratoire d’Innovation Numérique de la CNIL (LINC). 60 | 61 | * Enfin, soyez **inventifs** ! (En cas de doute, demandez conseil à la CNIL.) 62 | -------------------------------------------------------------------------------- /14-Gérer la durée de conservation des données.md: -------------------------------------------------------------------------------- 1 | # Fiche n°14 : Gérer la durée de conservation des données 2 | 3 | #### 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). 4 | 5 | ## Les cycles de conservation des données 6 | 7 | * Le cycle de conservation des données à caractère personnel peut être divisé en **trois phases successives distinctes** : 8 | 9 | * la base active ; 10 | 11 | * l’archivage intermédiaire ; 12 | 13 | * l’archivage définitif ou la suppression. 14 | 15 | * 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**. 16 | 17 | * 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. 18 | 19 | * 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. 20 | 21 | * 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](#Fiche_n°13%c2%a0:_Préparer_l’exercice_des_droits_des_personnes)), afin de garantir un fonctionnement homogène de votre système. 22 | 23 | ## Quelques exemples de durée de conservation 24 | 25 | * 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. 26 | 27 | * Les **données figurant dans un dossier médical** doivent être conservées 20 ans. 28 | 29 | * Les **coordonnées d’un prospect ne répondant à aucune sollicitation** peuvent être conservées pendant 3 ans. 30 | 31 | * 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. 32 | -------------------------------------------------------------------------------- /15-Prendre en compte les bases légales dans l’implémentation technique.md: -------------------------------------------------------------------------------- 1 | # Fiche n°15 : Prendre en compte les bases légales dans l’implémentation technique 2 | 3 | #### 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](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre2#Article6). 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](#Fiche_n°13%c2%a0:_Préparer_l’exercice_des_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. 4 | 5 | ## Définition des bases légales prévues par le RGPD 6 | 7 | * Dans le cadre d’un développement pour un organisme privé (entreprises, associations, etc.), les bases légales les plus souvent utilisées sont : 8 | 9 | * **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 ; 10 | 11 | * **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 ; 12 | 13 | * **le consentement** : la personne concernée a explicitement consenti au traitement. 14 | 15 | * 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 : 16 | 17 | * **l’obligation légale** : le traitement est imposé par des textes réglementaires; 18 | 19 | * **la mission d’intérêt public** : le traitement est nécessaire à l’exécution d’une mission d’intérêt public. 20 | 21 | * Vous trouverez sur le site de la CNIL un [ensemble de fiches pratiques](https://www.cnil.fr/fr/les-bases-legales) qui vous permettra de vous accompagner dans le choix des bases légales les plus adaptées à vos traitements. 22 | 23 | * 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. 24 | 25 | * 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](https://www.cnil.fr/fr/la-prospection-commerciale-par-courrier-electronique), [certains cookies et autres traceurs](https://www.cnil.fr/fr/site-web-cookies-et-autres-traceurs), etc.). 26 | 27 | ## Choisir la base légale adéquate 28 | 29 | * **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. 30 | 31 | * 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. 32 | 33 | * 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**. 34 | 35 | * 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. 36 | 37 | * 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](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre2#Article9). 38 | 39 | ## Les exercices des droits et les modalités d’information à prévoir suivant la base légale 40 | 41 | * Les bases légales utilisées doivent **toujours figurer dans les informations transmises à la personne**. 42 | 43 | * 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. 44 | 45 | * Le tableau suivant récapitule les exercices des droits à prévoir suivant les bases légales choisies : 46 | 47 | | | Droit d’accès | Droit de rectification | Droit à l’effacement | Droit à la limitation du traitement | Droit à la portabilité | Droit d’opposition | 48 | |:---------------------:|:-------------:|:----------------------:|:--------------------:|:-----------------------------------:|:----------------------:|:---------------------------:| 49 | | **Consentement** | ✔ | ✔ | ✔ | ✔ | ✔ | **retrait du consentement** | 50 | | **Contrat** | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ | 51 | | **Intérêt légitime** * | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ | 52 | | **Obligation légale** | ✔ | ✔ | ✔** | ✔ | ✘ | ✘ | 53 | | **Intérêt public** | ✔ | ✔ | ✘ | ✔ | ✘ | ✔ | 54 | | **Intérêts vitaux** | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | 55 | 56 | \* **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.) 57 | 58 | \** **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 : 59 | 60 | 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 61 | 62 | 2. les données à caractère personnel ont fait l'objet d'un traitement illicite; ou 63 | 64 | 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. 65 | -------------------------------------------------------------------------------- /16-Analyser les traceurs.md: -------------------------------------------------------------------------------- 1 | # Fiche n°16 : Analyser les pratiques en matière de traceurs sur vos sites et vos applications 2 | 3 | #### 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. 4 | 5 | 6 | ## Les traceurs visés par l'obligation du recueil du consentement préalablement à leur usage 7 | 8 | * **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. 9 | 10 | * 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**: 11 | * la publicité personnalisée ; 12 | * la mesure de la publicité (non ciblée) ; 13 | * la publicité geolocalisée ; 14 | * la personnalisation du contenu (éditorial ou en termes de produits) ; 15 | * le partage sur les réseaux sociaux. 16 | 17 | ## Les traceurs qui ne sont pas visés par ces obligations 18 | 19 | * **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. 20 | 21 | * 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é ». 22 | 23 | * [Sous certaines conditions](#Fiche_n°16%c2%a0:_Mesurer_la_fréquentation_de_vos_sites_web_et_de_vos_applications), 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](https://www.cnil.fr/fr/solutions-de-mesure-daudience-exemptees-de-consentement-la-cnil-lance-un-programme-devaluation). 24 | 25 | * 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](#Fiche_n°15_:_Prendre_en_compte_les_bases_légales_dans_l’implémentation_technique) vous accompagnera dans la bonne mise en oeuvre de ces traitements. 26 | 27 | * 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. 28 | 29 | ## En pratique 30 | 31 | * Si vous utilisez des traceurs visées par ces obligations, **il vous faut suivre les étapes suivantes** : 32 | 33 | 1- **Lister les traceurs utilisés** (tous les types de traceurs) et les classer par finalité en fonction des catégories identifiées. 34 | 35 | 2- **Lister les tiers** qui déposent ces traceurs. 36 | 37 | 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.. 38 | 39 | 4- **Mettre en place une interface** qui propose à l'utilisateur de consentir au dépôt de ces traceurs. 40 | 41 | 5- Sur chaque page, **intégrer une icône ou lien pour faire réapparaitre l'interface** afin de permettre le retrait du consentement. 42 | 43 | 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é. 44 | 45 | * 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**. 46 | 47 | * Il est fortement recommandé de hiérarchiser les informations délivrées à l'utilisateur sur plusieurs niveaux pour plus de clarté. 48 | 49 | * **Le premier niveau** de l'interface doit comprendre : 50 | * une liste des finalités poursuivies, 51 | * un lien vers la liste les tiers, 52 | * une explication des conséquences qui s'attachent à une acceptation ou un refus, 53 | * un bouton pour accepter et refuser (refuser les traceurs devant être aussi aisé que de les accepter). 54 | 55 |

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

56 | 57 | 58 | * Le second niveau d'interface doit **permettre à l'utilisateur de faire un choix sur la finalité de traceurs**: 59 |

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 60 | 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 61 |

62 | 63 | * [D'autres exemples d'interface](https://www.cnil.fr/sites/default/files/atoms/files/recommandation-cookies-et-autres-traceurs.pdf), 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". 64 | 65 | * 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**. 66 | -------------------------------------------------------------------------------- /17-Mesurer la fréquentation.md: -------------------------------------------------------------------------------- 1 | # Fiche n°17 : Mesurer la fréquentation de vos sites web et de vos applications 2 | 3 | #### 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. 4 | 5 | 6 | ## Bénéficier de l’exemption de consentement 7 | 8 | * **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 : 9 | 10 | * **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 ; 11 | 12 | * **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 ; 13 | 14 | * **servir uniquement à produire des données statistiques anonymes** ; 15 | 16 | * **ne pas conduire à un recoupement des données avec d’autres traitements ou à ce que les données soient transmises à des tiers**. 17 | 18 | * La CNIL recommande par ailleurs que : 19 | 20 | * **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 ; 21 | 22 | * **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 ; 23 | 24 | * les informations collectées par l'intermédiaire de ces traceurs soient conservées **pour une durée maximale de vingt-cinq mois** ; 25 | 26 | * 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. 27 | 28 | * 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. 29 | 30 | 31 | 32 | ## En pratique 33 | 34 | * **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](https://support.google.com/analytics/answer/6004245?hl=fr), de [Quantcast Analytics](https://www.quantcast.com/terms/measure-terms-service/) ou encore de [Facebook Analytics](https://developers.facebook.com/policy)). 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. 35 | 36 | * **La CNIL liste sur [son site](https://www.cnil.fr/fr/cookies-solutions-pour-les-outils-de-mesure-daudience) 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. 37 | -------------------------------------------------------------------------------- /18-Se prémunir contre les attaques informatiques.md: -------------------------------------------------------------------------------- 1 | # Fiche n°18 : Se prémunir contre les attaques informatiques 2 | 3 | #### 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. 4 | 5 | #### 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. 6 | 7 | ## Manipulation d'URL 8 | 9 | * **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…). 10 | 11 | * **Différents modes opératoires existent** : 12 | 13 | * **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 » ; 14 | 15 | * **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 ; 16 | 17 | * **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. 18 | 19 | * **Des mesures permettent de limiter ce risque** : 20 | 21 | * **vérifier que l’émetteur de cette requête est autorisé à accéder à la ressource associée** ; 22 | 23 | * **valider et vérifier la bonne construction des paramètres reçus en entrée** au sein de l’URL (coté serveur) ; 24 | 25 | * 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 ; 26 | 27 | * **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" » ; 28 | 29 | 30 | ### Ressources : 31 | 32 | * [OWASP: Path traversal](https://owasp.org/www-community/attacks/Path_Traversal) 33 | * [Webappsec: Predictable Resource Location](http://projects.webappsec.org/w/page/13246953/Predictable%20Resource%20Location) 34 | 35 | 36 | ## Bourrage d’identifiants (“Credential stuffing”) 37 | 38 | * 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 »). 39 | 40 | * 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) 41 | 42 | * **Des mesures permettent de limiter ce risque** : 43 | 44 | * **sensibiliser régulièrement les utilisateurs aux risques d’utiliser un même mot de passe pour plusieurs comptes** ; 45 | 46 | * **proposer un mécanisme de double authentification** ; 47 | 48 | * **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 ; 49 | 50 | * **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. 51 | 52 | ### Ressources : 53 | 54 | * [OWASP: Credential Stuffing Attack, Credential Stuffing Prevention Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.md) 55 | * [Retailers: Protecting Against Credential Stuffing Attacks](https://www.lexology.com/library/detail.aspx?g=453778d7-ccb7-424a-838f-d65155d55044) 56 | 57 | 58 | ## Attaques par force brute et par dictionnaire 59 | 60 | * 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). 61 | 62 | 63 | * **Des mesures permettent de limiter ce risque** : 64 | 65 | * 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,…) ; 66 | 67 | * 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 ; 68 | 69 | * inviter voire contraindre l'utilisateur à utiliser une authentification multi-facteurs (OTP, clé USB, carte à puce,…) suivant la sensibilité des données accédées ; 70 | 71 | * 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 ; 72 | 73 | * afficher la date et l’heure de la dernière connexion sur l’interface de l’utilisateur. 74 | 75 | ### Ressources : 76 | * [ANSSI : Recommandations relatives à l'authentification multifacteur et aux mots de passe - v2.0 du 08/10/2021](https://www.ssi.gouv.fr/uploads/2021/10/anssi-guide-authentification_multifacteur_et_mots_de_passe.pdf) 77 | * [OWASP: Bruteforce attack](https://owasp.org/www-community/attacks/Brute_force_attack) 78 | 79 | ## Injection de code indirecte (“Cross-Site Scripting”/XSS) 80 | 81 | * 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. 82 | 83 | * 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. 84 | 85 | * Ces injections peuvent prendre plusieurs formes : 86 | 87 | * le contenu malveillant peut être **injecté directement sur le site** par l'attaquant, par exemple dans ses champs de commentaires ; 88 | 89 | * 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 ; 90 | 91 | * 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. 92 | 93 | * **Des mesures permettent de limiter ces risques** : 94 | 95 | * mettre à jour les composants logiciels régulièrement ; 96 | 97 | * diligenter des audits de sécurité (tests de pénétration) de façon périodique et après chaque mise à jour significative ; 98 | 99 | * neutraliser les caractères utilisés pour l’insertion de script (> < /) lorsque c’est possible (cf. nettoyage « HTML escape ») ; 100 | 101 | * vérifier les éléments récupérés en paramètre et rejeter tous ceux qui ne sont pas attendus par l’application ; 102 | 103 | * 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 ; 104 | 105 | * 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). 106 | 107 | ### Ressources : 108 | * [CAPEC-63: Cross-Site Scripting](https://capec.mitre.org/data/definitions/63.html) 109 | * [CERT-FR: Cross-Site Scripting](https://www.cert.ssi.gouv.fr/information/CERTA-2002-INF-001/) 110 | * [OWASP: Cross-Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/) 111 | * [ANSSI: Recommandations pour la sécurisation des sites web (XSS)](hhttps://www.ssi.gouv.fr/uploads/2013/05/anssi-guide-recommandations_mise_en_oeuvre_site_web_maitriser_standards_securite_cote_navigateur-v2.0.pdf#section.5.2) 112 | 113 | ## Injection SQL (SQLi) 114 | 115 | * **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. 116 | 117 | * 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*). 118 | 119 | * **Des mesures permettent de limiter ce risque** : 120 | 121 | * utiliser des requêtes préparées (*Prepared Statements*) exclusivement, lorsque cela est possible ; 122 | 123 | * échapper les caractères susceptibles de provoquer une injection, en utilisant des fonctions spécialisées ; 124 | 125 | * restreindre et contrôler les entrées externes autant que possible. Par exemple, si l’identifiant est un chiffre, n’accepter que des chiffres ; 126 | 127 | * 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) ; 128 | 129 | * 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 ; 130 | 131 | * 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). 132 | 133 | ### Ressources : 134 | 135 | * [CAPEC-66: SQL Injection](https://capec.mitre.org/data/definitions/66.html) 136 | * [CERT-FR: Injection de données](https://www.cert.ssi.gouv.fr/information/CERTA-2004-INF-001/) 137 | * [OWASP: Injection](https://owasp.org/Top10/A03_2021-Injection/) 138 | * [OWASP: Prévention des injections SQL)](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) 139 | 140 | ## Les programmes malveillants et les rançongiciels 141 | 142 | * 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”). 143 | 144 | * 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 : 145 | 146 | * ouvrant la pièce jointe d’un email provenant d’une source inconnue ; 147 | 148 | * ou en téléchargeant un logiciel mis à disposition sur un site inconnu (ou n’étant pas de confiance) ; 149 | 150 | * ou en téléchargeant des logiciels associés à un logiciel connu ou provenant d’une source non fiable ; 151 | 152 | * ou en visitant un site web malveillant. 153 | 154 | * 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. 155 | 156 | * 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. 157 | 158 | * **Les mesures à mettre en œuvre afin de réduire le risque d’attaque sont surtout d’ordre organisationnel** : 159 | 160 | * maintenir à jour ses systèmes et logiciels (antivirus, équipements pare-feu, etc.) ; 161 | 162 | * 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 ; 163 | 164 | * 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 ; 165 | 166 | * 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) ; 167 | 168 | * ne pas installer de logiciels piratés ou issus de sources non fiables ; 169 | 170 | * cloisonner son réseau interne, notamment au moyen de VLAN afin de limiter la propagation de l’attaquant, le cas échéant ; 171 | 172 | * utiliser un proxy web permettant de bloquer les sites pouvant diffuser de tels logiciels. 173 | 174 | ### Ressources : 175 | 176 | * [Cybermalveillance : Les rançongiciels (ransomwares)](https://www.cybermalveillance.gouv.fr/tous-nos-contenus/fiches-reflexes/rancongiciels-ransomwares) 177 | * [ANSSI: Alerte – campagne de rançongiciels](https://www.ssi.gouv.fr/actualite/alerte-campagne-de-rancongiciel/) 178 | * [ANSSI: Etat de la menace rançongiciel](https://www.cert.ssi.gouv.fr/uploads/CERTFR-2020-CTI-001.pdf) 179 | * [NoMoreRansom!](https://www.nomoreransom.org/fr/index.html) 180 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU GENERAL PUBLIC LICENSE 2 | Version 3, 29 June 2007 3 | 4 | Copyright (C) 2007 Free Software Foundation, Inc. 5 | Everyone is permitted to copy and distribute verbatim copies 6 | of this license document, but changing it is not allowed. 7 | 8 | Preamble 9 | 10 | The GNU General Public License is a free, copyleft license for 11 | software and other kinds of works. 12 | 13 | The licenses for most software and other practical works are designed 14 | to take away your freedom to share and change the works. By contrast, 15 | the GNU General Public License is intended to guarantee your freedom to 16 | share and change all versions of a program--to make sure it remains free 17 | software for all its users. We, the Free Software Foundation, use the 18 | GNU General Public License for most of our software; it applies also to 19 | any other work released this way by its authors. You can apply it to 20 | your programs, too. 21 | 22 | When we speak of free software, we are referring to freedom, not 23 | price. Our General Public Licenses are designed to make sure that you 24 | have the freedom to distribute copies of free software (and charge for 25 | them if you wish), that you receive source code or can get it if you 26 | want it, that you can change the software or use pieces of it in new 27 | free programs, and that you know you can do these things. 28 | 29 | To protect your rights, we need to prevent others from denying you 30 | these rights or asking you to surrender the rights. Therefore, you have 31 | certain responsibilities if you distribute copies of the software, or if 32 | you modify it: responsibilities to respect the freedom of others. 33 | 34 | For example, if you distribute copies of such a program, whether 35 | gratis or for a fee, you must pass on to the recipients the same 36 | freedoms that you received. You must make sure that they, too, receive 37 | or can get the source code. And you must show them these terms so they 38 | know their rights. 39 | 40 | Developers that use the GNU GPL protect your rights with two steps: 41 | (1) assert copyright on the software, and (2) offer you this License 42 | giving you legal permission to copy, distribute and/or modify it. 43 | 44 | For the developers' and authors' protection, the GPL clearly explains 45 | that there is no warranty for this free software. For both users' and 46 | authors' sake, the GPL requires that modified versions be marked as 47 | changed, so that their problems will not be attributed erroneously to 48 | authors of previous versions. 49 | 50 | Some devices are designed to deny users access to install or run 51 | modified versions of the software inside them, although the manufacturer 52 | can do so. This is fundamentally incompatible with the aim of 53 | protecting users' freedom to change the software. The systematic 54 | pattern of such abuse occurs in the area of products for individuals to 55 | use, which is precisely where it is most unacceptable. Therefore, we 56 | have designed this version of the GPL to prohibit the practice for those 57 | products. If such problems arise substantially in other domains, we 58 | stand ready to extend this provision to those domains in future versions 59 | of the GPL, as needed to protect the freedom of users. 60 | 61 | Finally, every program is threatened constantly by software patents. 62 | States should not allow patents to restrict development and use of 63 | software on general-purpose computers, but in those that do, we wish to 64 | avoid the special danger that patents applied to a free program could 65 | make it effectively proprietary. To prevent this, the GPL assures that 66 | patents cannot be used to render the program non-free. 67 | 68 | The precise terms and conditions for copying, distribution and 69 | modification follow. 70 | 71 | TERMS AND CONDITIONS 72 | 73 | 0. Definitions. 74 | 75 | "This License" refers to version 3 of the GNU General Public License. 76 | 77 | "Copyright" also means copyright-like laws that apply to other kinds of 78 | works, such as semiconductor masks. 79 | 80 | "The Program" refers to any copyrightable work licensed under this 81 | License. Each licensee is addressed as "you". "Licensees" and 82 | "recipients" may be individuals or organizations. 83 | 84 | To "modify" a work means to copy from or adapt all or part of the work 85 | in a fashion requiring copyright permission, other than the making of an 86 | exact copy. The resulting work is called a "modified version" of the 87 | earlier work or a work "based on" the earlier work. 88 | 89 | A "covered work" means either the unmodified Program or a work based 90 | on the Program. 91 | 92 | To "propagate" a work means to do anything with it that, without 93 | permission, would make you directly or secondarily liable for 94 | infringement under applicable copyright law, except executing it on a 95 | computer or modifying a private copy. Propagation includes copying, 96 | distribution (with or without modification), making available to the 97 | public, and in some countries other activities as well. 98 | 99 | To "convey" a work means any kind of propagation that enables other 100 | parties to make or receive copies. Mere interaction with a user through 101 | a computer network, with no transfer of a copy, is not conveying. 102 | 103 | An interactive user interface displays "Appropriate Legal Notices" 104 | to the extent that it includes a convenient and prominently visible 105 | feature that (1) displays an appropriate copyright notice, and (2) 106 | tells the user that there is no warranty for the work (except to the 107 | extent that warranties are provided), that licensees may convey the 108 | work under this License, and how to view a copy of this License. If 109 | the interface presents a list of user commands or options, such as a 110 | menu, a prominent item in the list meets this criterion. 111 | 112 | 1. Source Code. 113 | 114 | The "source code" for a work means the preferred form of the work 115 | for making modifications to it. "Object code" means any non-source 116 | form of a work. 117 | 118 | A "Standard Interface" means an interface that either is an official 119 | standard defined by a recognized standards body, or, in the case of 120 | interfaces specified for a particular programming language, one that 121 | is widely used among developers working in that language. 122 | 123 | The "System Libraries" of an executable work include anything, other 124 | than the work as a whole, that (a) is included in the normal form of 125 | packaging a Major Component, but which is not part of that Major 126 | Component, and (b) serves only to enable use of the work with that 127 | Major Component, or to implement a Standard Interface for which an 128 | implementation is available to the public in source code form. A 129 | "Major Component", in this context, means a major essential component 130 | (kernel, window system, and so on) of the specific operating system 131 | (if any) on which the executable work runs, or a compiler used to 132 | produce the work, or an object code interpreter used to run it. 133 | 134 | The "Corresponding Source" for a work in object code form means all 135 | the source code needed to generate, install, and (for an executable 136 | work) run the object code and to modify the work, including scripts to 137 | control those activities. However, it does not include the work's 138 | System Libraries, or general-purpose tools or generally available free 139 | programs which are used unmodified in performing those activities but 140 | which are not part of the work. For example, Corresponding Source 141 | includes interface definition files associated with source files for 142 | the work, and the source code for shared libraries and dynamically 143 | linked subprograms that the work is specifically designed to require, 144 | such as by intimate data communication or control flow between those 145 | subprograms and other parts of the work. 146 | 147 | The Corresponding Source need not include anything that users 148 | can regenerate automatically from other parts of the Corresponding 149 | Source. 150 | 151 | The Corresponding Source for a work in source code form is that 152 | same work. 153 | 154 | 2. Basic Permissions. 155 | 156 | All rights granted under this License are granted for the term of 157 | copyright on the Program, and are irrevocable provided the stated 158 | conditions are met. This License explicitly affirms your unlimited 159 | permission to run the unmodified Program. The output from running a 160 | covered work is covered by this License only if the output, given its 161 | content, constitutes a covered work. This License acknowledges your 162 | rights of fair use or other equivalent, as provided by copyright law. 163 | 164 | You may make, run and propagate covered works that you do not 165 | convey, without conditions so long as your license otherwise remains 166 | in force. You may convey covered works to others for the sole purpose 167 | of having them make modifications exclusively for you, or provide you 168 | with facilities for running those works, provided that you comply with 169 | the terms of this License in conveying all material for which you do 170 | not control copyright. Those thus making or running the covered works 171 | for you must do so exclusively on your behalf, under your direction 172 | and control, on terms that prohibit them from making any copies of 173 | your copyrighted material outside their relationship with you. 174 | 175 | Conveying under any other circumstances is permitted solely under 176 | the conditions stated below. Sublicensing is not allowed; section 10 177 | makes it unnecessary. 178 | 179 | 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 180 | 181 | No covered work shall be deemed part of an effective technological 182 | measure under any applicable law fulfilling obligations under article 183 | 11 of the WIPO copyright treaty adopted on 20 December 1996, or 184 | similar laws prohibiting or restricting circumvention of such 185 | measures. 186 | 187 | When you convey a covered work, you waive any legal power to forbid 188 | circumvention of technological measures to the extent such circumvention 189 | is effected by exercising rights under this License with respect to 190 | the covered work, and you disclaim any intention to limit operation or 191 | modification of the work as a means of enforcing, against the work's 192 | users, your or third parties' legal rights to forbid circumvention of 193 | technological measures. 194 | 195 | 4. Conveying Verbatim Copies. 196 | 197 | You may convey verbatim copies of the Program's source code as you 198 | receive it, in any medium, provided that you conspicuously and 199 | appropriately publish on each copy an appropriate copyright notice; 200 | keep intact all notices stating that this License and any 201 | non-permissive terms added in accord with section 7 apply to the code; 202 | keep intact all notices of the absence of any warranty; and give all 203 | recipients a copy of this License along with the Program. 204 | 205 | You may charge any price or no price for each copy that you convey, 206 | and you may offer support or warranty protection for a fee. 207 | 208 | 5. Conveying Modified Source Versions. 209 | 210 | You may convey a work based on the Program, or the modifications to 211 | produce it from the Program, in the form of source code under the 212 | terms of section 4, provided that you also meet all of these conditions: 213 | 214 | a) The work must carry prominent notices stating that you modified 215 | it, and giving a relevant date. 216 | 217 | b) The work must carry prominent notices stating that it is 218 | released under this License and any conditions added under section 219 | 7. This requirement modifies the requirement in section 4 to 220 | "keep intact all notices". 221 | 222 | c) You must license the entire work, as a whole, under this 223 | License to anyone who comes into possession of a copy. This 224 | License will therefore apply, along with any applicable section 7 225 | additional terms, to the whole of the work, and all its parts, 226 | regardless of how they are packaged. This License gives no 227 | permission to license the work in any other way, but it does not 228 | invalidate such permission if you have separately received it. 229 | 230 | d) If the work has interactive user interfaces, each must display 231 | Appropriate Legal Notices; however, if the Program has interactive 232 | interfaces that do not display Appropriate Legal Notices, your 233 | work need not make them do so. 234 | 235 | A compilation of a covered work with other separate and independent 236 | works, which are not by their nature extensions of the covered work, 237 | and which are not combined with it such as to form a larger program, 238 | in or on a volume of a storage or distribution medium, is called an 239 | "aggregate" if the compilation and its resulting copyright are not 240 | used to limit the access or legal rights of the compilation's users 241 | beyond what the individual works permit. Inclusion of a covered work 242 | in an aggregate does not cause this License to apply to the other 243 | parts of the aggregate. 244 | 245 | 6. Conveying Non-Source Forms. 246 | 247 | You may convey a covered work in object code form under the terms 248 | of sections 4 and 5, provided that you also convey the 249 | machine-readable Corresponding Source under the terms of this License, 250 | in one of these ways: 251 | 252 | a) Convey the object code in, or embodied in, a physical product 253 | (including a physical distribution medium), accompanied by the 254 | Corresponding Source fixed on a durable physical medium 255 | customarily used for software interchange. 256 | 257 | b) Convey the object code in, or embodied in, a physical product 258 | (including a physical distribution medium), accompanied by a 259 | written offer, valid for at least three years and valid for as 260 | long as you offer spare parts or customer support for that product 261 | model, to give anyone who possesses the object code either (1) a 262 | copy of the Corresponding Source for all the software in the 263 | product that is covered by this License, on a durable physical 264 | medium customarily used for software interchange, for a price no 265 | more than your reasonable cost of physically performing this 266 | conveying of source, or (2) access to copy the 267 | Corresponding Source from a network server at no charge. 268 | 269 | c) Convey individual copies of the object code with a copy of the 270 | written offer to provide the Corresponding Source. This 271 | alternative is allowed only occasionally and noncommercially, and 272 | only if you received the object code with such an offer, in accord 273 | with subsection 6b. 274 | 275 | d) Convey the object code by offering access from a designated 276 | place (gratis or for a charge), and offer equivalent access to the 277 | Corresponding Source in the same way through the same place at no 278 | further charge. You need not require recipients to copy the 279 | Corresponding Source along with the object code. If the place to 280 | copy the object code is a network server, the Corresponding Source 281 | may be on a different server (operated by you or a third party) 282 | that supports equivalent copying facilities, provided you maintain 283 | clear directions next to the object code saying where to find the 284 | Corresponding Source. Regardless of what server hosts the 285 | Corresponding Source, you remain obligated to ensure that it is 286 | available for as long as needed to satisfy these requirements. 287 | 288 | e) Convey the object code using peer-to-peer transmission, provided 289 | you inform other peers where the object code and Corresponding 290 | Source of the work are being offered to the general public at no 291 | charge under subsection 6d. 292 | 293 | A separable portion of the object code, whose source code is excluded 294 | from the Corresponding Source as a System Library, need not be 295 | included in conveying the object code work. 296 | 297 | A "User Product" is either (1) a "consumer product", which means any 298 | tangible personal property which is normally used for personal, family, 299 | or household purposes, or (2) anything designed or sold for incorporation 300 | into a dwelling. In determining whether a product is a consumer product, 301 | doubtful cases shall be resolved in favor of coverage. For a particular 302 | product received by a particular user, "normally used" refers to a 303 | typical or common use of that class of product, regardless of the status 304 | of the particular user or of the way in which the particular user 305 | actually uses, or expects or is expected to use, the product. A product 306 | is a consumer product regardless of whether the product has substantial 307 | commercial, industrial or non-consumer uses, unless such uses represent 308 | the only significant mode of use of the product. 309 | 310 | "Installation Information" for a User Product means any methods, 311 | procedures, authorization keys, or other information required to install 312 | and execute modified versions of a covered work in that User Product from 313 | a modified version of its Corresponding Source. The information must 314 | suffice to ensure that the continued functioning of the modified object 315 | code is in no case prevented or interfered with solely because 316 | modification has been made. 317 | 318 | If you convey an object code work under this section in, or with, or 319 | specifically for use in, a User Product, and the conveying occurs as 320 | part of a transaction in which the right of possession and use of the 321 | User Product is transferred to the recipient in perpetuity or for a 322 | fixed term (regardless of how the transaction is characterized), the 323 | Corresponding Source conveyed under this section must be accompanied 324 | by the Installation Information. But this requirement does not apply 325 | if neither you nor any third party retains the ability to install 326 | modified object code on the User Product (for example, the work has 327 | been installed in ROM). 328 | 329 | The requirement to provide Installation Information does not include a 330 | requirement to continue to provide support service, warranty, or updates 331 | for a work that has been modified or installed by the recipient, or for 332 | the User Product in which it has been modified or installed. Access to a 333 | network may be denied when the modification itself materially and 334 | adversely affects the operation of the network or violates the rules and 335 | protocols for communication across the network. 336 | 337 | Corresponding Source conveyed, and Installation Information provided, 338 | in accord with this section must be in a format that is publicly 339 | documented (and with an implementation available to the public in 340 | source code form), and must require no special password or key for 341 | unpacking, reading or copying. 342 | 343 | 7. Additional Terms. 344 | 345 | "Additional permissions" are terms that supplement the terms of this 346 | License by making exceptions from one or more of its conditions. 347 | Additional permissions that are applicable to the entire Program shall 348 | be treated as though they were included in this License, to the extent 349 | that they are valid under applicable law. If additional permissions 350 | apply only to part of the Program, that part may be used separately 351 | under those permissions, but the entire Program remains governed by 352 | this License without regard to the additional permissions. 353 | 354 | When you convey a copy of a covered work, you may at your option 355 | remove any additional permissions from that copy, or from any part of 356 | it. (Additional permissions may be written to require their own 357 | removal in certain cases when you modify the work.) You may place 358 | additional permissions on material, added by you to a covered work, 359 | for which you have or can give appropriate copyright permission. 360 | 361 | Notwithstanding any other provision of this License, for material you 362 | add to a covered work, you may (if authorized by the copyright holders of 363 | that material) supplement the terms of this License with terms: 364 | 365 | a) Disclaiming warranty or limiting liability differently from the 366 | terms of sections 15 and 16 of this License; or 367 | 368 | b) Requiring preservation of specified reasonable legal notices or 369 | author attributions in that material or in the Appropriate Legal 370 | Notices displayed by works containing it; or 371 | 372 | c) Prohibiting misrepresentation of the origin of that material, or 373 | requiring that modified versions of such material be marked in 374 | reasonable ways as different from the original version; or 375 | 376 | d) Limiting the use for publicity purposes of names of licensors or 377 | authors of the material; or 378 | 379 | e) Declining to grant rights under trademark law for use of some 380 | trade names, trademarks, or service marks; or 381 | 382 | f) Requiring indemnification of licensors and authors of that 383 | material by anyone who conveys the material (or modified versions of 384 | it) with contractual assumptions of liability to the recipient, for 385 | any liability that these contractual assumptions directly impose on 386 | those licensors and authors. 387 | 388 | All other non-permissive additional terms are considered "further 389 | restrictions" within the meaning of section 10. If the Program as you 390 | received it, or any part of it, contains a notice stating that it is 391 | governed by this License along with a term that is a further 392 | restriction, you may remove that term. If a license document contains 393 | a further restriction but permits relicensing or conveying under this 394 | License, you may add to a covered work material governed by the terms 395 | of that license document, provided that the further restriction does 396 | not survive such relicensing or conveying. 397 | 398 | If you add terms to a covered work in accord with this section, you 399 | must place, in the relevant source files, a statement of the 400 | additional terms that apply to those files, or a notice indicating 401 | where to find the applicable terms. 402 | 403 | Additional terms, permissive or non-permissive, may be stated in the 404 | form of a separately written license, or stated as exceptions; 405 | the above requirements apply either way. 406 | 407 | 8. Termination. 408 | 409 | You may not propagate or modify a covered work except as expressly 410 | provided under this License. Any attempt otherwise to propagate or 411 | modify it is void, and will automatically terminate your rights under 412 | this License (including any patent licenses granted under the third 413 | paragraph of section 11). 414 | 415 | However, if you cease all violation of this License, then your 416 | license from a particular copyright holder is reinstated (a) 417 | provisionally, unless and until the copyright holder explicitly and 418 | finally terminates your license, and (b) permanently, if the copyright 419 | holder fails to notify you of the violation by some reasonable means 420 | prior to 60 days after the cessation. 421 | 422 | Moreover, your license from a particular copyright holder is 423 | reinstated permanently if the copyright holder notifies you of the 424 | violation by some reasonable means, this is the first time you have 425 | received notice of violation of this License (for any work) from that 426 | copyright holder, and you cure the violation prior to 30 days after 427 | your receipt of the notice. 428 | 429 | Termination of your rights under this section does not terminate the 430 | licenses of parties who have received copies or rights from you under 431 | this License. If your rights have been terminated and not permanently 432 | reinstated, you do not qualify to receive new licenses for the same 433 | material under section 10. 434 | 435 | 9. Acceptance Not Required for Having Copies. 436 | 437 | You are not required to accept this License in order to receive or 438 | run a copy of the Program. Ancillary propagation of a covered work 439 | occurring solely as a consequence of using peer-to-peer transmission 440 | to receive a copy likewise does not require acceptance. However, 441 | nothing other than this License grants you permission to propagate or 442 | modify any covered work. These actions infringe copyright if you do 443 | not accept this License. Therefore, by modifying or propagating a 444 | covered work, you indicate your acceptance of this License to do so. 445 | 446 | 10. Automatic Licensing of Downstream Recipients. 447 | 448 | Each time you convey a covered work, the recipient automatically 449 | receives a license from the original licensors, to run, modify and 450 | propagate that work, subject to this License. You are not responsible 451 | for enforcing compliance by third parties with this License. 452 | 453 | An "entity transaction" is a transaction transferring control of an 454 | organization, or substantially all assets of one, or subdividing an 455 | organization, or merging organizations. If propagation of a covered 456 | work results from an entity transaction, each party to that 457 | transaction who receives a copy of the work also receives whatever 458 | licenses to the work the party's predecessor in interest had or could 459 | give under the previous paragraph, plus a right to possession of the 460 | Corresponding Source of the work from the predecessor in interest, if 461 | the predecessor has it or can get it with reasonable efforts. 462 | 463 | You may not impose any further restrictions on the exercise of the 464 | rights granted or affirmed under this License. For example, you may 465 | not impose a license fee, royalty, or other charge for exercise of 466 | rights granted under this License, and you may not initiate litigation 467 | (including a cross-claim or counterclaim in a lawsuit) alleging that 468 | any patent claim is infringed by making, using, selling, offering for 469 | sale, or importing the Program or any portion of it. 470 | 471 | 11. Patents. 472 | 473 | A "contributor" is a copyright holder who authorizes use under this 474 | License of the Program or a work on which the Program is based. The 475 | work thus licensed is called the contributor's "contributor version". 476 | 477 | A contributor's "essential patent claims" are all patent claims 478 | owned or controlled by the contributor, whether already acquired or 479 | hereafter acquired, that would be infringed by some manner, permitted 480 | by this License, of making, using, or selling its contributor version, 481 | but do not include claims that would be infringed only as a 482 | consequence of further modification of the contributor version. For 483 | purposes of this definition, "control" includes the right to grant 484 | patent sublicenses in a manner consistent with the requirements of 485 | this License. 486 | 487 | Each contributor grants you a non-exclusive, worldwide, royalty-free 488 | patent license under the contributor's essential patent claims, to 489 | make, use, sell, offer for sale, import and otherwise run, modify and 490 | propagate the contents of its contributor version. 491 | 492 | In the following three paragraphs, a "patent license" is any express 493 | agreement or commitment, however denominated, not to enforce a patent 494 | (such as an express permission to practice a patent or covenant not to 495 | sue for patent infringement). To "grant" such a patent license to a 496 | party means to make such an agreement or commitment not to enforce a 497 | patent against the party. 498 | 499 | If you convey a covered work, knowingly relying on a patent license, 500 | and the Corresponding Source of the work is not available for anyone 501 | to copy, free of charge and under the terms of this License, through a 502 | publicly available network server or other readily accessible means, 503 | then you must either (1) cause the Corresponding Source to be so 504 | available, or (2) arrange to deprive yourself of the benefit of the 505 | patent license for this particular work, or (3) arrange, in a manner 506 | consistent with the requirements of this License, to extend the patent 507 | license to downstream recipients. "Knowingly relying" means you have 508 | actual knowledge that, but for the patent license, your conveying the 509 | covered work in a country, or your recipient's use of the covered work 510 | in a country, would infringe one or more identifiable patents in that 511 | country that you have reason to believe are valid. 512 | 513 | If, pursuant to or in connection with a single transaction or 514 | arrangement, you convey, or propagate by procuring conveyance of, a 515 | covered work, and grant a patent license to some of the parties 516 | receiving the covered work authorizing them to use, propagate, modify 517 | or convey a specific copy of the covered work, then the patent license 518 | you grant is automatically extended to all recipients of the covered 519 | work and works based on it. 520 | 521 | A patent license is "discriminatory" if it does not include within 522 | the scope of its coverage, prohibits the exercise of, or is 523 | conditioned on the non-exercise of one or more of the rights that are 524 | specifically granted under this License. You may not convey a covered 525 | work if you are a party to an arrangement with a third party that is 526 | in the business of distributing software, under which you make payment 527 | to the third party based on the extent of your activity of conveying 528 | the work, and under which the third party grants, to any of the 529 | parties who would receive the covered work from you, a discriminatory 530 | patent license (a) in connection with copies of the covered work 531 | conveyed by you (or copies made from those copies), or (b) primarily 532 | for and in connection with specific products or compilations that 533 | contain the covered work, unless you entered into that arrangement, 534 | or that patent license was granted, prior to 28 March 2007. 535 | 536 | Nothing in this License shall be construed as excluding or limiting 537 | any implied license or other defenses to infringement that may 538 | otherwise be available to you under applicable patent law. 539 | 540 | 12. No Surrender of Others' Freedom. 541 | 542 | If conditions are imposed on you (whether by court order, agreement or 543 | otherwise) that contradict the conditions of this License, they do not 544 | excuse you from the conditions of this License. If you cannot convey a 545 | covered work so as to satisfy simultaneously your obligations under this 546 | License and any other pertinent obligations, then as a consequence you may 547 | not convey it at all. For example, if you agree to terms that obligate you 548 | to collect a royalty for further conveying from those to whom you convey 549 | the Program, the only way you could satisfy both those terms and this 550 | License would be to refrain entirely from conveying the Program. 551 | 552 | 13. Use with the GNU Affero General Public License. 553 | 554 | Notwithstanding any other provision of this License, you have 555 | permission to link or combine any covered work with a work licensed 556 | under version 3 of the GNU Affero General Public License into a single 557 | combined work, and to convey the resulting work. The terms of this 558 | License will continue to apply to the part which is the covered work, 559 | but the special requirements of the GNU Affero General Public License, 560 | section 13, concerning interaction through a network will apply to the 561 | combination as such. 562 | 563 | 14. Revised Versions of this License. 564 | 565 | The Free Software Foundation may publish revised and/or new versions of 566 | the GNU General Public License from time to time. Such new versions will 567 | be similar in spirit to the present version, but may differ in detail to 568 | address new problems or concerns. 569 | 570 | Each version is given a distinguishing version number. If the 571 | Program specifies that a certain numbered version of the GNU General 572 | Public License "or any later version" applies to it, you have the 573 | option of following the terms and conditions either of that numbered 574 | version or of any later version published by the Free Software 575 | Foundation. If the Program does not specify a version number of the 576 | GNU General Public License, you may choose any version ever published 577 | by the Free Software Foundation. 578 | 579 | If the Program specifies that a proxy can decide which future 580 | versions of the GNU General Public License can be used, that proxy's 581 | public statement of acceptance of a version permanently authorizes you 582 | to choose that version for the Program. 583 | 584 | Later license versions may give you additional or different 585 | permissions. However, no additional obligations are imposed on any 586 | author or copyright holder as a result of your choosing to follow a 587 | later version. 588 | 589 | 15. Disclaimer of Warranty. 590 | 591 | THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 592 | APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT 593 | HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY 594 | OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, 595 | THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 596 | PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM 597 | IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF 598 | ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 599 | 600 | 16. Limitation of Liability. 601 | 602 | IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 603 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS 604 | THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY 605 | GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE 606 | USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF 607 | DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 608 | PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), 609 | EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF 610 | SUCH DAMAGES. 611 | 612 | 17. Interpretation of Sections 15 and 16. 613 | 614 | If the disclaimer of warranty and limitation of liability provided 615 | above cannot be given local legal effect according to their terms, 616 | reviewing courts shall apply local law that most closely approximates 617 | an absolute waiver of all civil liability in connection with the 618 | Program, unless a warranty or assumption of liability accompanies a 619 | copy of the Program in return for a fee. 620 | 621 | END OF TERMS AND CONDITIONS 622 | 623 | How to Apply These Terms to Your New Programs 624 | 625 | If you develop a new program, and you want it to be of the greatest 626 | possible use to the public, the best way to achieve this is to make it 627 | free software which everyone can redistribute and change under these terms. 628 | 629 | To do so, attach the following notices to the program. It is safest 630 | to attach them to the start of each source file to most effectively 631 | state the exclusion of warranty; and each file should have at least 632 | the "copyright" line and a pointer to where the full notice is found. 633 | 634 | Copyright (C) 2017 CNIL 635 | 636 | This program is free software: you can redistribute it and/or modify 637 | it under the terms of the GNU General Public License as published by 638 | the Free Software Foundation, either version 3 of the License, or 639 | (at your option) any later version. 640 | 641 | This program is distributed in the hope that it will be useful, 642 | but WITHOUT ANY WARRANTY; without even the implied warranty of 643 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 644 | GNU General Public License for more details. 645 | 646 | You should have received a copy of the GNU General Public License 647 | along with this program. If not, see . 648 | 649 | Also add information on how to contact you by electronic and paper mail. 650 | 651 | If the program does terminal interaction, make it output a short 652 | notice like this when it starts in an interactive mode: 653 | 654 | PIA Copyright (C) 2017 CNIL 655 | This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 656 | This is free software, and you are welcome to redistribute it 657 | under certain conditions; type `show c' for details. 658 | 659 | The hypothetical commands `show w' and `show c' should show the appropriate 660 | parts of the General Public License. Of course, your program's commands 661 | might be different; for a GUI interface, you would use an "about box". 662 | 663 | You should also get your employer (if you work as a programmer) or school, 664 | if any, to sign a "copyright disclaimer" for the program, if necessary. 665 | For more information on this, and how to apply and follow the GNU GPL, see 666 | . 667 | 668 | The GNU General Public License does not permit incorporating your program 669 | into proprietary programs. If your program is a subroutine library, you 670 | may consider it more useful to permit linking proprietary applications with 671 | the library. If this is what you want to do, use the GNU Lesser General 672 | Public License instead of this License. But first, please read 673 | . -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

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

2 | 3 | 4 | # Guide RGPD de l'équipe de développement 5 | #### La CNIL publie un guide RGPD pour les développeuses et développeurs 6 | 7 | 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. 8 | 9 | Ce guide est publié sous [licence GPLv3](https://www.gnu.org/licenses/gpl-3.0.html) et sous [licence ouverte 2.0](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf) (explicitement compatible avec [CC-BY 4.0 FR](https://creativecommons.org/licenses/by/4.0/deed.fr)). Vous pouvez donc librement contribuer à son enrichissement. 10 | 11 | #### Ce guide s’adresse-t-il uniquement aux développeuses et développeurs ? 12 | 13 | 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. 14 | 15 | 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. 16 | 17 | #### Que contient le guide ? 18 | 19 | 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. 20 | 21 | 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). 22 | 23 | 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. 24 | 25 | 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. 26 | 27 | ## Tables des matières 28 | 29 | 0. [Développer en conformité avec le RGPD](#Fiche_n°0%c2%a0:_Développer_en_conformité_avec_le_RGPD) 30 | 31 | 1. [Identifier les données à caractère personnel](#Fiche_n°1%c2%a0:_Identifier_les_données_à_caractère_personnel) 32 | 33 | 2. [Préparer son développement](#Fiche_n°2%c2%a0:_Préparer_son_développement) 34 | 35 | 3. [Sécuriser son environnement de développement](#Fiche_n°3%c2%a0:_Sécuriser_son_environnement_de_développement) 36 | 37 | 4. [Gérer son code source](#Fiche_n°4%c2%a0:_Gérer_son_code_source) 38 | 39 | 5. [Faire un choix éclairé de son architecture](#Fiche_n°5%c2%a0:_Faire_un_choix_éclairé_de_son_architecture) 40 | 41 | 6. [Sécuriser vos sites web, vos applications et vos serveurs](#Fiche_n°6%c2%a0:_Sécuriser_vos_sites_web,_vos_applications_et_vos_serveurs) 42 | 43 | 7. [Minimiser les données collectées](#Fiche_n°7%c2%a0:_Minimiser_les_données_collectées) 44 | 45 | 8. [Gérer les profils utilisateurs](#Fiche_n°8%c2%a0:_Gérer_les_utilisateurs) 46 | 47 | 9. [Maîtriser vos bibliothèques et vos SDK](#Fiche_n°9%c2%a0:_Maîtriser_vos_bibliothèques_et_vos_SDK) 48 | 49 | 10. [Veiller à la qualité de votre code et sa documentation](#Fiche_n°10%c2%a0:_Veiller_à_la_qualité_de_votre_code_et_sa_documentation) 50 | 51 | 11. [Tester vos applications](#Fiche_n°11%c2%a0:_Tester_vos_applications) 52 | 53 | 12. [Informer les utilisateurs](#Fiche_n°12%c2%a0:_Informer_les_personnes) 54 | 55 | 13. [Préparer l'exercice des droits des personnes](#Fiche_n°13%c2%a0:_Préparer_l’exercice_des_droits_des_personnes) 56 | 57 | 14. [Gérer la durée de conservation des données](#Fiche_n°14%c2%a0:_Gérer_la_durée_de_conservation_des_données) 58 | 59 | 15. [Prendre en compte les bases légales dans l’implémentation technique ](#Fiche_n°15%c2%a0:_Prendre_en_compte_les_bases_légales_dans_l’implémentation_technique) 60 | 61 | 16. [Analyser les pratiques en matière de traceurs sur vos sites et vos applications](#Fiche_n°16%c2%a0:_Analyser_les_traceurs) 62 | 63 | 17. [Mesurer la fréquentation de vos sites web et de vos applications](#Fiche_n°17%c2%a0:_Mesurer_la_fréquentation_de_vos_sites_web_et_de_vos_applications) 64 | 65 | 18. [Se prémunir contre les attaques informatiques](#Fiche_n°18%c2%a0:_Se_prémunir_contre_les_attaques_informatiques) 66 | 67 | ## Comment contribuer à ce guide ? 68 | 69 | **Ce guide est disponible en deux versions** : 70 | 71 | * Une [version web sur le site de la CNIL](https://cnil.fr/developpeur), et un export PDF dans l'onglet ["Releases"](https://github.com/LINCnil/Guide-RGPD-du-developpeur/releases) de ce repository ; 72 | * Cette [version GitHub](https://github.com/LINCnil/Guide-RGPD-du-developpeur), qui offre la possibilité à tous d’y contribuer. 73 | 74 | **La contribution se fait en quelques étapes** : 75 | 76 | * Inscrivez-vous sur la plateforme Github ; 77 | * Rendez-vous sur la page du projet ; 78 | * Vous pouvez : 79 | * Utiliser l’onglet "Issue" pour ouvrir des commentaires ou participer à la discussion 80 | * Utiliser l'option "Fork" pour faire vos propres modifications et proposer leur inclusion via le bouton "Pull Requests" 81 | 82 | **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. 83 | 84 | ## Usage 85 | 86 | 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. 87 | 88 | Vous pouvez retrouver les instructions pour installer cet outil [ici]( https://pandoc.org/installing.html) 89 | 90 | * **Pour générer un fichier .docx** : 91 | ```bash 92 | pandoc -s --toc --toc-depth=1 -o Guide_RGPD_developpeur.docx [0-9][0-9]*.md 93 | ``` 94 | 95 | * **Pour générer un fichier .html** : 96 | ```bash 97 | pandoc -s --template="templates/mytemplate.html" -H templates/pandoc.css -o index.html README.md [0-9][0-9]*.md 98 | ``` 99 | -------------------------------------------------------------------------------- /annexes/.gitkeep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LINCnil/Guide-RGPD-du-developpeur/c132de41486e54fc5da056ace55a9b9c8d1b68c4/annexes/.gitkeep -------------------------------------------------------------------------------- /annexes/Bandeau-Cookie-Niveau-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LINCnil/Guide-RGPD-du-developpeur/c132de41486e54fc5da056ace55a9b9c8d1b68c4/annexes/Bandeau-Cookie-Niveau-1.jpg -------------------------------------------------------------------------------- /annexes/Bandeau-Cookie-Niveau-2-details.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LINCnil/Guide-RGPD-du-developpeur/c132de41486e54fc5da056ace55a9b9c8d1b68c4/annexes/Bandeau-Cookie-Niveau-2-details.jpg -------------------------------------------------------------------------------- /annexes/Bandeau-Cookie-Niveau-2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LINCnil/Guide-RGPD-du-developpeur/c132de41486e54fc5da056ace55a9b9c8d1b68c4/annexes/Bandeau-Cookie-Niveau-2.jpg -------------------------------------------------------------------------------- /annexes/conf_tls_apache.txt: -------------------------------------------------------------------------------- 1 | # configuration Apache 2.4.41 2 | # générée à partir de https://ssl-config.mozilla.org/ avec des commentaires supplémentaires 3 | # nécessite mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers 4 | 5 | # configuration HTTP, qui redirige automatiquement l'URL vers HTTPS 6 | 7 | RewriteEngine On 8 | RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L] 9 | 10 | 11 | # configuration HTTPS 12 | 13 | SSLEngine on 14 | 15 | # certificat du site et certificats intermédiaires 16 | # attention à bien ajouter les paramètres Diffie-Hellman à la fin du fichier 17 | # il est préférable d'utiliser des paramètre d'au moins 2048 bits, voire plus 18 | SSLCertificateFile /path/to/signed_cert_and_intermediate_certs_and_dhparams 19 | clé privée du certificat 20 | SSLCertificateKeyFile /path/to/private_key 21 | 22 | # utiliser aussi HTTP/2 si ce protocole est disponible 23 | Protocols h2 http/1.1 24 | 25 | # activation de HSTS, qui force une connexion HTTPS au site, pour une durée de 2 ans 26 | Header always set Strict-Transport-Security "max-age=63072000" 27 | 28 | 29 | # support de TLS 1.2 et 1.3 (les deux dernières versions) 30 | SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 31 | # utilisation d'algorithmes à l'état de l'art, permettant la confidentialité persistance et l'authentification des connexions 32 | SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 33 | # utiliser les suites cryptographiques les plus performantes pour le client 34 | SSLHonorCipherOrder off 35 | # pas de tickets de session 36 | # car ils peuvent compromettre la confidentialité persistance ("forward secrecy") des communications 37 | SSLSessionTickets off 38 | 39 | # agrafage ("stapling") OCSP, qui permet de vérifier en temps réel la révocation d'un certificat 40 | SSLUseStapling On 41 | SSLStaplingCache "shmcb:logs/ssl_stapling(32768)" -------------------------------------------------------------------------------- /annexes/conf_tls_nginx.txt: -------------------------------------------------------------------------------- 1 | # configuration nginx 1.17.7 2 | # générée à partir de https://ssl-config.mozilla.org/ avec des commentaires supplémentaires 3 | 4 | # configuration HTTP, qui redirige automatiquement l'URL vers HTTPS 5 | server { 6 | listen 80 default_server; 7 | listen [::]:80 default_server; 8 | 9 | return 301 https://$host$request_uri; 10 | } 11 | 12 | # configuration HTTPS 13 | server { 14 | listen 443 ssl http2; 15 | listen [::]:443 ssl http2; 16 | 17 | # certificat du site et certificats intermédiaires 18 | ssl_certificate /path/to/signed_cert_plus_intermediates; 19 | # clé privée du certificat 20 | ssl_certificate_key /path/to/private_key; 21 | # dimensionnement du cache TLS et des timeouts 22 | ssl_session_timeout 1d; 23 | ssl_session_cache shared:MozSSL:10m; # à peu près 40000 sessions 24 | # pas de tickets de session 25 | # car ils peuvent compromettre la confidentialité persistance ("forward secrecy") des communications 26 | ssl_session_tickets off; 27 | 28 | # paramètres Diffie-Hellman 29 | # il est préférable d'utiliser des paramètres d'au moins 2048 bits, voire plus 30 | ssl_dhparam /path/to/dhparam; 31 | 32 | # support de TLS 1.2 et 1.3 (les deux dernières versions) 33 | ssl_protocols TLSv1.2 TLSv1.3; 34 | # utilisation d'algorithmes à l'état de l'art, permettant la confidentialité persistance et l'authentification des connexions 35 | ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; 36 | # utiliser les suites cryptographiques les plus performantes pour le client 37 | ssl_prefer_server_ciphers off; 38 | 39 | # activation de HSTS, qui force une connexion HTTPS au site, pour une durée de 2 ans 40 | add_header Strict-Transport-Security "max-age=63072000" always; 41 | 42 | # agrafage ("stapling") OCSP, qui permet de vérifier en temps réel la révocation d'un certificat 43 | ssl_stapling on; 44 | ssl_stapling_verify on; 45 | 46 | # Vérification de la chaîne de confiance pour OCSP 47 | ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; 48 | 49 | # serveur DNS à utiliser (à modifier) 50 | resolver 127.0.0.1; 51 | } -------------------------------------------------------------------------------- /templates/BANNIERE.JPG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/LINCnil/Guide-RGPD-du-developpeur/c132de41486e54fc5da056ace55a9b9c8d1b68c4/templates/BANNIERE.JPG -------------------------------------------------------------------------------- /templates/mytemplate.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | $for(author-meta)$ 9 | 10 | $endfor$ 11 | $if(date-meta)$ 12 | 13 | $endif$ 14 | $if(keywords)$ 15 | 16 | $endif$ 17 | $if(title-prefix)$$title-prefix$ – $endif$$pagetitle$ 18 | 19 | $if(quotes)$ 20 | 21 | $endif$ 22 | $if(highlighting-css)$ 23 | 26 | $endif$ 27 | $for(css)$ 28 | 29 | $endfor$ 30 | $if(math)$ 31 | $math$ 32 | $endif$ 33 | $for(header-includes)$ 34 | $header-includes$ 35 | $endfor$ 36 | 87 | 88 | 89 | 90 |
91 |
92 |
93 |
94 |
95 |
96 |
97 |
98 | $for(include-before)$ 99 | $include-before$ 100 | $endfor$ 101 | $if(title)$ 102 |
103 |

$title$

104 | $if(subtitle)$ 105 |

$subtitle$

106 | $endif$ 107 | $for(author)$ 108 |

$author$

109 | $endfor$ 110 | $if(date)$ 111 |

$date$

112 | $endif$ 113 |
114 | $endif$ 115 | $if(toc)$ 116 |
117 | $toc$ 118 |
119 | $endif$ 120 | $body$ 121 | $for(include-after)$ 122 | $include-after$ 123 | $endfor$ 124 |
125 |
126 | 127 | 128 | -------------------------------------------------------------------------------- /templates/pandoc.css: -------------------------------------------------------------------------------- 1 | 290 | --------------------------------------------------------------------------------