# Sécurité
Chapitre regroupant les cours théoriques sur les éléments relatifs à la cybersécurité.
# Sécurité - Analyse de risque (méthode Ebios)
### **I. Introduction**
La méthode EBIOS Risk Manager (EBIOS RM) est la méthode d’appréciation et de traitement du risque numérique publiée par l’Agence nationale de la sécurité et des systèmes d’information (ANSSI) avec le soutien du Club EBIOS.
Elle propose une boite à outils adaptable, dont l’utilisation varie selon l’objectif du projet et est compatible avec les référentiels normatifs en vigueur, en matière de gestion des risques comme en matière de sécurité numérique4. EBIOS Risk Manager permet d’apprécier les risques numériques et d’identifier les mesures de sécurité à mettre en œuvre pour les maitriser.
Elle permet aussi de valider le niveau de risque acceptable et de s’inscrire à plus long terme dans une démarche d’amélioration continue.
Enfin, cette méthode permet de faire émerger les ressources et arguments utiles à la communication et à la prise de décision au sein de l’organisation et vis-à-vis de ses partenaires.
La méthode EBIOS Risk Manager peut être utilisée à plusieurs fins :
- mettre en place ou renforcer un processus de management du risque numérique au sein d’une organisation ;
- apprécier et traiter les risques relatifs à un projet numérique, notamment dans l’objectif d’une homologation de sécurité ;
- définir le niveau de sécurité à atteindre pour un produit ou un service selon ses cas d’usage envisagés et les risques à contrer, dans la perspective d’une certification ou d’un agrément par exemple.
Elle s’applique aussi bien aux organisations publiques ou privées, quels que soient leur taille, leur secteur d’activité et que leurs systèmes d’information soient en cours d’élaboration ou déjà existants.
### **II. Principes de la méthode Ebios**
La méthode EBIOS Risk Manager adopte une approche de management du risque numérique partant du plus haut niveau (grandes
missions de l’objet étudié) pour atteindre progressivement les fonctions métier et techniques, par l’étude des scénarios de risque
possibles. Elle vise à obtenir une synthèse entre « conformité » et « scénarios », en positionnant ces deux approches complémentaires
là où elles apportent la plus forte valeur ajoutée.
Cette démarche est symbolisée par la pyramide du management du risque numérique (cf. figure 1).
Avec EBIOS Risk Manager, l’ensemble des risques est appréhendé par la combinaison :
- d’une approche par conformité pour déterminer le socle de sécurité pour les risques les plus communs, y compris ceux liés à des événements accidentels et environnementaux ;
- et d’une approche par scénarios pour identifier les risques avancés, d’origine intentionnelle, et notamment les attaques
particulièrement ciblées ou sophistiquées.
Ces deux approches permettent d’éclairer les décideurs dans leurs choix de traitement du risque.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/o48image-png.png)
### **III. Fonctionnement de la méthode Ebios**
La méthode Ebios s'articule autour de 5 ateliers de manière itérative (cf. figure 2).
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/50Iimage-png.png)
#### **3.1 Atelier 1 - Cadrage et socle de sécurité**
Le premier atelier vise à identifier l’objet de l’étude, les participants aux ateliers et le cadre temporel.
Au cours de cet atelier, vous recensez les missions, valeurs métier5 et biens supports relatifs à l’objet étudié.
Vous identifiez les événements redoutés associés aux valeurs métier et estimez la gravité de leurs impacts.
Vous évaluez également la conformité au socle de sécurité.
**NOTE** : l’atelier 1 permet de suivre une approche par « conformité », correspondant aux deux premiers étages de la pyramide
du management du risque numérique et d’aborder l’étude du point de vue de la « défense ».
#### **3.2 Atelier 2 - Sources de risque**
Dans le deuxième atelier, vous identifiez et caractérisez les sources de risque (SR) et leurs objectifs de haut niveau, appelés objectifs visés (OV).
Les couples SR/OV jugés les plus pertinents sont retenus au terme de cet atelier.
Les résultats sont formalisés dans une cartographie des sources de risque.
#### **3.3 Atelier 3 - scénarios stratégiques**
Dans l’atelier 3, vous allez acquérir une vision claire de l’écosystème et établir une cartographie du niveau de dangerosité induit par la relation avec les parties prenantes majeures de l’objet étudié.
Ceci va vous permettre de bâtir des scénarios de haut niveau, appelés scénarios stratégiques.
Ils représentent les chemins d’attaque qu’une source de risque est susceptible d’emprunter pour atteindre son objectif.
Ces scénarios se conçoivent à l’échelle de l’écosystème et des valeurs métier de l’objet étudié.
Leur gravité est ensuite estimée.
À l’issue de cet atelier, vous pouvez déjà définir des mesures de sécurité sur l’écosystème.
#### **3.4 Atelier 4 - Scénarios Opérationnels**
Le but de l’atelier 4 est de construire des scénarios techniques reprenant les modes opératoires susceptibles d’être utilisés par les sources de risque pour réaliser les scénarios stratégiques.
Cet atelier adopte une démarche similaire à celle de l’atelier précédent mais se concentre sur les biens supports critiques.
Vous estimez ensuite le niveau de vraisemblance des scénarios opérationnels obtenus.
**Info** : Les ateliers 3 et 4 s’alimentent naturellement au cours d’itérations successives.
**Info** : Les ateliers 2, 3 et 4 permettent d’apprécier les risques, ce qui constitue le dernier étage de la pyramide du management
du risque numérique. Ils sollicitent le socle de sécurité selon des axes d’attaque différents, pertinents au regard des menaces
considérées et en nombre limité pour en faciliter l’analyse.
#### **3.5 Atelier 5 - Traitement du risque**
Le dernier atelier consiste à synthétiser l’ensemble des risques étudiés et à définir une stratégie de traitement du risque. Cette dernière
est ensuite déclinée en mesures de sécurité inscrites dans un plan de traitement du risque. Lors de cet atelier, vous établissez la synthèse des risques résiduels et définissez le cadre de suivi des risques.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/bOmimage-png.png)
**Note** : en général, chaque chemin d’attaque d’un scénario stratégique donne lieu à un scénario opérationnel. Un scénario de risque correspond à l’association d’un chemin d’attaque et de son scénario opérationnel.
### **IV. Conclusion**
EBIOS Risk Manager est une méthode adaptable. Elle constitue une véritable boîte à outils, dont le niveau de détail et le séquencement
des activités à réaliser pour chaque atelier, seront adaptés en fonction des objectifs.
La manière dont s’applique la méthode diffère selon le sujet étudié, les livrables attendus, le degré de connaissance du périmètre de l’étude ou encore le secteur auquel on l’applique.
La grille ci-après propose des cas d’usage selon l’objectif visé.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/bE3image-png.png)
# Sécurité - CIA Triad
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/pnBdebutant-png.png) | Difficulté : Débutant
Notions : Principes fondamentaux en cybersécurité.
|
---
### **I. Introduction**
Lorsque l'on parle de cybersécurité, il est important d'en saisir les objectifs principaux.
Pour cela, il a été créé un acronyme mnémotechnique : la triade ***CIA***.
Il s'agit d'un modèle conceptuel où chaque lettre représente l'un des trois grands piliers de la cybersécurité :
- Confidentiality
- Integrity
- Availability
Soit en français : Confidentialité, Intégrité, Disponibilité.
Ces piliers sont d'une importance équivalente.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/oJjimage-png.png)*Source : Try Hack Me*
Cela découle dune application des normes suivantes :
- ISO 27001
- NIST CSF
- ANSSI (PGSSI-S, RGS)
---
### **II. Confidentialité**
Le premier principe est d'assurer la confidentialité des données.
Cette confidentialité assure que des données sensibles ne sont accessibles qu'aux personnes explicitement autorisées.
Si jamais cette confidentialité n'était pas maintenue, des personnes non autorisées, voire mal intentionnées, pourraient accéder à ces données et les exploiter. Ce qui entraînerait à minima une perte de confiance, voire des conséquences plus graves :
- Pertes financières
- Fuites de données personnelles
- Fuites de secrets industriels
- Poursuites judiciaires
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/6Glimage-png.png)
Quelques exemples de perte de confidentialité de l'information :
- *Un employé partage son mot de passe à un collègue, celui-ci est entendu par une personne mal intentionnée qui accède ensuite au poste et vole des données confidentielles et personnelles. Elle pourra plus tard la faire chanter ou réutiliser contre elle ces informations.*
- *Des données sensibles concernant des secrets de fabrication pour un client ont fuité depuis une sauvegarde mal sécurisée. Cela entraîne des poursuites de la part du client mécontent que ses Propriété Intellectuelles aient été compromises.*
- *Les fiches de paye des salariés ont été rendues publiquement accessibles sur internet. Cela a entraîné des conflits internes et des mouvements de grèves qui ont déstabilisé le fonctionnement de l'entreprise. *
---
### **III. Intégrité**
Le second principe est d'assurer l'intégrité des données.
Cette intégrité assure que les données n'ont pas été altérées. Que la confiance que l'on peut leur accorer reste pleine et entière.
Mais également que celles-ci sont précises et fiables.
Si jamais cette intégrité n'était pas maintenue, altérée par des personnes malveillantes, les données ne pourraient plus être considérées comme fiables.
Dans le meilleur des cas, ces données pourraient être relevées et corrigées, n'entraînant qu'une perte de temps.
Dans des cas plus extrêmes, ces données altérées pourraient entraîner des conséquences plus graves :
- Communications erronées
- Prise de décision basées sur de fausses données
- Dommages collatéraux
- Perte de confiance
- Poursuites judiciaires
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/TH3image-png.png)
Quelques exemples de perte d'intégrité de l'information :
- *Des logs systèmes ont été modifiés pour effacer les traces d'une activité.*
- *Un rapport financier à été altéré, poussant le conseil d'administration à prendre de mauvaises décisions.*
- *Des enregistrements de base de données contenant les mélanges des préparations ont été modifiés, conduisant à une production de produits inexploitables voire dangereux.*
---
### **IV. Disponibilité**
Le troisième principe est d'assurer la disponibilité des données et des services.
La disponibilité vise à assurer que les utilisateurs de la donnée ou du service puissent y accéder **o*****ù*** ils en ont besoin et **q*****uand*** ils en ont besoin.
En fonction du secteur d'activité de l'entreprise, il peut même s'agir de l'élément fondamental qui en permet le fonctionnement.
Par exemple les secteurs bancaire ou hospitalier. Dans ces deux cas, une perte de service, même momentanée, pourrait avoir des conséquences dramatiques. Comme par exemple :
- Perte de production.
- Destruction de stocks.
- Pertes de vies humaines.
- Perte de confiance
- Poursuites judiciaires
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/3Tbimage-png.png)
Quelques exemples de perte de disponibilité des données :
- *Le cœur de réseau est tombé en panne, privant les utilisateurs de l'intégralité des services informatiques.*
- *Suite à une attaque par déni de service, les services de suivi de commandes ne sont plus disponibles.*
- *Une mise à jour a été effectuée sur un serveur de production, celle-ci a fait redémarrer le service.*
---
### **V. Conclusion**
La triade **Confidentialité – Intégrité – Disponibilité** constitue le socle fondamental de toute démarche de sécurité informatique. Elle permet d’évaluer, structurer et prioriser les protections nécessaires pour garantir que les données restent accessibles aux bonnes personnes, exactes, et disponibles lorsque les utilisateurs en ont besoin.
Comprendre ces trois piliers, leurs risques et leurs interactions est essentiel pour analyser un système d’information, identifier ses vulnérabilités et mettre en place des mesures adaptées.
Dans les cours et les environnements professionnels, la triade CIA sert de référence pour aborder les normes, les bonnes pratiques et les stratégies de défense qui composent la cybersécurité moderne.
Voici un tableau récapitulatif qui résume les piliers, leurs objectifs et les risques auxquels ils permettent de faire face.
| **Pilier** | **Objectif** | **Risques** |
| Confidentialité | Protéger les accès, gérer les permissions. | Fuite, espionnage, vol de donnée. |
| Intégrité | Garantir l'exactitude des données. | Altération, fraude. |
| Disponibilité | Assurer l'accès aux données. | Pannes, DDoS. |
# Sécurité - Hash et chiffrement
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/t12intermediaire-png.png)
| Difficulté : Intermédiaire
Notions : Cybersécurité, Hashing, chiffrement.
|
---
### **I. Introduction**
Afin de protéger les données sensibles et garantir la sécurité des échanges, les mécaniques cryptographiques jouent un rôle clé dans la cybersécurité. Elles permettent entre autres choses :
- De chiffrer des données sensibles (mots de passes, contenu protégé, données confidentielles, etc...)
- De chiffrer des communications (web, email, protocoles, ...)
- D'authentifier un système ou un utilisateur (signature numérique, empreinte, certificat, etc...)
Il existe pléthore d'algorithmes et de méthodes pour cacher ou protéger de la donnée. On retiendra ici deux concepts majeurs :
- Le hachage.
- Le chiffrement.
Il sera également possible d'aborder la notion de stéganographie.
**Trivia** : Dû à l'évolution des puissances de calcul et des menaces croissantes, il est nécessaire de constamment adapter les algorithmes de chiffrements afin de les renforcer voire de les abandonner si une méthode a été trouvée pour les 'casser'.
---
### **II. Le Hash**
#### **2.1 Définition**
Le Hash (ou hashing, hachage) est une fonction mathématique qui vise à transformer une donnée de taille variable en une ***empreinte*** ***de taille fixe***.
Cette empreinte disposera de propriétés intrinsèques. En effet, par nature
- Non réversible : Il est donc impossible de retrouver le message d'origine
- Déterministe : Une même entrée donnera toujours la même empreinte.
- Non falsifiable : La moindre altération de la donnée d'entrée donnera un hash complètement différent.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/VgIimage-png.png)
De par sa nature, cela rend cette méthode idéale pour le stockage sécurisé de mots de passe, la vérification d'intégrité des téléchargements, les signatures numériques et l'indexation rapide.
La vérification se fera par comparaison.
*exemples :*
*Dans le cas d'un téléchargement, le fournisseur du téléchargement fournit le hash ou somme de contrôle du téléchargement.*
*Après téléchargement, il est possible de calculer à son tour le hash / checksum et de les comparer à celui fourni par l'éditeur sur la page de téléchargement. Cela permet de s'assurer de l'intégrité des données et de leur non-altération.*
*Dans le cas de l'authentification, l'utilisateur entre son mot de passe. Celui-ci est Haché et envoyé au serveur d'authentification, celui-ci compare alors le hash reçu et le hash présent en base de donnée pour confirmer que le mot de passe fourni est le bon.*
#### **2.2 Algorithmes courants**
| **Algorithme**
| **Statut** | **Usage recommandé**
|
| MD5 | Obsolète | Aucun (présence de failles majeures) |
| SHA-1 | Obsolète | Aucun (collisions d'entrées) |
| SHA-256 | Sûr | Intégrité des données, signatures |
| SHA-3 | Sûr | Applications |
| bcrypt / scrypt / Argon2 | Très sûr | Stockage de mots de passe |
*Le statut des algorithmes se base sur les données de 2025*
**Attention** : Lors du stockage de mots de passe avec sha-256, il faudra utiliser en complément un **KDF** (**K**ey **D**erivation **F**unction) comme vu ci-dessus (bcrypt, scrypt, pbkdf2, argon2).
---
### **III. Le Chiffrement**
#### **3.1 Définition**
Le chiffrement (Cypher / Encryption), à l'inverse du hash, a pour vocation à être déchiffré et pas seulement comparé.
Celui-ci sert essentiellement dans les échanges. Pour chiffrer ou déchiffrer de la donnée, il faudra utiliser une ou plusieurs clés.
Il existe deux types de chiffrement, le chiffrement **Symétrique** et le chiffrement **Asymétrique.**
**Info** : Plus la clé de chiffrement est longue, plus le chiffrement sera fort.
#### **3.2 Le chiffrement symétrique**
Le principe du chiffrement symétrique est d'utiliser ***une seule clé*** qui permettra à la fois de chiffrer et de déchiffrer la donnée.
L'avantage de ce type d'algorithme est qu'il est rapide à mettre en oeuvre. Cela le rend donc idéal pour le chiffrement de gros volumes comme des disques dur ou des bases de données.
L'inconvénient réside dans le fait que si la clé fuite, l'ensemble des données sera simple. Ce qui rend cette clé difficilement partageable.
Les algorithmes les plus courants sont :
| **Algorithme**
| **Type** | **Statut** | **Usage recommandé**
|
| DES | Bloc | Obsolète | aucun |
| 3DES | Bloc | Déprécié | Transition uniquement |
| AES (128,192,256) | Bloc | Standard moderne | VPN, TLS, Chiffrement de disque |
| ChaCha20 | Flux | Très sûr | réseau mobile, environnements connectés. |
A noter que AES s'accompagne également de différentes méthodes pour chiffrer des blocs successifs.
| **Algorithme**
| **Statut** | **Sécurité** | **Remarques**
|
| ECB | Osolète | Mauvais | Révèle les motifs (patterns) de la donnée chiffrée. |
| CBC | Sûr | Bon | Nécessite un IV (**I**nitial **V**ector) aléatoire |
| CFB / OFB | Sûr | Bon | Flux pseudo-aléatoire |
| GCM | Très sûr | Excellent | Authentifié (AEAD), rapide |
#### **3.3 Le chiffrement asymétrique**
Le principe du chiffrement asymétrique est qu'il dépends de deux clé. La première sert à chiffrer la donnée, la seconde à la déchiffrer.
Il s'agit du fameux couple ***Clé privée*** / ***Clé publique*** que l'on retrouve dans l'architecture PKI.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/aHtimage-png.png)
L'on s'en sert pour échanger des clé de chiffrement de manière sécurisée, pour vérifier les certificats et signatures numériques ainsi que pour de l'authentification par certificats.
Les algorithmes les plus courants sont :
| **Algorithme**
| **Type** | **Usage recommandé**
|
| DSA | Signature | Aucun (déprécié) |
| ECDSA | Curve (courbes elliptiques) | Signatures |
| RSA (2048, 3072,4096) | Facteurs premiers | Chiffrement, signature |
| Ed25519 | Curve (courbes elliptiques) | multiple (rapide et sûr) |
| DH (**D**iffie-**H**ellman) / ECDH | Echange de clés | TLS, VPN |
---
### **IV. Les signatures numériques**
#### **4.1 Définition**
Le principe de la signature numérique est de garantir ***authenticité*** (qui), l'***intégrité*** (non altération) et la ***non-répudiation***.
Le processus de signature et de validation se déroule comme suit :
---
### **V. Limitations et bonnes pratiques**
#### **5.1 Considérations générales**
Lors de l'application des concepts ci-dessus, il conviendra de respecter quelques principes élémentaires :
- Ne pas utiliser d'algorithmes obsolètes, dépréciés ou compromis.
- Préférer des clés fortes dans la mesure du possible.
- Conserver les secrets et clés publiques de manière sécurisée.
#### **5.2 Considérations particulières**
##### 5.2.1 Pour le hachage
- Toujours utiliser un KDF (**K**ey **D**erivation **F**unction) pour les mots de passes.
- Ajouter un salt (sel) unique par utilisateur
Un ***Salt*** est un élément aléatoire introduit dans le processus de hachage des mots de passes pour éviter que si plusieurs utilisateurs utilisent le même mot de passe, le hash soit exactement le même.
*Exemple sans salt :*
| **Username** | **String to be hashed** | **Hashed value = [SHA256](https://en.wikipedia.org/wiki/SHA256 "SHA256")** |
| `user1` | `password123` | `EF92B778BAFE771E89245B89ECBC08A44A4E166C06659911881F383D4473E94F` |
| `user2` | `password123` | `EF92B778BAFE771E89245B89ECBC08A44A4E166C06659911881F383D4473E94F` |
*Exemple avec salt :*
| **Username** | **Salt value** | **String to be hashed** | **Hashed value = [SHA256](https://en.wikipedia.org/wiki/SHA256 "SHA256") (Password + Salt value)** |
| `user1` | `D;%yL9TS:5PalS/d` | `password123D;%yL9TS:5PalS/d` | `9C9B913EB1B6254F4737CE947EFD16F16E916F9D6EE5C1102A2002E48D4C88BD` |
| `user2` | `)<,-*` | `password123)<,-*` | `6058B4EB46BD6487298B59440EC8E70EAE482239FF2B4E7CA69950DFBD5532F2` |
##### 5.2.2 Pour le chiffrement symétrique
- Ne jamais réutiliser un IV (vecteur d'initialisation)
Le ***vecteur d'initialisation (IV)*** est un bloc de bits utilisé dans le chiffrement pour initialiser le processus de chiffrement.
Il est généralement généré aléatoirement ou pseudo-aléatoirement et est utilisé pour initialiser le premier bloc de donnée lors d'une opération de chiffrement.
Cela garantit que lors du chiffrement, deux blocs identiques en entrée donne des résultats différents en sortie.
**Trivia** : Cela rend plus difficile les attaques par cryptanalyse en évitant les pattern récurrents.
##### 5.2.3 Pour le chiffrement asymétrique
- Le standard actuel (2025) est d'utiliser des clés supérieures ou égales à 2048 bits.
##### 5.2.4 Autres recommandations
- Utilisation de TLSv1.3 pour les protocoles sécurisés
- Utilisation de clés ed25519 pour le SSH
- Préférer WireGuard pour le VPN client (utilisation de ChaCha20).
---
### **Conclusion**
En conclusion, dans le monde d'aujourd'hui, la cryptographie n'est pas seulement un moyen technique permettant d'assurer la confidentialité des échanges. C'est un pilier essentiel de la confiance numérique garantissant également l'intégrité et l'authenticité des échanges, d'autant plus primordiale dans une logique d'architecture Zero Trust.
Les méthodes utilisées vont dépendre grandement du besoin à adresser :
| **Objectif** | **Technique** | **Algorithmes à privilégier** |
| Intégrité des données | Hash | SHA-256, SHA-3 |
| Stockage de mots de passe | KDF | bcrypt, Argon2
|
| Confidentialité | Chiffrement symétrique | AES‑GCM, ChaCha20 |
| Echange de clé | Asymétrique | Diffie‑Hellman, ECDH
|
| Signature | Asymétrique + Hash | RSA, Ed25519 |
**Trivia** : Bitlocker utilise un chiffrement asymétrique AES256 en mode XTS et s'appuie sur un chiffrement matériel grâce à la puce TPM si disponible.
# Sécurité - La sauvegarde
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/823novice-png.png)
| Difficulté : Novice
Notions : Sauvegardes, stratégies de sauvegarde, gestion du risque.
|
---
### **I. Introduction**
#### **1.1 Principe de la sauvegarde**
Le but d'une sauvegarde est de garder une copie de la donnée à un instant T.
Combiné à une stratégie de sauvegarde, cela permet de garder un historique de la donnée ou d'un système à des fins de restauration ultérieure en cas de perte ou d'altération.
Cela peut se produire dans plusieurs situations :
- Perte de donnée (suite à une fausse manipulation, défaillance ou cyberattaque)
- Corruption de donnée
- Désastre ( de cause naturelle ou anthropique )
#### **1.2 Types de sauvegarde**
Là ou la sauvegarde diffère de la simple copie, c'est dans sa régularité et dans le fait d'en garder des copies à des dates antérieures.
En effet, bien qu'une copie seule permettrait de se prémunir contre une défaillance matérielle, si l'on en a un seul exemplaire et que la donnée d'origine est corrompue ou altérée, cette corruption ou altération sera également copiée.
Plusieurs types de sauvegardes existent.
##### ***1.2.1 Full backup***
Sauvegarde complète du système, de la machine virtuelle ou du jeu de donnée.
| **AVANTAGES** | **INCONVENIENTS** |
| - Copie complète.
- Ne nécessite pas de rassembler plusieurs jeu de sauvegardes.
- Restauration simple en l'état.
| - Peut être très (trop) longue.
- Nécessite beaucoup d'espace.
|
##### ***1.2.2 Incrémental***
Une première sauvegarde complète est faite en début de cycle.
Puis chaque jour, une sauvegarde uniquement des données modifiées ou ajoutées depuis la dernière sauvegarde qui peut être une sauvegarde complète ou une sauvegarde incrémentielle..
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/FFMimage-png.png)
| **AVANTAGES** | **INCONVENIENTS** |
| - Sauvegarde rapide
- Nécessite beaucoup moins d'espace
| - Nécessite d'avoir l'ensemble du jeu de sauvegarde
|
##### ***1.2.3 Différentiel***
Une première sauvegarde complète est faite en début de cycle.
Puis, chaque jour, une sauvegarde des données modifiées ou nouvellement ajoutées sur la base de la dernière sauvegarde complète.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/m1Kimage-png.png)
Pour cette méthode, les avantages et inconvénients sont un compromis sur les deux méthodes précédentes.
- La sauvegarde est plus rapide qu'une complète, mais moins qu'une incrémentale.
- Nécessite moins d'espace qu'une complète journalière, mais plus qu'une incrémentale.
- Ne nécessite que la complète et la dernière différentielle pour la restauration au lieu du jeu complet.
En résumé, c'est un bon compromis entre les deux méthodes.
Mais l'important est avant tout d'avoir la méthode la plus adaptée aux contraintes de productions et aux budgets.
#### **1.3 Supports de sauvegardes**
Les supports de sauvegardes sont multiples et se divisent en 3 catégories majeures :
1. Le stockage local ( HDD, SSD, NAS, SAN, ...).
2. Le stockage **Offsite** ou externalisé ( Bande, disque externe ).
3. Le stockage Cloud.
Comme il sera vu plus tard, il est nécessaire de mixer au moins deux types de sauvegardes afin de pérenniser la solution et anticiper le plus de risques possible.
---
### **II. Définir un plan de sauvegarde**
#### **2.1 Composantes de la stratégie**
Pour créer une stratégie de sauvegarde pertinente, il est avant tout nécessaire de se poser certaines question :
- **Scope** : Quelles données je sauvegarde ? Machine virtuelle, répertoires, fichiers, ...
- **Fréquence** : A quelle fréquence je sauvegarde ? Les données changent elles souvent ?
- **Responsabilité** : Qui en prends la responsabilité ? Qui en suit l'exécution ?
- **Stockage** : Où sont-elles stockées, sur quel support ?
- **Sécurité** : Comment sont-elles protégées ?
**Conseil** : Répondre à ces questions est essentiel et il faudra le faire dans cet ordre car les réponses aux premières conditionneront les réponses aux suivantes.
Exemple
***Scope :** je dois sauvegarder une serveur de fichiers contenant des données de production tels que des bons de commande et de la facturation d'une volumétrie d'environ 400Go (+ ou - 500Mo par jours)*
***Fréquence** : les données sont vitales dans l'activité de l'entreprise et changent tous les jours. Il faudra donc à minima une sauvegarde journalière. Au vu du volume et des temps de sauvegarde, on pourra opter pour une complète hebdomadaire dans la nuit de samedi à dimanche et des incrémentales ou des différentielles quotidiennes*
***Responsabilité** : le service informatique en assurera le fonctionnement et la restauration éventuelle. Le suivi se fera par le service informatique également et des mails d'alerte et de rapports seront envoyés au service informatique et au responsable de production pour suivi.*
***Stockage** : le volume étant important, un disque est a exclure, il faudra donc opter pour un NAS en local avec suffisamment d'espace. D'autant que pour des raisons juridiques, il faudra garder un historique long. Le plan de sauvegarde pourrait ainsi s'accompagner d'un plan d'archivage sur un cold Storage (stockage à froid) pour les sauvegardes les plus anciennes.*
*On peut par exemple envisager une sauvegarde NAS pour un cycle d'une semaine, puis basculer les sauvegardes les plus anciennes sur des bandes externalisées pour plus de sécurité.*
***Sécurité** : Le NAS qui contiendra les sauvegardes des cycles les plus récents devra être isolé du réseau autant que faire se peut pour limiter les risques de cyber attaque.*
*Les volumes seront montés si pas de traces d'activité suspectes en début de travail (job) et seront démontés à la fin après validation.*
*Les bandes devront être stockées dans un local adapté en dehors du site de production principal pour palier au risque d'incendie.*
*L'ensemble des locaux contenant les données seront munies de portes coupe-feu, situé à un étage pour éviter les dommages en cas d'inondation et équipés de serrures à codes et d'alarmes pour limiter les disques d'intrusion.*
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/jEgimage-png.png)
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/aJ2image-png.png)
|
| *Stockage sur bande LTO*
| *Evolution de la capacité de stockage des bandes LTO* |
Basés sur ces deux éléments, le principe d'une bonne politique de rétention est d'obtenir le meilleurs compromis possible entre la durée de rétention, et l'optimisation des coûts de celle-ci.
#### **2.2 Sauvegarde vs archivage**
La rétention de sauvegarde peut être mise en place en vue de pouvoir restaurer à des dates antérieures en cas de compromission silencieuse.
**Info** : Il est arrivé par exemple qu'un serveur soit 'cryptolocké' par un virus, mais que celui-ci ai en fait compromis le serveur 1 mois avant et soit resté en dormance.
Un exemple de stratégie de rétention :
L'archivage quand à lui est prévu à plus ou moins long terme et consistera à garder la donnée en vue d'une utilité ou consultation ultérieure, sans forcément attendre un sinistre. C'est le cas des documents où la loi exige de garder un historique, pour le fournir à l'administration sur demande.
#### **2.2 Politique de suppression et d'audit**
Dans les deux cas, il faudra prévoir une politique de suppression, sans quoi le besoin en stockage ne fera que croitre indéfiniment.
Dans le cas des sauvegardes, cela pourra être géré automatiquement par la solution de sauvegarde qui supprimera automatiquement les points de restauration les plus anciens.
**Info** : Il faudra également prendre en compte le point à partir duquel on considèrera qu'une sauvegarde est trop vielle et qu'une récupération de celle-ci sera de toute façon inutile tant ses données seront obsolètes.
Dans le cas de l'archivage, cela se fera en fonction des contraintes légales. Il s'agira alors de purger les ***n*** plus vieux fichiers ou les fichiers plus vieux que ***n*** jours, mois, années.
**Info** : Tout comme il sera parfois nécessaire juridiquement de garder des fichiers sur une certaine période de temps, il pourra être obligatoire de les supprimer après une certaine période. Par exemple les données à caractère personnel dans le cadre de la **RGPD**.
Enfin, il faudra s'assurer régulièrement que ces données sauvegardées ou archivées soient lisibles et exploitables en mettant en place des politiques d'audit et de tests. Au travers par exemple de tests réguliers de restauration ou de lecture, ou bien des tests de vérification d'intégrité.
---
### **III. Restauration des données**
#### **3.1 RPO, RTO et MTD**
L'objectif de restauration pourra être découpé comme suit :
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/BYVimage-png.png)
Le **RPO** (Objectif de récupération) est la durée maximale de perte de donnée acceptable. Elle correspond à la période entre la dernière sauvegarde et l'incident. En effet, toute donnée sur cette période est définitivement perdue.
Le **RTO** (Objectif de temps de récupération) est la durée visée pour la récupération de la donnée et le retour à un fonctionnement nominal.
Le **MTD** (Temps de rupture de service maximum toléré) est le temps total de coupure de service tolérable entre l'incident et le retour à la normale avant que les conséquences de cette absence de service deviennent critique (perte de production, pénalité financières, ...)
Il faudra ajouter aux estimations, la perte sèche de données ainsi que le temps passé à les reconstruire (si c'est possible).
Ces indicateurs, sont importants, car ils permettront de définir les stratégies de sauvegarde, cibler et prioriser les systèmes critiques et évaluer les risques financiers et opérationnels liés à l'interruption de service.
#### **3.2 Scénarii de restauration**
Dans le cadre d'une restauration, il faudra définir ce que l'on restaure :
- **File-level recovery** : Uniquement la donnée ou les fichier perdus ou altérés.
- **System-level recovery** : Le système en entier.
- **Bare-metal restore** : Restauration de l'ensemble de la VM y compris de son enveloppe.
Le scénario de récupération dépendra principalement de plusieurs facteurs :
- le type de sinistre (système endommagé ou juste donnée perdue/altérée)
- la nature et la quantité de donnée perdue ou altérée à restaurer
- l'origine du sinistre (attaque, perte de l'installation, fichiers supprimés)
Il faudra donc faire une estimation du temps de récupération de chaque scénario afin de calculer le RTO, voir si cela rentre dans le MTD.
Ce qui amènera donc à faire des simulations et estimations afin de prévoir à l'avance le scénario le plus adapté à l'incident.
#### **3.3 Tests et validation**
Au vu de l'ensemble des éléments présentés, il est donc crucial de procéder régulièrement à des tests et auditer scrupuleusement la consistance des sauvegardes et archives.
Cela permettra de répondre à l'ensemble des questions essentielles :
- La restauration est-elle possible ?
- Quelle sera la perte pour l'entreprise ?
- Combien de temps cela prendra ?
Il faudra donc organiser ces audits avec la participations des décideurs. Ils seront à même de fournir les contraintes métiers, définir l'acceptabilité de la perte, les conséquences d'une interruption de service et sa limite.
Faire l'exercice de restauration ou consultation des archives régulièrement permet de :
- tester, valider, documenter l'ensemble des éléments vu ci-dessus.
- faire évoluer les documentation et estimations existantes.
- s'assurer que le personnel est en mesure de mener efficacement les procédures.
# Sécurité - PCA, PRA et DRP
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/823novice-png.png)
| Difficulté : Novice
Notions : PCA, PRA, stratégies de survie.
|
---
### **I. Introduction**
Dans certains secteurs d'activité (médicaux, bancaires, défense, etc...), une simple coupure de service peut avoir des conséquences graves. Et même pour des secteurs moins sous tensions, cela peut avoir des conséquences financières directes.
( *exemple : dans le secteur de l'agroalimentaire ou du médicament, le moindre doute sur la gestion de la chaîne du froid peut signifier une destruction de la production* ).
Afin d'assurer la pérennité du service informatique de l'organisation, Il est nécessaire d'anticiper ces problèmes et de prévoir des solutions.
La sauvegarde, bien que répondant en partie à ces points, doit être intégrée dans des plans plus larges.
On distingue 2 scenarii principaux dans la gestion de crise :
- **La continuité d'activité** : un problème survient (matériel par exemple), comment l'on s'assure de poursuivre l'activité avec pas ou peu de rupture de service.
- **La reprise d'activité** : un problème a eu pour conséquence l'arrêt de tout ou partie de l'activité de l'entreprise et il faut repartir.
---
### **II. Notions fondamentales**
Lors de l'établissement de ces plans, un certain nombres de points sont à retenir :
**La résilience** : Il s'agit de la capacité de l'organisation à résister à un incident qui pourrait entraîner une rupture d'activité.
**La disponibilité** (Availability) : Il s'agit du temps de disponibilité du service. Certaines entreprises (opérateurs télécom, datacenters, doivent assurer une disponibilité et garantissent souvent celle-ci. Elle est défini en pourcentage de disponibilité sur 1 année (par exemple, un datacenter peut assurer une disponibilité de 98% ce qui signifie que sur une année de 365 jours, ce qui signifie que l'entreprise garantit que sur une année, il n'y aura jamais plus de 7jours d'indisponibilité cumulés, consécutifs ou non)
**La récupération** (recovery) : En cas d'incident, la capacité à repartir en production et de récupérer les données de l'entreprise.
**La continuité** (continuity) : La continuité de l'activité ou du service. La capacité à assurer la fourniture de celui-ci même en cas d'incident.
Ces points seront étudiés, définis et des solutions seront apportées pour atteindre les objectifs fixés.
---
### **III. Le PCA**
#### **3.1 But du PCA**
Le PCA (**P**lan de **C**ontinuité d'**A**ctivité) est un ensemble de mesures prises pour s'assurer de la continuité des services essentiels et minimiser au maximum l'impact d'un dysfonctionnement ou d'un incident.
Cela se réalise à tous les niveaux de votre infrastructure.
Sur la couche matérielle par exemple, on trouve sur les serveurs 2 alimentations électriques indépendantes, deux processeurs, des contrôleurs RAID pour s'assurer que le serveur continue de fonctionner même en cas de défaillance matérielle.
Sur la couche réseau, un certain nombres de protocoles permettent une redondance des équipements (STP, RSTP, LACP sur les switch, HSRP, VRRP pour les routeurs). Cela permet de palier à la perte d'un équipement réseau ou la défaillance d'une interface.
Ou sur des couches plus haute, des mises en place de redondances de services (2 AD, 2 filers, hébergés sur des nodes différents).
Ainsi, grâce à la combinaison de toutes ces mesures, on assure un certain niveau de fiabilité et de continuité.
Le service peut continuer à fonctionner malgré un problème ou une situation de crise.
#### **3.2 Méthodologie de mise en place**
Basés sur une étude de risque (voir [Sécurité - Analyse de risque (méthode Ebios)](https://docs.labs404.fr/books/cours-it/page/securite-analyse-de-risque-methode-ebios "Sécurité - Analyse de risque (méthode Ebios)") ), l'on devra suivre le schéma de réflexion suivant :
1. Définir les points critiques à protéger. Les "fonctions vitales" de l'entreprise.
2. Etablir les scénarii qui entraineraient une rupture de service.
3. Proposer, pour chaque point, une solution adaptée pour y répondre
4. Définir les responsabilité et rôles dans la mise en œuvre et le suivi du PCA
5. Rédiger les process
6. Effectuer des test réguliers après mise en œuvre
*Exemple : Une société agroalimentaire fabrique des tourtes à la viande, elle doit gérer des stocks de matières première et s'assurer du bon fonctionnement de la chaîne du froid. Dans ce cadre là, elle a déployé une solution de supervision à travers un réseau de capteurs dans les frigo et les entrepôts, ainsi que des outils de traçabilité des stocks et du temps passé hors stockage.*
*Scénario 1 : un dysfonctionnement suite à une coupure de courant, à mis HS certains équipements réseaux. Cela empêcherai la lecture des capteurs, ce qui ferait que l'entreprise n'aurai plus de moyen de remonter les données, ni d'être avertie en cas de problème. La chaîne de production devrait être bloquée et l'ensemble des stocks vérifiés. En cas de doute, cela entrainerai une destruction des stocks. Donc pertes financières directes, délai d'approvisionnement pour renouveler le stock.*
*Solutions proposées : Adopter une topologie réseau full mesh, redonder les équipements critiques, mettre en place des onduleurs afin de palier aux futures coupures électriques. Cela permettra en cas de rupture d'un chemin réseau, de panne d'un équipement ou d'une coupure électrique, de continuer à assurer la traçabilité des informations.*
*Scénario 2 : Les données des capteurs sont enregistrés dans une base de donnée, suite à une corruption système due à un disque plein, celle-ci est mise à l'arrêt. De fait, les données ne sont plus enregistrées et les conséquences seraient les mêmes que dans le scénario d'avant.*
*Solutions proposées : Séparer les données de la bases du système en les mettant sur des disques séparés. Cela réduira les pertes et empêchera une production future. Superviser l'espace disque afin de pouvoir entreprendre des actions préventives. Redonder le serveur de base de donnée sur un second nœud de la ferme de serveurs. Si l'un des serveurs tombe en panne, le second prendra le relai, assurant la continuité de l'enregistrement des mesures.*
#### **3.3 Bonne pratiques**
Tout comme pour la sauvegarde, Il faut s'assurer que le PCA sera fonctionnel le jour où celui-ci doit servir.
Il faut donc tester régulièrement celui-ci, valider les process et/ou les faire évoluer.
Il faut également mettre en place un plan de communication interne, s'assurer que les personnes qui sont responsables de ces points sont informées.
Vérifier la conformité avec les standards ISO 22301 et 27001.
---
### **IV. Le PRA**
#### **4.1 But du PRA**
Le PRA (**P**lan de **R**eprise d'**A**ctivité) est un ensemble de mesures visant à reprendre le plus rapidement possible une activité normale suite à un incident majeur ayant entrainé une rupture de l'activité.
Cela peut consister à disposer d'équipements de rechange, d'un site où les machines virtuelles sont répliquées, de locaux déportés.
Contrairement au PCA où le but est d'éviter la rupture, le PRA part du principe que cette rupture est survenue et qu'il faut donc faire reprendre l'activité.
#### **4.2 Méthodologie de mise en place**
Basés sur une étude de risque (voir [Sécurité - Analyse de risque (méthode Ebios)](https://docs.labs404.fr/books/cours-it/page/securite-analyse-de-risque-methode-ebios "Sécurité - Analyse de risque (méthode Ebios)") ), l'on devra suivre le schéma de réflexion suivant :
1. Définir les points critiques à rétablir en priorité. Les "fonctions vitales" de l'entreprise.
2. Etablir les scénarii qui entraineraient une rupture de service.
3. Proposer, pour chaque point, une solution adaptée pour y répondre
4. Définir les responsabilité et rôles dans la mise en œuvre et le suivi du PRA
5. Rédiger les process
6. Effectuer des test réguliers après mise en œuvre
*Exemple : Une société de gestion d'autoroute dispose d'un centre de contrôle assurant la surveillance du réseau autoroutier et la coordination des interventions de maintenance et le contact avec les services d'urgences.*
*Scénario 1 : Suite à un accident, un incendie s'est déclenché à côté du site du PC. L'incendie se propage jusqu'aux locaux du PC. Une évacuation est demandée.*
*Solutions proposées : Construire un second bâtiment de PC de l'autre côté du réseau autoroutier géré et y disposer tout l'équipement nécessaire au fonctionnement du PC. Répliquer l'ensemble des serveurs et baies de stockages sur le site de secours. La procédure de démarrage est lancée au moment de l'ordre d'évacuation. Quand le personnel investit le site de secours, les équipements sont démarrés, fonctionnels, les données sont accessibles. La reprise de l'activité normale peut reprendre.*
*Scénario 2: Suite à une compromission des serveurs, un cryptolocker à infecté le réseau informatique et a chiffré les données. Le système est hors service.*
*Solutions proposées : Mettre ne place un système de sauvegarde hors ligne éprouvé et testé régulièrement. Disposer de réseaux isolés permettant une reprise de l'activité sans risquer une nouvelle compromission. Mettre en place un plan, au moins partiellement automatisé, de reconstruction des services et de récupération de la donnée.*
#### **4.3 Bonne pratiques**
Tout comme pour la sauvegarde et le PCA, Il faut s'assurer que le PRA sera fonctionnel le jour où celui-ci doit servir.
Il faut donc tester régulièrement celui-ci, valider les process et/ou les faire évoluer.
Il faut également mettre en place un plan de communication interne, s'assurer que les personnes qui sont responsables de ces points sont informées.
Les outils principaux du PRA à mettre en place et valider sont :
- Sauvegardes
- DRP (Disaster Recovery Procedure)
**Info** : Là où auparavant, les efforts du PRA se concentraient sur la réplication des machines, une sauvegarde complète des VM et de leur contenu, l'évolution des menaces en terme de cybersécurité fait qu'aujourd'hui on aura plus tendance à partir du principe que les réplicas et les sauvegardes du système sont potentiellement corrompu(e)s.
**Astuce** : Découlant du constat ci-dessus, la méthode aujourd'hui privilégiée est une reconstruction complète du système et de l'infrastructure. Suivi d'une restauration des données conservées à part. Une bonne partie de la reconstruction est partiellement, voire entièrement automatisée.
Définir correctement le RTO et le RPO.
Si il y a une possibilité lors de la conception de choisir le placement du site de PRA.
Table des distances - risques naturels et anthropiques
Dans la conception d'un centre de données, le choix du site est l'une des étapes les plus cruciales et constitue la toute première étape. Nous nous concentrons principalement sur deux sous-domaines : les risques naturels et anthropiques.
| **Objet fabriqué par l'homme** | **Distance minimale (KM)** |
| Stations-service/carburant | 1.6 |
| Lignes de transmission à haute tension | 1.6 |
| Les fugues des aéroports | 1.6 |
| Petits lacs et zones de débordement | 1.6 |
| Chemins de fer | 1.6 |
| Grand complexe de magasins | 1.6 |
| Tours de stockage d'eau | 1.6 |
| Canaux | 3.2 |
| Ports et ports | 3.2 |
| Lacs et barrages | 3.2 |
| Carrières | 3.2 |
| Stations radar | 5 |
| Laboratoires de recherche | 5 |
| Stations de radio/télévision | 5 |
| Ambassades | 5 |
| Aéroports | 8 |
| Usines chimiques et électriques | 8 |
| Stations et installations militaires | 13 |
| centrales nucléaires | 80 |
Distance entre deux sites
| **Distance** | **Buts et considérations** | **Sources** |
|---|
| **1-5 km** | Protection contre les menaces locales (feu, explosion, crash aérien, etc...) | Internal safety design |
| **50-160 km** | Compromis entre un temps de latence correct et une distance optimale prévenant les risques régionaux. | , |
| **320+km** | Assure une dépendance régionale (Grille énergétiques différentes, régions sismiques différentes, etc...) mais peut probablement introduire de la latence. | |
| **Fonction** | **pca** | **pra** |
| timing | Pendant et immédiatement après incident | Après incident, en réponse. |
| focus | Continuité des opérations vitales | Restauration de l'ensemble des opérations. |
| nature | Proactive | Réactive |
| exemple | Garder un portail client accessible. | Restaurer un service après une cyberattaque. |
Et évidement, le tout devra être documenté, testé et amélioré.
Complétés avec des études de nouveaux scenarii.
# Sécurité - PKI et Certificats
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/t12intermediaire-png.png)
| Difficulté : Intermédiaire
Notions : certificats, identité, https, chiffrement.
|
---
### **I. Introduction**
Lors d’échanges sur des protocoles standards non sécurisés, il est facile d’intercepter les données. Afin de sécuriser ces échanges, celles‑ci doivent être chiffrées à l’aide d’algorithmes adaptés.
Cependant, même si les données sont chiffrées, il reste essentiel de s’assurer que l’on communique avec un partenaire de confiance. Il devient donc nécessaire de pouvoir valider l’identité de ce partenaire.
Il faut également garantir que les données transmises n’ont pas été altérées pendant l’échange.
Pour répondre à ces trois besoins (confidentialité, authentification et intégrité) a été créée l’infrastructure à clés publiques, ou Public Key Infrastructure (PKI).
Une PKI est un ensemble de composants matériels, logiciels et de procédures permettant de gérer les clés publiques des utilisateurs et des systèmes, afin de garantir la fiabilité de leurs identités. Elle renforce ainsi la confiance dans les systèmes numériques.
Bien qu’il existe plusieurs modèles de PKI, ce cours se concentrera sur un modèle reposant sur trois composants principaux :
- **Autorité de certification (CA)**
- **Autorité d’enregistrement (RA)**
- **Service ou autorité de validation (VA)**
Le principe de fonctionnement est le suivant :
1. Un utilisateur ou une machine génère une clé privée.
2. À partir de cette clé, une requête de certificat (CSR) est créée.
3. Cette requête est soumise à une autorité d’enregistrement.
4. L’autorité d’enregistrement vérifie l’identité du demandeur et transmet la requête à l’autorité de certification.
5. Une fois validée, l’autorité de certification signe la requête et génère le certificat, qui sera fourni à l’utilisateur ou à la machine.
6. Lors des échanges entre deux tiers, le destinataire peut vérifier la validité du certificat et son état (non‑révocation) via un service de validation
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/AXgimage-png.png)
|
| *Source : appViewx* |
---
### **II. Le protocole SSL/TLS**
**Info** : Le protocole SSL/TLS intervient entre les couches transport (4) et application (7).
#### **2.1 Qu'est ce que SSL/TLS**
Pour chiffrer les communications, notamment web, il existe deux protocoles principalement utilisés :
- **SSL (Secure Sockets Layer)**: Le SSL est une technologie standard de chiffrement qui permet d'établir une communication à travers un socket chiffré entre un navigateur et un serveur web.
**Attention** : l'usage de SSL est déprécié et remplacé par TLS.
- **TLS (Transport Layer Security)**: Le protocole TLS est le successeur de SSL. Celui-ci permet une sécurité accrue avec des validations plus poussées et un meilleur chiffrement. Il est plus souvent appelé SSL/TLS.
- Les versions majoritairement utilisées sont TLS 1.2 et 1.3
Ceux-ci s'appuieront sur des certificats et des clés de chiffrement.
Plus les algorithmes de chiffrements utilisés sont performants, plus il sera difficile de déchiffrer la communication.
#### **2.2 Le but des certificats SSL**
L'utilisation des certificats poursuit un but triple :
- **Chiffrement** : Le certificat contient la clé publique utilisée pour établir un secret partagé, qui servira ensuite à chiffrer la communication.
- **Authentification** : Il garantit que l'identité du pair est vérifiée et qu'il s'agit bien de la machine/personne avec qui l'on souhaite communiquer.
- **Intégrité de la donnée** : L’intégrité des données est assurée par les mécanismes cryptographiques de TLS (MAC ou AEAD), pas par le certificat lui‑même.
---
### **III. Le fonctionnement de SSL/TLS**
#### **3.1 Application de Public Key Infrastructure (PKI)**
Lors d’un échange d’informations utilisant SSL/TLS, le serveur possède une paire de clés composée d’une clé privée et d’une clé publique. La clé publique est intégrée dans un certificat numérique signé par une autorité de certification (CA).
Le client, quant à lui, ne possède généralement pas de clé privée : il utilise simplement les certificats des autorités de certification de confiance installés dans son système pour vérifier l’authenticité du certificat du serveur.
Lors de la connexion, le client peut :
- vérifier la signature du certificat du serveur grâce au certificat de la CA,
- vérifier que le certificat est valide (dates, nom de domaine),
- vérifier que le certificat n’a pas été révoqué (via CRL ou OCSP).
Une fois ces vérifications effectuées, le client peut établir une connexion TLS sécurisée avec le serveur.
| [](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/PQeimage-png.png) |
| *Source : Sectigo* |
#### **3.2 Le processus du "Handshake" SSL**
Une étape clé du fonctionnement de SSL/TLS est le '***handshake**'*. Cette phase permet au client et au serveur de négocier les paramètres de sécurité, d’authentifier le serveur et d’établir un secret partagé qui servira à chiffrer la session.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/Vueimage-png.png)
1. **Client Hello**: Le client envoie un message contenant la version de TLS qu’il supporte, la liste des suites cryptographiques disponibles et des paramètres aléatoires.
2. **Server Hello**: Le serveur répond en choisissant une version TLS et une suite de chiffrement parmi celles proposées. Il envoie également son certificat SSL/TLS.
3. **Certificate Verification**: Le client vérifie le certificat du serveur à l’aide des autorités de certification de confiance (CA) et des mécanismes de révocation (CRL/OCSP).
4. **Pre-Master Secret**: Le client génère un pré‑secret (Pre‑Master Secret), le chiffre avec la clé publique du serveur (présente dans le certificat) et l’envoie au serveur.
5. **Session Keys**: Le client et le serveur dérivent indépendamment les clés de session à partir du Pre‑Master Secret et des valeurs aléatoires échangées.
6. **Secure Connection** : Une fois les clés établies, la communication est chiffrée et l’échange sécurisé peut commencer.
**Info** : Dans la version 1.3 de TLS, le processus de handshake à été simplifié afin d'être plus rapide et sécurisé (suppression du Pré-master secret et utilisation obligatoire de ECDHE (Perfect Forward Security)).
---
### **IV. Les autorités de certifications**
Comme vu plus haut, les autorité de certifications jouent un rôle déterminant dans une PKI. Elles sont responsables de la création, de la signature et de la gestion des certificats numériques.
#### **4.1 Portée des autorités de certification**
On les divise en deux groupes :
- **Les CA publiques.**
- Elles sont publiées et accessible sur internet.
- Elles ont fait l'objet de validations par des organismes spécialisés et disposent ainsi d'un haut degré de confiance.
- Les certificats des autorités publiques sont installés dans tous les navigateurs et les OS et mis à jours avec ceux-ci.
- Ainsi ils permettent une ***confiance Universelle***.
*Par exemple : let's encrypt, Sectigo, Digicert, ...*
- **Les CA privées ou organisationnelles.**
- Ce sont les CA mises en place au sein d'une organisation.
- Elles ne sont validée qu'en interne par l'organisation et la portée de leur confiance se limite donc à celle-ci.
- Les certificats ne sont pas installés dans les navigateurs ou les systèmes et doivent donc être déployés.
- Elles permettent donc d'avoir une ***confiance en interne*** envers les composants de l'organisation.
*Utilisés par exemple pour : VPN, interfaces web, applications, DNSsec, messagerie chiffrée, LDAPs, ...*
#### **4.2 Type des autorités de certification**
Une chaîne de certificat est généralement construite comme suit et repose sur :
- **Une autorité racine de confiance (ROOT CA)**
- C’est l’autorité la plus haute dans la hiérarchie PKI.
- Son certificat est ***autosigné*** (elle se signe elle-même).
- Elle est ***extrêmement protégée*** : souvent hors ligne, stockée dans des modules matériels sécurisés (HSM).
- Elle ne signe généralement ***pas directement*** les certificats des serveurs.
- Son rôle principal est de signer les certificats des autorités intermédiaires.
La confiance dans toute la PKI repose sur la sécurité de la Root CA.
- **Les autorités intermédiaires (Intermediate CA)**
- Située entre la Root CA et les certificats finaux (serveurs, utilisateurs).
- Son certificat est signé par la Root CA ou par une autre CA intermédiaire.
- Elle signe les certificats des serveurs ou des utilisateurs.
- Permet de limiter les risques : si une CA intermédiaire est compromise, la Root CA peut la révoquer sans détruire toute la PKI.
La plupart des certificats SSL/TLS sont signés par une ***CA intermédiaire***, pas par la racine.
#### **4.3 Les certificats auto-signés**
Un certificat autosigné est un certificat dont la clé publique appartient au même acteur que la clé privée et qui est ***signé par lui-même***.
Il existe deux cas :
**1. Certificat autosigné légitime**
- C’est le cas des **certificats racine**.
- Ils doivent être autosignés, car ils sont au sommet de la chaîne de confiance.
**2. Certificat autosigné non reconnu**
- Généré par un serveur ou un administrateur sans passer par une CA.
- Utilisé parfois pour des tests ou des environnements internes.
- Les navigateurs affichent une alerte car **aucune autorité de confiance ne l’a validé**.
[](https://docs.labs404.fr/uploads/images/gallery/2026-07/scaled-1680-/dbTimage-png.png)
---
### **V. Les types de certificats**
|
| **Validation** | **Cas d'usage** |
| Validation de domaine (**DV**) | L’autorité de certification vérifie que le demandeur contrôle bien le nom de domaine concerné. Cela peut se faire par e‑mail, en ajoutant un enregistrement DNS, ou via un fichier placé sur le serveur.
| *Sites web simples, blogs, pages d’information, environnements de test...*
Ce type de certificat ne garantit pas l’identité de l’organisation derrière le site
|
| Validation d'organisations (**OV**) | En plus de la vérification du domaine, l’autorité de certification vérifie l’existence légale de l’organisation, son adresse, son numéro d’enregistrement, etc. | *Sites professionnels, plateformes e‑commerce, services publics.*
Le certificat affiche le nom de l’organisation, ce qui renforce la confiance des utilisateurs.
|
| Validation étendue (**EV**) | Vérification approfondie de l’organisation (existence légale, physique et opérationnelle).
L’autorité de certification suit un processus strict et documenté.
| *Sites à haute sensibilité : banques, services financiers, plateformes de paiement, administrations.*
Dans certains navigateurs, le nom de l’organisation apparaît en vert ou dans la barre d’adresse.
|
---
### **VI. Considérations de sécurité**
L’utilisation de certificats SSL/TLS renforce la sécurité des échanges, mais elle n’est pas infaillible. En effet, une mauvaise configuration expose à des risques. Il est essentiel de connaître les principales vulnérabilités et d’adopter des bonnes pratiques pour garantir une protection efficace.
#### **6.1 Faiblesses et attaques**
- **Man-in-the-Middle (MitM) :**Un attaquant intercepte la communication entre le client et le serveur, pouvant ainsi lire, modifier ou injecter des données.
Cette attaque est possible si le certificat n’est pas correctement vérifié ou si la connexion n’est pas chiffrée.
- **Usurpation de certificat (Certificate Spoofing) :** Des certificats falsifiés ou compromis peuvent être utilisés pour faire croire à l’utilisateur qu’il communique avec un site légitime.
Cela peut survenir si une autorité de certification est compromise ou si l’utilisateur ignore les avertissements du navigateur.
#### **6.2 Bonnes pratiques**
- **Mises à jour régulières :** Maintenir à jour les logiciels serveurs, bibliothèques SSL/TLS et certificats permet de corriger les vulnérabilités connues et d’éviter les failles exploitées par les attaquants.
- **Chiffrement fort :** Utiliser des algorithmes modernes et robustes (ex : AES‑256, ECDHE) et désactiver les suites de chiffrement obsolètes (ex : RC4, MD5, SSLv3).
- **Surveillance et audit :** Vérifier régulièrement la configuration SSL/TLS du serveur, la validité des certificats, et surveiller les journaux pour détecter toute tentative d’accès non autorisé ou anomalie.
#### **6.3 Erreurs courantes**
Les erreurs les plus courantes lors de l'utilisation des certificats qui peuvent empêcher l'affichage correcte d'un site sont :
- Certificat expiré
- Nom de domaine incorrect
- Chaîne incomplète
- Utilisation de suites de chiffrement faibles
---
### **Conclusion**
Les certificats SSL/TLS et l’infrastructure à clés publiques (PKI) constituent la base de la confiance numérique moderne. Ils permettent de garantir la confidentialité des échanges, d’authentifier les acteurs et d’assurer l’intégrité des données. Leur efficacité repose autant sur la robustesse des algorithmes que sur la bonne gestion des autorités de certification, des chaînes de confiance et des mécanismes de validation.
Dans un contexte où les attaques deviennent plus sophistiquées, il est essentiel de maintenir des configurations TLS à jour, de surveiller l’état des certificats et d’adopter des pratiques de sécurité rigoureuses. Une PKI bien conçue et correctement administrée reste l’un des piliers les plus fiables pour sécuriser les communications et renforcer la confiance dans les systèmes d’information. 
