Cas pratiques corrigés type E7

• Disponibilité : 3. La paie doit être versée à date fixe chaque mois ; une interruption de quelques jours est supportable en dehors de la période de calcul, pas pendant.
• Intégrité : 4. Une erreur ou une modification malveillante (un RIB changé, un salaire modifié) a des conséquences financières et sociales directes pour les agents.
• Confidentialité : 4. L'annexe 1 montre des données très sensibles : numéro de sécurité sociale, RIB, salaire et arrêts maladie, qui sont des données de santé (article 9 du RGPD).

On peut ajouter Preuve : 3 : il faut pouvoir retracer qui a modifié une fiche de paie.

Une même adresse IP externe (198.51.100.23) a tenté 2 312 ouvertures de session sur le compte administrateur en un peu plus d'une heure et demie, en pleine nuit (événements 4625) : c'est une attaque par force brute sur le bureau à distance. À 4 h 47, une tentative réussit (4624), et cinq minutes plus tard l'attaquant crée un compte svc-backup2 (4720), dont le nom imite un compte de service pour passer inaperçu : c'est une persistance, qui lui permettra de revenir même si le mot de passe de l'administrateur est changé.

L'attaquant contrôle le serveur de paie : il peut lire les données des agents (confidentialité), les modifier (intégrité) ou chiffrer le serveur (disponibilité), et tenter de rebondir vers le reste du réseau.

Constats en cause (annexe 2) : le RDP exposé sur Internet, un mot de passe inchangé depuis 2021 sur un compte au nom prévisible (administrateur), et l'absence de verrouillage après des échecs répétés, qui a laissé 2 312 tentatives se dérouler sans obstacle.

Menace : un groupe cybercriminel qui déploie un rançongiciel (scénario rendu crédible par l'intrusion du 14 mars). Vulnérabilité : les sauvegardes sont sur un NAS joint au domaine, dans la même salle que les serveurs, sans copie hors ligne ni hors site, et jamais testées. Actif : l'ensemble des données de la mairie (état civil, paie, portail citoyen, fichiers). Impact : un attaquant qui obtient les droits d'administrateur du domaine chiffre ou efface le NAS en même temps que les serveurs. La mairie perd toutes ses données sans possibilité de restauration : atteinte majeure à la disponibilité et à l'intégrité, arrêt des services aux habitants, violation de données à notifier. Un incendie de la salle serveur aurait le même effet.

1. Confiner : couper l'accès RDP depuis Internet, isoler le serveur de paie du réseau sans l'éteindre, désactiver le compte svc-backup2 et changer le mot de passe du compte administrateur.
2. Alerter la direction générale des services et ouvrir un journal de bord de l'incident.
3. Préserver les preuves : exporter les journaux du serveur et du pare-feu, calculer leur empreinte, noter chaque action.
4. Chercher l'étendue de la compromission : autres connexions de l'adresse 198.51.100.23, autres comptes créés, mouvements vers d'autres serveurs, données consultées ou exfiltrées.
5. Se faire assister : le CSIRT régional ou 17Cyber (Cybermalveillance.gouv.fr) pour une collectivité de cette taille, et le prestataire de réponse à incident si la mairie en a un.
6. Notifier la CNIL : les données des agents (dont des données de santé) ont pu être consultées par l'attaquant, donc avant le 19 mars à 10 h (72 heures après la prise de connaissance). Selon ce que révèle l'enquête, informer les agents.
7. Porter plainte (accès frauduleux et maintien dans un système, article 323-1 du Code pénal), dans les 72 heures si la mairie veut être indemnisée par son assurance.
8. Avant toute remise en service, éradiquer (supprimer ce que l'attaquant a installé, ou reconstruire le serveur) et refermer la porte d'entrée.

Une proposition qui respecte la règle 3-2-1-1-0 et un RPO d'une demi-journée :

• Fréquence : deux sauvegardes par jour ouvré (12 h 30 et 23 h) des serveurs de fichiers, de paie et d'état civil, ce qui limite la perte à une demi-journée ; sauvegarde complète hebdomadaire et incrémentales le reste du temps.
• Copie 1 : le NAS local, sorti du domaine, accessible uniquement par le logiciel de sauvegarde avec un compte dédié, pour des restaurations rapides.
• Copie 2, hors site et immuable : une réplication chiffrée vers un stockage externe (prestataire ou NAS dans un autre bâtiment municipal) avec une immutabilité de 30 jours : personne, même un administrateur, ne peut la modifier ou la supprimer pendant ce délai.
• Copie hors ligne : une copie mensuelle sur disque ou bande déconnectés, conservée dans un coffre.
• Rétention : 14 sauvegardes quotidiennes, 8 hebdomadaires, 12 mensuelles, pour pouvoir remonter avant une compromission ancienne.
• Tests : une restauration test chaque mois, avec un compte rendu (durée, données vérifiées) comparé au RTO souhaité.

• Séparer les comptes : chaque technicien reçoit un compte d'administration nominatif (par exemple adm-hbernard), utilisé uniquement pour administrer, sans messagerie ni navigation ; son compte habituel sort du groupe « Admins du domaine ». Un hameçonnage réussi ne livrera plus les droits d'administration du domaine (règles d'hygiène de l'ANSSI sur l'administration).
• Accès du prestataire : supprimer le RDP exposé ; accès par VPN avec MFA, compte nominatif du prestataire, activé seulement pendant ses interventions, actions journalisées.
• Verrouillage : verrouiller le compte après 10 échecs au plus (ou temporisation croissante), ce qui place la mairie dans le cas « mot de passe avec restriction d'accès » de la CNIL (50 bits).
• Longueur plutôt que renouvellement : passer à au moins 12 caractères, refuser les mots de passe courants, et supprimer le renouvellement tous les 30 jours pour les comptes ordinaires, déconseillé par la CNIL car il pousse à des mots de passe prévisibles ; le garder pour les comptes à privilèges.
• MFA sur la messagerie et sur tous les accès distants.

Actions (exemples) :

1. Mois 1 : réunion de la direction générale pour expliquer l'incident de mars (sans désigner personne) et annoncer le plan ; message du maire ou du directeur général des services.
2. Mois 2 : session obligatoire de 45 minutes par service sur l'hameçonnage, les mots de passe et le signalement, avec des exemples tirés de messages reçus par la mairie.
3. Mois 3 à 12 : un « point cyber » mensuel par courriel (un sujet, un geste) et des affiches près des imprimantes ; module SecNumacadémie de l'ANSSI proposé à tous.
4. Tous les trimestres : un exercice de faux hameçonnage avec page pédagogique, suivi d'un bilan collectif.
5. Actions ciblées : les agents des ressources humaines et des finances (fraude au changement de RIB), les agents d'accueil (appels de faux techniciens), les élus.
6. Charte informatique mise à jour, présentée et signée par tous les agents, avec un bouton « Signaler » ajouté dans la messagerie.

Indicateurs : taux de participation aux sessions, taux de clic et surtout taux de signalement lors des exercices, nombre de signalements spontanés au service informatique.

1. Injection SQL : l'adresse est concaténée dans la requête. Avec contact@pharmacie-des-alpes.example' -- dans le champ email (attention à l'espace après les deux tirets), la vérification du mot de passe passe en commentaire : l'attaquant se connecte au compte de son choix sans connaître le mot de passe. ' OR 1=1 LIMIT 1 -- ouvre même le premier compte de la table (le LIMIT 1 est nécessaire, car le code exige exactement une ligne : sans lui, la requête renverrait les 1 900 clients et la connexion échouerait). Confidentialité et intégrité de toute la base.
2. Hachage SHA-1 sans sel : fonction rapide et obsolète. Si la base est volée, les mots de passe sont cassés en masse hors ligne. Confidentialité.
3. Limitation des tentatives inefficace : le compteur est stocké dans la session ; il suffit de supprimer le cookie de session pour le remettre à zéro, et il ne bloque rien de toute façon. Force brute et bourrage d'identifiants possibles. Confidentialité.
4. Pas de régénération de l'identifiant de session après connexion : risque de fixation de session. Confidentialité.
5. Toute la ligne du client (y compris le hachage du mot de passe) est placée en session, et SELECT * récupère des colonnes inutiles : contraire à la minimisation.

$stmt = $pdo->prepare('SELECT id, raison_sociale, mdp FROM client WHERE email = ?');
$stmt->execute([$_POST['email'] ?? '']);
$client = $stmt->fetch();

if ($client && password_verify($_POST['mdp'] ?? '', $client['mdp'])) {
    session_regenerate_id(true);
    $_SESSION['id_client'] = $client['id'];
    $_SESSION['raison_sociale'] = $client['raison_sociale'];
    header('Location: /commandes');
    exit;
}
echo 'Identifiant ou mot de passe incorrect';

La requête préparée bloque l'injection, password_verify() compare avec un hachage lent et salé, la session est régénérée et ne contient que le nécessaire, le message reste générique. La limitation des tentatives doit être stockée côté serveur (une table des échecs par compte et par adresse IP, avec temporisation croissante et verrouillage après 10 échecs), et la migration des anciens hachages SHA-1 se fait à la prochaine connexion réussie de chaque client.

• Clients : proposer la MFA par application d'authentification (TOTP) ou, mieux, par clé d'accès (passkey), et l'imposer au moins pour les actions sensibles (modification des coordonnées, export des factures). Le SMS reste une solution de repli acceptable pour des pharmacies peu équipées, mais il est le moins robuste.
• Administrateurs : MFA obligatoire et résistante à l'hameçonnage (clés de sécurité FIDO2 ou clés d'accès), car un compte d'administration compromis donne accès à toutes les données des 1 900 clients, dont des données de santé ; accès à l'interface d'administration limité au réseau interne ou au VPN.

C'est une fraude au changement de RIB par hameçonnage, qui usurpe l'identité numérique de Soléane, doublée d'un faux site (extranet-soleane-medical.com, un domaine sosie) destiné à voler les identifiants des clients.

Le champ « De » d'un courriel peut contenir n'importe quelle adresse. Le SPF seul ne suffit pas : sans DMARC, les serveurs destinataires ne savent pas qu'ils doivent rejeter un message qui affiche @soleane-medical.fr mais échoue aux contrôles.

Mesures techniques : publier un enregistrement DMARC (d'abord p=none pour analyser les rapports, puis p=reject) et signer les courriels en DKIM ; demander la suspension du domaine extranet-soleane-medical.com à son bureau d'enregistrement et surveiller les domaines ressemblants.

Communication : prévenir tous les clients par un canal sûr (bannière sur l'extranet, appel des commerciaux) que Soléane ne change pas de coordonnées bancaires par courriel et que toute demande doit être vérifiée par téléphone auprès de leur contact habituel.

Le journal indique qui (un identifiant), quand et quoi, mais il manque des éléments pour prouver et enquêter :

• l'adresse IP et le navigateur ou l'appareil d'origine, pour savoir si la connexion venait des locaux de la pharmacie ou d'ailleurs ;
• le résultat de l'action (succès ou échec) et les échecs de connexion ;
• le fuseau horaire de l'horodatage (idéalement en UTC, sur un serveur synchronisé par NTP) ;
• le détail de l'export (quelles factures, combien de lignes).

Il faut aussi garantir son intégrité : aujourd'hui, le compte de l'application peut sans doute modifier ou supprimer des lignes de la table. Proposition : le compte applicatif n'a que le droit INSERT sur la table journal (ni UPDATE ni DELETE), les journaux sont copiés régulièrement vers un serveur centralisé, et leur durée de conservation est fixée (entre six mois et un an, comme le recommande la CNIL pour ce type de journaux).

C'est une violation de données personnelles (accès non autorisé et divulgation). Les références de matériel médical prescrit associées à des noms révèlent des informations sur la santé des personnes : le risque est élevé.

• Documenter la violation dans le registre interne (article 33, paragraphe 5 du RGPD).
• Notifier la CNIL dans les 72 heures après en avoir pris connaissance (article 33), en décrivant la nature de la violation, le nombre approximatif de personnes et d'enregistrements (412 factures), les conséquences probables et les mesures prises.
• Informer les personnes concernées dans les meilleurs délais, en raison du risque élevé (article 34). Soléane travaille avec la pharmacie, qui est en relation avec ses propres clients, et avec son délégué à la protection des données.
• Porter plainte pour accès frauduleux et usurpation d'identité, et prévenir l'assureur.
• Mesures correctives : réinitialiser le mot de passe de l'utilisateur 17, invalider ses sessions, imposer la MFA, et traiter les causes (DMARC, faux domaine, sensibilisation des clients).