Kit de bonnes pratiques de la CNIL à destination des développeurs

La CNIL vient de publier un kit des bonnes pratiques à appliquer dès la conception d’une solution IT (Code, SDK, bibliothèques, etc.) selon le principe GDPR de Privacy by Design afin d’améliorer la gestion des données et sécuriser les projets.

https://www.cnil.fr/fr/kit-developpeur

Les premières recommandations visent le choix des outils de travail (messagerie instantanée, outil de planification et suivi des tâches, outil d’édition collaborative de code source et de document, etc.) et l’accès aux données de l’entreprise. Plusieurs types de données sont concernés :

  • Les données personnelles manipulées (risque de fuite de données) ;
  • Les données client (confidentialité);
  • Les données en lien avec l’intelligence économique de l’entreprise.

Dans le cadre du développement, il convient donc de maintenir à jour les outils de l’environnement de développement, notamment au cours du processus de compilation du code source où des vulnérabilités peuvent apparaître ou de nouvelles techniques de protection peuvent être intégrées.

https://www.cnil.fr/fr/choisir-ses-outils-de-travail

Les secondes sont relatives à la sécurité qui doit être intégrée dès la conception des projets IT et à chaque étape du développement.

  • Faire une analyse d’impact (AIPD) avant de commencer à développer ;
  • Gardez la maîtrise des systèmes afin d’en assurer le bon fonctionnement et le niveau de sécurité ;
  • Adoptez une méthodologie agile intégrant la sécurité. Par exemple, si vous utilisez la méthodologie « Scrum », vous pouvez inclure des « User Stories » relatives à la protection des données de vos utilisateurs ou aux mesures de sécurité que vous souhaitez intégrer (cf. Guide de l’ANSSI « Agilité & Sécurité numériques »)
  • Utilisez des normes de programmation incluant la sécurité : des listes de normes, bonnes pratiques ou guides de codage améliorant la sécurité des développements sont disponibles. Des outils annexes peuvent également être intégrés dans les environnements de développement intégrés (« IDE ») afin de vérifier automatiquement que le code respecte les différentes règles faisant partie de ces normes ou bonnes pratiques. Pour le développement d’application web, des guides de bonnes pratiques spécifiques existent, tels que ceux publiés par l’OWASP.
  • Choix des technologies : Avant de se lancer dans le développement, il convient de choisir les technologies et langages de programmation. De nombreuses vulnérabilités sont désormais connues. Elles peuvent être prises en compte pour le choix du langage de programmation ou des technologies. De plus, parmi ces vulnérabilités, beaucoup étant corrigées, il faut utiliser les langages et technologies dans leur dernière version.

https://www.cnil.fr/fr/preparer-son-developpement-en-toute-securite

https://www.ssi.gouv.fr/uploads/2018/11/guide-securite-numerique-agile-anssi-pa-v1.pdf

https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards

https://www.owasp.org/index.php/Main_Page

Les troisièmes sont relatives à la gestion des codes source. Les principaux outils de gestion de code source (Git, Mercurial par exemple) sont décentralisés mais la grande majorité des développeurs utilise des solutions centralisées pour gérer leur code source : un outil tel que Github, Gitlab, Framagit ou Bitbucket offre à la fois l’accès à des dépôts Git, mais aussi à une interface web et à des outils annexes (gestion des bugs, wiki pour votre documentation, etc.). Il est important de bien configurer les permissions de « check out » ou « pull » (c’est-à-dire de récupération du code source) et de « commit » ou « push » (c’est-à-dire d’enregistrement d’une nouvelle version de votre code). Pour ce qui est de la récupération du code source, vous pouvez configurer votre dépôt afin de spécifier qui peut récupérer le code source. Les restrictions d’accès doivent passer par une authentification des développeurs et utilisateurs (mot de passe, authentification en utilisant des clés publiques et privées, voire des certificats). Pour assurer la sécurité du système lors de sa mise en production, il est très fortement recommandé d’utiliser des données fictives tout au long de la phase de test et de développement. Un code est de moins en moins développé par une seule personne et est voué à évoluer dans le temps. Appliquer les principes de qualité du code permet d’en simplifier la maintenance, tant sur les aspects fonctionnels que vis-à-vis de la sécurité. Par ailleurs, il est conseillé de développer un code propre pour le rendre facilement compréhensible aux futurs contributeurs pour le corriger, maintenir, le faire évoluer et l’auditer. Des outils existent pour aider à contrôler la qualité d’un code qui peuvent signaler les duplications de code, le respect des règles de programmation ou des bugs potentiels

https://www.cnil.fr/fr/gerer-le-code-source

https://www.cnil.fr/fr/renforcer-la-qualite-du-code

Les quatrièmes sont relatives à l’intégration bibliothèques, kits de développements (« SDK »), ou d’autres composants logiciels écrits par des tiers :  

  • Cartographier les différentes bibliothèques et SDK tiers intégrés aux développements. Une bonne pratique consiste à utiliser 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. Ceci facilitera leur identification et leur mise à jour, notamment lorsque l’une d’elles devra être mise à jour rapidement à cause d’une vulnérabilité ;
  • Lire leur documentation et changez leur configuration par défaut si nécessaire ;
  • Auditez les bibliothèques et SDK
  • Intégrez que les fonctionnalités nécessaires et désactivez les autres afin de réduir le nombre de bugs potentiels ;
  • Gérez les mises à jour, en particulier celles qui corrigent des vulnérabilités ;
  • Choisir des logiciels, bibliothèques et SDK maintenus
  • Utilisez des bibliothèques cryptographiques maintenues, reconnues et faciles d’utilisation, en particulier la dernière version des protocoles cryptographiques (par exemple TLS) et des algorithmes reconnus (par exemple AES pour du chiffrement symétrique).

https://www.cnil.fr/fr/bibliotheques-sdk-ou-outils-tiers-comment-les-integrer-dans-vos-applications

Les cinquièmes sont relatives à la documentation du code et de l’architecture:  

  •  Documenter l’architecture, pas uniquement le code
  •  Maintenir la documentation en même temps que le code
  •  « Versionnez » la documentation avec le code
  • Traiter de la sécurité dans votre documentation

https://www.cnil.fr/fr/documenter-le-code-et-larchitecture

Télécharger (PDF, 3.12MB)