Casterman — SLAM, session 2025

La méthode : pour chaque récit, on évalue le besoin de confidentialité, intégrité, disponibilité selon l’impact d’une atteinte sur la donnée manipulée.

a) Confidentialité (récit 1) : niveau élevé si le récit manipule des données personnelles/stratégiques (dont la divulgation nuirait) ; faible s’il s’agit d’informations publiques (ex. catalogue).

b) Intégrité (récit 3) : niveau élevé si une altération des données fausserait le métier (ex. droits, tarifs, contenu d’un ouvrage à publier).

c) Différence de preuve (récits 2 vs 3) : le besoin de traçabilité/preuve est plus fort là où il faut pouvoir prouver qui a fait quoi (action sensible, juridiquement engageante) que sur une opération anodine.

1. Indisponibilité : chiffrement des données et des serveurs → activité bloquée (BDPro inutilisable).
2. Perte financière et fuite de données : coût de la rançon/remise en service, et en cas de double extorsion, exfiltration puis publication des données (atteinte à la confidentialité et à la réputation).

1. Sauvegardes régulières, testées, hors ligne/immuables (règle 3-2-1) — pour restaurer sans payer.
2. Mises à jour systématiques (OS, applications) — fermer les failles exploitées.
3. Antivirus/EDR + filtrage de la messagerie (le rançongiciel arrive souvent par hameçonnage). (On peut ajouter : segmentation réseau, MFA, sensibilisation.)

a) La CNIL doit être notifiée (dans les 72 heures) ; et les personnes concernées doivent être informées si la violation engendre un risque élevé pour leurs droits et libertés.

b) La violation doit obligatoirement être consignée dans le registre des violations de données (tenu par le responsable de traitement).

a) Les mots de passe en clair doivent être supprimés car, en cas de fuite de la base (vol, injection, sauvegarde compromise), tous les comptes sont immédiatement utilisables par l’attaquant — y compris ailleurs (réutilisation de mots de passe).

b) La solution adaptée est l’empreinte (hachage), pas le chiffrement : un mot de passe ne doit jamais pouvoir être déchiffré. On stocke un condensat (avec sel, ex. bcrypt/Argon2) et on compare des empreintes à la connexion. Le chiffrement est réversible (la clé volée révèle tout) → inadapté pour un mot de passe.

a) La table HistoMotDePasse reste vide parce que le déclencheur n’effectue pas l’insertion de l’ancien mot de passe : soit le test sur mdpExisteHisto est mal exploité (l’action n’est faite que dans une branche jamais atteinte), soit l’INSERT INTO HistoMotDePasse est absent du traitement.

b) Correction : dans le cas où mdpExisteHisto retourne false, le trigger doit (1) INSERT l’ancien mot de passe dans HistoMotDePasse, (2) compter les entrées de cet utilisateur, (3) supprimer la plus ancienne si le total dépasse 5, (4) mettre à jour mdpActuel/dateHeureMdpActuel dans Utilisateur — dans cet ordre.

Elle garantit l’intégrité (le PDF n’a pas été modifié après signature) et l’authenticité/non-répudiation (il provient bien de l’éditeur). Pour l’imprimeur, c’est la preuve qu’il imprime la version exacte et validée voulue par Casterman.

Un transfert chiffré adapté aux gros fichiers : par exemple SFTP (SSH File Transfer Protocol) vers un serveur dédié, ou une solution de transfert chiffrée de bout en bout — pas par courriel (taille + confidentialité non garantie).

Elle parcourt les droits de l’utilisateur et renvoie true si le couple (table, opération) demandé est autorisé :

public boolean possedeDroit(String uneTable, String uneOperation) {
    for (Droit d : this.lesDroits) {
        if (d.getTable().equals(uneTable)
         && d.getOperation().equals(uneOperation)) {
            return true;
        }
    }
    return false;
}

SELECT COUNT(*) AS nb_delete
FROM Log
WHERE operation = 'delete'
  AND dateHeure >= NOW() - INTERVAL 30 MINUTE;

a) La requête fournie ne répond pas au besoin : elle liste les idUtilisateur mais ne compte pas par utilisateur et n’applique aucun seuil (« plus de 5 ajouts »). Il manque un GROUP BY et un HAVING.

b) Correction :

SELECT idUtilisateur, COUNT(*) AS nb_ajouts
FROM Log
WHERE nomTable = 'BandeDessinee'
  AND operation = 'insert'
  AND dateHeure >= CONCAT(CURRENT_DATE(), ' 08:00:00')
GROUP BY idUtilisateur
HAVING COUNT(*) > 5;

Ce sont des méthodes d’écriture : DELETE supprime une ressource et PUT la modifie/remplace. Mal contrôlées, elles permettent une altération ou une destruction de données → atteinte directe à l’intégrité de la base.

Avant d’exécuter la suppression, on vérifie l’autorisation via autoriseAction(). Si le demandeur n’a pas le droit, on renvoie un statut HTTP 403 (Forbidden) sans toucher la base :

si NON autoriseAction(demandeur, ...) :
    réponse HTTP 403 (Forbidden)   // accès refusé
sinon :
    exécuter la suppression
    réponse HTTP 200/204

Créer une seconde API dédiée, publique mais en lecture seule sur le seul catalogue, applique la séparation des privilèges : l’accès public n’expose aucune écriture ni donnée sensible et ne partage pas l’authentification de l’API métier. Modifier l’API existante l’aurait au contraire élargie et fragilisée.

a) Deux problèmes : (1) le courriel renvoie l’identifiant et un mot de passe en clair → fuite directe si la boîte mail est compromise (et le mot de passe est donc connu/stocké en clair) ; (2) rien ne prouve que le demandeur est bien le titulaire du compte (pas de vérification, pas de péremption).

b) Mode sécurisé : envoyer un lien de réinitialisation à usage unique, contenant un jeton aléatoire à durée de vie courte, qui mène vers un formulaire où l’utilisateur choisit un nouveau mot de passe (jamais transmis par mail, et stocké haché).