Upload files to "content/posts/infosec"
This commit is contained in:
parent
7f0c81fb65
commit
3e183ae990
|
|
@ -0,0 +1,100 @@
|
|||
---
|
||||
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
|
||||
Loading…
Reference in New Issue