Dossier complet — Sécurité informatique

L3 · S6 · Systèmes, réseaux et sécurité

Dossier pédagogique original Matrice MI. Contenu d’entraînement non officiel; il ne remplace pas le support ou la maquette d’un établissement.

Objectifs d’apprentissage

• Construire un modèle de menace distinguant actifs, menaces, vulnérabilités, impacts et mesures.

• Choisir un mécanisme cryptographique selon confidentialité, intégrité, authenticité et stockage des mots de passe.

• Concevoir une authentification et une autorisation côté serveur fondées sur le moindre privilège.

• Réduire les vulnérabilités applicatives par validation contextuelle, requêtes paramétrées et gestion sûre des secrets.

• Organiser une réponse à incident traçable, proportionnée, autorisée et orientée vers l’amélioration.

Prérequis

• Bases de programmation et lecture de code, notamment variables, fonctions et exceptions.

• Notions élémentaires de réseaux, HTTP, systèmes d’exploitation et bases de données.

• Capacité à raisonner avec des probabilités simples, des rôles et des scénarios techniques.

Cours

1. Menaces et modèles de risque

Définir le risque avant de choisir un outil

Un actif est une donnée, un service ou une capacité à protéger. Une menace est une cause possible d’incident; une vulnérabilité est une faiblesse exploitable; un événement redouté décrit la conséquence pour l’actif. On peut prioriser avec $R \approx P \times I$, où $P$ est une probabilité estimée et $I$ un impact, sans confondre ce produit avec une mesure scientifique exacte. La méthode consiste à délimiter le système, inventorier les actifs, identifier les acteurs et les chemins d’attaque, puis choisir des mesures préventives, détectives et correctives.

Exemple guidé : pour une application de réservation, l’actif « comptes clients » vaut un impact 4/5 et une fuite par mot de passe réutilisé une probabilité 3/5. Le score conventionnel est donc $3\times4=12/25$. L’authentification multifacteur réduit surtout $P$; la journalisation et l’alerte réduisent le temps de détection, pas la probabilité initiale. Erreur fréquente : lister des logiciels sans relier chaque mesure à un scénario. Point de contrôle : pouvez-vous nommer actif, menace, vulnérabilité et impact dans un cas concret ?

Points-clés

• Distinguer actif, menace, vulnérabilité et événement redouté.
• Prioriser avec probabilité et impact sans donner une fausse précision au score.
• Relier chaque mesure à un scénario d’attaque et à une propriété de sécurité.

2. Cryptographie et authentification

Confidentialité, intégrité et preuve d’identité

Le chiffrement symétrique utilise une même clé pour chiffrer et déchiffrer : $C=E_K(M)$ puis $M=D_K(C)$. Il est efficace pour de gros volumes, mais le partage de la clé est délicat. Le chiffrement asymétrique sépare clé publique et clé privée; il facilite l’échange et les signatures, mais coûte. Une fonction de hachage n’est pas un chiffrement réversible : elle sert notamment à vérifier l’intégrité. Pour un mot de passe, on stocke un dérivé lent et salé, jamais le mot de passe ni un hachage rapide seul.

Exemple guidé : Alice veut envoyer un fichier à Bob. Elle calcule une empreinte, chiffre le fichier avec une clé symétrique aléatoire, puis protège cette clé avec la clé publique de Bob. Elle signe l’empreinte avec sa clé privée; Bob déchiffre la clé, vérifie la signature avec la clé publique d’Alice, puis contrôle l’empreinte. La signature authentifie l’origine et l’intégrité, pas la confidentialité. Erreur fréquente : croire qu’une URL en HTTPS prouve la fiabilité éditoriale du site. Point de contrôle : associez chaque objectif à chiffrement, hachage ou signature.

Points-clés

• Distinguer chiffrement, hachage et signature par leur objectif.
• Protéger les mots de passe avec sel et dérivation lente.
• Comprendre le rôle complémentaire des clés symétriques et asymétriques.

3. Sécurité applicative

Construire une chaîne de traitement défensive

Toute donnée venant d’un navigateur, d’un fichier ou d’une API externe est non fiable. La validation côté serveur impose type, longueur, format et contraintes métier; l’échappement dépend du contexte de sortie HTML, SQL ou JavaScript. Les requêtes paramétrées séparent données et syntaxe et réduisent l’injection SQL. Il faut aussi protéger les cookies de session avec Secure, HttpOnly et SameSite, traiter les erreurs sans divulguer de secrets et mettre à jour les dépendances.

Exemple guidé : pour rechercher un livre, le serveur reçoit q. Il limite la taille à 80 caractères, refuse les caractères de contrôle, utilise SELECT ... WHERE titre LIKE ? avec un paramètre, puis encode le titre au rendu HTML. Un filtre qui retire simplement les apostrophes est fragile : il dépend du moteur et oublie d’autres contextes. Une défense en profondeur ajoute droits minimaux, journalisation sans mot de passe et sauvegardes. Point de contrôle : pour chaque entrée, indiquez source, validation, traitement, sortie et journal à ne pas enregistrer. Testez aussi vide, trop long, Unicode et valeur inattendue.

Points-clés

• Considérer toute entrée externe comme non fiable.
• Employer validation contextuelle, requêtes paramétrées et encodage approprié.
• Combiner protections applicatives, configuration sûre, mises à jour et sauvegardes testées.

4. Authentification, autorisation et secrets

Ne pas confondre identité et droit d’accès

L’authentification répond à « qui êtes-vous ? », l’autorisation à « que pouvez-vous faire ? ». Une politique de contrôle d’accès associe sujets, ressources et actions; RBAC attribue des rôles, tandis qu’ABAC peut tenir compte d’attributs. Le principe du moindre privilège limite les dégâts lorsqu’un compte est compromis. Une session doit avoir une durée, une révocation et une protection contre la fixation; les jetons ne doivent pas contenir de secret.

Exemple guidé : dans une API de bibliothèque, l’utilisateur connecté peut consulter ses emprunts, le bibliothécaire peut enregistrer un retour, et l’administrateur gère les comptes. Pour POST /retours, le serveur vérifie d’abord la session, ensuite le rôle, puis que l’emprunt ciblé appartient à une opération autorisée. Une interface qui masque un bouton ne constitue pas une autorisation : la règle doit être contrôlée côté serveur. Les clés API sont injectées par secret manager, jamais commitées. Erreur fréquente : partager un compte de service. Point de contrôle : écrivez la décision pour sujet, ressource et action, puis testez un refus explicite.

Points-clés

• Séparer authentification, autorisation et contrôle côté serveur.
• Appliquer RBAC et moindre privilège avec révocation vérifiable.
• Gérer les secrets hors du code et éviter les comptes partagés.

5. Défense en profondeur et réponse à incident

Détecter, contenir et apprendre

La défense en profondeur empile des contrôles indépendants : segmentation réseau, durcissement, authentification forte, filtrage, sauvegardes, supervision et formation. La journalisation doit être utile, horodatée, protégée contre la modification et parcimonieuse avec les données personnelles. Une réponse à incident suit généralement préparation, détection, qualification, confinement, éradication, restauration puis retour d’expérience. Il faut préserver les preuves et documenter les décisions sans transformer un diagnostic en accusation.

Exemple guidé : une alerte signale des connexions impossibles depuis deux pays. On qualifie l’alerte en vérifiant journaux et contexte, on révoque le jeton suspect et on force une réauthentification, puis on cherche d’autres actions du compte. Après confinement, on corrige la cause, restaure si nécessaire et mesure le délai de détection. Couper tous les serveurs immédiatement peut détruire des preuves et interrompre un service critique. Point de contrôle : indiquez quelle action est réversible, quelle preuve doit être conservée et quel indicateur suivra l’amélioration. Un exercice sur données fictives est préférable à un test intrusif en production.

Points-clés

• Combiner prévention, détection, réaction et reprise.
• Suivre une chronologie d’incident en préservant les preuves.
• Mesurer délais, couverture des journaux et qualité du retour d’expérience.

Exercices corrigés

Exercice 1 · Fondamental

Une plateforme universitaire expose trois actifs : A, comptes (probabilité 4/5, impact 5/5), B, page publique (1/5, 2/5), C, sauvegardes (2/5, 5/5). Calculez le score conventionnel $P\times I$, classez les actifs et proposez une première mesure pour le plus prioritaire.

Correction détaillée

1. A vaut 4 x 5 = 20/25. 2. B vaut 1 x 2 = 2/25. 3. C vaut 2 x 5 = 10/25. 4. L’ordre est A, C, B. 5. Pour A, activer une authentification multifacteur et surveiller les connexions réduit la probabilité et améliore la détection. Le score sert au triage; il ne prouve pas qu’A est exactement deux fois plus dangereux que C.

Exercice 2 · Fondamental

Associez chaque besoin à un mécanisme principal et justifiez : (a) vérifier qu’un fichier n’a pas changé, (b) empêcher un tiers de lire un message, (c) prouver que l’auteur possède une clé privée, (d) stocker un mot de passe utilisateur.

Correction détaillée

1. (a) utilise une empreinte de hachage, comparée à une valeur de référence authentique. 2. (b) utilise un chiffrement; une clé symétrique convient au contenu. 3. (c) utilise une signature numérique vérifiée avec la clé publique correspondante. 4. (d) utilise une dérivation lente et salée, par exemple Argon2id ou scrypt, jamais un chiffrement réversible. 5. Un hachage seul ne garantit pas l’origine si l’attaquant peut remplacer le fichier et son empreinte.

Exercice 3 · Intermédiaire

Une API propose GET /dossiers/{id}. Les rôles sont lecteur, agent et administrateur. Un lecteur ne voit que ses dossiers, un agent voit les dossiers de son service, et un administrateur voit tout. Décrivez l’algorithme d’autorisation serveur et donnez quatre tests, dont deux doivent être refusés.

Correction détaillée

1. Authentifier la requête et refuser 401 si la session est absente ou invalide. 2. Charger le dossier par identifiant côté serveur, puis récupérer propriétaire et service; ne pas faire confiance à un service envoyé par le client. 3. Autoriser si rôle=administrateur, ou si rôle=agent et même service, ou si rôle=lecteur et même propriétaire; sinon répondre 403 sans révéler l’existence du dossier. 4. Tests : lecteur sur son dossier (autorisé), agent de même service (autorisé), lecteur sur dossier d’un autre utilisateur (refusé), agent d’un autre service (refusé). Ajouter un test administrateur et vérifier qu’un identifiant inexistant ne provoque pas d’erreur détaillée.

Exercice 4 · Intermédiaire

Un développeur écrit sql = "SELECT id FROM users WHERE email='" + email + "'" et place un jeton de session dans un cookie sans attribut. Identifiez deux risques et réécrivez la stratégie de correction pour la requête et le cookie.

Correction détaillée

1. La concaténation permet une injection SQL, car l’entrée devient une partie de la syntaxe. Utiliser SELECT id FROM users WHERE email = ? et transmettre email comme paramètre au pilote; valider longueur et format avant, sans remplacer cela par un filtre de caractères. 2. Un cookie sans attribut peut être envoyé en clair ou lu par un script. Servir uniquement en HTTPS et ajouter Secure; HttpOnly; SameSite=Lax selon le besoin de navigation. 3. Régénérer l’identifiant après connexion, expirer la session et prévoir une révocation. 4. Tester une adresse normale, une apostrophe, une valeur trop longue, un script et une requête intersites; inspecter les journaux pour ne pas y imprimer le jeton.

Exercice 5 · Avancé

Des journaux fictifs indiquent qu’un compte de support s’est connecté depuis une adresse inhabituelle, a créé une clé API puis exporté 1 200 dossiers. Concevez un plan de réponse en 24 heures : qualification, confinement, preuves, éradication, reprise et indicateurs. Précisez les limites de votre conclusion.

Correction détaillée

1. Dans la première heure, ouvrir un ticket horodaté, vérifier la source des journaux et corréler connexion, création de clé et export; ne pas conclure à une exfiltration certaine sans preuve de sortie. 2. Préserver les journaux en lecture seule avec hash, limiter l’accès aux enquêteurs et noter les heures et décisions. 3. Contenir : suspendre le compte, révoquer la clé, bloquer les sessions actives et isoler le service d’export si cela reste proportionné; conserver une copie forensique avant modification. 4. Éradiquer : rechercher persistance, corriger la cause, faire tourner les secrets concernés et appliquer le moindre privilège. 5. Reprendre depuis une version saine après validation et surveillance renforcée. 6. Mesurer délai de détection, durée de confinement, couverture des événements et nombre de comptes touchés. 7. Limites : adresse inhabituelle peut être un VPN, et les journaux peuvent être incomplets; l’analyse doit rester autorisée et respecter les règles de notification applicables.

Quiz d’autoévaluation

Question 1

Quelle distinction est correcte ?

• Une vulnérabilité est toujours un attaquant • Une menace est une faiblesse interne ✓ Une vulnérabilité est une faiblesse exploitable • Un actif est uniquement un serveur

Explication : Une vulnérabilité est une faiblesse exploitable; la menace est la cause ou l’acteur potentiel, tandis qu’un actif est ce que l’on protège.

Question 2

Quel mécanisme est adapté au stockage d’un mot de passe ?

• Un texte en clair • Un hachage rapide sans sel ✓ Une dérivation lente et salée • Une compression réversible

Explication : Une dérivation lente et salée ralentit les essais et empêche que deux mots de passe identiques aient nécessairement la même valeur stockée.

Question 3

Quelle propriété une signature numérique apporte-t-elle principalement ?

• La confidentialité du message ✓ L’intégrité et l’authentification de l’origine • La disponibilité d’un serveur • La suppression des sauvegardes

Explication : La signature permet de vérifier l’intégrité et la possession de la clé privée; elle ne chiffre pas à elle seule le contenu.

Question 4

Où l’autorisation doit-elle être imposée pour une API ?

• Uniquement dans le bouton de l’interface • Uniquement dans la documentation ✓ Côté serveur pour chaque action sensible • Dans le nom du fichier JavaScript

Explication : L’interface est contrôlable par le client. Le serveur doit vérifier l’identité, le rôle et le périmètre de chaque opération.

Question 5

Quelle pratique réduit directement l’injection SQL ?

• Augmenter la taille des champs ✓ Utiliser des requêtes paramétrées • Masquer le bouton de recherche • Encoder les mots de passe en base

Explication : Les paramètres séparent les données de la syntaxe SQL; masquer l’interface ou changer les mots de passe ne traite pas cette injection.

Question 6

Quel attribut de cookie empêche normalement la lecture par JavaScript ?

✓ HttpOnly • Public • Cacheable • Indexed

Explication : HttpOnly demande au navigateur de ne pas exposer le cookie aux scripts; Secure et SameSite répondent à d’autres risques.

Question 7

Quelle action appartient au confinement d’un incident ?

• Publier une accusation immédiate ✓ Révoquer un jeton compromis • Supprimer tous les journaux • Ignorer l’alerte

Explication : Révoquer un jeton limite l’accès tout en laissant possible l’enquête. Les preuves doivent être préservées et les conclusions étayées.

Question 8

Pourquoi pratiquer la défense en profondeur ?

• Pour supprimer toute maintenance • Pour dépendre d’un seul filtre ✓ Pour conserver des barrières complémentaires si l’une échoue • Pour rendre les journaux inutiles

Explication : Des contrôles complémentaires réduisent la probabilité qu’une seule défaillance suffise; ils doivent toutefois être testés et maintenus.

Glossaire

• Actif — Donnée, service, équipement ou capacité ayant une valeur et nécessitant une protection.
• Vulnérabilité — Faiblesse technique, humaine ou organisationnelle susceptible d’être exploitée.
• Menace — Cause, événement ou acteur pouvant exploiter une vulnérabilité et produire un dommage.
• Risque — Combinaison raisonnée de la vraisemblance d’un scénario et de son impact.
• Hachage — Transformation à sens unique produisant une empreinte de taille déterminée, utile pour l’intégrité.
• Signature numérique — Mécanisme fondé sur une clé privée permettant de vérifier origine et intégrité avec la clé publique.
• Moindre privilège — Principe qui accorde seulement les droits nécessaires, pendant la durée nécessaire.
• Défense en profondeur — Combinaison de contrôles préventifs, détectifs et correctifs qui se renforcent mutuellement.

TP · Audit défensif d’une mini-API de bibliothèque

Dans un dépôt local fictif fourni par l’enseignant, une API de bibliothèque gère comptes, livres et emprunts. Les données sont synthétiques; toute exploration reste limitée à cet environnement autorisé. L’équipe doit produire un diagnostic reproductible, sans exploitation destructive.

Objectifs

• Cartographier actifs, rôles et scénarios de menace.

• Vérifier validation des entrées et contrôle d’accès avec des tests non destructifs.

• Repérer les secrets ou journaux sensibles sans les divulguer.

• Prioriser des corrections et justifier leurs critères de vérification.

Étapes

1. Lire le périmètre et créer un inventaire des routes, actifs, rôles et données; noter les hypothèses.

2. Construire une matrice de risques avec au moins six scénarios, probabilité, impact et mesure associée.

3. Écrire des tests locaux pour accès autorisé/refusé, entrée vide, valeur trop longue et caractères inattendus; conserver les résultats.

4. Inspecter configuration et journaux avec des données fictives; signaler toute clé en clair sans la recopier.

5. Rédiger puis prioriser trois corrections, rejouer les tests et présenter les limites de l’audit.

Livrables attendus

• Une cartographie et matrice de risques au format PDF ou Markdown.

• Un script ou tableau de tests avec résultats avant/après, sans donnée réelle.

• Une note de recommandations priorisées avec preuves, limites et plan de recontrôle.

Critères d’évaluation

• Couverture et exactitude des actifs, rôles et scénarios : 25 %.

• Tests reproductibles, non destructifs et correctement interprétés : 30 %.

• Qualité technique et priorité des recommandations : 30 %.

• Traçabilité, confidentialité des artefacts et clarté des limites : 15 %.

Piste de résolution

Une solution solide sépare les rôles, impose l’autorisation côté serveur, paramètre les requêtes, valide les entrées selon leur contexte, retire les secrets du dépôt et journalise sans mots de passe ni jetons. La matrice met généralement en tête l’accès indu à des dossiers et l’exposition de secrets. Les résultats doivent montrer un cas autorisé et un cas refusé par règle, puis une régression après correction. Toute conclusion doit distinguer vulnérabilité observée, hypothèse et risque résiduel.

Sujets originaux d’entraînement (non officiels)

Sujet original de préparation — session normale

Sujet pédagogique original et non officiel : il ne s’agit jamais d’une épreuve d’années passées ni d’un cours institutionnel. Les scénarios sont fictifs et doivent être traités dans un cadre autorisé.

Exercice 1

Une association stocke des dossiers dans une application web. Proposez un modèle de menace avec quatre actifs, trois scénarios et une mesure par scénario. Justifiez l’ordre de priorité.

Correction : Identifier comptes, dossiers, clés et disponibilité comme actifs. Pour chaque scénario, préciser acteur, vulnérabilité, événement redouté, probabilité et impact. Par exemple, réutilisation de mot de passe vers lecture de dossiers; classer avec une échelle explicite, puis préférer MFA, contrôle d’accès et alertes. Expliquer que le score guide la décision et ne remplace pas la validation.

Exercice 2

Expliquez, sur un échange de fichier, le rôle respectif du chiffrement symétrique, de la clé publique du destinataire et de la signature de l’émetteur.

Correction : Générer une clé symétrique aléatoire pour chiffrer le fichier. Chiffrer cette clé avec la clé publique du destinataire afin que sa clé privée puisse la retrouver. Calculer une empreinte et la signer avec la clé privée de l’émetteur; le destinataire vérifie avec la clé publique. Ainsi le contenu est confidentiel et la signature atteste intégrité et origine, sous réserve de clés authentiques.

Exercice 3

Concevez les contrôles de POST /emprunts pour un utilisateur et un bibliothécaire, y compris les réponses attendues pour une requête non authentifiée et une ressource indisponible.

Correction : Vérifier session ou jeton et répondre 401 s’il manque ou est invalide. Vérifier que l’utilisateur peut emprunter pour lui-même, ou que le bibliothécaire agit dans son rôle; répondre 403 si le droit manque. Valider l’identifiant, charger le livre côté serveur et contrôler sa disponibilité. Répondre 409 si une concurrence a déjà créé l’emprunt, transactionner la mise à jour et journaliser un identifiant non sensible. Ne jamais faire confiance au rôle envoyé dans le corps.

Sujet original de préparation — session de rattrapage

Sujet pédagogique original et non officiel : il ne s’agit jamais d’une épreuve d’années passées ni d’un cours institutionnel. Les scénarios sont fictifs et doivent être traités dans un cadre autorisé.

Exercice 1

Une alerte montre dix échecs de connexion puis une réussite et la création d’un jeton. Décrivez les premières actions d’enquête et de confinement sans détruire les preuves.

Correction : Horodater l’incident, vérifier la fiabilité de l’alerte et corréler les événements. Copier les journaux dans un espace protégé en lecture seule et limiter l’accès. Suspendre le compte ou révoquer le jeton, conserver les sessions et rechercher d’autres actions liées. Vérifier si l’adresse est un VPN ou une source connue avant d’attribuer l’action. Après analyse, réinitialiser les secrets, corriger la cause, restaurer si nécessaire et documenter le retour d’expérience.

Exercice 2

Expliquez pourquoi remplacer les apostrophes par une chaîne vide n’est pas une défense générale contre l’injection, puis donnez une correction de conception.

Correction : Le filtre dépend du moteur, des encodages et du contexte; il peut oublier des caractères ou altérer une donnée valide. La correction est une requête paramétrée, où la valeur est transmise séparément à l’API du pilote. Ajouter une validation de type, longueur et domaine métier; encoder à la sortie selon HTML ou JavaScript. Tester des entrées adverses en environnement autorisé et vérifier que les journaux ne conservent pas les secrets.

Exercice 3

Une équipe veut donner à un service de statistiques un accès administrateur à toute la base. Proposez une alternative conforme au moindre privilège et indiquez deux contrôles de suivi.

Correction : Créer un compte dédié sans administration, limité aux vues ou tables nécessaires, en lecture seule, avec filtrage des colonnes sensibles. Préparer une vue agrégée si les statistiques n’ont pas besoin des identifiants. Stocker le secret dans un gestionnaire, le faire tourner et limiter les réseaux sources. Suivre les requêtes et refus dans des journaux protégés, effectuer une revue périodique des droits et alerter sur les volumes ou horaires anormaux. Tester qu’une lecture interdite renvoie un refus.

Parcours de révision sur quatre semaines

Semaine 1 · Actifs, menaces, vulnérabilités et risque

Construire deux matrices de menace; recalculer les scores et justifier trois priorités. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.

Semaine 2 · Cryptographie, mots de passe et identité

Classer dix besoins par mécanisme; expliquer un échange hybride et vérifier une politique de session. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.

Semaine 3 · Autorisation et sécurité applicative

Écrire les règles RBAC d’une API, tester quatre cas d’accès et corriger une requête concaténée. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.

Semaine 4 · Défense en profondeur et incidents

Réaliser le mini-cas, chronométrer une réponse à alerte et relire les erreurs fréquentes avec le quiz. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.