Sécuriser dès la conception

1 → D ; 2 → F ; 3 → E ; 4 → I ; 5 → G ; 6 → B ; 7 → J ; 8 → A ; 9 → C ; 10 → H.

a) Ces phrases décrivent une intention, pas une condition : « sécurisée », « bonnes personnes », « bien gérées » ne disent ni ce qui doit être refusé, ni à qui, ni comment le vérifier. Aucun test ne peut prouver qu’elles ne sont pas respectées : elles ne protègent donc rien et ne peuvent pas fonder une réserve à la recette.

b) Une réponse possible :

c) US7 — En tant que responsable technique, je veux suspendre les plans d’un établissement pendant sa fermeture afin de ne pas générer de contrôles inutiles.

• Scénario 1 : Étant donné Franck Guillou connecté avec le profil Responsable et le plan « Contrôle mensuel ascenseur A » actif, quand il suspend le plan, alors le plan passe à l’état « suspendu », aucune intervention n’est générée pendant la suspension et l’action est journalisée.
• Scénario 2 (sécurité) : Étant donné Mathis Le Goff connecté avec le profil Technicien, quand il envoie au serveur une demande de suspension du même plan, alors la demande est refusée, le plan reste actif et le refus est journalisé.

d) Cas d’abus : « En tant que technicien en retard sur ses contrôles, je veux suspendre les plans en retard afin qu’ils n’apparaissent plus en orange. » Exigences qui y répondent : EXS-10 (seul le Responsable suspend) et EXS-13 (toute suspension est tracée) ; on peut ajouter une règle : « une suspension porte une date de fin obligatoire et un motif ».

a) Total = 70 + 183 + 92 = 345 exigences.

• L1 : 70 ÷ 345 = 20,3 % ;
• L2 : 183 ÷ 345 = 53,0 % ;
• L3 : 92 ÷ 345 = 26,7 %.

b) Niveau 2 = L1 + L2 = 70 + 183 = 253 exigences, soit 253 ÷ 345 = 73,3 % du total. (L’ASVS annonce « environ 70 % » : le calcul le confirme.)

c) KerResa est exposée sur Internet et traite les données des clients : L2. KerMaint est interne et ne traite pas de données de clients (les noms des techniciens sont des données de salariés) : L1, complété des exigences L2 que la modélisation des menaces rend utiles (journalisation, gestion des erreurs, secrets). Le niveau se justifie par l’exposition et la sensibilité des données, pas par la taille de l’application.

d) Date limite = date de publication + délai de la politique.

e) Ordre : C d’abord (déjà hors délai : non-conformité à la politique, à régulariser et à signaler à Anaïs), puis A (critique, demain), puis B, enfin D. On peut défendre A avant C si la faille A est activement exploitée et le composant exposé : la gravité réelle compte plus que l’ordre administratif ; il faut alors l’écrire.

a) Défauts relevés :

b) La préparation protège les valeurs transmises par execute() : elles ne peuvent pas devenir du SQL. Mais ici les noms de colonnes sont collés dans le texte de la requête à partir des clés envoyées par l’utilisateur : cette partie n’est pas protégée par la préparation, et l’utilisateur décide des colonnes écrites. Une requête préparée doit avoir un texte fixe, écrit par le développeur.

c) Version corrigée, qui réutilise les modules communs du cours :

<?php
declare(strict_types=1);
require __DIR__ . '/erreurs.php';      // pas d'affichage d'erreur, journal + référence
require __DIR__ . '/config.php';       // secrets lus dans l'environnement
require __DIR__ . '/droits.php';       // refus par défaut
require __DIR__ . '/validation.php';   // normalisation + liste blanche

function enregistrerPlan(PDO $pdo, ?string $profil, array $saisie): string
{
    if (!peutFaire($profil, 'gerer_plan')) {
        return 'refusé : droit insuffisant';
    }
    [$plan, $erreurs] = validerPlan($saisie);
    if ($plan === null) {
        return 'refusé : ' . implode(' ', $erreurs);
    }
    $req = $pdo->prepare('INSERT INTO plan_preventif (id_equip, libelle, periodicite, prochaine_echeance, actif)
                          VALUES (:id_equip, :libelle, :periodicite, :premiere_echeance, 1)');
    $req->execute($plan);              // seuls les champs validés partent vers la base
    return 'enregistré (plan ' . $pdo->lastInsertId() . ')';
}

En production, la connexion est ouverte avec le compte kermaint_app et le mot de passe obtenu par parametresBase(). Pour l’essai, la fonction est appelée sur une base SQLite en mémoire qui contient la table plan_preventif :

Responsable           : enregistré (plan 1)
Technicien            : refusé : droit insuffisant
Consultation          : refusé : droit insuffisant
Responsable + "actif" : refusé : Champ non prévu : actif
Lignes en base        : 1

Les essais prouvent : un essai positif (le Responsable enregistre), deux essais négatifs de droits (Technicien, Consultation), un essai négatif de validation (champ ajouté), et le contrôle final qu’une seule ligne a été écrite. Le texte de la requête est fixe ; la valeur de actif est imposée par le code (1, sécurité par défaut). Il resterait à journaliser la création (EXS-03).

a) Diagramme de flux de données :

• traitement : la tâche nocturne (planifiée à 5 h sur KV-KERMAINT) ;
• stockages : la base kermaint (lecture des plans, écriture des interventions) ; le fichier de journal de la tâche ;
• entités externes : le serveur de messagerie ; le responsable technique (destinataire des courriels) ; le planificateur du système (qui déclenche la tâche) ;
• flux : plans → tâche ; tâche → interventions ; tâche → journal ; tâche → messagerie → responsable ;
• frontières de confiance : entre la tâche et la base (compte applicatif), entre le serveur et la messagerie (sortie vers un autre système), et entre le journal et les autres comptes du serveur (le journal est lisible par tous : la frontière n’est pas protégée).

b) et c) Criticité = G × V ; classement par criticité puis par gravité.

À criticité égale (3), f passe avant e, car sa gravité est plus forte.

d) Mesures :

a) Kervanet décide de la finalité (traiter les réclamations, informer le client) : elle est responsable du traitement. Vellacor, qui développe et héberge KerMaint pour son compte, est sous-traitant. L’article 25 vise le responsable, mais Vellacor a une obligation de conseil (CEJMA-03) et doit offrir des garanties suffisantes : livrer une conception manifestement contraire à la protection par défaut engagerait sa responsabilité contractuelle (CEJMA-08).

b)

c) Non. Par défaut, aucun courriel n’est envoyé : le réceptionniste demande au client s’il souhaite être informé, et coche la case avec son accord (ou le client le demande dans l’application). C’est la logique de la protection par défaut : le traitement supplémentaire (envoyer un courriel) exige une action, il n’est pas imposé.

d) En tant qu’administrateur fonctionnel de Kervanet, je veux extraire toutes les données de réclamation liées à un client afin de répondre à sa demande d’accès dans le délai d’un mois.

• Étant donné un client ayant deux réclamations (une ouverte, une clôturée), quand l’administrateur lance l’export à partir du numéro de réservation ou de l’identifiant du client, alors un fichier JSON contient les deux réclamations avec leurs dates, motifs, statuts et le choix d’information par courriel, et l’export est journalisé.
• Étant donné un utilisateur du profil Technicien, quand il tente de lancer l’export, alors l’export est refusé.

a) Âge = 20/10/2026 − date de publication ; limite = publication + délai de la politique.

Le contrôle de Sarah (cours, partie 6) appliqué à ces données donne :

AVIS-2026-0064  exemple/client-http    5.2.0   À METTRE À JOUR en 5.2.3 (élevée, avis de 61 j, délai 30 j : DÉPASSÉ)
AVIS-2026-0098  exemple/planificateur  2.3.0   À METTRE À JOUR en 2.3.2 (moyenne, avis de 36 j, délai 90 j : reste 54 j)
AVIS-2026-0121  exemple/journal-psr    3.0.4   corrigé (>= 3.0.4)
code retour : 1

b) Sans composer.lock versionné, chaque installation choisit « la dernière version compatible » au moment où elle est faite : la recette et la production peuvent avoir des versions différentes, la production peut recevoir une version jamais testée (voire une version piégée publiée la veille), et l’inventaire n’est plus fiable (impossible de savoir quelle version tourne où). Le fichier de verrouillage garantit que l’on livre ce qui a été testé et rend la veille possible.

c)

Calcul de l’indicateur : 4 ÷ 11 = 36,4 % de fusions sans approbation.

d) Priorités : 1. rotation des secrets du .env (déjà divulgués) ; 2. mise à jour de client-http (hors délai) ; 3. versionner composer.lock et ajouter les contrôles au pipeline ; 4. supprimer le push direct ; 5. règle et suivi des approbations ; 6. mise à jour de planificateur avant le 13/12/2026.

Message possible :

Anaïs, audit de la chaîne KerResa du 20/10. Urgent : le fichier .env de recette est versionné depuis juin ; je propose de changer aujourd’hui tous les secrets de recette et de vérifier qu’aucun n’est réutilisé en production. client-http 5.2.0 porte un avis élevé hors délai depuis le 19/09 : mise à jour en 5.2.3 à tester en recette cette semaine. Ensuite : versionner composer.lock, ajouter composer audit et la détection de secrets au pipeline, retirer le push direct sur main. 4 fusions sur 11 en septembre n’avaient pas d’approbation : je propose que seuls Romain et toi fusionniez. planificateur est à mettre à jour avant le 13/12. Détail en pièce jointe. Sarah

a) Le fichier n’existe plus dans la version actuelle (« non »), mais la recherche git log -S le retrouve dans deux commits : celui qui l’a ajouté et celui qui l’a retiré, et le contenu du mot de passe s’affiche encore. Un commit de suppression ajoute une nouvelle version sans effacer les anciennes : toute copie du dépôt (6 postes, sauvegardes, forge) contient le secret depuis mars 2025. Le risque n’a pas disparu le 02/04/2025 : il a seulement été caché.

b) Changer le mot de passe du compte de la base de recette (et de tout compte qui l’utiliserait) : c’est la seule action qui rend le secret divulgué inutilisable. Toutes les autres (enquête, nettoyage) prennent du temps ; pendant ce temps, le secret resterait valable.

c) Ordre proposé :

1. Rotation du mot de passe de la base de recette par l’administrateur (Thomas Guéguen, sur demande d’Anaïs), nouveau secret rangé dans le gestionnaire de secrets ; vérification que l’ancien environnement de test n’existe plus ou que son mot de passe a aussi changé.
2. Recherche de réutilisation : ce mot de passe sert-il ailleurs, notamment en production ? (Sarah et Thomas) Si oui, rotation immédiate là aussi.
3. Vérification des journaux de la base de recette depuis mars 2025, dans la limite de leur conservation : connexions inhabituelles avec ce compte (Thomas).
4. Ticket de sécurité et information d’Anaïs Lecoq ; si une utilisation frauduleuse touchant des données personnelles apparaissait, alerte de Kervanet selon l’accord de sous-traitance (B3-02).
5. Nettoyage de l’historique, si l’équipe le décide (réécriture de l’historique et nouvelle copie sur tous les postes) : utile mais secondaire, puisque le secret est déjà changé.
6. Prévention : crochet pre-commit sur les postes, détection de secrets dans le pipeline, analyse unique de tout l’historique, un secret différent par environnement (Sarah, validé par Anaïs).
7. Retour d’expérience : mise à jour de la charte de développement et du registre des risques de Vellacor (risque « secrets dans GitLab », B3-01).

d)

e) Non : avec des données réelles, la fuite d’un accès à la base aurait pu permettre une violation de données personnelles, à évaluer avec le DPO de Kervanet et peut-être à notifier ; l’anonymisation de la recette (et l’absence de données réelles hors production) réduit fortement la gravité.

Mission 1 — Les exigences

1.1 Niveau L2 de l’ASVS : la fonction est exposée sur Internet (API KerResa, document 1) et traite des données de clients (séjour, chambre, description) ; c’est la règle de la charte de Vellacor (document 5).

1.2 Exigences possibles :

1.3 Étant donné un client connecté dont le séjour en cours est la chambre 214 du Phare de Royan, quand l’application envoie un signalement contenant la chambre 101, alors le signalement est refusé et aucune intervention n’est créée.

Mission 2 — La modélisation des menaces

2.1 Entités externes : client (application mobile), réceptionniste et technicien (KerMaint). Traitements : API KerResa (exposée sur Internet) ; KerMaint (interne). Stockages : base de KerResa (séjours), base de KerMaint (interventions), journaux. Flux : application → KerResa (signalement) ; KerResa → base KerResa (séjour en cours) ; KerResa → KerMaint (création de l’intervention, avec jeton) ; KerMaint → réceptionniste et technicien ; KerMaint → client (information de réparation, si accepté). Frontières de confiance : Internet / API KerResa (la plus exposée) ; KerResa / KerMaint (passage dans le réseau interne par le VPN) ; applications / bases.

2.2 Criticité = G × V.

M4 est classé premier (criticité 9). M1 et M6 ont la même criticité et la même gravité : l’ordre entre eux se discute (M1 désorganise le service, M6 crée une copie de données personnelles).

Mission 3 — La revue du prototype

3.1

3.2 Version corrigée :

<?php
declare(strict_types=1);

const CATEGORIES = ['chauffage' => 2, 'eau' => 2, 'climatisation' => 3,
                    'electricite' => 3, 'tv_wifi' => 4, 'autre' => 4];   // catégorie => priorité
const CHAMPS = ['categorie', 'description'];

function traiterSignalement(string $corps, array $sejour): array
{
    try {
        $donnees = json_decode($corps, true, 4, JSON_THROW_ON_ERROR);
        if (!is_array($donnees) || array_diff(array_keys($donnees), CHAMPS) !== []) {
            return [400, ['erreur' => 'requete_invalide']];
        }
        $categorie = $donnees['categorie'] ?? null;
        if (!is_string($categorie) || !array_key_exists($categorie, CATEGORIES)) {
            return [422, ['erreur' => 'categorie_inconnue']];
        }
        $texte = trim(Normalizer::normalize((string) ($donnees['description'] ?? ''), Normalizer::FORM_C));
        if (mb_strlen($texte) < 5 || mb_strlen($texte) > 300) {
            return [422, ['erreur' => 'description_5_a_300_caracteres']];
        }
        // La chambre et l'établissement viennent du séjour en cours (serveur), jamais du client ;
        // la priorité est calculée par le serveur selon la règle de gestion.
        $signalement = ['site' => $sejour['site'], 'chambre' => $sejour['chambre'],
                        'categorie' => $categorie, 'priorite' => CATEGORIES[$categorie],
                        'description' => $texte];
        error_log(sprintf('signalement site=%s chambre=%s categorie=%s', $sejour['site'], $sejour['chambre'], $categorie));
        return [201, ['statut' => 'enregistre', 'priorite' => $signalement['priorite']]];
    } catch (JsonException $e) {
        return [400, ['erreur' => 'requete_invalide']];
    } catch (Throwable $e) {
        $ref = bin2hex(random_bytes(4));
        error_log("ref=$ref " . get_class($e));          // détail au journal, pas au client
        return [500, ['erreur' => 'erreur_interne', 'reference' => $ref]];
    }
}

$sejour est fourni par KerResa à partir du client authentifié (B3SLAM-03) ; l’envoi à KerMaint (non montré) utilise le jeton lu par la fonction secret() du cours. Essais avec le séjour « Phare de Royan, chambre 214 » :

Journal produit :

signalement site=ROY chambre=214 categorie=chauffage

Un essai positif, quatre essais négatifs, et le journal ne contient ni adresse électronique ni description.

Mission 4 — La chaîne de développement

4.1 client-http 5.2.0 : avis de gravité élevée publié le 20/08/2026, délai de 30 jours, limite le 19/09/2026, dépassée de 31 jours au 20/10/2026 → ne l’utiliser qu’en version 5.2.3 ou plus (et corriger KerResa, qui l’utilise déjà, exercice 8). redim-image 0.9.2 : composant abandonné (aucune activité depuis 2022, aucune réponse aux signalements) → refuser : une faille découverte demain ne serait jamais corrigée ; la photo n’est pas dans la première version, on choisira un composant maintenu le moment venu.

4.2 Ajouter au pipeline : composer audit --locked --no-dev (avec le contrôle des avis de la veille et blocage si un délai est dépassé), et le modèle GitLab de détection de secrets ; on peut ajouter les tests automatiques des refus (priorité, chambre, catégorie).

Mission 5 — Protection des données et note

5.1 Récit R3 : par défaut, pas de notification. L’application propose au client, au moment du signalement, une case « Me prévenir quand c’est réparé » non cochée ; la notification passe par l’application (notification dans « Kervanet & Moi ») plutôt que par un courriel qui recopierait le détail ; elle ne contient que « Votre demande du … est traitée ». C’est la protection par défaut de l’article 25 (document 6) : un traitement supplémentaire n’a lieu que si la personne agit.

5.2 Note possible :

Madame Le Bihan, la fonction « signaler une panne » sera la première qui permette à des clients d’agir sur KerMaint depuis Internet. Notre analyse fait apparaître trois risques élevés : un secret technique exposé dans l’application, des priorités faussées par l’utilisateur, des adresses de clients copiées dans les journaux. Les exigences que nous proposons (contrôles côté serveur, gestion des secrets, journaux limités, composants à jour) représentent quelques jours de travail si elles sont prévues dès la conception. Ajoutées après la mise en service, elles demanderaient de modifier une application déjà utilisée, de refaire la recette et, en cas d’incident, de gérer une violation de données avec votre DPO. Le RGPD (art. 25) impose d’ailleurs à Kervanet, responsable du traitement, de protéger les données dès la conception. Nous vous proposons donc de les inclure dans le devis. Sarah Cherif, pour Anaïs Lecoq.