TP1re année18 livrables
Enquête cyber chez GSB
Une séance entière pour penser en défenseur : reconnaître ce qui est menacé, et le protéger pour de vrai.
Par Josselyn C., prof de BTS SIO. Publié le , mis à jour le .
- Objectif
- maîtriser la triade C · I · D et la mettre en pratique sur des cas réels
- On manipule
- analyses de cas, mots de passe, empreintes (PowerShell), hameçonnage, RGPD
- Pré-requis
- avoir vu les slides « La cybersécurité » · un poste Windows
- Pour qui
- SLAM et SISR, 1re année
- Durée
- environ 3 h
Compétences : C3.1 Protéger les données à caractère personnel, C3.3 Sécuriser les équipements et les usages des utilisateurs, C3.4 Garantir la disponibilité, l'intégrité et la confidentialité, C3.5 Assurer la cybersécurité d'une solution applicative
Aucune attaque réelle : on raisonne en défenseur. Avance à ton rythme — il y a largement de quoi remplir la séance.
Introduction — pourquoi on fait ça
Avant d'apprendre à attaquer (ça viendra), il faut comprendre ce qu'on défend. Un bon défenseur, devant n'importe quel incident, sait répondre à une seule question : qu'est-ce qui vient d'être menacé, et comment l'empêcher ? Toute cette séance muscle ce réflexe, sur le décor de notre laboratoire GSB, où les données de santé sont parmi les plus sensibles qui soient.
Ce que tu vas apprendre
| Notion | À quoi ça te sert |
|---|---|
| La triade C · I · D | nommer précisément ce qu'une menace fait tomber |
| Mots de passe & force brute | juger et fabriquer un secret réellement solide |
| Hachage & empreinte | comprendre pourquoi on ne stocke jamais un mot de passe en clair, et prouver qu'un fichier est intact |
| Moindre privilège | donner le bon accès à la bonne personne |
| Sauvegarde 3-2-1 & ransomware | garder un service en vie face à une attaque |
| Hameçonnage & RGPD | repérer la manipulation, protéger les données personnelles |
Pré-requis
Aucune connaissance préalable en sécurité. Tu as besoin d'un poste Windows (pour les manips PowerShell) et d'un accès à un moteur de recherche (pour les enquêtes documentaires). C'est tout.
Vocabulaire express — les mots qu'on va répéter
| Mot | Traduction |
|---|---|
Pilier | une des trois promesses de sécurité : C, I ou D |
Menace | ce qui peut casser un pilier (vol, panne, falsification…) |
Force brute | essayer tous les mots de passe possibles, un par un, à toute vitesse |
Empreinte (hash) | une « signature » calculée à partir d'un contenu, qui change du tout au tout si le contenu change |
DCP | donnée à caractère personnel : toute info qui identifie quelqu'un |
Mise en place — ton carnet d'enquête
Ta boussole : la triade C · I · D
| Pilier | La promesse | Ce qui la casse |
|---|---|---|
| C — Confidentialité | seuls les ayants droit accèdent à l'info | vol / fuite |
| I — Intégrité | l'info n'est pas modifiée en douce | falsification, suppression |
| D — Disponibilité | l'info répond quand on en a besoin | ransomware, panne, saturation |
Partie 1 — Reconnaître quel pilier tombe
Le réflexe de base de tout défenseur. On le muscle avec une méthode, un exemple décortiqué, puis tes propres cas.
1.1 — La méthode des trois questions
Devant un incident, pose-toi, dans l'ordre :
| Question | Si oui → pilier touché |
|---|---|
| Quelqu'un a-t-il vu une info sans en avoir le droit ? | C — Confidentialité |
| Une info a-t-elle été modifiée ou supprimée sans autorisation ? | I — Intégrité |
| Un service ou une donnée est-il devenu inaccessible ? | D — Disponibilité |
1.2 — Exemple travaillé (on le fait ensemble)
On applique la méthode :
Quelqu'un a-t-il VU sans droit ? -> OUI (le visiteur lit des dossiers) => C
Une info a-t-elle été MODIFIÉE ? -> non (il ne fait que lire)
Un service est-il INACCESSIBLE ? -> non (tout fonctionne)
Conclusion : pilier touché = C (Confidentialité). Remarque : le visiteur n'a rien cassé ni bloqué — pourtant c'est bien un incident de sécurité. Voir une donnée sans droit suffit.
1.3 — Comment ça marche : un incident peut casser DEUX piliers
Beaucoup d'attaques touchent plusieurs promesses à la fois. Décortiquons un ransomware :
Ransomware = il chiffre les fichiers
-> on ne peut plus y accéder ............. D (Disponibilité) tombe
-> ET souvent il copie les données avant de chiffrer
(pour faire chantage) .................. C (Confidentialité) tombe aussi
=> un seul incident, deux piliers
D'où le réflexe : ne t'arrête pas au premier pilier trouvé, vérifie les trois questions à chaque fois.
1.4 — À toi : l'enquête des 8 incidents
| # | Incident |
|---|---|
| 1 | Un pirate modifie le dosage inscrit dans une ordonnance déjà enregistrée. |
| 2 | Une panne de serveur rend l'appli de commande inaccessible deux jours. |
| 3 | Un ransomware chiffre tous les fichiers ; rien n'est lisible sans payer. |
| 4 | Un mot de passe volé permet de lire les e-mails du directeur. |
| 5 | Quelqu'un supprime sans autorisation des lignes de la base de données. |
| 6 | Le site public de GSB est saturé de requêtes et tombe en pleine campagne. |
| 7 | Une clé USB perdue contenait la liste non chiffrée des patients. |
| 8 | Un employé envoie par erreur un tableau de patients à la mauvaise adresse e-mail. |
Flag B1
L'enquête
Pour les 8 incidents, applique la méthode des trois questions et indique le ou les piliers touchés (C, I, D), avec une justification courte. Rends : une ligne par incident, ex. 1 → I (le dosage est modifié).
1.5 — De l'incident à l'impact
Reconnaître le pilier, c'est l'étape 1. Un pro mesure aussi l'impact. Exemple travaillé pour l'incident 2 (panne 2 jours → D) :
Pilier : D (Disponibilité)
Impact concret chez GSB :
- les pharmacies ne sont plus livrées en médicaments
- perte de chiffre d'affaires + image dégradée
- les commandes urgentes (patients) sont retardées
Flag B2
Analyse d'impact
Choisis 3 incidents de la liste 1.4 et, pour chacun, rends : le pilier + 2 conséquences concrètes pour GSB ou ses patients.
Partie 2 — Confidentialité : verrouiller les accès
La confidentialité repose d'abord sur deux choses : des secrets solides (mots de passe) et des droits bien réglés (qui accède à quoi). On va comprendre pourquoi un mot de passe tombe, pas seulement le constater.
2.1 — Comment ça marche : casser un mot de passe
Un attaquant qui veut deviner un mot de passe a deux grandes méthodes :
1) Attaque par DICTIONNAIRE
-> il teste d'abord tous les mots connus, prénoms, "azerty", "123456",
et leurs variantes ("P@ssw0rd"). Très rapide.
2) Attaque par FORCE BRUTE
-> il teste TOUTES les combinaisons possibles, une par une.
Le seul rempart : la LONGUEUR. Chaque caractère en plus
multiplie le nombre de combinaisons -> le temps explose.
Conséquence : un mot de passe court avec des symboles (P@ss1!) tombe vite ; une longue phrase simple (cactus-vélo-tonnerre-42) résiste des siècles.
| Longueur / type | Combinaisons possibles | GPU RTX 4090, hash MD5 (≈100 Mrd tests/s) | Avec bcrypt coût 12 (≈1 000 tests/s) |
|---|---|---|---|
| 6 chiffres (PIN) | 1 000 000 | < 1 milliseconde | ∼ 17 minutes |
| 8 minuscules seules | ∼ 208 milliards | ∼ 2 secondes | ∼ 6 600 ans |
| 8 car. alphanum. + symboles (~90 car.) | ∼ 4 × 10¹⁵ | ∼ 11 heures | hors de portée |
| 12 car. alphanumériques | ∼ 3 × 10²¹ | > 1 000 ans (SHA-256) | hors de portée |
| 20+ car. (phrase de passe type) | ∼ 10³⁸ | des milliards d'années | hors de portée |
2.2 — Exemple travaillé : pourquoi « P@ssw0rd! » est faible
P@ssw0rd!
-> c'est le mot "Password" déguisé (a->@, o->0)
-> les attaquants connaissent CES substitutions par cœur :
elles sont dans tous les dictionnaires d'attaque
-> 9 caractères seulement
=> faible, malgré les symboles
2.3 — À toi : audit de mots de passe
Pour chacun, dis faible ou fort, et pourquoi.
a) azerty
b) Marc2024
c) P@ssw0rd!
d) cactus-vélo-tonnerre-42
e) Tr0ub4dor&3
Flag B4
Audit
Classe a→e en faible/fort avec une raison. Rappelle-toi : la longueur prime sur les symboles.
2.4 — Construis ton secret
Flag B5
Production
Crée une phrase de passe (4 mots + 1 chiffre), différente de l'exemple, et explique en une phrase pourquoi elle bat P@ssw0rd!.
2.5 — Pourquoi on ne stocke jamais un mot de passe « en clair »
Si GSB rangeait les mots de passe tels quels, un seul vol de base = tous les comptes ouverts. La parade : le hachage. On va le voir en vrai, dans le terminal.
C'est quoi le hachage ?
Ouvre PowerShell (menu Démarrer → tape « PowerShell »). Écris le mot azerty dans un fichier :
"azerty" | Out-File mdp.txt
Calcule son empreinte SHA-256 :
Get-FileHash mdp.txt -Algorithm SHA256
Tu vois s'afficher une longue empreinte (toujours la même pour « azerty ») :
Algorithm Hash
--------- ----
SHA256 C9C1E91A... (64 caractères en tout)
Pourquoi SHA-256 seul ne suffit pas pour les mots de passe
SHA-256 est conçu pour être rapide — vérifier l'intégrité d'un fichier de 1 Go en quelques secondes est une qualité. Pour les mots de passe, c'est un défaut : à 100 milliards de tests par seconde, un dictionnaire de 10 millions de mots courants se vérifie en 0,1 milliseconde. La contre-mesure : bcrypt.
Bcrypt — comment ça marche
bcrypt(mot_de_passe, coût=12)
1. génère un sel aléatoire de 128 bits
2. itère la fonction interne 2^12 = 4 096 fois
3. produit une empreinte de 60 caractères :
$2b$12$[22 chars sel][31 chars hash]
^^ ^^
| coût stocké dans l'empreinte elle-même
version bcrypt (2b)
Deux calculs bcrypt du même mot (coût 12) — vois la différence :
bcrypt("azerty") → $2b$12$Lm8...xY4 (60 caractères)
bcrypt("azerty") → $2b$12$Qr3...mZ7 (60 caractères différents !)
→ sel différent à chaque appel → empreintes uniques
→ pour VÉRIFIER : bcrypt compare en interne automatiquement
| Algorithme | Vitesse GPU (RTX 4090) | Sel intégré | Usage recommandé | OK pour les mots de passe ? |
|---|---|---|---|---|
| MD5 | ∼ 164 Mrd/s | non | NE PLUS UTILISER (cassé cryptographiquement) | non |
| SHA-256 | ∼ 22 Mrd/s | non | intégrité de fichier, signatures TLS/JWT | non — trop rapide |
| SHA-512 | ∼ 8 Mrd/s | non | signatures, TLS | non — encore trop rapide |
| bcrypt (coût 12) | ∼ 1 000/s | oui (128 bits) | mots de passe utilisateurs | oui |
| Argon2id | ∼ quelques centaines/s | oui | mots de passe (favori OWASP 2024) | oui — champion actuel |
Flag D1
Investigation
En vrai, pour les mots de passe on n'utilise pas SHA-256 seul mais bcrypt (une fonction faite pour être lente). Cherche « bcrypt mot de passe ». Rends : en 2 phrases, pourquoi une fonction lente protège mieux ici qu'une fonction rapide.
2.6 — Le bon accès à la bonne personne (moindre privilège)
Tout le monde n'a pas à tout voir. Principe du moindre privilège : chacun n'a que les droits dont il a besoin. Complète par oui/non.
| Action | Médecin | Secrétaire | Visiteur |
|---|---|---|---|
| Lire un dossier patient | ? | ? | ? |
| Modifier une ordonnance | ? | ? | ? |
| Voir le planning des RDV | ? | ? | ? |
| Exporter toute la base | ? | ? | ? |
Flag B6
Matrice des droits
Recopie le tableau complété, et justifie la ligne « Exporter toute la base » avec le principe du moindre privilège.
2.7 — La double authentification (2FA) : quand le mot de passe seul ne suffit plus
Même un mot de passe solide peut être volé — phishing ciblé, fuite de base, keylogger. La 2FA ajoute un second facteur : même avec le mot de passe, un attaquant ne peut pas entrer sans l'avoir.
Facteur 1 — ce que tu SAIS : ton mot de passe
Facteur 2 — ce que tu AS : ton téléphone (code TOTP ou push)
— ce que tu ES : empreinte digitale, reconnaissance faciale
| Type 2FA | Comment ça marche | Solidité | Piège réel |
|---|---|---|---|
| SMS (OTP 6 chiffres) | code valide ~3 min envoyé par SMS | moyen | SIM swapping : l'attaquant convainc l'opérateur de transférer ton numéro sur sa SIM → il reçoit tes codes. Technique documentée sur des dirigeants d'entreprises. |
| TOTP (Google Auth, Authy) | appli génère un code à 6 chiffres, valide 30 s, basé sur heure + secret partagé (RFC 6238) | bon | Relay attack : un site pirate relaie ton code vers le vrai site en temps réel, avant que les 30 s expirent. |
| Push notification (Duo, MS Auth) | appli envoie « Accepter / Refuser » | bon | MFA fatigue : l'attaquant spamme les push à 3h du matin jusqu'à ce que l'utilisateur accepte par erreur. Microsoft a documenté des attaques réelles sur cette technique en 2022. |
| Clé hardware FIDO2 (YubiKey) | clé USB/NFC, cryptographie à clé publique — la clé privée ne quitte jamais le dispositif, liée au domaine exact du site | excellent | Perte de la clé → compte verrouillé si pas de backup. Protège nativement contre le phishing (la clé vérifie l'URL). |
Partie 3 — Intégrité : garder l'info exacte
L'intégrité garantit que l'information n'est pas modifiée ou supprimée en douce. Chez GSB, un dosage faussé peut être dangereux. On va même manipuler une empreinte pour le prouver.
3.1 — Exemple travaillé : repérer une atteinte à l'intégrité
A-t-on VU sans droit ? -> non
A-t-on MODIFIÉ ? -> OUI (le prix a changé sans contrôle) => I
Service INACCESSIBLE ? -> non
=> pilier touché = I (Intégrité)
3.2 — À toi : le tri
| # | Situation |
|---|---|
| a | Un fichier confidentiel est copié sur une clé USB. |
| b | Une mise à jour bugguée corrompt des enregistrements. |
| c | Le serveur ne répond plus du tout. |
| d | Quelqu'un antidate une facture dans la base. |
Flag B7
Tri
Indique pour a→d le(s) pilier(s) touché(s), et entoure ceux qui relèvent de l'intégrité.
3.3 — Le journal d'audit : savoir qui a fait quoi
Pour protéger l'intégrité, on garde une trace horodatée de chaque action sensible : le journal (audit log). Après un incident, c'est lui qui dit ce qui a changé, quand, et par qui. Un journal utile ne note pas « quelqu'un a fait quelque chose » — il enregistre au minimum 5 champs :
| Champ | Exemple GSB — modification d'ordonnance | Pourquoi indispensable |
|---|---|---|
timestamp | 2026-03-15 14:32:07 UTC | situer l'action dans le temps, corréler avec d'autres événements (log serveur, badge d'entrée…) |
user_id | medecin_dupont / ID 42 | identifier QUI — un nom affiché est falsifiable, un ID en base ne l'est pas |
action | UPDATE ordonnance SET dosage | savoir CE QUI a changé, assez précis pour rejouer ou annuler |
old_value / new_value | « 1 cp/j » → « 2 cp/j » | la preuve de l'altération, indispensable en cas de litige médical ou pénal |
ip_source | 192.168.1.55 (poste cabinet) | D'OÙ vient l'action — une IP inhabituelle (ex. adresse étrangère à 3h du matin) lève une alerte |
Flag D2
Investigation
Cherche « audit log application ». Rends : 2 informations que le journal devrait enregistrer pour une modification d'ordonnance, et en quoi ça aide après coup.
3.4 — Hands-on : prouver qu'un fichier est intact
Comment être sûr qu'une ordonnance, une facture, n'a pas été altérée ? On compare son empreinte avant/après. Même outil qu'en 2.5, appliqué à l'intégrité. On le fait étape par étape.
Étape 1 — Créer le fichier de test
"Ordonnance : 1 comprimé par jour" | Out-File ordo.txt
Étape 2 — Relever son empreinte
Get-FileHash ordo.txt -Algorithm SHA256
Note les 8 premiers caractères de l'empreinte affichée :
Algorithm Hash
--------- ----
SHA256 A1B2C3D4...
Étape 3 — Altérer le fichier, puis recommencer
Ouvre ordo.txt (Bloc-notes), change « 1 comprimé » en « 2 comprimés », enregistre. Recalcule l'empreinte :
Get-FileHash ordo.txt -Algorithm SHA256
SHA256 9Z8Y7X6W... <- TOTALEMENT différent
Flag C1
Manipulation (effet avalanche)
Rends : les 8 premiers caractères de l'empreinte AVANT et APRÈS ta modification, et une phrase expliquant pourquoi ce comportement permet de détecter n'importe quelle altération.
Partie 4 — Disponibilité : rester en ligne
La disponibilité garantit que le service répond quand on en a besoin. Si l'appli de commande de GSB tombe, les pharmacies ne sont plus livrées. Le rempart universel : la sauvegarde.
4.1 — Ce qui casse la disponibilité
| Cause | Comment ça frappe |
|---|---|
| Ransomware | chiffre les fichiers : présents mais illisibles |
| Panne matérielle | un disque serveur lâche, le service s'arrête |
| Déni de service (saturation) | on noie le serveur de requêtes jusqu'à le faire tomber |
| Erreur humaine | une suppression ou une fausse manip |
Point commun : si une copie saine existe, on restaure et on repart. D'où la règle de sauvegarde.
4.2 — La règle 3-2-1
3 copies des données
2 supports différents (ex. disque interne + disque externe)
1 copie hors site (déconnectée / dans le cloud)
Flag D4
Investigation
Cherche « règle de sauvegarde 3-2-1 ». Rends : ce que représentent le 3, le 2 et le 1, et une phrase expliquant pourquoi la copie hors site est cruciale contre un ransomware.
4.3 — Cas : réagir au ransomware de GSB
Lundi, tous les écrans : « Vos fichiers sont chiffrés. Payez. » Voici le plan modèle d'un défenseur — étudie-le, tu devras l'adapter ensuite.
Étape 1 — ISOLER : débrancher du réseau les machines touchées
(on stoppe la propagation avant tout)
Étape 2 — RESTAURER : repartir d'une sauvegarde saine (hors ligne)
(la copie hors site de la règle 3-2-1)
Étape 3 — ANALYSER : comprendre par où c'est entré, l'étendue
Étape 4 — PRÉVENIR : changer les mots de passe, corriger la faille,
sensibiliser les employés
On ne paie PAS.
Flag B8
Plan de réaction
Variante : le ransomware s'est propagé et les pirates menacent de publier les données patients (donc C et D tombent). Rédige un plan en 4 étapes ordonnées adapté à CETTE variante (pense à la notification des personnes et de la CNIL). Pour chaque étape : quoi + pourquoi.
4.4 — RTO et RPO : les deux métriques d'un plan de reprise
Face à un incident, deux questions dictent tout le plan :
| Métrique | Définition | Exemple GSB concret |
|---|---|---|
| RTO (Recovery Time Objective) | Délai maximum acceptable pour remettre le service en ligne après l'incident | RTO = 4 h pour l'appli de commande (au-delà, les pharmacies ne sont plus livrées en médicaments d'urgence) |
| RPO (Recovery Point Objective) | Perte de données maximale tolérable, exprimée en durée : jusqu'à quel point dans le passé remonter | RPO = 24 h (on tolère de perdre une journée de saisies, mais pas plus — sinon ressaisie impossible) |
RTO = 4 h → la restauration doit s'achever en moins de 4 h
(ce qui impose des TESTS réguliers de restauration :
une sauvegarde jamais testée est une sauvegarde qu'on
découvre corrompue au pire moment)
RPO = 24 h → sauvegarde toutes les 24 h minimum, stockée hors site
(si incident à 15h, on repart du backup de 7h : on perd 8h)
Partie 5 — L'humain, le maillon visé
La plupart des attaques ne cassent pas la technique : elles trompent une personne. L'hameçonnage (phishing) est la porte d'entrée n°1 des incidents en entreprise. On apprend à le démasquer, indice par indice — mais d'abord à le nommer précisément.
5.0 — Taxonomie : les formes d'hameçonnage à connaître
| Terme | Vecteur | Exemple concret | Cible type |
|---|---|---|---|
| Phishing | e-mail de masse non ciblé | faux e-mail « Ameli » envoyé à des millions de personnes | grand public |
| Spear phishing | e-mail ciblé, personnalisé | « Bonjour Dupont, suite à notre réunion du 12 mars avec GSB… » — l'attaquant se documente (LinkedIn, presse) avant d'écrire | dirigeants, comptables, RH |
| Smishing | SMS | faux SMS « Chronopost — votre colis est bloqué, cliquez ici » | grand public |
| Vishing | appel vocal | faux « technicien informatique » qui demande d'installer un logiciel de prise en main à distance | entreprises, personnes âgées |
| Whaling | spear phishing sur PDG / DAF | fausse demande de virement urgente, signée « PDG » — le DAF reçoit et exécute sans vérifier | direction, finance |
5.0 bis — Pourquoi les e-mails peuvent être usurpés
L'e-mail a été conçu dans les années 1970 sans authentification de l'expéditeur : n'importe qui peut mettre From: support@gsb.fr dans un en-tête. Trois standards modernes limitent (mais n'éliminent pas) ce problème :
| Standard | Ce qu'il fait | Limite |
|---|---|---|
| SPF | liste dans le DNS les serveurs autorisés à envoyer pour ce domaine ; le serveur destinataire vérifie | ne protège pas si l'attaquant loue un domaine sosie (gsb-support.fr) |
| DKIM | ajoute une signature cryptographique à l'e-mail ; le destinataire vérifie via le DNS que le message n'a pas été altéré | ne prouve pas l'identité réelle de l'expéditeur, juste l'intégrité du message |
| DMARC | politique qui dit quoi faire si SPF ou DKIM échoue : rejeter, mettre en spam, ou juste signaler | beaucoup de domaines restent en mode « p=none » (rapport seulement) — sans effet bloquant |
5.1 — Exemple travaillé : ce faux e-mail, décortiqué
De : support-gsb@secure-verif-account.com
Objet : URGENT — votre compte sera suspendu sous 24h
Bonjour,
Nous avons détecter une activité inhabituel sur votre compte.
Cliquez immédiatement ici pour confirmer votre mot de passe :
http://gsb-verification-login.ru/confirm
L'équipe Sécurité GSB
| Indice | Ce qui cloche |
|---|---|
| Expéditeur | secure-verif-account.com n'est pas le vrai domaine de GSB |
| Urgence | « sous 24h », « immédiatement » : on te presse pour t'empêcher de réfléchir |
| Lien | ...login.ru : domaine étranger douteux, pas le site officiel |
| Fautes | « détecter », « inhabituel » : un vrai service se relit |
| Demande | jamais un service sérieux ne demande ton mot de passe par e-mail |
5.2 — Comment ça marche : vérifier sans se faire avoir
5.3 — À toi : un cas plus subtil
Tu reçois un SMS : « GSB-RH : votre fiche de paie est disponible, connectez-vous : gsb-rh-portail.com/login ». Pas de faute, ton crédible.
Flag D5
Esprit critique
Rends : 2 vérifications à faire avant de cliquer, et le réflexe sûr pour accéder à ta fiche de paie sans utiliser ce lien.
5.4 — Que fais-tu ?
| # | Situation |
|---|---|
| a | Un e-mail « urgent » te demande ton mot de passe pour « vérification ». |
| b | Une clé USB est posée sur ton bureau, sans mot. Tu es curieux. |
| c | Au téléphone, quelqu'un se dit « technicien » et demande ton code d'accès. |
Flag B9
Mises en situation
Pour a, b, c : dis ce que tu fais (et ne fais pas), et la raison en une phrase.
5.5 — Ton mémo pour GSB
Flag E1
Production
Rédige un mémo de 5 règles d'or contre l'hameçonnage, pour tous les employés de GSB. Court, clair, applicable par n'importe qui.
Partie 6 — Les données personnelles
Tout ce qu'on protège vise surtout les données à caractère personnel (DCP) — toute info qui identifie une personne. Chez GSB, ce sont des données de santé : parmi les plus sensibles qui soient, et les plus encadrées par la loi.
6.1 — Exemple travaillé : DCP ou pas ?
"L'adresse e-mail d'un patient" -> identifie une personne => DCP
"La marque du serveur de GSB" -> identifie un matériel => PAS une DCP
"Le traitement médical de M. X" -> donnée de santé => DCP TRÈS sensible
La question test : cette info, seule ou recoupée, permet-elle de remonter à une personne ?
| # | Information |
|---|---|
| a | Le numéro de sécurité sociale |
| b | La version de Windows d'un poste |
| c | Le nom et l'adresse d'un patient |
| d | L'adresse IP publique du site GSB |
| e | Le groupe sanguin d'une personne nommée |
Flag B10
Tri des données
Classe a→e en DCP / pas DCP. Pour les DCP, signale celles que tu juges très sensibles.
6.2 — Ce que dit le RGPD — les articles qui comptent vraiment
Le RGPD (Règlement Général sur la Protection des Données, en vigueur depuis mai 2018) crée des droits pour les personnes et des obligations pour les organisations qui traitent leurs données. Pour un développeur SLAM, voici les articles à connaître par cœur :
| Article | Principe / Obligation | Ce que ça veut dire pour GSB |
|---|---|---|
| Art. 5 | Principes fondamentaux : licéité, loyauté, transparence, limitation des finalités, minimisation, exactitude, limitation de la conservation, intégrité et confidentialité | Ne collecter que les champs utiles pour la finalité déclarée. Supprimer les données quand la finalité est atteinte (ex. ordonnances d'un patient décédé). |
| Art. 9 | Catégories spéciales de données — interdiction par défaut de traiter : données de santé, origine ethnique, opinions politiques, données biométriques… | Tous les dossiers patients de GSB contiennent des données de santé = catégorie spéciale → protection renforcée obligatoire : chiffrement au repos, accès strictement limité, journalisation des accès. |
| Art. 17 | Droit à l'effacement (« droit à l'oubli ») | Un patient peut demander la suppression de toutes ses données. GSB a 1 mois pour répondre (et 3 mois si traitement complexe). Exceptions : obligation légale de conservation (ex. dossier médical = 20 ans en France). |
| Art. 32 | Obligation de sécurité appropriée : mesures techniques et organisationnelles proportionnées au risque | Chiffrement des données en transit (TLS) et au repos, hachage bcrypt des mots de passe, contrôle d'accès (moindre privilège), journalisation des accès aux dossiers sensibles. |
| Art. 33 | Notification à l'autorité (CNIL) dans les 72 h après découverte d'une violation | Ransomware avec exfiltration détecté lundi à 9h → notification CNIL au plus tard jeudi à 9h. Formulaire en ligne sur notifications.cnil.fr. |
| Art. 34 | Notification aux personnes concernées si risque élevé | Si les dossiers patients ont été volés → informer chaque patient concerné « dans les meilleurs délais ». |
| Art. 83 | Sanctions | Jusqu'à 20 M€ ou 4 % du CA mondial pour les violations les plus graves (art. 5, 9, 25, 35). Jusqu'à 10 M€ ou 2 % pour les violations organisationnelles (art. 33, 34…). Cumulables. |
Amendes réelles prononcées par la CNIL (exemples)
| Organisation | Violation | Amende |
|---|---|---|
| Amazon Europe (2021) | Cookies sans consentement valide | 35 M€ |
| Groupe Caisse d'Épargne (2024) | Failles de sécurité, accès non contrôlé | 3 M€ |
| Boulanger (2024) | Données clients exposées suite à une faille | 3 M€ |
| Libre Software (PME) | Absence de mesures de sécurité élémentaires | 75 000 € |
La CNIL ne sanctionne pas seulement les grandes entreprises. Une PME sans mesures de sécurité élémentaires est aussi exposée.
Flag D7
Investigation
Cherche « droits RGPD des personnes ». Rends : trois droits (en plus du droit à l'effacement cité ci-dessus), et lequel s'applique quand un patient demande à récupérer ses données pour les transmettre à un autre médecin.
6.3 — Exemple travaillé : collecter le juste nécessaire
Le RGPD impose la minimisation : ne demander que ce qui est utile à la finalité. Exemple, un formulaire d'inscription à la newsletter de GSB demande :
nom, e-mail, date de naissance, n° sécurité sociale, traitement en cours
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
utile ? aucun rapport aucun rapport
avec une newsletter avec une newsletter
Flag B11
Minimisation
Rends : quels champs tu retires de ce formulaire et pourquoi, et lesquels tu gardes. Justifie avec le principe de minimisation.
6.4 — Cas travaillé : la violation de données de GSB
Appliquons le RGPD sur un scénario réaliste. Lis le cas, puis réponds aux questions.
ANALYSE RGPD — que doit faire GSB ?
1. Données volées = données de santé (traitements) + numéro SS
→ CATÉGORIE SPÉCIALE (art. 9) + DCP très sensibles
→ Risque ÉLEVÉ pour les personnes concernées
2. Art. 33 — Notification CNIL :
Découverte : lundi 09h00
Deadline : jeudi 09h00 (72h exactement)
→ Formulaire sur notifications.cnil.fr
→ Inclure : nature de la violation, données concernées,
nbre de personnes, mesures prises, contact DPO
3. Art. 34 — Notification des patients :
1 840 patients doivent être informés individuellement
→ Délai : « meilleurs délais » (quelques jours max)
→ Contenu : ce qui a été exposé, risques, ce que fait GSB
→ Si GSB ne dispose pas des coordonnées de tous : annonce publique
4. Art. 32 — Mesures correctives immédiates :
→ Désactiver la route vulnérable
→ Auditer toutes les routes de l'API (contrôle d'accès systématique)
→ Renforcer la revue de code (vérification auth avant déploiement)
→ Former les stagiaires aux règles de mise en prod
5. Exposition aux sanctions :
→ Violation art. 32 (sécurité insuffisante) : jusqu'à 10 M€ ou 2% CA
→ Violation art. 9 (données de santé mal protégées) : jusqu'à 20 M€ ou 4% CA
→ Circonstance atténuante : notification rapide, mesures correctives proactives
Flag B12
Cas GSB
À partir du scénario 6.4 : rends (a) la deadline exacte de notification CNIL en heure et jour, (b) pourquoi GSB doit aussi notifier les patients directement (cite l'article), (c) une mesure technique qui aurait empêché la fuite — et le principe OWASP qu'elle respecte.
Pour finir
Ce que tu sais faire maintenant
| Domaine | Tu sais… |
|---|---|
| Triade C·I·D | appliquer la méthode des 3 questions à n'importe quel incident |
| Confidentialité | expliquer force brute/dictionnaire, juger un mot de passe, appliquer le moindre privilège |
| Intégrité | reconnaître une altération, calculer et comparer une empreinte (PowerShell) |
| Disponibilité | expliquer la sauvegarde 3-2-1 et bâtir un plan anti-ransomware |
| Facteur humain | démasquer un hameçonnage, vérifier un lien/un expéditeur |
| Données perso | reconnaître une DCP, appliquer la minimisation, citer des droits RGPD |
Glossaire
| Mot | Définition |
|---|---|
Triade C·I·D | les trois promesses : Confidentialité, Intégrité, Disponibilité |
Force brute | tester toutes les combinaisons d'un mot de passe, une par une |
Attaque par dictionnaire | tester d'abord tous les mots/variantes connus |
Phrase de passe | mot de passe fait de plusieurs mots : long et mémorisable |
Hachage | transformation à sens unique (mot de passe → empreinte) |
Empreinte (SHA-256) | signature d'un contenu ; change totalement si le contenu change |
Moindre privilège | ne donner que les droits strictement nécessaires |
2FA | double authentification (un second facteur) |
Journal (audit log) | trace horodatée de qui a fait quoi |
Ransomware | logiciel qui chiffre les fichiers et réclame une rançon |
Sauvegarde 3-2-1 | 3 copies, 2 supports, 1 hors site |
Hameçonnage | faux message pour voler identifiants/argent (phishing) |
Ingénierie sociale | manipuler une personne pour obtenir un accès/une info |
DCP | donnée à caractère personnel (toute info qui identifie une personne) |
Catégorie spéciale (art. 9) | données sensibles à protection renforcée : santé, origine ethnique, biométrie, opinions politiques… |
RGPD | Règlement Général sur la Protection des Données — loi européenne en vigueur depuis mai 2018 |
CNIL | autorité française de contrôle du RGPD, peut infliger jusqu'à 20 M€ ou 4 % du CA mondial |
ANSSI | Agence Nationale de la Sécurité des Systèmes d'Information — autorité nationale de cybersécurité |
RTO | Recovery Time Objective — délai max pour remettre un service en ligne après incident |
RPO | Recovery Point Objective — perte de données maximale tolérée (exprimée en durée) |
SIM swapping | attaque où l'attaquant convainc un opérateur de rediriger le numéro de téléphone d'une victime sur sa SIM |
MFA fatigue | attaque sur la 2FA : spam de push notifications pour que l'utilisateur finisse par valider par erreur |
Spear phishing | hameçonnage ciblé et personnalisé (vs phishing de masse) |
SPF / DKIM / DMARC | standards d'authentification des e-mails (qui peut envoyer, intégrité du message, politique si échec) |
OWASP Top 10 | classement des 10 vulnérabilités applicatives les plus critiques, mis à jour régulièrement (2021 en vigueur) |
Broken Access Control (A01) | vulnérabilité n°1 OWASP — une route ou ressource accessible sans les bons droits |
art. 323-1 CP | accès/maintien frauduleux dans un système informatique — jusqu'à 3 ans / 100 000 € (5 ans / 150 000 € si données de santé) |