Analyse de risques & conformité réglementaire de mon projet HealthNorth

Contexte

Dans le cadre de ce projet, j’endosse le rôle d’une consultante en cybersécurité mandatée pour auditer le SI de HealthNorth. Après avoir conçu et développé l’application, puis réalisé un test d’intrusion en whitebox, j’ai conduit cette analyse de risques selon la méthodologie ISO 27005, avec deux objectifs : prévenir tout incident lié à la nature sensible des données traitées (données de santé, art.9 RGPD), et établir un socle de bonnes pratiques de sécurité avant toute mise en production réelle.

Cette analyse a été conduite dans une logique volontairement distincte du développement : HealthNorth a d’abord été pensée fonctionnellement (projet E6 du BTS SIO), avant qu’une démarche sécurité ne lui soit appliquée a posteriori un cas fréquent en entreprise sur des applications en MVP ou legacy. Les scénarios identifiés ont ensuite été confrontés au réel via un pentest whitebox.

L’application est composée de quatre éléments déployés en production sur AlwaysData :

App web PHP (architecture MVC)
API REST FastAPI avec authentification
Application mobile React Native
Base de données MySQL

Valeurs métier

Avant d’analyser les biens supports, j’identifie les valeurs métier que le SI doit protéger :

Valeur métier	Description
Continuité des soins	Les médecins et patients doivent pouvoir accéder aux dossiers à tout moment
Confidentialité médicale	Secret médical, données sensibles RGPD
Intégrité des informations médicales	Une prescription ou un diagnostic modifié peut avoir un impact direct sur la santé
Conformité réglementaire	RGPD, obligation HDS pour un hébergement réel de données de santé

Socle de sécurité grille DICP

Évaluation des besoins de sécurité par bien support. Échelle : 1 = négligeable, 2 = limité, 3 = important, 4 = critique.

Bien support	D	I	C	P	Commentaire
Données de santé	3	4	4	2	Données sensibles art.9 RGPD, impact direct sur la santé en cas d’altération
Données personnelles	2	3	3	2	Données classiques RGPD,risque d’usurpation en cas de fuite
Comptes utilisateurs	3	4	4	2	Clé d’accès à toutes les données, compromission = accès total
Base de données MySQL	3	4	4	2	Contient l’ensemble des données, dump = compromission totale
Serveur AlwaysData	3	3	4	2	Héberge tous les autres biens supports
API FastAPI	3	3	3	2	Point d’entrée principal de l’app mobile
App PHP web	2	3	2	1	Vecteur d’attaque côté client (XSS, injection)
App mobile React Native	2	2	2	1	Surface d’attaque limitée au device

Constat durant whitebox : la colonne P (Preuve) est à 2 maximum sur l’ensemble des biens supports. Il n’existe pas de traçabilité applicative (pas de table d’audit user_id / action / ressource / timestamp). Les logs disponibles sont les logs d’erreur PHP d’AlwaysData, utiles pour le débogage, insuffisants pour l’accountability RGPD.

Identification et évaluation des risques

Matrice de criticité

Criticité = Vraisemblance (V) × Gravité (G), échelle 1 à 4.

	G1 — Négligeable	G2 — Limité	G3 — Important	G4 — Critique
V4 — Très probable	Modéré	Élevé	Critique	Critique
V3 — Probable	Modéré	Élevé	Élevé	S1, S2, S3
V2 — Peu probable	Faible	Modéré	S4	Élevé
V1 — Rare	Faible	Faible	Modéré	Modéré

Scénario 1 — Compromission des comptes via mots de passe en clair


Actif ciblé	Base de données MySQL + comptes utilisateurs
Menace	Attaquant externe
Vulnérabilité	Mots de passe stockés sans hachage (en clair) en base
Événement redouté	Exfiltration de la base → tous les mots de passe immédiatement exploitables, sans effort de craquage
DICP impacté	I, C
Vraisemblance	3, un attaquant ayant accès à la base (via injection SQL ou phpMyAdmin exposé) obtient les mots de passe sans aucun obstacle
Gravité	4, données de santé + risque de réutilisation des mots de passe sur d’autres services
Criticité	Élevée
Parade	Hachage avec `password_hash()` (bcrypt) à l’inscription + `password_verify()` à la connexion. Reset forcé des comptes existants.

Scénario 2 — Accès non autorisé aux dossiers patients (IDOR)


Actif ciblé	API FastAPI + données de santé
Menace	Utilisateur malveillant authentifié
Vulnérabilité	Absence de vérification des autorisations sur les endpoints, un utilisateur authentifié peut accéder aux ressources d’un autre utilisateur en manipulant les identifiants dans les requêtes
Événement redouté	Un patient consulte les dossiers médicaux d’un autre patient
DICP impacté	C
Vraisemblance	3, exploitable par tout utilisateur authentifié sans compétences techniques avancées
Gravité	4, violation directe du secret médical et de la confidentialité des données de santé
Criticité	Élevée
Parade	Vérification systématique que `user_id` du token correspond à la ressource demandée. Tests d’autorisation automatisés sur chaque endpoint sensible.

Scénario 3 — Injection SQL sur l’application PHP


Actif ciblé	App PHP web + base de données MySQL
Menace	Attaquant externe
Vulnérabilité	Requêtes SQL non préparées, confirmé par le test d’intrusion réalisé sur l’application
Événement redouté	Exfiltration ou destruction complète de la base de données
DICP impacté	D, I, C
Vraisemblance	3, outils d’exploitation automatisés disponibles publiquement (SQLmap), faille détectée en pentest
Gravité	4, accès total à la base, compromission de toutes les données de santé
Criticité	Élevée
Parade	Remplacement de toutes les requêtes dynamiques par des requêtes préparées (PDO + `bindParam`). Tests d’injection réguliers (minimum tous les 6 mois).

Scénario 4 — Indisponibilité du service (panne hébergeur)


Actif ciblé	Serveur AlwaysData
Menace	Panne technique, incident hébergeur
Vulnérabilité	Absence de sauvegarde hors-site, point de défaillance unique, toute l’infrastructure repose sur un seul hébergeur
Événement redouté	Interruption totale du service, accès aux dossiers médicaux impossible
DICP impacté	D
Vraisemblance	2, les pannes hébergeur restent rares mais non nulles (Cloudflare par exemple plusieurs fois cette année)
Gravité	3, impact direct sur la continuité des soins
Criticité	Modérée
Parade	Mise en place de sauvegardes hors-site automatisées (minimum 1 backup quotidien). Plan de reprise d’activité.

Plan de traitement priorisé

Priorité	Scénario	Criticité	Action	Délai
1	S1 — Mots de passe en clair	Élevée	Implémenter `password_hash()` + reset comptes	Court terme (< 1 mois)
2	S3 — Injection SQL	Élevée	Requêtes préparées sur toute l’app PHP	Court terme (< 1 mois)
3	S2 — IDOR	Élevée	Contrôle d’autorisation sur tous les endpoints API	Court terme (< 2 mois)
4	S4 — Indisponibilité	Modérée	Sauvegardes hors-site + plan de reprise	Moyen terme (< 3 mois)

Limites réglementaires identifiées

AlwaysData non certifié HDS : en France, tout hébergement de données de santé à caractère personnel est soumis à la certification HDS (Hébergeur de Données de Santé) délivrée par l’ANS. AlwaysData ne dispose pas de cette certification. Dans un contexte de production réel, HealthNorth devrait migrer vers un hébergeur certifié HDS (ex : OVHcloud HDS, Outscale, Scaleway Health).

Absence de traçabilité applicative : aucune table d’audit n’est implémentée. Cela constitue un manquement au principe d’accountability et rend impossible toute investigation en cas d’incident de sécurité.

Données de santé fictives : les données manipulées dans ce projet sont fictives. Les niveaux de gravité retenus reflètent le contexte d’une mise en production réelle, conformément à l’objectif pédagogique de l’analyse.

Analyse d’Impact sur la Protection des Données (AIPD)

Le traitement de données de santé (art.9 RGPD) impose la réalisation d’une AIPD avant toute mise en production. Voici une version synthétique appliquée à HealthNorth.

Description du traitement

Élément	Détail
Finalité	Gestion de rendez-vous médicaux et suivi des dossiers patients
Responsable de traitement	HealthNorth
Données traitées	Identité, coordonnées, données de santé (dossiers, prescriptions)
Personnes concernées	Patients (environs une dizaine), médecins (2-3), secrétaires (2-3)
Durée de conservation	6 mois (données de test en production : durée légale dossier médical = 20 ans)
Sous-traitant	AlwaysData (hébergeur)

Base légale

Constat : aucune base légale n’a été formalisée dans l’application. Tout utilisateur peut s’inscrire comme médecin sans vérification ce qui constitue une non-conformité majeure.

Recommandation : dans un contexte réel, la base légale applicable serait l’art. 9.2.h RGPD traitement nécessaire à des fins médicales, réalisé par un professionnel de santé soumis au secret médical. Cela implique :

Vérification du statut professionnel à l’inscription (numéro RPPS pour les médecins)
Information claire des patients sur leurs droits (art.13 RGPD)
Désignation d’un DPO si le traitement est réalisé à grande échelle

Évaluation des risques sur les droits et libertés

Risque	Scénario associé	Impact sur les personnes
Accès non autorisé aux données de santé	S2 — IDOR	Violation du secret médical, atteinte à la vie privée
Compromission des comptes	S1 — Mots de passe en clair	Usurpation d’identité, accès aux dossiers d’autrui
Destruction/altération des données	S3 — Injection SQL	Perte de l’historique médical, risque pour la santé
Indisponibilité du service	S4 — Panne hébergeur	Interruption de la continuité des soins

Mesures envisagées

Mesure	Objectif	Référence
Hachage des mots de passe (bcrypt)	Réduire l’impact d’une fuite de base	S1
Contrôle d’autorisation sur les endpoints	Empêcher l’accès aux données d’autrui	S2
Requêtes préparées (PDO)	Bloquer les injections SQL	S3
Sauvegardes hors-site	Garantir la continuité des soins	S4
Migration vers hébergeur certifié HDS	Conformité réglementaire obligatoire	Limites identifiées
Mise en place d’une table d’audit	Accountability RGPD art.5.2	Constat transversal

Résultats

Deux vulnérabilités ont été identifiées et traitées dans le cadre de ce projet :

Affichage défaillant du dossier patient (dossier.php)

Avant : variable $patient non définie dans certains cas → affichage en échec, warnings répétés dans les logs PHP AlwaysData. Risque secondaire d’information disclosure si display_errors avait été actif en production.
Après : contrôle de nullité ajouté avant affichage, logs assainis, display_errors vérifié à Off.

Recommandations restantes : les scénarios S1, S2 et S3 (criticité élevée) constituent le plan d’action prioritaire à mettre en œuvre avant toute mise en production réelle de l’application.