Épreuve blanche E7 n° 1 : un réseau de centres de rééducation

A1.1 (confidentialité de R1). Le bilan contient la pathologie du patient, ses observations cliniques et ses objectifs de rééducation : ce sont des données de santé, donc des données sensibles au sens de l'article 9 du RGPD. Leur divulgation porterait atteinte à la vie privée du patient (un employeur ou un assureur qui apprendrait une pathologie, par exemple) et engagerait la responsabilité de Kinéo Santé, tenue au secret médical, avec un risque de sanction de la CNIL. Le niveau important est justifié.

A1.2 (disponibilité de R2 et R3). Si le planning du jour est indisponible (R2), le secrétariat ne sait plus quels patients arrivent, avec quel praticien et dans quelle salle : l'activité du centre est désorganisée immédiatement, des séances sont perdues ou doublonnées, et il n'existe pas de solution de repli simple. Le besoin est important. Si la vidéo d'exercices est indisponible (R3), le patient peut reporter sa séance à domicile ou suivre la fiche papier remise en séance ; la gêne est réelle mais différable, sans conséquence immédiate sur la prise en charge. Le besoin est modéré.

A2.1 (données personnelles et sensibles).

• Table Patient : id, nom, prenom, dateNaissance, telephone, mel et numeroSecu sont des données à caractère personnel ; idCentre et idReferent, rattachés à un patient identifié, le sont aussi indirectement.
• Table Bilan : toutes les colonnes rattachées à un patient (idPatient, dateBilan, pathologie, contenu) sont personnelles ; idPraticienModif est une donnée personnelle du praticien.
• Données sensibles : pathologie et contenu du bilan, qui sont des données concernant la santé (article 9 du RGPD). Par extension, le simple fait d'être patient d'un centre de rééducation révèle une information de santé.
• Le numéro de sécurité sociale (NIR) n'est pas une donnée sensible au sens de l'article 9, mais son usage est strictement encadré en France : la CNIL le considère comme une donnée particulière à protéger. Le mentionner est un plus.

A2.2 (hébergement). Deux obligations parmi :

• Recourir à un hébergeur certifié HDS (hébergeur de données de santé) : le Code de la santé publique (article L1111-8) impose cette certification à quiconque héberge des données de santé recueillies lors d'activités de soins pour le compte d'un tiers.
• Réaliser une analyse d'impact relative à la protection des données (AIPD) avant le traitement (article 35 du RGPD) : il s'agit de données sensibles traitées à grande échelle.
• Encadrer la sous-traitance par un contrat qui fixe les obligations de l'hébergeur en matière de sécurité, de confidentialité et d'assistance en cas de violation (article 28 du RGPD).
• Vérifier la localisation des données et, s'il y a des transferts hors de l'Union européenne, leur encadrement.

A3.1 (l'attaque). C'est une attaque par bourrage d'identifiants (credential stuffing) : l'attaquant essaie automatiquement des couples identifiant et mot de passe volés sur d'autres sites. Elle réussit parce que beaucoup d'utilisateurs réutilisent le même mot de passe sur plusieurs services : RééduPlan n'a pas besoin d'avoir été piraté, il suffit qu'un patient ait utilisé le même couple sur un site qui, lui, a fui.

A3.2 (deux mesures). Deux parmi :

• Authentification multifacteur : même avec le bon mot de passe, l'attaquant ne possède pas le second facteur (code envoyé ou généré sur le téléphone du patient).
• Limitation du nombre de tentatives par compte et par adresse IP, avec temporisation croissante ou blocage temporaire : l'automatisation de milliers d'essais devient impossible.
• Détection et alerte sur le volume d'échecs de connexion, pour réagir pendant l'attaque.
• Vérification des mots de passe contre les listes de mots de passe compromis à la création et au changement, avec une politique de longueur conforme aux recommandations de la CNIL.

B1.1. Les comptes apetit et cmorel ont la même empreinte : ils ont donc le même mot de passe. Un attaquant qui obtient la table le voit immédiatement et sait qu'en trouvant un mot de passe, il en a deux. Le stockage est insuffisant pour deux raisons : SHA-256 est une fonction rapide, qu'un processeur graphique calcule des milliards de fois par seconde, ce qui rend l'attaque par dictionnaire efficace ; et il n'y a pas de sel, donc deux mots de passe identiques donnent la même empreinte et les tables précalculées fonctionnent. C'est une défaillance cryptographique (A02:2021). Il faut une fonction lente et salée : bcrypt ou Argon2.

B1.2.

• Ligne 3 : supprimée. Le mot de passe n'est plus haché avant la requête : la vérification se fait après, en PHP.
• Lignes 4 et 5 (modifiées) : on cherche le compte par son identifiant seul, puisqu'une empreinte salée ne peut plus être comparée en SQL.

4.  $sql = "SELECT id, role, idCentre, empreinte FROM Compte
5.          WHERE login = :login";

• Ligne 7 (modifiée) : $stmt->execute([':login' => $login]);
• Ligne 9 (modifiée) : if ($compte && password_verify($_POST['mdp'], $compte['empreinte'])) {
• Après la ligne 9 (ajout, 9a) : session_regenerate_id(true);

password_verify relit l'algorithme, le coût et le sel dans l'empreinte stockée. session_regenerate_id(true) attribue un nouvel identifiant de session après la connexion, ce qui empêche la fixation de session. À l'inscription et au changement de mot de passe, l'empreinte est calculée par password_hash($mdp, PASSWORD_ARGON2ID). Les empreintes SHA-256 existantes doivent être migrées : par exemple, forcer la réinitialisation des mots de passe, ou recalculer l'empreinte au premier login réussi.

B1.3. Il a tort. La requête utilise des marqueurs nommés (:login, :empreinte) et les valeurs sont transmises séparément par execute() : une saisie ne peut pas modifier la structure de la requête. Le problème de cette page est le hachage, pas l'injection.

B2.1. Ligne 6, le déclencheur enregistre NEW.contenu, c'est-à-dire le contenu après modification, dans la colonne contenuPrecedent. L'ancienne version, OLD.contenu, n'est enregistrée nulle part : elle est perdue à chaque modification, et l'historique ne contient que des copies du contenu actuel.

B2.2. CURRENT_USER() renvoie le compte MySQL de la connexion. Or RééduPlan se connecte toujours avec le même compte, reeduplan_app : la colonne contient donc reeduplan_app@localhost pour toutes les modifications, quel que soit le praticien. L'historique ne permet pas d'imputer une modification à une personne, ce qui ruine le critère de preuve. L'identité du praticien est connue de l'application, qui la renseigne dans Bilan.idPraticienModif.

B2.3. Ligne 6 (modifiée) :

6.         VALUES (NEW.id, OLD.contenu, NOW(), NEW.idPraticienModif);

Amélioration possible de la ligne 4 : IF NOT (OLD.contenu <=> NEW.contenu) THEN. L'opérateur <=> compare aussi correctement les valeurs NULL, alors que <> renvoie NULL (donc faux) si l'un des contenus vaut NULL.

B3.1.

• test1 : un kinésithérapeute consulte un patient de son propre centre : autorisé.
• test2 : un kinésithérapeute consulte un patient d'un autre centre dont il n'est pas le référent : refusé.
• test3 : un kinésithérapeute consulte un patient d'un autre centre dont il est le référent : autorisé.
• test4 : un médecin-chef consulte un patient d'un autre centre : autorisé.

Cas non testé : un compte qui n'est ni kinésithérapeute ni médecin-chef, par exemple une secrétaire du centre du patient, doit être refusé. Sans ce test, une méthode qui autoriserait tout le centre, quel que soit le rôle, passerait les quatre tests.

B3.2.

public boolean peutConsulter(Patient unPatient) {
    if (this.role.equals("medecin-chef")) {
        return true;
    }
    if (unPatient.getLeReferent() != null
            && unPatient.getLeReferent().getId() == this.id) {
        return true;
    }
    return this.role.equals("kine")
        && unPatient.getLeCentre().getId() == this.leCentre.getId();
}

Le test getLeReferent() != null évite une NullPointerException pour un patient sans référent. Les chaînes se comparent avec equals, les identifiants entiers avec ==. La dernière condition vérifie le rôle et le centre : une secrétaire du même centre est refusée.

B4.1.

CREATE VIEW reeduplan.v_stats_seances AS
SELECT idCentre,
       DATE_FORMAT(dateHeure, '%Y-%m') AS mois,
       COUNT(*) AS nbSeances
FROM reeduplan.Seance
WHERE statut = 'REALISEE'
GROUP BY idCentre, DATE_FORMAT(dateHeure, '%Y-%m');

CREATE USER 'stats'@'10.8.0.12' IDENTIFIED BY 'mot_de_passe_long_et_aleatoire';
GRANT SELECT ON reeduplan.v_stats_seances TO 'stats'@'10.8.0.12';

La vue ne renvoie que des agrégats par centre et par mois : aucune donnée personnelle. Le compte n'est utilisable que depuis le serveur du service qualité et ne peut lire que la vue ; la vue s'exécutant avec les droits de son créateur, il n'a besoin d'aucun droit sur la table Seance. C'est l'application du moindre privilège.

C1.1. C'est un contrôle d'accès défaillant (A01:2021), sous la forme d'une référence directe non sécurisée à un objet (IDOR). Le middleware authentifie bien le patient 2207, mais la route utilise l'identifiant fourni dans l'URL (ligne 2) sans vérifier qu'il correspond au patient connecté. Tout patient authentifié peut lire les exercices de n'importe quel autre en changeant ce numéro ; or les exercices révèlent une information de santé.

C1.2. Après la ligne 2 (ajout, 2a à 2c) :

2a.  if (req.utilisateur.role !== 'patient' || Number(req.utilisateur.sub) !== idPatient) {
2b.    return res.status(403).json({ erreur: 'Accès refusé' });
2c.  }

L'identité vient du jeton vérifié (req.utilisateur.sub), jamais d'un paramètre modifiable par le client. Une variante, plus robuste encore, consiste à créer une route GET /api/moi/exercices qui n'accepte aucun identifiant et lit directement req.utilisateur.sub.

C1.3. a) 401 : pas authentifié. b) 403 : authentifié, mais pas autorisé pour cette ressource. c) 401 : un jeton expiré n'authentifie plus ; l'application doit en obtenir un nouveau avec son jeton de rafraîchissement.

C1.4. 1 806 000 900 − 1 806 000 000 = 900 secondes, soit 15 minutes. Le jeton d'accès accompagne chaque appel à l'API : il circule beaucoup et peut être intercepté ou lu sur un appareil compromis. Une durée courte limite le temps pendant lequel un jeton volé est utilisable. Le jeton de rafraîchissement, lui, n'est envoyé qu'au serveur d'authentification pour obtenir un nouveau jeton d'accès : il circule peu, peut être stocké de façon protégée sur le téléphone et révoqué côté serveur (perte du téléphone, changement de mot de passe). Ce couple évite de redemander le mot de passe au patient toutes les quinze minutes.

C2.1.

• Après la ligne 5 (ajout, 5a) : * @param string $adresseIP l'adresse IP du poste à l'origine de l'accès
• Ligne 7 (modifiée) : public function journaliserAcces(int $idCompte, int $idPatient, string $action, string $adresseIP): void {
• Lignes 8 et 9 (modifiées) :

8.     $sql = "INSERT INTO JournalAcces (idCompte, idPatient, action, dateHeure, adresseIP)
9.             VALUES (:compte, :patient, :action, NOW(), :ip)";

• Ligne 12 (modifiée) : ':action' => $action, ':ip' => $adresseIP]);

À l'appel : journaliserAcces($_SESSION['idCompte'], $idPatient, 'consultation', $_SERVER['REMOTE_ADDR']);. La requête reste préparée, le paramètre est documenté, et la trace contient l'auteur individuellement identifié, l'horodatage, la nature de l'opération, la référence des données concernées et l'équipement.

C2.2. La CNIL recommande d'enregistrer la référence des données concernées, pas les données elles-mêmes, et d'éviter de les dupliquer dans les journaux. Copier le bilan dans le journal créerait une seconde copie de données de santé, conservée plus longtemps et souvent moins protégée que la base : la surface d'exposition augmente sans aucun bénéfice, puisque idPatient suffit pour savoir quel dossier a été consulté. C'est aussi contraire au principe de minimisation (article 5 du RGPD).

C2.3.

SELECT c.login, COUNT(DISTINCT j.idPatient) AS nbDossiers
FROM JournalAcces j
JOIN Compte c ON c.id = j.idCompte
JOIN Patient p ON p.id = j.idPatient
WHERE j.action = 'consultation'
  AND DATE(j.dateHeure) = '2027-03-08'
  AND p.idCentre <> c.idCentre
GROUP BY c.id, c.login
HAVING COUNT(DISTINCT j.idPatient) > 3;

COUNT(DISTINCT j.idPatient) compte des dossiers différents : un dossier ouvert deux fois ne compte qu'une fois. Un COUNT(*) compterait des consultations, ce qui ne répond pas à la question. La condition sur le nombre va dans le HAVING, après le regroupement.

C2.4. Les deux lignes ne s'interprètent pas de la même façon. dsimon est médecin-chef : il supervise plusieurs centres et la règle d'accès l'autorise à consulter tous les dossiers ; ses quatre consultations peuvent être légitimes, à vérifier avec son activité du jour. apetit est kinésithérapeute à Rennes et a consulté quatre dossiers de patients d'autres centres : c'est légitime seulement s'il est leur référent. Sinon, soit le contrôle d'accès de RééduPlan est défaillant (il n'aurait pas dû pouvoir les ouvrir), soit son compte est utilisé par quelqu'un d'autre. Il faut croiser avec Patient.idReferent, interroger le praticien et, si l'accès était illégitime, traiter l'événement comme une violation de données de santé. La requête affinée exclurait les médecins-chefs et les patients dont le compte est le référent.

C2.5. La CNIL recommande une durée comprise entre six mois et un an dans le cas général (délibération n° 2021-122). Mesures d'intégrité, deux parmi : stocker les journaux sur un système séparé, accessible en écriture seule par l'application et sans possibilité d'écrasement ; horodater et signer les journaux dès leur création ; réserver la lecture à quelques personnes habilitées et alerter en cas d'accès en modification ; sauvegarder les journaux.