101 lines
7.6 KiB
Markdown
101 lines
7.6 KiB
Markdown
---
|
||
title: "Guide CNIL: sécurité des données personnelles"
|
||
date: 2024-04-16T10:45:00+02:00
|
||
draft: false
|
||
tags: ["GDPR","data privacy","infosec","CNIL","ANSSI"]
|
||
author: "Olivier Falcoz"
|
||
hidemeta: false
|
||
ShowReadingTime: true
|
||
ShowPostNavLinks: true
|
||
showtoc: false
|
||
cover:
|
||
image: "/images/"
|
||
alt: "<alt text>"
|
||
caption: "<text>"
|
||
---
|
||
|
||
|
||
## RGPD - Le guide pratique
|
||
|
||
La CNIL[^1] est sympa. Le *gendarme français des données personnelles* inflige (parfois) des amendes (modestes au regard de ce qu'autorise le RGPD) à ceux qui bafouent le respect de la vie privée et la sécurité des données personnelles. Enfin, quand elle ne fait pas de siestes trop longues[^2] ou ne fait pas preuve d'un laxisme éhonté comme le rapportait La Quadrature du Net en 2021[^3]. Mais globalement la situation s'améliore: en 2023, la CNIL a instruit 16 000 plaintes, procédé à 340 contrôles et prononcé 168 mises en demeure et 42 sanctions pour un montant de 90 millions d'Euros.
|
||
|
||
Elle publie également de nombreux guides à l'intention des particuliers, des professionnels et de la presse. C'est sous la rubrique *Professionnels* que la version 2024 du *Guide CNIL de la sécurité des données personnelles* est publiée.
|
||
|
||
Destiné en priorité à un public averti - *Data Protection Officer*, *Chief Information Security Officer*, juristes, mais également aux gens curieux de la préservation de leurs données, ce guide fournit des méthodes pour *accompagner les organismes dans la mise en place de mesures de sécurité pour assurer la protection des données personnelles qu’ils traitent*.
|
||
|
||
Divisé en 25 fiches thématiques, le document est un recueil de précautions qu'il est recommandé de mettre en place. La patte de l'ANSSI y est visible d'où son aspect plus technique que les publications habituelles de la CNIL.
|
||
|
||
## Architecture
|
||
|
||
Le guide est divisé en cinq thèmes, sous forme de fiches:
|
||
|
||
1. Les **utilisateurs** - le cadre, leur sensibilisation et formation, l'authentification, les habilitations;
|
||
2. Le **matériel** - sécuriser le poste de travail, le mobile, les réseau et sites Web, les serveurs, encadrer le développement, garantir la sécurité physique des locaux;
|
||
3. La **maîtrise des données** - les échanges avec les tiers, la sous-traitance, la maintenance et fin de vie des équipements;
|
||
4. Anticiper **les incidents** - tracer les opérations, les sauvegardes, la continuité et reprise d'activité, la gestion des violations;
|
||
5. **Focus** - l'analyse de risque, le chiffrement, hash et signature, le *cloud*, les applications mobiles, l'intelligence artificielle, les API
|
||
|
||
Chaque fiche est articulée en trois parties:
|
||
|
||
- les précautions élémentaires ou encore ce qu'il **faut** faire ou ce qui peut **raisonnablement** être fait, aussi appelé RTFM[^4];
|
||
- les mauvaises pratiques (*bad boy, bad boy huh*), ce que **beaucoup** d'entre nous probablement font;
|
||
- les mesures complémentaires plus pointues, donc à l'intention des SecDevOps[^5] ou ce qu'il **faudrait** donc faire en sus du reste.
|
||
|
||
## Un exemple - Chiffrement, hachage, signature
|
||
|
||
Fiche 21: **Assurer l’intégrité, la confidentialité et l’authenticité d’une information**, un exemple pris (pas tout à fait) au hasard de la façon dont une fiche est articulée:
|
||
|
||
### Précautions élémentaires
|
||
- Utiliser un **algorithme reconnu et sûr**:
|
||
- SHA-296 ou SHA-397 comme familles de fonctions de hachage;
|
||
- bcrypt, scrypt, Argon2 ou PBKDF2 pour stocker les mots de passe;
|
||
- AES98 avec un mode de construction approprié (CCM, GCM, ou EAX) ou ChaCha2099 (avec
|
||
Poly1305) pour le chiffrement symétrique;
|
||
- RSA-OAEP100, ECIES-KEM101 ou DLIES-KEM101 pour le chiffrement asymétrique;
|
||
- RSA-SSA-PSS100 ou ECDSA102 pour les signatures.
|
||
|
||
- Utiliser des **tailles de clés suffisantes** :
|
||
- pour AES, les clés de 128, 192 ou 256 bits sont considérées comme suffisantes;
|
||
- pour les algorithmes basés sur RSA, il est recommandé d’utiliser des modules et exposants
|
||
secrets d’au moins 2 048 bits ou 3 072 bits, avec des exposants publics, pour le chiffrement,
|
||
supérieurs à 65 536 bits.
|
||
|
||
- Appliquer les **recommandations d’utilisation appropriées**, en fonction de l’algorithme utilisé. Les
|
||
erreurs d’implémentation ont un impact important sur la sécurité du mécanisme cryptographique.
|
||
- **Protéger les clés secrètes**, au moins par la mise en œuvre de droits d’accès restrictifs et d’un mot
|
||
de passe sûr.
|
||
- Rédiger une **procédure** indiquant la **manière** dont les **clés et certificats vont être gérés** en prenant
|
||
en compte les cas d’oubli du mot de passe de déverrouillage.
|
||
|
||
### Ce qu'il ne faut pas faire
|
||
|
||
- Utiliser des algorithmes obsolètes, comme les chiffrements DES et 3DES ou les fonctions de
|
||
hachage MD5 et SHA-1.
|
||
- Confondre fonction de hachage et de chiffrement et considérer qu’une fonction de hachage seule est suffisante pour assurer la confidentialité d’une donnée. Bien que les fonctions de hachage
|
||
soient des fonctions « à sens unique », c’est-à-dire des fonctions difficiles à inverser, une donnée peut être retrouvée à partir de son empreinte. En effet, ces fonctions étant rapides à l’exécution, il est souvent possible de tester automatiquement toutes les possibilités et ainsi de reconnaître l’empreinte.
|
||
- Hacher les mots de passe sans faire intervenir un sel.
|
||
|
||
### Pour aller plus loin
|
||
|
||
- Voir la [page dédiée](https://www.cnil.fr/fr/comprendre-les-grands-principes-de-la-cryptologie-et-du-chiffrement) sur le site de la CNIL
|
||
- L’ANSSI a publié des [guides](https://cyber.gouv.fr/publications/mecanismes-cryptographiques) pour aider les développeurs et administrateurs dans leurs choix d’algorithmes cryptographiques, de dimensionnement et d’implémentation.
|
||
- Lors de la réception d’un certificat électronique, vérifier que le certificat contient une indication d’usage conforme à ce qui est attendu, qu’il est valide et non révoqué, et qu’il
|
||
possède une chaîne de certification correcte à tous les niveaux.
|
||
- Utiliser des logiciels ou des bibliothèques cryptographiques ayant fait l’objet de vérifications par des tierces parties à l’expertise avérée.
|
||
- Différentes solutions de chiffrement peuvent être utilisées, telles que:
|
||
- les solutions certifiées ou qualifiées par l’[ANSSI](https://cyber.gouv.fr/visa-de-securite);
|
||
- le logiciel [VeraCrypt](https://www.veracrypt.fr), permettant la mise en œuvre de conteneurs chiffrés;
|
||
- le logiciel [GNU Privacy Guard](https://www.gnupg.org/index.fr.html), permettant la mise en œuvre de la cryptographie asymétrique (signature et chiffrement).
|
||
|
||
|
||
## Téléchargement
|
||
|
||
Le guide est disponible au [téléchargement en français](https://www.cnil.fr/sites/cnil/files/2024-03/cnil_guide_securite_personnelle_2024.pdf) (.pdf-1.66Mo) ou [English version](https://www.cnil.fr/sites/cnil/files/2024-03/cnil_guide_securite_personnelle_ven_0.pdf) (.pdf-730KB).
|
||
|
||
|
||
[^1]: Commission Nationale de l'Informatique et des Libertés - [cnil.fr](https://cnil.fr/)
|
||
[^2]: La CNIL s'est vue longtemps reprocher des délais de saisine trop longs.
|
||
[^3]: [Les GAFAM échappent au RGPD, la CNIL complice](https://www.laquadrature.net/2021/05/25/les-gafam-echappent-au-rgpd-avec-la-complicite-de-la-cnil/) - La Quadrature Du Net
|
||
[^4]: [Read The Fucking Manual](https://www.explainxkcd.com/wiki/index.php/293:_RTFM) - xkcd
|
||
[^5]: [DevOpsSec, SecDevOps, DevSecOps: What’s in a Name?](https://www.csoonline.com/article/558441/devopssec-secdevops-devsecops-whats-in-a-name.html) - Jamie Tischart, CSO Online
|