1. Dans les critères DICP, que désigne la lettre D ?
2. À quoi sert une sauvegarde testée régulièrement ?
3. Que permet un cluster de deux serveurs en haute disponibilité ?
Le directeur de Brocéliande Logistique s'inquiète : une entreprise voisine a été paralysée dix jours par un rançongiciel, et le local serveur du siège a déjà connu une fuite d'eau. Il pose deux questions simples : « Qu'est-ce qui pourrait nous arriver de grave, et qu'est-ce qui coûterait le plus cher ? » et « Combien de temps peut-on rester à l'arrêt, et combien de données peut-on se permettre de perdre ? »
Ces deux questions sont le cœur de ce cours. La première est une analyse de risques : lister ce qui peut arriver, estimer la gravité et décider quoi faire. La seconde prépare la continuité et la reprise : organiser l'entreprise pour tenir et redémarrer après un sinistre.
Avant de mesurer un risque, il faut nommer précisément ses éléments. On confond souvent menace, vulnérabilité et risque ; or chacun se traite différemment.
Pour comparer des risques très différents, on note leur vraisemblance (quelle chance qu'il survienne) et leur impact (quelle gravité s'il survient), chacun de 1 à 4. On place ensuite chaque risque sur une matrice : sa position donne la priorité.
Clique sur un risque de Brocéliande pour le situer sur la matrice et voir son traitement conseillé.
Choisis un risque : sa gravité et son traitement conseillé s'affichent ici.
La note n'a de sens que relative : elle sert à classer les risques entre eux, pas à donner une vérité absolue. Deux évaluateurs peuvent diverger d'un cran ; ce qui compte, c'est l'accord sur ce qui est intolérable et doit être traité d'abord.
Une fois les risques classés, on décide pour chacun. Il n'existe que quatre traitements possibles, et on les combine souvent.
| Traitement | Exemple chez Brocéliande | Attention |
|---|---|---|
| Réduire (atténuer) | Sauvegardes testées et externalisées contre le rançongiciel ; détecteur d'eau dans le local | Le plus courant ; vérifier que la mesure fonctionne vraiment |
| Transférer (partager) | Assurance cyber ; héberger le site public chez un prestataire | On transfère le coût, pas la responsabilité juridique des données (RGPD) |
| Éviter (refuser) | Ne pas publier sur Internet un service qui n'en a pas besoin ; déménager la baie hors de la zone inondable | Parfois impossible sans renoncer à une activité utile |
| Accepter (assumer) | Vol d'un portable chiffré : impact faible, on assume | Doit être une décision écrite, pas un oubli |
« Ne rien faire » n'est pas un traitement : c'est une acceptation par défaut, non décidée, du risque. Un risque important laissé sans décision explicite est une faute de gestion que le jury d'examen, comme un auditeur, relèvera.
EBIOS RM est la méthode d'analyse de risques de l'ANSSI. Elle met tout le monde autour de la table (direction, métiers, informatique) et déroule cinq ateliers. En BTS, on en retient la logique et on la pratique en version simplifiée.
Quand un traitement concerne des données personnelles à risque (santé, biométrie, grand nombre de personnes), le RGPD impose une analyse d'impact relative à la protection des données (AIPD, fiche B3-02). C'est une analyse de risques centrée sur la vie privée des personnes : même démarche, autre point de vue.
L'analyse de risques dit quoi craindre ; la continuité organise l'entreprise pour tenir malgré un sinistre, et la reprise pour redémarrer. Deux documents, deux objectifs chiffrés.
| Terme | Ce que c'est | Exemple |
|---|---|---|
| PCA Plan de continuité d'activité | Comment continuer à travailler pendant le sinistre, même en mode dégradé | Basculer sur le second serveur, prendre les commandes sur papier le temps de la panne |
| PRA Plan de reprise d'activité | Comment remettre le système en service après le sinistre | Restaurer les serveurs à partir des sauvegardes sur un site de secours |
| RTO Durée maximale d'interruption admissible | Le temps maximal acceptable d'arrêt d'un service (aussi noté DMIA) | Le serveur de fichiers doit revenir en moins de 4 heures |
| RPO Perte de données maximale admissible | La quantité de données qu'on accepte de perdre, mesurée en temps (aussi noté PDMA) | Au plus 1 heure de données perdues → sauvegarde au moins toutes les heures |
Pour bien comprendre : la crevaison
Tu crèves sur l'autoroute. Grâce à la roue de secours, tu repars tout de suite, mais moins vite et sur une distance limitée : c'est le PCA, l'activité continue en mode dégradé.
Ensuite, le garage remet un pneu neuf et la voiture retrouve son état normal : c'est le PRA, la reprise complète. Le temps passé avant de pouvoir rouler normalement, c'est le RTO.
Sans roue de secours vérifiée (gonflée, outils présents), tout s'arrête : un plan non testé, c'est une roue de secours à plat.
RPO regarde en arrière (Point de reprise : quelle photo des données ?), RTO regarde en avant (Time : combien de temps pour revenir ?). RPO court = sauvegardes fréquentes ; RTO court = redémarrage rapide. Les deux coûtent cher : on ne vise « zéro » que sur les services vitaux.
La sauvegarde (fiche B2-24) protège contre la perte de données (règle 3-2-1-1-0, fiche B3-15). La haute disponibilité (fiche B2-25) masque une panne matérielle mais ne protège ni d'un rançongiciel ni d'une erreur, qui frappent les deux nœuds. Le PRA organise le redémarrage complet après un sinistre majeur, souvent sur un site de secours. Les trois se complètent, aucun ne remplace les autres.
En pratique, on produit deux livrables : un tableau d'analyse de risques (le registre) et un plan de continuité et de reprise. Voici la démarche appliquée à Brocéliande Logistique.
| Bien | Événement redouté | V | I | Niveau | Traitement et mesures |
|---|---|---|---|---|---|
| Serveur de fichiers | Chiffrement par rançongiciel | 2 | 4 | Rouge | Réduire : sauvegardes 3-2-1-1-0, EDR, sensibilisation ; PRA testé |
| Local serveur | Dégât des eaux | 2 | 3 | Orange | Réduire : détecteur d'eau, baie surélevée ; à terme, déménager |
| Serveur de fichiers | Panne matérielle (matériel ancien) | 4 | 3 | Rouge | Réduire : cluster HA, contrat de maintenance 4 h, pièces de rechange |
| Bâtiment | Incendie | 1 | 4 | Orange | Transférer : assurance ; réduire : sauvegarde hors site, PRA |
| Fichier clients | Fuite de données personnelles | 2 | 4 | Rouge | Réduire : chiffrement, droits, journaux ; AIPD ; procédure de notification CNIL |
| Portables | Vol | 2 | 1 | Vert | Accepter : BitLocker déjà en place (fiche B3-06) |
Tous les services ne méritent pas le même effort. On range les biens par criticité, puis on fixe des objectifs réalistes : viser un RTO très court sur un service peu important coûte cher pour rien.
L'entreprise s'arrête-t-elle vraiment si ce service est indisponible ?Par exemple l'ERP qui gère les commandes et les expéditions.
Perdre une journée de ces données serait-il grave ?Commandes, facturation, dossiers clients.
Le service est-il quand même attendu dans la journée ?Partage de fichiers interne, intranet.
RTO très court (quelques heures), RPO très court (minutes à 1 h) : cluster en haute disponibilité, réplication, sauvegardes fréquentes, PRA testé. Service vital.
RTO court, RPO plus large (une journée acceptable) : redémarrage rapide mais sauvegarde quotidienne suffisante. Service important mais données peu changeantes.
RTO d'une journée, RPO de 24 h : restauration depuis la sauvegarde quotidienne sur du matériel standard. Pas de haute disponibilité nécessaire.
RTO et RPO larges (plusieurs jours) : remise en service quand on peut, sauvegarde hebdomadaire. Risque accepté, documenté.
Tu accompagnes le responsable informatique de Brocéliande Logistique. Six situations arrivent : lis chacune, puis choisis la bonne analyse ou décision.
« Le local serveur n'a pas de détecteur de fumée. » Comment nommer cet élément dans l'analyse de risques ?
C'est…
Réponse : l'absence de détecteur est une faiblesse du bien : une vulnérabilité. La menace serait l'incendie, l'événement redouté la destruction du serveur. On agit justement sur la vulnérabilité : poser un détecteur.
« On a un cluster de deux serveurs en haute disponibilité. On peut donc supprimer les sauvegardes du serveur de fichiers, non ? »
Que réponds-tu ?
Réponse : la haute disponibilité protège d'une panne matérielle, pas d'une donnée corrompue, chiffrée ou effacée, qui se réplique sur les deux nœuds. La sauvegarde reste indispensable : elle garde des copies anciennes et hors ligne.
« La direction veut perdre au maximum une heure de données sur l'ERP. » Sur quoi agit-on, et comment ?
Ce besoin fixe…
Réponse : « perdre au maximum une heure de données » définit le RPO. On règle donc la fréquence des sauvegardes (ou une réplication) à une heure au plus. Le RTO, lui, parle de la durée d'interruption, une autre question.
« Pour le risque de fuite du fichier clients, la direction souscrit une assurance cyber. Est-ce suffisant ? »
Que dis-tu ?
Réponse : transférer (assurer) complète les mesures de réduction, il ne les remplace pas. Vis-à-vis de la CNIL, l'entreprise reste responsable des données : il faut aussi chiffrer, restreindre les droits et pouvoir notifier une violation (fiche B3-02). Supprimer le fichier clients n'est pas réaliste.
Deux risques : (A) panne du serveur ancien, V=4 I=3 ; (B) incendie du bâtiment, V=1 I=4. Par lequel commencer ?
On traite d'abord…
Réponse : on hiérarchise par le niveau (vraisemblance × impact). A obtient 12, B obtient 4 : la panne du serveur ancien est prioritaire. L'impact seul ne suffit pas : un événement très grave mais très rare passe après un événement grave et fréquent.
« Notre PRA est écrit, rangé dans un classeur depuis deux ans. On est prêts, non ? »
Que manque-t-il ?
Réponse : un PRA jamais testé est aussi incertain qu'une sauvegarde jamais restaurée. On l'exerce au moins une fois par an (restauration réelle, chronométrée), on met à jour les procédures et les contacts, et on vérifie que les objectifs RTO et RPO sont tenus.
| Notion | À retenir |
|---|---|
| Risque | vraisemblance × impact d'un événement redouté |
| Vulnérabilité / menace | faiblesse corrigeable / cause subie |
| Traitements | réduire · transférer · éviter · accepter |
| EBIOS RM | 5 ateliers ANSSI : cadrage, sources, stratégiques, opérationnels, traitement |
| PCA / PRA | continuer pendant / redémarrer après |
| RTO / RPO | durée d'arrêt admissible / données perdues admissibles |
| Régler RPO / RTO | fréquence des sauvegardes / rapidité de restauration |
Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.
1. Comment se calcule le niveau d'un risque ?
2. « L'antivirus du serveur n'est pas à jour. » Dans l'analyse de risques, c'est…
3. L'entreprise souscrit une assurance cyber. Quel traitement du risque applique-t-elle ?
4. Que définit le RTO ?
5. On veut perdre au plus 15 minutes de données. Sur quoi agit-on ?
6. Quelle affirmation est vraie ?
7. Combien d'ateliers compte la méthode EBIOS Risk Manager ?
8. Que faut-il faire d'un PRA une fois rédigé ?
Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.
Pour la phrase « Faute de sauvegarde testée, un rançongiciel a rendu le serveur de fichiers indisponible pendant trois jours », identifie : le bien, la vulnérabilité, la menace, l'événement redouté. Puis dis sur lequel de ces éléments l'administrateur peut agir, et comment.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Note vraisemblance et impact (1 à 4), calcule le niveau et classe du plus urgent au moins urgent : (a) panne de la climatisation du local serveur, matériel sensible à la chaleur ; (b) vol d'un téléphone professionnel non chiffré contenant la messagerie ; (c) coupure électrique de quelques minutes, onduleur en place ; (d) erreur de manipulation qui supprime un dossier partagé, sauvegardes quotidiennes.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Pour l'ERP de gestion de Brocéliande, la direction fixe : interruption acceptable 2 heures, perte de données acceptable 30 minutes. Donne le RTO et le RPO, puis propose une stratégie de sauvegarde et une solution de redémarrage qui tiennent ces objectifs.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Brocéliande Logistique n'a ni analyse de risques ni PRA. La direction te demande une note d'une dizaine de lignes présentant la démarche que tu proposes : par où commencer, quels livrables produire, comment fixer les priorités et comment s'assurer que le dispositif reste efficace dans le temps.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Sur ton pool Proxmox (page Mes serveurs et VM), tu joues un sinistre sur une VM de service, puis tu la restaures à partir d'une sauvegarde et tu mesures le RTO et le RPO réels. Tu compares ensuite avec une bascule par instantané. Compte 2 heures. Tu travailles sur une VM de test, jamais sur une VM utile.
| Machine | Système | Rôle dans le TP |
|---|---|---|
| SRV-TEST | Debian 13 avec un petit service (un fichier de données qui change) | La VM « de production » que tu vas sinistrer puis restaurer |
| Stockage de sauvegarde | Dépôt de sauvegarde Proxmox (ou PBS si disponible) | Reçoit les sauvegardes planifiées de SRV-TEST |
| Chronomètre | Ton téléphone ou une horloge | Mesurer le temps de restauration (RTO) |
Attends quelques minutes après la dernière sauvegarde (pour avoir des données « perdues » à mesurer), puis simule le sinistre : arrête la VM et supprime-la (ou efface /srv et casse le service). Démarre le chronomètre à cet instant : c'est le début de l'interruption.
La suppression est définitive. Vérifie trois fois que tu agis bien sur SRV-TEST et sur ton propre pool, jamais sur une VM partagée ou utile. Au moindre doute, demande à ton professeur.
/srv/activite.log : la dernière ligne date de la sauvegarde, pas du sinistre. L'écart entre les deux est ton RPO réel (les minutes de données perdues).Reprends l'expérience, mais crée d'abord un instantané (snapshot) de la VM (Snapshots → Take Snapshot). Cette fois, le sinistre doit rester à l'intérieur de la VM : sudo rm -rf /srv/* ou un service cassé. Si tu supprimes la VM, ses instantanés disparaissent avec elle. Après le sinistre, fais Rollback vers l'instantané. Compare le temps obtenu avec celui de la restauration depuis sauvegarde, et note l'inconvénient de l'instantané (il reste sur le même serveur : il ne protège pas d'une panne du serveur lui-même).
Complète le bilan chiffré de ton TP (avec tes propres mesures, les valeurs ci-dessous sont un exemple), puis vérifie chaque ligne.
| N° | Test | Comment | Résultat attendu | OK |
|---|---|---|---|---|
| 1 | La sauvegarde planifiée fonctionne | Onglet Backup et dépôt de sauvegarde | Au moins deux sauvegardes horodatées de SRV-TEST (la tienne et une de la tâche planifiée) | |
| 2 | Restauration réussie | Restore puis démarrage | La VM redémarre et le service répond | |
| 3 | RTO mesuré | Chronomètre, du sinistre au service rétabli | Une durée notée (en minutes) | |
| 4 | RPO mesuré | Écart entre la dernière ligne du journal et l'heure du sinistre | Une durée notée, cohérente avec la fréquence de sauvegarde | |
| 5 | Comparaison avec l'instantané | Rollback chronométré | RTO plus court, mais limite notée | |
| 6 | Conclusion | Deux phrases | Comment tenir un RPO plus court et un RTO plus court |