Cours IT

Hardware
Notions théoriques liées au hardware.

Hardware - Le binaire
Difficulté : Débutant
Notions : Binaire, base 2
I. Introduction
Il y a 10 types de personnes dans le monde : celles qui savent compter en binaire et les autres.
                                                                                                                                               - Blague de geek
Le langage binaire est le langage informatique le plus bas niveau.
En effet un ordinateur fonctionnant avec du courant électrique, il n'y a que deux états possible pour un bit à l'instant T.
Circuit fermé, présence de courant : 1
Circuit ouvert, absence de courant : 0
De par ses deux valeurs possible, le binaire est donc un système de calcul en base 2.
II. Les bases de calcul
Information : Quel que soit le calcul, il est à noter que la première valeur possible est toujours 0 (Zero).
2.1 Base 10
La base 10 est la base naturelle pour l'humain et celle courrament utilisée dans le monde.
De par le fait que les mains humaines disposent de 10 doigts, c'est en effet plus pratique et instinctif pour compter.
on a donc les valeur suivantes possibles :
Valeurs base 10
0 =00
1 = 01
2 = 02
3 = 03
4 = 04
5 = 05
6 = 06
7 = 07
8 = 08
9 = 09
Une fois la valeur maximum atteinte (09) pour incrémenter au delà, on ajoute une dizaine devant l'unité et on continue ainsi à incrémenter.
10, 20, 30 etc... etc...
2.1 Base 2
En binaire le principe reste le même qu'en base 10 , on à donc 0, 1 et quand la valeur maximum est atteinte, on incrémente.
Valeurs base 2
0 =0
1 = 1
2 = 10
3 = 11
4 = 100
5 = 101
6 = 110
7 = 111
8 = 1000
9 = 1001
etc...
Si de prime abord, cela peut ne pas sembler naturel, il s'agit juste de reproduire la même logique de comptage que la base 10, mais avec seulement 2 valeurs disponible.
III. l'Octet
3.1 Construction
Heureusement, pour rendre tout cela plus lisible et car un bit seul ne fait pas sens dès lors qu'il s'agit de compter au delà de 1, on va regrouper ces bits par paquets. Ces packets sont appelés des registres.
Le registre le plus connu et celui qui sera courrament utilisé est l'octet (un paquet de 8 bits).
Basé sur ce principe on aura donc la représentation suivante : 00000000
Et là encore, si cela paraît compliqué, il existe un moyen simple et mnémotechnique de se représenter facilement les valeurs en binaire.
En effet, le binaire à une particularité, pour chaque bit que l'on rajoute devant, on double les possibilité, ce qui fait que chaque bit a une valeur différente. Cela s’appelle un Poid de bit.
Pour se donner une bonne idée, voici la valeur de chaque bit dans un octet :
128
64
32
16
8
4
2
1
0
0
0
0
0
0
0
0
3.2 Conversion base 10 / Base 2
Dès lors, pour convertir des nombres binaires en base 10 et de base 10 en binaire, cela deviens facile.
Il suffit d'additionner les valeurs de tous les bits égaux à 1. Ainsi,
01101011 par exemple se note :
128
64
32
16
8
4
2
1
0
1
1
0
1
0
1
1
soit : 64 + 32 + 8 + 2 + 1 = 107.
De la même manière, pour convertir un nombre en base 10 en binaire, il faudra additionner en partant de la droite les valeurs pour arriver à la somme du nombre que l'on veut et passer leurs valeurs à 1.
218 par exemple se note :
Détail de l'opération
128 < 218, donc on part avec 128 = 1.
128
64
32
16
8
4
2
1
1
0
0
0
0
0
0
0
128 + 64 = 192.
192 < 218, le bit avec une valeur de 64 est donc à 1.
128
64
32
16
8
4
2
1
1
1
0
0
0
0
0
0
192+32 = 224.
224 > 218 donc le bit avec une valeur de 32 est à 0. On passe à la valeur suivante.
128
64
32
16
8
4
2
1
1
1
0
0
0
0
0
0
192+16 = 208.
208 < 218, donc le bit avec une valeur de 16 est à 1.
128
64
32
16
8
4
2
1
1
1
0
1
0
0
0
0
208+8 = 216.
216 < 218, donc le bit avec une valeur de 8 est à 1.
128
64
32
16
8
4
2
1
1
1
0
1
1
0
0
0
216+4 = 220.
220 > 218, donc le bit avec une valeur de 4 est à 0.
128
64
32
16
8
4
2
1
1
1
0
1
1
0
0
0
216+2 = 218.
218 = 218. On passe donc notre dernier bit (celui dont la valeur est 2) à 1. La valeur des bits restant à droite sera donc 0.
128
64
32
16
8
4
2
1
1
1
0
1
1
0
1
0
128
64
32
16
8
4
2
1
1
1
0
1
1
0
1
0
Note : Si l'on additionne toutes les valeurs, le résultat est de 255. Par conséquent, si l'on doit traiter des nombres supérieurs à 255, on ajoutera simplement un octet devant, et l'on poursuivra le tableau de la manière suivante.
32768
16384
8192
4096
2048
1024
512
256
128
64
32
16
8
4
2
1
octet 2
octet 1
3.3 Les Échelles de tailles
Partant du principe qu'un octet peut stocker toutes sortes de données et que les bits sont donc l'unité de mesure la plus petite, si l'on veut stocker plus de données, on sera donc obligé d'accoler des octets, ou utiliser des registres plus grands.
Au bout d'un moment, il faudra que nos échelles de mesures continuent d'avoir un sens.
Si on empile beaucoup d'octets, on ne va pas continuer à dire, la taille de ce bloc est de 1 228 283 219 233 274 272 octets.
Pour cela, sur le même principe que les tableau de conversion, on va utiliser d'autre échelles.
A l'instar des unités de mesures classiques (gramme, kilogramme) ( centimètre, mètre, kilomètre) il va falloir établir un tableau de conversion pour faire la mise à l'échelle.
Les unités sont donc les suivante :
bit (unité)
octet (8 bits)
KiloOctet ou Ko (1024 octets)
MegaOctet ou Mo (1024 Ko)
GigaOctet ou Go (1024 Mo)
TéraOctet ou To (1024 Go)
PétaOctet ou Po (1024 To)
Note : A l'américaine, l'octet se dit Byte. Un equivalent est donc, le GigaByte ou Mega byte, etc... Notés : Kb, Mb, Gb, etc...
Trivia : au dessus du péta, il y a l'Exa, le Zeta, le Yotta, Ronna, Quetta, ...
IV. Les opérations en binaire
4.1 Addition
Cela fonctionne plus ou moins comme une addition standard, avec les retenues.
Selon les principes suivants :
0 + 0 = 0
(0 + 1 ou 1+0) = 1
1+1 = 10 (équivalent de 2) Donc dans ce cas, l'on pose 0 et on retient 1.
Par exemple : 00100101 + 10110010 ( soit 37 + 178 )
Détail de l'opération
retenue
Nombre 1
0
0
1
0
0
1
0
1
Nombre 2
1
0
1
1
0
0
1
0
Total
1
 
On commence par la droite. 1+0 = 1, pas de retenue.
retenue
Nombre 1
0
0
1
0
0
1
0
1
Nombre 2
1
0
1
1
0
0
1
0
Total
1
0
1
1
1
0 + 1 = 1, pas de retenue,
1 + 0 = 1, pas de retenue,
0 + 0 = 0, pas de retenue,
0 + 1 = 1, pas de retenue.
retenue
1
Nombre 1
0
0
1
0
0
1
0
1
Nombre 2
1
0
1
1
0
0
1
0
Total
0
1
0
1
1
1
1 + 1 = 10. je pose 0 et je retiens 1.
retenue
1
Nombre 1
0
0
1
0
0
1
0
1
Nombre 2
1
0
1
1
0
0
1
0
Total
1
0
1
0
1
1
1
1 + 0 = 1 puis 1 + 0 = 1. Pas de retenue
retenue
1
Nombre 1
0
0
1
0
0
1
0
1
Nombre 2
1
0
1
1
0
0
1
0
Total
1
1
0
1
0
1
1
1
enfin, 0 + 1 = 1, pas de retenue.
1
Nombre 1
0
0
1
0
0
1
0
1
Nombre 2
1
0
1
1
0
0
1
0
TOTAL
1
1
0
1
0
1
1
1
on a donc 00100101 + 10110010 = 11010111 ( soit 37 + 178 = 215 )
4.2 Soustraction
La soustraction est un peu plus complexe que l'addition, en effet il va faloir jongler sur les chiffres.
Selon les principes suivants :
0 - 0 = 0
1 - 1 = 0
1 - 0 = 1
0 - 1 = Ne peux pas directement être résolu, nécessite un emprunt.
Par exemple : 10110010 - 00100101 ( soit 178 - 37 )
Détail de l'opération
retenue
0
10
Nombre 1
1
0
1
1
0
0
1
0
Nombre 2
0
0
1
0
0
1
0
1
Total
1
 
On commence par la droite. 0-1, emprunt à gauche.
On barre le 1 à gauche on le remplace par un 0. (car 1-1=0)
On ajoute 2 soit 102 en remplacement du 0 ce qui donne le calcul 2-1 = 1.
retenue
0
10
Nombre 1
1
0
1
1
0
0
1
0
Nombre 2
0
0
1
0
0
1
0
1
Total
0
1
0 - 0 = 0 pas d'emprunt.
retenues
0
10
 
0
10
Nombre 1
1
0
1
1
0
0
1
0
Nombre 2
0
0
1
0
0
1
0
1
Total
 
0
1
 
0 - 1 non solvable sans emprunts. 
 
Pas de 1 adjacent à gauche, on va donc devoir aller chercher le premier disponible pour l'emprunter.
 
on barre le 1 que l'on remplace par 0 (1-1=0). Puis on barre le 0 à sa droite pour remplacer par 2 soit 102.
retenues
1
10
0
10
 
0
10
Nombre 1
1
0
1
1
0
0
1
0
Nombre 2
0
0
1
0
0
1
0
1
Total
1
0
1
On continue à décaler. On soustrait 1 de 2 (102), il reste 1.
Enfin, on reporte le 1 à droite et on exécute le calcul.
2 - 1 = 1.
retenues
1
10
0
10
 
0
10
Nombre 1
1
0
1
1
0
0
1
0
Nombre 2
0
0
1
0
0
1
0
1
Total
1
0
0
0
1
1
0
1
On continue ainsi :
1 - 0 = 1
0 - 0 = 0
1 - 1 = 0
1 - 0 = 1
Nombre 1
1
0
1
1
0
0
1
0
Nombre 2
0
0
1
0
0
1
0
1
TOTAL
1
0
0
0
1
1
0
1
on a donc 10110010 - 00100101 = 10001101 ( soit 178 - 37 = 141 )
V. Les fonctions binaires
Les fonctions en binaire ne sont pas des opérations à proprement parler mais le résultat d'un test livré par ce que l'on appelle en informatique et en électronique une porte logique.
5.1 AND (et)
0
0
0
0
1
0
1
0
0
1
1
1
Le résultat de la condition est vrai uniquement si les deux termes sont vrais.
5.2 OR (ou)
0
0
0
0
1
1
1
0
1
1
1
1
Le résultat de la condition est vrai si au moins l'un des deux termes est vrai.
5.3 XOR (ou exclusif)
0
0
0
0
1
1
1
0
1
1
1
0
Le résultat de la condition est vrai seulement si l'un des deux terme est vrai.
Trivia : c'est ce système là qui va être utilisé pour calculé des bits de parité. Dans les matrices RAID par exemple.
Pour aller plus loin : Wikipedia | Tables de vérité
VI. Conclusion
Au sein de l'ordinateur, tout est binaire. De la donnée écrite sur les supports de stockage, jusqu'à l'information transitant par le réseau, en passant par les opérations processeurs et le contenu de la mémoire.
Nous manipulons juste de moins en moins ce type de contenu au fil de l'évolution des langages informatiques et de programmation.
Mais il est cependant important de comprendre (au moins en théorie) comment fonctionne l'informatique sur sa couche la plus basique.

Hardware - Le RAID
Difficulté : Intermédiaire
Notions : RAID, Stockage, volumes, sécurité matérielle.
I.Notions Importantes
Le RAID ou ‘Redondant Array of Independant Disk’ consiste a prendre plusieurs supports de stockage indépendant (HDD, SSD,NVME) et les assembler en un volume virtuel dans le but d’améliorer la performance, la capacité et/ou la tolérance à la panne.
Le RAID ne remplace pas la sauvegarde !!!
Le but du RAID est avant tout de fournir une extension de capacité de volume et/ou une redondance de disque. Ce qui rendra la machine tolérante à la panne d’un ou plusieurs disques. Mais il ne s’agit en aucun cas d’une sauvegarde et une donnée perdue au sein du volume l’est pour de bon.
Sur les RAID apportant une tolérance à la panne, si un disque tombe en panne, celui-ci peut être remplacé. Le volume commencera alors automatiquement une reconstruction de volume.
Durant une reconstruction, le système n’est plus tolérant à la panne jusqu’à la fin de la reconstruction. Toute nouvelle défaillance durant cette période entrainera la perte des données.
Il est fortement recommandé de prendre des disques de même performance et capacité.
En effet, lorsque les disques seront agrégés ensemble dans un volume, l’ensemble des disques ajusteront leurs performances sur celui qui a la plus basse disponible. Cela s’explique par la nécessité d’utiliser simultanément plusieurs disques, ce qui ne peut se faire que si tous les disques ont la même vitesse de lecture/écriture. Sinon il y aurait un risque de désynchronisation.
Concernant la capacité, il s’agit a peu prés de la même raison. Si un disque est plein avant les autres, les données ne pourront théoriquement plus être écrites que sur les disques où il reste de l’espace libre. Or le but recherché ici est d’avoir une redondance des données ou d’agréger ensemble des volumes.
Pour ajouter un niveau de sécurité en plus, il est conseillé de prendre des disques provenant de lots différents.
En effet, des disques provenant tous du même lot et du même constructeur auront statistiquement la même chance de tomber en panne. Or la plupart des types de RAID classiques ne tolèrent qu’une seule panne. Ainsi, choisir des disques provenant de lots différents et donc n’ayant pas été fabriqués au même moment réduira le risque d’avoir une panne simultanée de plusieurs disques, ce qui entrainerai la perte des données du volume.
II. Raid matériel vs raid logiciel
2.1 Raid matériel
Ce type de RAID fait appel a une carte contrôleur matérielle dédiée. La carte est ajoutée au serveur et les disques sont branchés dessus.
Le principal avantage de cette méthode est que la carte dédiée dispose de son propre processeur, mémoire et stockage pour faire la mise en cache des données et les calculs de lecture ou écriture. Le volume RAID est directement présenté au système.
Celui-ci n’a donc pas a gérer les calculs liés a la répartition des blocs et toute la puissance de calcul de la machine peut être exploitée par le système.
Convient à des environnements de production.
Pours :
Contres :
Plus performant que le raid logiciel.
Ne sollicite pas la puissance de calcul.
Indépendant du système d’exploitation.
Plus coûteux (achat d’une carte dédiée).
2.2 Raid logiciel
Ce type de RAID est géré par le système. Cela le rend indépendant du Hardware mais l’absence de matériel dédié implique que les calculs doivent être gérés par le système. Utilisant donc le processeur, la mémoire et le cache des disques pour réaliser les calculs et impactant donc les performances systèmes.
Il faut donc prévoir plus de puissance que nécessaire pour compenser la baisse de performance.
Cependant, en cas de panne totale ou changement du matériel, l’ensemble du matériel peut être remplacé sans problème. Ce qui n’est pas forcément toujours le cas sur du RAID matériel (si la carte RAID lâche par exemple).
Plus adapté a un usage sur les postes de travail ou un usage domestique.
Pours :
Contres :
Moins coûteux.
indépendant du matériel.
impacte les performances.
2.3 Raid Pseudo-matériel
C’est un hybride des deux modes ci-dessus. Un contrôleur RAID est intégré à la carte mère et le système pourra s’appuyer dessus pour contrôler le RAID. Cependant, celui-ci reste géré logiciellement .
L’avantage de ce mode est surtout pour les PC de bureau. Beaucoup de cartes mères haut de gamme disposent de cette option et cela permet de mettre en place un RAID a moindre coût.
III. Principaux types de raid
3.1 Raid 0 - Striping
Prérequis : 2 disques ou plus.
Le RAID 0 ou ‘striping' est le niveau le plus basique de RAID.
Il s’agit tout simplement de prendre tous des disques participant et de les mettre ensemble pour présenter un seul gros volume au système. Permettant ainsi de cumuler les capacité des disques et d’exploiter en parallèle leurs bandes passantes. Améliorant très significativement les performances lors de la la lecture ou écriture des données.
Source : amenschool
espace exploitable : Total des disques.
Dans ce cas, deux disques de 500Go par exemples seront vu comme un volume logique de 1To (2*500Go)
Pours :
Contres :
Très performant.
Permet de disposer de gros volumes.
Capacité maximale.
N’offre aucune sécurité.
3.2 Raid 1 - Mirroring
Prérequis : 2 disques
Maximum : 32 *voir RAID Combiné 0+1
Le Raid 1 ou ‘mirroring’ consiste a prendre un disque et en faire un ‘miroir’ sur un second disque.
Chaque donnée est ainsi écrite en double, une fois sur le disque 1 et une fois sur le disque 2.
Bien que cela soit une perte nette de capacité, le système devient ainsi redondant et donc tolérant a la panne d’un des deux disques.
En situation normale, les données seront lues à partir des deux disques, augmentant ainsi les performances en lecture.
L'écriture en double de toute données quand à elle, diminue légèrement les performances en écriture.
La tolérance a la panne est de 1 disque.
Source : amenschool
espace exploitable : Total des disques / 2
Dans ce cas, deux disques de 500Go par exemples seront vu comme un volume logique de 500Go
Pours :
Contres :
Sécurisé (perte 1 disque).
Idéal pour un disque système.
Seule la moitié de la capacité est utilisable.
3.3 Raid 5 - Striping with parity Across drives
Prérequis : 3 disques minimum
Maximum : 32 (dépendant du contrôleur utilisé)
Le RAID 5 utilise un algorithme combinant les avantages des deux niveaux de RAID précédents, bien que fonctionnant de manière totalement différente.
En effet, dans ce mode de fonctionnement, les données seront constituées en blocs.
Chaque bloc sera coupé en deux et un bloc de parité sera créé et placé sur un autre disque que ceux contenant les demi blocs.
Sur le schéma suivant, le bloc A est coupé en deux blocs A1 et A2 placés chacun sur un disque puis un bloc de parité P est créé et placé sur le disque 3.
Le bit de parité est ensuite décalé et ainsi de suite de sorte a ce qu’un disque ne contienne pas uniquement les blocs de parités. Ce qui optimise l’espace utilisable.
Source : amenschool
Pour aller plus loin
Pour aller plus loin, l’opération faite sur les blocs au niveau binaire est un XOR.
Table XOR :
0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 1
Ce qui donne par exemple : bloc initial 0110110111010100
Bloc1 (disque 1) = 01101101
Bloc 2 (disque 2) = 11010100
Bloc de parité (disque 3) = 10111001
espace exploitable : Capacité Totale des disques - Capacité de 1 disque
Dans ce cas, trois disques de 500Go. la capacité utilisable est donc (500*3)-500 = 1To
Pours :
Contres :
Sécurisé (perte 1 disque).
Idéal pour un disque de données.
Bon compromis entre capacité et fiabilité.
perte de capacité équivalente à 1 disque
impact sur les performances
3.4 Raid 6 - Striping with dual parity Across drives
Prérequis : 4 disques minimum
Maximum : 32 (dépendant du contrôleur utilisé)
Le RAID 6 fonctionne sur le même principe que le RAID 5 mais améliore néanmoins celui-ci en redondant le bloc de parité, ce qui augmente la tolérance à la panne.
Source : amenschool
espace exploitable : Capacité Total des disques - Capacité de 2 disque
Dans ce cas, quatre disques de 500Go. La capacité utilisable est (500*4)-(2*500)=1To
Pours :
Contres :
Sécurité exceptionnelle (2 disques).
Idéal pour volume de stockage infra.
Seule la moitié de la capacité est utilisable.
Coûteux
3.5 Autres types de RAID
Il existe d’autres types de RAID assez exotiques, comme le RAID 3, 4, RAIDn ou RAIDdp
Pour des renseignement exhaustif sur le RAID : https://fr.wikipedia.org/wiki/RAID_(informatique)
IV. Combiner les niveaux de RAID
Il est possible de combiner plusieurs Type de RAID entre eux pour tirer le maximum de performance ou de sécurité de ceux-ci. Cependant, ces solutions sont assez peu répandues à moins d’avoir un besoin spécifique car elles deviennent rapidement très coûteuses.
La notation se fera alors de la façon suivante :
01 ou 0+1 = un RAID 1 de volumes en RAID 0
10 ou 1+0 = un RAID 0 de volumes en RAID 1
4.1 Le RAID 0+1
Prérequis : 4 disques minimum
Maximum : 32 (dépendant du contrôleur utilisé)
Il s’agit de prendre plusieurs volumes en ‘striping’ et de les ‘mirorer’ entre eux.
Ce qui permet d’agréger ensemble plusieurs volumes pour présenter un gros volume, qui sera ensuite lui-même mis en miroir sur un autre agrégat équivalent.
Dans ce niveaux, même sir une grappe RAID 0 peut être perdue, on vise avant tout les volumes de grosses capacité.
Source : amenschool
espace exploitable : Capacité totale des disques / 2
Dans ce cas, quatre disques de 500Go. La capacité utilisable est (500*4)/2=1To
4.2 Le RAID 1+0
Prérequis : 4 disques minimum
Maximum : 32 (dépendant du contrôleur utilisé)
Il s’agit de l’inverse du RAID 01. Au lieu d’agréger des disques et de les ‘mirorer’ ensuite. On agrégera une série de disques en miroirs. Cela permet de répartir différemment les pertes de disques au sein des grappes.
Ce niveau de RAID est extrêmement fiable car il faut qu’une grappe entière soit défectueuse avant de perdre les données.
Source : amenschool
espace exploitable : Capacité totale des disques / 2
Dans ce cas, quatre disques de 500Go. La capacité utilisable est (500*4)/2=1To
4.3 Autres exemples
source : Storage-insider
Source : recoverhdd.com

Hardware - Un ordinateur
Difficulté : Débutant
Notions : ordinateur, composants.
I.Introduction
Un ordinateur est défini comme étant une machine automatique de traitement de l'information, obéissant à des programmes formés par des suites d'opérations arithmétiques et logiques.
Est considéré comme ordinateur tout système possédant les caractéristiques suivantes :
Effectuer des calculs et opérations préprogrammées.
Stocker des informations.
Avoir une capacité de mise en réseau.
lien utile : https://fr.wikipedia.org/wiki/Ordinateur
II. Différents Types d'ordinateurs
Fixe (desktop)
Portable (laptop)
Tablette
Serveur tour
Serveur rackable
Micro ordinateur
Il existe également des “Barebones” qui sont des bases dites “nues” et sans OS pour créer un système personnalisé. Le coût de ceux-ci sont relativement bas, mais il faut prévoir d’ajouter un OS voire certaines pièces.
Barebone PC
Barebone Stockage
Barebone réseau
III. Les composants

Infrastructure
Notions théorique liées à l'infrastructure.

Infrastructure - La virtualisation
Difficulté : Intermédiaire
Notions : Hyperviseurs
I. Introduction
La virtualisation est une technologie qui permet d'exécuter plusieurs systèmes d'exploitations et environnements isolés sur une même machine physique. Optimisant ainsi l'utilisation du matériel et améliorant la flexibilité et la 'scalabilité' des infrastructures informatiques.
Les hyperviseurs sont aujourd'hui devenu un élément essentiel des infrastructures informatiques.
En effet, traditionnellement dans l'informatique, un serveur est une machine physique où l'on va installer un système d'exploitation et des rôles ou des fonctionnalités pour fournir un service aux utilisateurs. Mais avec l'arrivée de la virtualisation, il est devenu possible de détacher les serveurs et services de l'aspect matériel.
Cela apporte certains avantages :
Réduction des coûts
Réduction des coûts liés au matériel.
Simplification de la maintenance et des déploiement.
Flexibilité
Les machines peuvent être rapidement déployées ou détruites pour suivre l'évolution du besoin.
Elles peuvent être clonées, déplacées sur d'autres matériels physiques ou sites distants.
On peut faire évoluer leur matériel afin d'ajuster leurs performances.
Création rapide d’environnements de tests ou de formation.
Consolidation
Les machines peuvent être regroupées sur un seul serveur.
Avec la haute disponibilité, amélioration de de la disponibilité des services.
Info : La virtualisation se démarque de l'émulation dans le fait qu'elle permet de faire fonctionner des machines complètes incluant l'OS et le matériel virtualisé associé, là où l'émulation reproduit logiciellement un matériel différent.
II. Les types d'hyperviseur
2.1 Hyperviseurs de type 1
Les hyperviseur de type 1, aussi appelé Bare-metal, sont des hyperviseurs installés directement sur le matériel.
Par exemple : VMware ESXi, Hyper-V, Proxmox VE, Xen...
Cela convient particulièrement à des infrastructures de production.
Pours :
Performances élevées
Meilleure isolation
Fiabilité pour la production
Possibilité de paramétrer de la haute disponibilité
Contres :
Plus coûteux (achats de licences).
Nécessite du matériel spécifique aux performances élevées.
Nécessite de solides compétences pour une bonne mise en oeuvre.
2.2 Hyperviseurs de type 2
Les hyperviseur de type 2, aussi appelé Hyperviseur hébergés, sont des hyperviseurs installés comme un logiciel ou un service par dessus un système hôte existant.
Par exemple : VMware workstation, VirtualBox, Parallels...
Cela convient particulièrement à des environnements de développement, tests ou prototypage.
Pours :
Simple à installer
Simple à prendre en main
Idéal sur poste de travail
Contres :
Moins d'isolation par rapport au système hôte.
Moins performant.
Moins fiables.
Fonctionnalités réduites.
2.3 Choisir son hyperviseur
En définitive, le choix de l'hyperviseur dépend avant tout de son usage de destination.
Si l'objectif est de monter une infrastructure de production avec une bonne redondance, choisir le type 1.
Sinon, si l'objectif est de disposer d’environnements de tests à des fins de développement ou de prototypage de solutions, privilégier un type 2.
Le choix de la solution dépendra ensuite du budget et des fonctionnalités recherchées.
III. Architecture de plateforme virtualisée
Une architecture de plateforme virtualisée s'articule autour des composantes traitées ci-dessous. Chaque composante aura son rôle et son importance dans certains aspects de la performance ou compatibilité de l'infrastructure.
3.1 Matériel de l'hôte physique
Il s'agit de l'hôte en tant que machine physique sur lequel sera installé l'hyperviseur. Comme toute machine physique, il s'agit d'un serveur matériel avec son hardware.
Le matériel choisi pour le(s) hôte(s) physique(s) influera directement les performances et capacités de l'infrastructure.
Les points à prendre en comptes sont évidement :
Le ou les CPU et leur nombre de cœurs
la RAM
Le type de stockage (HDD, SSD, hybride, tearing, ...)
La bande passante des cartes réseaux.
Info : Il est également primordial que la machine choisie dispose des capacité de virtualisation (intel-VT ou AMD-VT).
3.2 L'hyperviseur
L'hyperviseur est le gestionnaire des machines virtuelles. Il permet leur création, manipulation, paramétrage et est également en charge de l'allocation et le suivi des ressources pour les machines virtuelles.
Comme évoqué plus haut, le choix du type de celui-ci dépendra de l'usage.
Le choix du produit quand à lui devra être guidé par les contraintes budgétaires, de performances, mais également les éventuels aspects contractuels.
Comparatif hyperviseurs
Hyperviseur
Type
Fonctionnalités clés
Fourchette budgétaire (indicative)
Mode de licensing
VMware ESXi / vSphere
Type 1
Haute disponibilité (HA), vMotion, DRS, snapshots avancés, gestion centralisée via vCenter, très mature
Moyen à très élevé selon l’édition (Essentials → Enterprise Plus)
Licence par CPU + options (vCenter, fonctionnalités avancées)
Microsoft Hyper‑V
Type 1
Intégration Windows Server, Live Migration, Replica, clustering, snapshots, gestion via SCVMM
Faible à moyen (inclus dans Windows Server)
Licence Windows Server (Standard ou Datacenter), par cœur CPU
Proxmox VE
Type 1
KVM + LXC, clustering simple, snapshots, backup intégré, interface web complète, Ceph intégré
Très faible (open‑source, support payant optionnel)
Gratuit (AGPL) + abonnement support optionnel
XCP‑ng
Type 1
Basé sur Xen, live migration, snapshots, gestion via Xen Orchestra, cluster
Très faible à faible
Gratuit (open‑source) + support commercial via Vates
Oracle VM VirtualBox
Type 2
Multi‑OS, snapshots, portable, idéal labo/test, large compatibilité
Gratuit
Gratuit (GPL + extension pack sous licence Oracle)
VMware Workstation / Fusion
Type 2
Environnements de test, snapshots, clonage, réseau virtuel avancé
Faible (licence unique)
Licence poste utilisateur
KVM (Linux)
Type 1 (intégré OS)
Très performant, supporté par la plupart des distributions, snapshots, live migration via libvirt/virt‑manager
Gratuit
Inclus dans Linux (GPL), support via distributions
source : copilot, basé sur une liste de sources et de critères définies dans le prompt.
3.3 Les machines virtuelles
Les machines virtuelles sont les machines hébergées sur l'hyperviseur. Comme toute machine, elles disposent d'un matériel avec ses caractéristiques, sauf que celui-ci n'est pas physique mais plutôt logiciel. Aussi, chaque machine se voit allouée des ressources définies comme suit :
Vcpu et Vcore ( un nombre de socket et de cœurs de CPU que la machine pourra exploiter)
Mémoire virtuelle (une quantité de RAM maximum allouée à la machine)
Disques virtuels ( souvent sous la forme de fichiers .vmdk, .vhdx, etc.. ; C'est l'espace disque maximal qui sera alloué à la machine)
Carte réseau virtuelle ( une interface réseau pour la connectivité, souvent la gestion des adresses MAC est gérée par l'hyperviseur)
3.4 Les outils de gestion
Afin de gérer le ou les hyperviseur(s) la plupart des solutions intègrent des outils de gestion. Souvent sous la forme d'appliances ou de machines dédiées, ils sont généralement accessibles via une interface web et permettent la configuration du cluster, des hôtes et la gestion des machines virtuelles.
On pourra citer par exemple VMware Vcenter, ProxmoxVE, Hyper-V manager, etc...
3.5 Notions de cluster
Par nature, les machines virtuelles sont donc dé-corrélées du matériel physiques sur lequel elles s'appuient et son donc 'portables'.
On peut ainsi les déplacer d'un hôte à un autre. Cela ouvre la voie à une notion de cluster.
Un cluster est un groupement d'hôtes gérés par un manager qui vont donc pouvoir travailler ensemble afin de se répartir les machines virtuelles. Ce qui permet ainsi :
La haute disponibilité ( les machines peuvent être répliquées et disponibles sur plusieurs hôtes)
La migration à chaud ( les machines peuvent être déplacées d'un hôte à un autre sans forcement les éteindre)
La répartition de charge ( il est possible de répartir les VM afin d'optimiser la consommation de ressources )
IV. Allocation et gestion des ressources
La gestion des ressources et l'un des aspects les plus importants de la virtualisation.
Une VM ne possède pas réellement ses propres composants matériels. Elle reçoit une portion des ressources de l'hôte physique et l'hyperviseur doit en permanence arbitrer entre les besoin de l'ensemble des VM.
Lors de l'allocation de ressources à une VM, il y a plusieurs facteurs à prendre en compte.
4.1 Le CPU
Sur une VM, il est possible d'allouer de la puissance de calcul en ajoutant des Vcpu et des Vcore.
 Un vCPU correspond à un thread logique que l’hyperviseur peut planifier. Un vCore est une manière de présenter ces vCPU à la VM.
En définitive, il est possible d'allouer plus de Vcpu ou Vcore au VM que ce qui est réellement présent sur la machine. Cela est possible car l'hyperviseur sais répartir la charge des instruction sur son matériel physique et que toutes les VM ne sont pas tout le temps à 100% de leur utilisation CPU. Cela s'appelle l'Overcommit CPU.
Exemple : un hôte à 64Go de RAM / 16cores, on provisionne 8VM à 4 Vcpu. Il y a overcommit. Cela ne posera pas de problème à moins que la charge sur les machine soit à 100% sur chacune d'elles sur une longue période.
Attention : Contrairement à ce que l'on peut penser, il n'est pas forcement bon d'allouer plus de Vcpu que réellement nécessaire. En effet, cela peut mener à une situation ou une VM attends d'exécuter des instructions, mais l'hyperviseur n'a pas de CPU disponibles car déjà alloués aux autre machines. Cela créée donc des tentions sur le CPU et des contentions entre VM. Ce phénomène s'appelle le 'CPU Ready'.
Un CPU Ready élevé indique :
surcharge CPU de l’hôte
trop de vCPU attribués
VM surdimensionnées
contention entre VM
Ordres de grandeur :
< 5 % : normal
5–10 % : surveiller
10 % : impact visible (latence, lenteur)
20 % : problème sérieux
Exemple : Une VM avec 8 cœurs sur un host 4 cœurs --> CPU Ready élevé garanti !
Il est donc important de bien dimensionner les VM pour n'attribuer que le nombre de Vcore nécessaire à son fonctionnement.
4.2 La mémoire
La Mémoire est LA ressource critique lorsque l'on parle de virtualisation. En effet, c'est le point sur lequel il est le moins possible de faire de compromis car les services qui sont lancés sur une VM vont consommer une certaine quantité de mémoire au minimum, puis des parts par utilisateurs utilisant le service.
Les hyperviseur vont ensuite utiliser plusieurs mécaniques pour en partager et en optimiser l'usage.
Comme pour le CPU, il est possible d'allouer plus de ressource mémoire que disponible sur l'hôte. Cela s'appelle l'Overcommit mémoire.
L'hyperviseur va ensuite se reposer sur plusieurs mécaniques. Dont :
Le ballooning
Lors de l'installation des pilotes de l'hyperviseur sur les systèmes invités, un driver appelé 'balloon' a été installé. Le 'ballon' dans les VM est une portion de la mémoire qui peut être récupérée par l'hyperviseur pour être affectée de manière 'scalable' à d'autres VM.
En cas de tension sur l'hyperviseur, celui-ci 'gonfle' le ballon qui prends la forme d'un processus réservant de la RAM sur la VM invitée. Cette RAM n'est alors plus utilisable par la VM car elle la juge déjà utilisée par ce processus. L'hyperviseur réaffecte donc cette plage de RAM réservée à une autre VM qui en a besoin.
Dès que la tension est libérée, le ballon est 'dégonflé' et la RAM réservée est rendue à la VM.
Info : Bien que le ballooning ne soit pas un problème en soi, il deviens problématique dès lors que les VM impactées n'ont plus assez de ressources mémoire pour fonctionner normalement. Cela cause du swapping et donc des lenteurs.
La compression
L'hyperviseur est capable de compresser certaines pages mémoire peu utilisées pour économiser de la mémoire.
Swapping hyperviseur
Tout comme n'importe quelle machine, en cas de sur utilisation de la mémoire, l'hyperviseur est également capable de swap. C'est à dire qu'il va commencer à écrire des pages mémoires sur le disque. Au vu de la dégradation de performances que cela implique, c'est une situation à éviter.
4.3 Le stockage
Le choix du stockage est important et doit être déterminé par les fonctionnalités souhaitées.
Un stockage local en SSD est rapide et offre d’excellentes performances. La sécurité peut en être améliorée avec du RAID.
Attention : Le RAID permet une sécurité locale mais ne permet pas de faire de la haute disponibilité.
Pour cela, il faudra opter pour un stockage mutualisé de type NAS ou SAN, ce qui rendra les VM visibles depuis l'ensemble des nœuds du cluster et permettra une bascule rapide en cas de coupure ou maintenance d'un hôte.
Cela permettra aussi d'activer des fonctions d'optimisation de charge et de consommation électrique, ainsi que des règles de répartition des VM.
Exemple : 2 actives directory redondants ne doivent pas se trouver en même temps sur un même nœud.
Si la solution du stockage partagée est privilégiée, il faudra également prendre en compte la liaison réseau avec les hôtes. En effet la bande passante de celle-ci impactera grandement les performances en lecture/Ecriture sur les volumes.
Il est préférable également d'opter pour des cartes réseaux dédiées et optimisées pour cet usage comme les cartes Melanox
En effet, en plus de leur excellentes capacité réseaux, celles-ci intègrent un cache dédié pour le stockage et l'écriture de blocs.
Les transactions sur le stockage se mesure en IOpS (Input/Output per Second). C'est cet indicateur qu'il faut vérifier pour mesurer la performance du stockage.
V. Les fonctionnalités avancées
Comme vu plus haut, dans la logique de la virtualisation, les VM ne sont plus directement corrélées au matériel. Cette couche d'abstraction implique que la VM soit vue par l'hyperviseur comme simplement un processus et un ensemble de fichiers.
Cela ouvre la porte a beaucoup de fonctionnalités intéressantes et qui sont devenue clés de la gestion des machines virtuelles au sein d'une architecture d'entreprise.
5.1 Les snapshots
Un snapshot ou 'cliché instantané', est un point de restauration d'une machine à un instant T.
Lors d'une prise de snapshot, le fichier de disque actuel de la VM est figé, un nouveau fichier de disque est créé. Celui-ci contient le Delta depuis le dernier snapshot.
Il sera ensuite possible de faire des modifications, puis de revenir en quelques minutes à cet état précédent. Annulant ainsi tout ce qui est survenu depuis.
Ou de valider cet état comme définitif et de supprimer les snapshots. Auquel cas, les fichiers du snapshot sont supprimés et les fichiers de disques sont fusionnés.
C'est particulièrement utile pour sécuriser ponctuellement une opération comme une mise à jour, un changement de version ou un test quelconque.
Il est également possible de faire un snapshot, tester un scénario, refaire un snapshot, revenir sur l'original, tester un autre scénario, refaire un snapshot, etc... les snapshots seront ainsi géré en arborescence.
Lors de l'effacement des snapshots, ceux utilisés seront fusionnés, les autres seront détruits. Cette opération s'appelle la 'consolidation'.
Attention : Les snapshots ne sont pas des sauvegardes. Si cela est utile pour un usage ponctuel, il n'est pas recommandé de les empiler et encore moins de les conserver de façon durable.
5.2 Live migration
Une 'Live migration' ou migration à chaud est le fait de déplacer une VM d'un hyperviseur ou d'un nœud d'une ferme à un autre, sans forcément avoir besoin d'éteindre cette machine et donc sans interrompre le service.
Selon le type de migration, l'hyperviseur fait tout d'abord une copie du fichier descriptif de la VM, puis copie les disques et enfin le fichier mémoire. Dès lors que l'état de la VM est synchronisée sur le nœud source et le nœud de destination, la VM source est coupée et ses fichiers sont détruits.
Dans le cadre de l'utilisation d'un stockage partagé, c'est plus simple dans la mesure ou il suffit juste de transférer les fichiers mémoires.
Le déplacement peut être un déplacement sur une autre puissance de calcul, sur un autre stockage voire les deux.
5.3 High availability & Fault Tolerance
La haute disponibilité et la Tolérance à la panne, sont des mécanismes qui exploitent la capacité de transfert d'une machine d'un hôte à un autre pour permettre automatiquement, en cas de coupure d'un nœud ou d'une VM, d'en reprendre l'exécution depuis un autre nœud.
5.4 Load balancing, fencing
Partant de ce même principe et afin de fiabiliser celui-ci, il est possible de définir des ensembles de règles afin d'éviter que deux machines portant le même rôle dans un but de haute disponibilité se retrouvent au même moment sur le même hôte physique.
Ou inversement, pour des raisons d'économie d'énergie, de regrouper les machines virtuelles sur un même hôte physique afin d'optimiser le rendement énergétique.
5.5 Templates et clônes
La dernière fonctionnalité intéressante est de pouvoir, grâce au snapshots et au fait que les machines soient des ensembles de fichiers, est de pouvoir installer une machine, la préparer et la transformer en 'template' ou modèle.
Cela permet ensuite de repartir de ce modèle afin de faire des déploiement en masse et de standardiser la production. Ce qui représente également un gain de temps non négligeable, car ce qui a été fait une fois pour le template, n'a plus à être refait par la suite.
A partir de ce template, il sera possible de déployer des clones. Il y a deux façons de créer un clone :
Clone lié (la nouvelle machine se base sur les fichiers de l'ancienne et seul le delta est créé)
Clone intégral (la machine est entièrement recréée à partir du modèle)
La création d'un clone lié à l'avantage d'être immédiate mais l'inconvénient de dépendre des disques des templates pour fonctionner (un peu à la manière des snapshots). En cas de corruption de celui-ci, l'ensemble des clones liées seront rendus inopérants.
La création d'un clone intégral prends plus de temps et de place sur le disque. C'est en effet une nouvelle machine intégralement créée, mais totalement indépendante.
En résumé, les clones liés sont pratique pour faire des tests rapides, mais pour de la production, il faut privilégier les clones intégraux.
5.6 Thin provisioning
Le thin provisionning, ou provisionnement dynamique, permet de n'allouer à une machine virtuelle que l'espace disque qu'elle va occuper. La taille définie sur le disque agit ici plus comme une 'limite totale d'espace disponible' que comme une réservation stricte de l'espace disque.
Cette fonctionnalité est très pratique pour des tests et pour optimiser l'espace disque disponible. Mais cela est fortement déconseillé dans un environnement de production car elle entraîne un risque de sur-provisionnement.
En effet, l'espace disque côté hyperviseur est perçu comme libre. Mais si les machines consomment toutes la capacité de leur disque au maximum, la capacité maximale de l'espace de stockage peut être dépassée, ce qui conduit au remplissage à 100% de celui-ci et potentiellement à une corruption des données.
Exemple : 10 VM de 100Go en thin provisioning sur un datastore de 500Go --> Si les VM se mettent à utiliser tout le stockage, risque de corruption et de perte de données.
VI. Virtualisation du stockage
Datastores
SAN / NAS / iSCSI / NFS
vSAN / Ceph / stockage distribué
Impact des performances disque sur les VM
VII. Virtualisation réseau
vSwitch / vNIC
VLAN, trunking, tagging
Distributed Virtual Switch
SDN (Software Defined Networking) : principes de base
VIII. Sécurité dans un environnement virtualisé
Isolation des VM
Risques spécifiques (VM escape, snapshots oubliés, sprawl)
Sécurisation de l’hyperviseur
Gestion des accès et rôles (RBAC)
Chiffrement des VM / disques / migrations
IX. Administration et bonnes pratiques
Planification des ressources
Monitoring (CPU ready, IOPS, latence, mémoire)
Sauvegarde des VM (image‑level, agent‑based)
Gestion du cycle de vie des VM
Documentation et gouvernance
X. Virtualisation et Cloud
Virtualisation vs Cloud
IaaS, PaaS, SaaS
Conteneurs et orchestrateurs (Docker, Kubernetes)
Notion de virtualisation “cloud-native”

Infrastructure - Les Tiers de datacenter
Le classement des data centers
L’organisme ayant pour dénomination Uptime Institute qui est un laboratoire d’idées ayant pour but de rechercher les solutions permettant aux data centers d’offrir des services performants a classé les niveaux de sécurité offerts par ces structures en quatre tiers différents.
En France, les certifications correspondant à ces niveaux de sécurité sont effectuées depuis le mois de janvier 2014.
Le niveau Tier 1
Un data center ayant le niveau Tier 1 ne possède qu’un seul circuit électrique ainsi qu’un circuit de distribution de refroidissement et il n’a pas de composants redondants. Sa disponibilité est de 99,67 % et ses clients doivent prendre en compte une interruption annuelle de 28 heures et huit dixièmes.
Le niveau Tier 2
Ce niveau est attribué à un data center ayant un circuit électrique et un circuit de distribution de refroidissement , mais ayant des composants redondants. La disponibilité offerte est de 99,75 % et il faut prévoir 22 heures d’interruption chaque année.
Le niveau Tier 3
La classification Tier 3 est accordée à un data center ayant plusieurs circuits d’alimentation en électricité et de distribution de refroidissement. La disponibilité offerte doit s’élever à 99,982% avec une interruption limitée à un peu plus d’une heure et demie chaque année.
La redondance offerte s’élève à N+1. En conséquence, cette redondance n’est ni intégrale ni entièrement distincte. Il en résulte que l’absence totale d’incidents sérieux sur les éléments constituant l’infrastructure n’est pas totalement garantie.
Le niveau Tier 4
Cette classifications qui correspond au meilleur niveau de garantie d’un data center n’est accordée que si le data center a plusieurs circuits assurant l’alimentation en électricité et la distribution du refroidissement.
La redondance doit atteindre 2N+1 et l’interruption annuelle ne doit pas dépasser 48 minutes.
Les clients qui choisissent un data center ayant ce niveau bénéficient donc d’une garantie totale pour la protection de leurs stocks de données informatisées.
De plus, les serveurs stockés dans un data center ayant le niveau Tier 4 bénéficient d’un bloc d’alimentation doublé, de la disponibilité de deux processeurs et de la possibilité d’un changement de disque en Hot Swap, ce qui permet aux collaborateurs de remplacer un composant défaillant sans qu’il soit nécessaire d’interrompre la disponibilité du serveur concerné.
L’importance du niveau de classification dans le choix du data center
Toute entreprise qui doit externaliser le stockage de ses serveurs informatiques doit choisir un prestataire ayant un niveau de qualification adapté aux conditions exigées par le contenu de ces données.
Si les données stockées on une importance vitale, le choix d’un data center ayant le niveau Tier 4 est indispensable, car l’entreprise ne peut pas prendre le risque de voir ces données effacées à cause d’une panne d’électricité ou d’une défaillance du système de contrôle de la température du data center. 
Un data center ayant une classification inférieure ne peut être choisi que si l’entreprise peut supporter sans dommage la détérioration d’un stock de données.

Licensing
Notions théoriques liées au licencing des différents produits.

Licensing Microsoft - Modèle général
Difficulté : Débutant
Notions : Licensing Microsoft, types de licences.
Cette fiche est complémentaire avec : Licensing Microsoft - Windows Server
I. Les Licences OEM
Il s’agit de la licence la plus courante. Celle dont dispose l’ensemble des machines vendue dans le commerce. Dans ce modèle, la licence est attachée à la machine et à usage unique.
La machine est fournie à l’utilisateur activée.
La licence est indissociable du matériel. Si le Poste est remplacé où mis au rebut, la licence est perdue avec.
L’utilisateur peut ainsi, par exemple, restaurer ou formater sa machine et conserver sa licence. Mais si il souhaite changer de machine sa licence ne pourra pas être transférée.
II. Les licences Retail
Le second modèle dit des licence de revente présente un avantage certain pour les particuliers et entreprises soucieuse de gérer un parc de licences.
En effet, dans ce modèle la licence est acheté indépendamment du matériel.
Il y a deux types de licence dans cette catégorie :
la licence par poste : une licence est liée à un poste et ce poste peut être utilisé indifféremment par un nombre illimité d’utilisateur. La licence retail est indépendante du matériel et ne doit être que sur une machine à la fois. Mais contrairement à la licence OEM, celle-ci peut être transféré d’une machine à une autre. Sous réserve de désactiver l’ancienne.
La licence par utilisateur : la licence est liée à l’utilisateur et non plus à la machine. L’usage lui en est donc réservé, mais elle est valide peu importe le nombre de machine que l’utilisateur possède. Pour un particulier ou un utilisateur ayant plusieurs postes, c’est le modèle le plus avantageux. Depuis Windows 10, cette licence peut être associée à un compte Microsoft. Et le fait de s’authentifier avec son compte Microsoft sur n’importe quelle machine active de facto celle-ci.
III. Les licences en volume
Ce modèle s’adresse d’avantage aux entreprises. Il s’agit de prendre un nombre défini de licences qui pourront être ensuite utilisées au sein d’une entreprise de manière complétement indépendante de son parc ou des salariés.
Le principal avantage de ce type d’acquisition, c’est qu’il ouvre le droit à l’utilisation des systèmes d’activation automatisés et qu’une entreprise peut désormais raisonner en pool de licence et affectation de celles-ci.
Pour l’activation, les clients nécessitent des clés spéciales dites “KMS Client”. Elles sont disponibles ici : Windows - Liste des clés KMS
Pour obtenir des licences en volume, il y a deux façon de procéder :
Achat d’un lot de licence : il s’agit de prendre en lot un nombre défini de licence chez un revendeur qui fera ici office de “grossiste”. Par ce biais, il est possible de prendre par exemple un lot de 100 licences qui pourra ensuite être étendu par l’achat de lots supplémentaires. L’acquisition de ces licences se fait également par machine ou par utilisateur. Dans ce modèle les licences peuvent être transférées de façon illimitée d’un poste à l’autre ou d’un utilisateur à l’autre. La seule contrainte est de ne pas dépasser le nombre d’utilisation simultanées autorisée par le pool de licence.
Contrat OPEN : Il s’agit d’un contrat ouvert chez Microsoft. Lorsqu’un contrat open est ouvert, Microsoft met a disposition un pool de licence à la demande du client. Le client pourra alors augmenter son pool de licence comme il le souhaite sans pour autant ré-ouvrir un nouveau contrat. En effet a l’inverse de l’achat en lot, ici le contrat couvre un pool et les extensions de pool seront rattachés au contrat existant.
IV. Licences additionnelles et CAL
Dans certains cas, en plus des licences de produits, son utilisation nécessitera des CAL ou “Client Access Licences”. Ces licences sont à acquérir en plus des licences produits pour le serveur.
Ce qui donne donc une licence pour le serveur et une CAL par utilisateur ou machine selon le modèle choisi. Sachant qu’il est possible de mixer les deux formules.
4.1 Active directory
Pour active directory, la fonctionnalité est comprise dans Windows Server et ne nécessite pas de licence serveur.
Il faut cependant, des cals machines et/ou utilisateurs.
La manière la plus simple est de prendre une CAL pour chaque utilisateur de domaine.
4.2 Exchange
Pour Exchange, il faut une licence serveur pour chaque serveur ou le produit est installé.
Plus une CAL par boite aux lettre utilisateur.
Les alias, boites partagées et comptes de services ne comptent pas et n’ont pas besoin de licences.
4.3 MS SQL Server
Pour SQL Server, il faut une licence serveur pour chaque serveur ou le produit est installé.
Il faut ensuite une CAL par utilisateur qui accède directement OU indirectement aux bases de données.
Ce qui signifie qu’en théorie, pour une application métier comptant 5 utilisateurs qui stocke ses données dans la base et les utilisent a travers un compte de service unique, il faut quand même 5 CAL Utilisateur.
Passé un certain nombre d’utilisateurs, il peut être plus rentable de passer a une licence par coeur de processeur.
V. Office 365
Concernant les licences Office365, la logique change radicalement. Il ne s’agit plus en effet de devenir propriétaire des licences, mais de louer un service.
Le service comprends un certain nombre de fonctionnalité disponibles individuellement pour chaque utilisateur en fonction de sa formule.
Acheter Microsoft 365 - Comparer les abonnements pour TPE/PME

Licensing Microsoft - Windows Server
Difficulté : Débutant
Notions : Licensing Microsoft, windows server.
Complète la documentation suivante : Licensing Microsoft - Modèle général
I. Présentation
Depuis windows 2016, le modèle de licence a changé pour s’adapter aux évolutions du marché.
En effet, avec la démocratisation de la virtualisation et par conséquent l’arrivée de microsoft Hyper-V, la virtualisation est devenu un standard de l’IT.
Il faut donc maintenant suivre le modèle de licencing suivant :
II. Explications
Les licences windows serveur sont des licences par coeur physique de processeur.
Windows serveur se décline désormais en deux éditions :
Standard : une licence standard est liée à un hôte physique et donne le droit a deux machines virtuelles sur cet hôte.
Datacenter : une licence datacenter est liée à un hôte physique et donne le droit à un nombre illimité de VM.
Les contraintes sont les suivantes : 
Dans la mesure où le modèle de licence est prévu à la base pour Hyper-V. Une licence est installée sur l’hôte Hyper-V et sert a activer celui-ci, ainsi que 2 machines virtuelles sur cet hôte. Dans le cas de l’utilisation d’un autre hyperviseur (vmware, proxmox, etc…) la licence ne s’applique donc qu’au 2 machines virtuelles.
Il y a un seuil minimum de cœurs licenciés par hôte physique. Celui-ci est de 8 dans le cas d’une machine avec 1 ou 2 processeurs physiques et de 12 dans le cas d’une machine avec 3 processeurs physiques.
Les licences sont attachées à l’hôte physique. Aussi, il n’est pas possible d’avoir par exemple la même licence pour 2 VM qui fonctionneraient sur des hôtes physiques différents.
De la même manière, les coeurs couverts par les licences ne concernent que l’hôte physique qui les possède.
Si le nombre de cœurs physiques dépassent le seuil minimum, il faut acheter des packs d’extension de licence pour couvrir les cœurs supplémentaires. Ceux-ci sont sous la forme de packs de 2 cœurs.
Les cœurs virtuels (threads) ne comptent pas dans le calcul.
III. Exemples
Le principe n’étant pas facilement compréhensible, voici quelques exemples pour mieux comprendre.
Exemple 1 : 
1 serveur avec 2 processeurs Xeon de 4 cœurs qui hébergera 4 machines virtuelles.
Dans cette situation : 1 serveur X 2 processeurs X 4 cœurs donc un total de 8 cœurs.
Une licence couvre 2 machines virtuelles donc 4VM / 2 = 2 packs de 8 cœurs.
Il me faut donc dans ce cas 2 packs de 8coeurs pour couvrir toutes mes machines.
Exemple 2 : 
2 serveurs avec 2 processeurs Xeon de 6 cœurs qui hébergera 5 machines virtuelles.
Dans cette situation : il faut calculer par serveur. La distribution des machines se fera de la façon suivante :
Le premier hôte hébergera 3 machines
le second en hébergera deux.
Donc pour le premier hôte : 1 serveur X 2 processeurs X 6 cœurs donc un total de 12 coeurs. Il faut donc 1 “starter pack” de 8 cœurs + 2 extension pour 2 cœurs supplémentaires.
Il y a 3 machines. Une licence étant valable pour 2 machines, il faut donc multiplier les quantités par deux.
On a donc pour le serveur 1 : 2 pack de 8 + 4 pack de 2.
Pour le second hôte : 1 serveur X 2 processeurs X 6 cœurs donc un total de 12 cœurs. Il faut également un pack de 8 cœurs + deux extensions pour 2 cœurs supplémentaires. Il n’y a que 2 machines virtuelles sur ce serveur, donc : 1 pack de 8 + 2 pack de 2.
Au total, pour licencier tout le parc, il faut donc 3 packs de 8 et 6 packs de deux.
IV. Licences Datacenter
Comme vu plus haut, les licences Datacenter sont liées a une machine physique et ouvrent le droit à un nombre illimité de machines virtuelles sur ce serveur. Si l’on sait donc a l’avance que le nombre de machine risque d'être important, ou de varier énormément au cours du temps, cette licence est à envisager.
Cependant, elle est bien plus coûteuse qu’une licence standard. Aussi il est important de calculer au préalable le seuil de rentabilité d’une telle licence.
A titre d’exemple, pour un hôte physique classique ( 2 processeurs 4 cœurs ), il faut 10 machines virtuelles pour que la licence Datacenter soit rentable.
V. Conclusion
Ce modèle de licence est réellement compliqué à appréhender au premier abord. Mais cela viendra en pratiquant. Mais heureusement 
 :
Un calculateur de licence est disponible : Windows Server Licensing Calculator - WintelGuy.com

Windows - Liste des clés KMS
Ces clés KMS sont légales. Il s'agit de celles fournies par Microsoft pour l'activation des clients KMS en volume.
Ces clés seules ne suffisent pas à activer Windows. Elles indiquent au système qu'il sera un client activé par un serveur KMS.
Ces clés sont toutes utilisables dans le cadre d'un contrat de licence en volume.
Pour l’activation en volume, il faut fournir une clé spécifique au client. Dite clé de client KMS.
Voici la liste des clés :
Windows Server (LTSC versions)
Windows Server 2025
Windows Server 2025
Operating system edition
KMS Client Product Key
Windows Server 2025 Standard
TVRH6-WHNXV-R9WG3-9XRFY-MY832
Windows Server 2025 Datacenter
D764K-2NDRG-47T6Q-P8T8W-YP6DF
Windows Server 2025 Datacenter : Azure Edition
XGN3F-F394H-FD2MY-PP6FD-8MCRC
Windows Server 2022
Windows Server 2022
Operating system edition
KMS Client Product Key
Windows Server 2022 Datacenter
WX4NM-KYWYW-QJJR4-XV3QB-6VM33
Windows Server 2022 Standard
VDYBN-27WPP-V4HQT-9VMD4-VMK7H
Windows Server 2019
Windows Server 2019
Operating system edition
KMS Client Product Key
Windows Server 2019 Datacenter
WMDGN-G9PQG-XVVXX-R3X43-63DFG
Windows Server 2019 Standard
N69G4-B89J2-4G8F4-WWYCC-J464C
Windows Server 2019 Essentials
WVDHN-86M7X-466P6-VHXV7-YY726
Windows Server 2016
Windows Server 2016
Operating system edition
KMS Client Product Key
Windows Server 2016 Datacenter
CB7KF-BWN84-R7R2Y-793K2-8XDDG
Windows Server 2016 Standard
WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY
Windows Server 2016 Essentials
JCKRF-N37P4-C2D82-9YXRT-4M63B
Windows Server (Semi-Annual Channel versions)
Windows Server, versions 20H2, 2004, 1909, 1903, and 1809
Windows Server, versions 20H2, 2004, 1909, 1903, and 1809
Operating system edition
KMS Client Product Key
Windows Server Datacenter
6NMRW-2C8FM-D24W7-TQWMY-CWH2D
Windows Server Standard
N2KJX-J94YW-TQVFB-DG9YT-724CC
Windows 11 and Windows 10 (Semi-Annual Channel versions)
See the Windows lifecycle fact sheet for information about supported versions and end of service dates.
Windows 11 and Windows 10 (Semi-Annual Channel versions)
Operating system edition
KMS Client Product Key
Windows 11 Pro
Windows 10 Pro
W269N-WFGWX-YVC9B-4J6C9-T83GX
Windows 11 Pro N
Windows 10 Pro N
MH37W-N47XK-V7XM9-C7227-GCQG9
Windows 11 Pro for Workstations
Windows 10 Pro for Workstations
NRG8B-VKK3Q-CXVCJ-9G2XF-6Q84J
Windows 11 Pro for Workstations N
Windows 10 Pro for Workstations N
9FNHH-K3HBT-3W4TD-6383H-6XYWF
Windows 11 Pro Education
Windows 10 Pro Education
6TP4R-GNPTD-KYYHQ-7B7DP-J447Y
Windows 11 Pro Education N
Windows 10 Pro Education N
YVWGF-BXNMC-HTQYQ-CPQ99-66QFC
Windows 11 Education
Windows 10 Education
NW6C2-QMPVW-D7KKK-3GKT6-VCFB2
Windows 11 Education N
Windows 10 Education N
2WH4N-8QGBV-H22JP-CT43Q-MDWWJ
Windows 11 Enterprise
Windows 10 Enterprise
NPPR9-FWDCX-D2C8J-H872K-2YT43
Windows 11 Enterprise N
Windows 10 Enterprise N
DPH2V-TTNVB-4X9Q3-TJR4H-KHJW4
Windows 11 Enterprise G
Windows 10 Enterprise G
YYVX9-NTFWV-6MDM3-9PT4T-4M68B
Windows 11 Enterprise G N
Windows 10 Enterprise G N
44RPN-FTY23-9VTTB-MP9BX-T84FV
Windows 10 (LTSC/LTSB versions)
Windows 10 LTSC 2021 and 2019
Windows 10 LTSC 2021 and 2019
Operating system edition
KMS Client Product Key
Windows 10 Enterprise LTSC 2021
Windows 10 Enterprise LTSC 2019
M7XTQ-FN8P6-TTKYV-9D4CC-J462D
Windows 10 Enterprise N LTSC 2021
Windows 10 Enterprise N LTSC 2019
92NFX-8DJQP-P6BBQ-THF9C-7CG2H
Windows 10 LTSB 2016
Windows 10 LTSB 2016
Operating system edition
KMS Client Product Key
Windows 10 Enterprise LTSB 2016
DCPHK-NFMTC-H88MJ-PFHPY-QJ4BJ
Windows 10 Enterprise N LTSB 2016
QFFDN-GRT3P-VKWWX-X7T3R-8B639
Windows 10 LTSB 2015
Windows 10 LTSB 2015
Operating system edition
KMS Client Product Key
Windows 10 Enterprise 2015 LTSB
WNMTR-4C88C-JK8YV-HQ7T2-76DF9
Windows 10 Enterprise 2015 LTSB N
2F77B-TNFGY-69QQF-B8YKP-D69TJ
Earlier versions of Windows Server
Windows Server, version 1803
Windows Server, version 1803
Operating system edition
KMS Client Product Key
Windows Server Datacenter
2HXDN-KRXHB-GPYC7-YCKFJ-7FVDG
Windows Server Standard
PTXN8-JFHJM-4WC78-MPCBR-9W4KR
Windows Server, version 1709
Windows Server, version 1709
Operating system edition
KMS Client Product Key
Windows Server Datacenter
6Y6KB-N82V8-D8CQV-23MJW-BWTG6
Windows Server Standard
DPCNP-XQFKJ-BJF7R-FRC8D-GF6G4
Windows Server 2012 R2
Windows Server 2012 R2
Operating system edition
KMS Client Product Key
Windows Server 2012 R2 Standard
D2N9P-3P6X9-2R39C-7RTCD-MDVJX
Windows Server 2012 R2 Datacenter
W3GGN-FT8W3-Y4M27-J84CP-Q3VJ9
Windows Server 2012 R2 Essentials
KNC87-3J2TX-XB4WP-VCPJV-M4FWM
Windows Server 2012
Windows Server 2012
Operating system edition
KMS Client Product Key
Windows Server 2012
BN3D2-R7TKB-3YPBD-8DRP2-27GG4
Windows Server 2012 N
8N2M2-HWPGY-7PGT9-HGDD8-GVGGY
Windows Server 2012 Single Language
2WN2H-YGCQR-KFX6K-CD6TF-84YXQ
Windows Server 2012 Country Specific
4K36P-JN4VD-GDC6V-KDT89-DYFKP
Windows Server 2012 Standard
XC9B7-NBPP2-83J2H-RHMBY-92BT4
Windows Server 2012 MultiPoint Standard
HM7DN-YVMH3-46JC3-XYTG7-CYQJJ
Windows Server 2012 MultiPoint Premium
XNH6W-2V9GX-RGJ4K-Y8X6F-QGJ2G
Windows Server 2012 Datacenter
48HP8-DN98B-MYWDG-T2DCC-8W83P
Windows Server 2008 R2
Windows Server 2008 R2
Operating system edition
KMS Client Product Key
Windows Server 2008 R2 Web
6TPJF-RBVHG-WBW2R-86QPH-6RTM4
Windows Server 2008 R2 HPC edition
TT8MH-CG224-D3D7Q-498W2-9QCTX
Windows Server 2008 R2 Standard
YC6KT-GKW9T-YTKYR-T4X34-R7VHC
Windows Server 2008 R2 Enterprise
489J6-VHDMP-X63PK-3K798-CPX3Y
Windows Server 2008 R2 Datacenter
74YFP-3QFB3-KQT8W-PMXWJ-7M648
Windows Server 2008 R2 for Itanium-based Systems
GT63C-RJFQ3-4GMB6-BRFB9-CB83V
Windows Server 2008
Windows Server 2008
Operating system edition
KMS Client Product Key
Windows Web Server 2008
WYR28-R7TFJ-3X2YQ-YCY4H-M249D
Windows Server 2008 Standard
TM24T-X9RMF-VWXK6-X8JC9-BFGM2
Windows Server 2008 Standard without Hyper-V
W7VD6-7JFBR-RX26B-YKQ3Y-6FFFJ
Windows Server 2008 Enterprise
YQGMW-MPWTJ-34KDK-48M3W-X4Q6V
Windows Server 2008 Enterprise without Hyper-V
39BXF-X8Q23-P2WWT-38T2F-G3FPG
Windows Server 2008 HPC
RCTX3-KWVHP-BR6TB-RB6DM-6X7HP
Windows Server 2008 Datacenter
7M67G-PC374-GR742-YH8V4-TCBY3
Windows Server 2008 Datacenter without Hyper-V
22XQ2-VRXRG-P8D42-K34TD-G3QQC
Windows Server 2008 for Itanium-Based Systems
4DWFP-JF3DJ-B7DTH-78FJB-PDRHK
Earlier versions of Windows
Windows 8.1
Windows 8.1
Operating system edition
KMS Client Product Key
Windows 8.1 Pro
GCRJD-8NW9H-F2CDX-CCM8D-9D6T9
Windows 8.1 Pro N
HMCNV-VVBFX-7HMBH-CTY9B-B4FXY
Windows 8.1 Enterprise
MHF9N-XY6XB-WVXMC-BTDCT-MKKG7
Windows 8.1 Enterprise N
TT4HM-HN7YT-62K67-RGRQJ-JFFXW
Windows 8
Windows 8
Operating system edition
KMS Client Product Key
Windows 8 Pro
NG4HW-VH26C-733KW-K6F98-J8CK4
Windows 8 Pro N
XCVCF-2NXM9-723PB-MHCB7-2RYQQ
Windows 8 Enterprise
32JNW-9KQ84-P47T8-D8GGY-CWCK7
Windows 8 Enterprise N
JMNMF-RHW7P-DMY6X-RF3DR-X2BQT
Windows 7
Windows 7
Operating system edition
KMS Client Product Key
Windows 7 Professional
FJ82H-XT6CR-J8D7P-XQJJ2-GPDD4
Windows 7 Professional N
MRPKT-YTG23-K7D7T-X2JMM-QY7MG
Windows 7 Professional E
W82YF-2Q76Y-63HXB-FGJG9-GF7QX
Windows 7 Enterprise
33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
Windows 7 Enterprise N
YDRBP-3D83W-TY26F-D46B2-XCKRJ
Windows 7 Enterprise E
C29WB-22CC8-VJ326-GHFJW-H9DH4

Réseau
Notions Théoriques liées au réseau.

Réseau - Adressage IPV4
Difficulté : Débutant
Notions : Réseau, adressage Modèle OSI Couche 3.
Voir la ressource sur le modèle OSI : Réseau - Modèle OSI
I.Introduction
Cette page a pour but d’introduire les notions d’adressage ip dans la norme IPV4.
1.1 Un besoin, une solution
Avec l’arrivée des réseaux, les ordinateurs se sont vu offrir la capacité de communiquer entre eux pour échanger des informations.
Cela a ouvert la voie au modèle client/serveur, puis plus tard a internet qui est l’assemblage des mot inter(entre eux) network (réseau) soit, littéralement, un ensemble de réseaux interconnectés.
Mais pour que cela fonctionne, il faut déjà pouvoir savoir qui est qui. Pour ensuite savoir qui veut parler à qui.
Il faut donc un système permettant “d’adresser” la communication. C’est là qu’intervient le système d’adressage IP.
1.2 Analogie avec le réel
Pour faire une analogie simple, il faut voir cela comme des villes. Avec leurs rues, immeubles et numéros.
Pour envoyer un colis (un paquet) à Mr Dupuis, il faut lui envoyer cela dans la ville de Lyon, Rue Descola au numéro 108.
Pour un ordinateur, c’est la même chose. Pour envoyer un paquet (réseau cette fois), il faut avoir soi-même une adresse et connaître celle de son interlocuteur.
En complément de cela, comme les ordinateurs sont dans des réseaux interconnectés, il faut savoir dans quel réseau son interlocuteur se trouve. Pour cela deux notions sont importantes :
L'adresse de réseau
L’adresse hôte
II. Fonctionnement
Défini dans la 4
2.1 Structure
Les adresses IPV4 sont construites en 4 blocs. Chaque bloc étant un octet (8bits). Ce qui donne un total de 32 bits.
Ces blocs sont séparés par un point. Cela donne quelque chose comme :
192.168.1.27
2.2 Le binaire
Question 1 : d’où viennent ces chiffres ? 
c’est en réalité assez simple. Voici un octet :
Composé de 8 bits, cet octet est vide. Sa valeur totale est donc 0.
Le binaire est un système de comptage en base 2 (nous comptons en base 10).
Il n’y a donc pour chaque bit que deux états possibles : 0 ou 1.
Pour l’ordinateur, un bloc d’adresse ressemble donc à ceci :
Question 2 : Comment convertir ce nombre binaire en nombre compréhensible par un humain ?
Avec une table de conversion. Chaque bit d’un octet a une valeur décimale. Voici la table de conversion :
Pour calculer combien cela fait en décimal, il faut ajouter les chiffre correspondant à chaque 1.
Dans cet exemple : 128+64+8+2+1 = 203.
Ainsi voici l’adresse complète ci-dessus :
Une adresse est donc ‘codée’ sur 32 bits.
2.3 Le masque de sous-réseau
Il est maintenant possible de comprendre l’adresse d’un machine, mais il manque un point essentiel :
Question 1 : Comment peut-on savoir à quel réseau appartient cette machine ?
En effet, comme dit en introduction, pour pouvoir communiquer avec une autre machine, son adresse ne suffit pas. Il faut aussi savoir dans quel réseau elle se trouve.
Pour éviter de gérer trop de données et d’adresses différentes, faciliter les communications et permettre une découpage sur mesure des réseaux, une solution a été trouvée :
L’adresse IP contiendra à la fois les informations du réseau ET de la machine.
C’est là que rentre en jeu une seconde donnée importante : le masque de sous-réseau
Question 2 : Comment tout cela fonctionne ?
Les choses se corsent un peu, mais sans devenir réellement plus complexes.
Si l’on reprends l’exemple ci-dessus : 192.168.1.27
Cette adresse contient en réalité les deux informations. Mais comment les différencier ?
A l’aide du masque de sous-réseau.
Celui-ci est sous la forme 255.255.255.0
Il est construit de la même manière que l’adresse. 4 blocs de 8 bits pour un total de 32 bits.
Ce n’est pas une coïncidence si les deux données font 32 bits. En effet, si cela s’appelle un masque, c’est qu’il doit se superposer à l’adresse. Voici à quoi ressemble ce masque en binaire.
Normalement, quelque chose doit sauter aux yeux. Tous les 1 sont d’un côté et tous les 0 de l’autre.
Et voila comment la ‘magie’ opère. Pour savoir quelle partie est l’adresse réseau et quelle partie est l’adresse machine, il faut séparer les 1 (partie réseau) et les 0 (partie machine).
Pour plus de clarté dans l’affichage, la table de conversion ne sera plus affichée.
Reprenons les exemples ci-dessus et Appliquons le masque: 
Ici, l’on peut donc voir sur l’adresse que : 192.168.1 est la partie réseau et .27 la partie machine.
En déplaçant le curseur du masque (appelée "longueur de préfixe"), on peut ajuster la taille des réseaux et ainsi le nombre de machines qu’ils peuvent accueillir. Par exemple, si l’on reprends l’adresse 192.168.1.27 mais que l’on applique cette fois un masque en 255.255.0.0 , On obtient :
Le ‘curseur’ peut bien sûr être positionné au milieu d’un bloc pour ajuster le nombre de machine au plus près du besoin.
Question 3 : A quoi ça sert d’avoir différente tailles de réseaux ?
A avoir des réseaux plus ou moins grands.
La première limitation de ce système, c’est que le fait de déplacer ce curseur signifie que l’on va jouer sur les quantités de réseaux disponibles et de machines par réseaux. Les adresses sont constituées de 32 bits. Ni plus, ni moins.
Moins l’on alloue de bits à la partie réseau, plus on en alloue à la partie machine et vice versa.
En pratique, cela signifie que l’on a :
Soit, peu de gros réseaux avec beaucoup de machines par réseau.
Soit, beaucoup de petits réseaux, mais avec un nombre limité de machines par réseau.
Question 4 : Et pourquoi avoir tous ces différents réseaux ?
De base, les ordinateurs ne peuvent communiquer qu’entre membres d’un même réseau.
Donc il est important de pouvoir adapter la taille de celui-ci au nombre de machines que l’on veut mettre dedans.
Cela permet de segmenter les réseaux pour les spécialiser, mais aussi les sécuriser en séparant des réseaux plus ou moins exposés ou avec des usages différents.
Les réseaux pourront ensuite êtres interconnectés entre eux en utilisant des 'passerelles'.
III. Applications
3.1 Les adresses réservées
En se basant sur tout ce qui a été expliqué avant, l’on peut comprendre que pour un octet, la valeur minimale est donc 0 et la valeur maximale est la somme des valeurs de tout ses bits, soit 255.
Cependant, deux choses rentrent également en ligne de comptes :
De la même façon qu’il faut pouvoir définir une ville par son nom, il faut pouvoir définir un réseau par une adresse, qui sera son identifiant (son code postal en quelque sorte).
Il a donc été défini que lorsque la partie machine de l’adresse est égale à 0 (c’est a dire que tous ces bits sont a Zéro), cette adresse est réservée comme identifiant du réseau
*ici, si l’on met tous les bits de la partie machine a 0, l’adresse du réseau est donc 192.168.1.0
En réseau, il est non seulement possible d’envoyer un paquet à une machine, mais également d’envoyer un paquet à toutes les machines d’un réseau en même temps. On appelle cela un Broadcast.
Et pour cela, utiliser une adresse spéciale où tous les bits de la partie machine sont égaux à 1.
*ici, si l’on met tous les bits de la partie machine a 1, l’adresse de broadcast est 192.168.1.255
Lorsque l’on calcule donc la capacité d’un réseau en nombre d’adresses machine, il faut retirer ces deux adresses du nombre d’adresses disponibles. Qui sont donc la première et la dernière adresse de la plage.
Dans l’exemple du réseau pris dans ce chapitre, voici donc ses données :
Adresse réseau : 192.168.1.0
Masque réseau : 255.255.255.0
Adresse de broadcast : 192.168.1.255
Nombre d’adresses machines disponibles : 254
Ainsi les machines pourront avoir les adresses suivantes :
192.168.1.1
192.168.1.2
192.168.1.3
… … …
192.168.1.254
3.2 Exemples courants
Voici une table des tailles de masques avec pour chacune le nombre de réseaux et de machines disponible.
nombre de bits de la partie réseau
masque
nombre d’adresse disponible
24
255.255.255.0
254
16
255.255.0.0
65 534
27
255.255.255.224
30
28
255.255.255.240
14
3.3 Les passerelles
Étant donné que les machines ne peuvent communiquer qu’entre machines d’un même réseau, il faut utiliser des machines pour servir de passerelles entre les réseaux. Ces machines doivent évidement disposer d’une adresse dans chaque réseau auxquels elles seront connectées.
Il faut donc prévoir dans son calcul de réserver les adresses pour ces passerelles.
Ces machines seront appelées ‘routeurs’.
Cours sur le routage :  todo  
IV. Conventions
4.1 La notation CIDR
Par facilité, une notation alternative à la notation adresse + masque a été mise au point.
Il s’agit ici de noter l’adresse et y accoler le nombre de bits de cette adresse constituant la partie réseau.
Ainsi 192.168.1.0 et 255.255.255.255 deviennent 192.168.1.0/24
Et l’on peux aussi utiliser cette notation pour désigner une machine 192.168.1.27/24
Ainsi, l’on a en une fois à la fois l’adresse d’une machine et les informations permettant de savoir à quel réseau elle appartient.
4.2 Les classes d’adresses
Les adresses sont réparties en 4 classes définies par le nombre de bits alloués aux réseaux afin de regrouper ensemble les réseaux de même capacité.
Ainsi, les réseaux de classe A ont un premier octet compris entre 1 et 126*. soit un bit de poids fort égal à 0.
Les réseaux de classe B ont un premier octet compris entre 128 et 191. soit deux bits de poids fort égaux à 10.
Les réseaux de classe C ont un premier octet compris entre 192 et 223. Soit 3 bits de poids fort égaux à 110.
Les réseaux de classe D sont un cas particulier. Ils ont un premier octet compris entre 224 et 239. Soit 3 bits de poids fort égaux à 1. Il s’agit de réseaux et adresses réservées pour le multicast.
Cours sur le multicast :   todo  
Une dernière classe existe, avec un premier octet compris entre 240 et 255. Il s’agit de la classe E. Ces adresses sont réservées pour l’expérimentation et ne DOIVENT PAS être utilisées.
*le réseau de classe A 127 est réservé.
4.3 Les IP privées et publiques
Défini dans la rfc1918
En plus de ces classes, il faut différencier les plages d’adresses réservées à un usage public, par les opérateurs internets notamment et celles, privées, utilisable par les particuliers et les entreprises.
Actuellement les adresses privées utilisables sont les suivantes :
classe A : 10.0.0.0 à 10.255.255.255
classe B : 172.16.0.0 à 172.31.255.255
classe C : 192.168.0.0 à 192.255.255.255
Sachant que la plupart des réseaux domestiques sont en 192.168.1.0/24 ou 192.168.1.0/24 il est recommandé d’utiliser d’autres plages pour des réseaux de LAB ou d’entreprise.
Notamment ceux de classe B, qui ne sont pas utilisés en usage domestique ou en IoT.
4.4 Les ip particulières
Dans les plages existantes il y a un certains nombres d’adresses ou de réseaux qui sont réservés à des usages particuliers et qui ne sont par conséquent pas utilisables :
127.0.0.1 : adresse générique utilisée pour désigner la boucle locale (localhost)
0.0.0.0 : adresse utilisée pour indiquer une route par défaut (tout le monde).
255.255.255.255 : broadcast général.
V. Conclusion
Pour résumer,
Au sein d’un LAB ou d’une entreprise. Il est possible de découper plusieurs sous-réseaux. Dans la limite des IP privées des classes A,B et C. Avec une préconisation pour l’usage d’adresses de classe B.
Aller plus loin :
cours sur le NAT/PAT : Réseau - Le NAT / PAT
cours sur les ports et les sockets : Réseau - Définition du socket
Adressage IPV6 : Réseau - Adressage IPv6

Réseau - L'agrégation de liens (LAGG)
Difficulté : Débutant
Notions : Réseau, interfaces, agrégation de liens.
I.Différents scenarii
Cette fiche a pour but d’expliquer le fonctionnement des agrégations de liens (Link aggregation ou LAGG)
2.1 Scenario 1 : Agrégation de lien (actif/actif)
Le but de ce scénario est d’agréger la bande passante afin de cumuler les bandes passantes de toutes les cartes.
Dans cette configuration, une interface virtuelle est créée.
Elle va utiliser les deux adaptateurs physique afin de cumuler leurs débit.
Les cartes fonctionnent ensemble et si l’une des deux est coupée. L’ensemble n’est plus actif et le lien ne fonctionne plus.
2.2 Scenario 2 : Failover (actif/passif)
Le but de ce scénario est d’avoir un lien de secours pour anticiper une éventuelle panne de matériel.
Dans cette configuration, une interface virtuelle est créée.
Elle va utiliser le premier adaptateur en lien nominal et le second en lien de secours.
En cas de rupture du lien nominal, la carte de secours sera utilisée.
Cela apporte une sécurité mais n’augmente pas le débit.
2.3 Scenario 3 : LACP (actif/actif + Redondance)
Ce scénario nécessite un switch manageable prenant en charge le LACP.
Le LACP est la fusion des deux scenarii ci-dessus.
Dans cette configuration, une interface virtuelle est créée.
Les deux adaptateurs sont activement utilisés, en cas de coupure d’un lien, le système fonctionne en mode dégradé

Réseau - Modèle OSI
Difficulté : Débutant
Notions : réseau, modèle OSI
I. Introduction
Le  modèle OSI  (Open Systems Interconnection) est un modèle conceptuel en couche développé par l'International Standardisation Organisation (ISO).
Il permet de conceptualiser les communications réseaux entre les ordinateurs en divisant le processus de communication en 7 couches distinctes.
Chaque couche à un rôle spécifique et interagis avec les couches directement situées en dessous et au dessus d'elle.
Cette approche, en plus de visualiser le fonctionnement des communication réseau en permet un diagnostic efficace.
Voici la représentation des différentes couches.
Lors des communications entre machines, celles-ci seront encapsulées les unes dans les autres donnant alors ce que l'on appellera une 'trame' réseau.
II. Les couches du modèle OSI
2.1 Couche 1 : Physique
Il s'agit de la couche matérielle. Celle permettant de porter le signal réseau.
Elle est constituée des câbles réseaux, fibres optiques, ondes WIFI et des contacts électroniques des cartes réseaux.
Il s'agit de ce que l'on appelle le 'medium de propagation du signal'
câble RJ45
connecteurs fibre
antenne wifi
Outils de diagnostics
vérification du câble ou fibre
état des voyants sur l'interface
état de la carte : 'link up / link down'
2.2 Couche 2 : Liaison
Il s'agit de la couche permettant aux machines de communiquer entre elles au plus bas niveau et de se transmettre le signal d'un nœud à un autre. En d'autre terme, d'établir une 'liaison' entre elles.
On y retrouve notamment les adresses MAC (Media Access Control).
Une adresse MAC est un identifiant physique unique permettant d'identifier l'interface réseau au plus bas niveau.
Les plages d'adresses MAC sont distribuées aux constructeurs de matériel réseau et chaque interface matérielle est dotée de sa propre adresse MAC unique au monde.
Les protocoles utilisés à ce niveau sont :
Ethernet
PPP
...
C'est à ce niveau que va s'opérer le contrôle d'erreur (CRC) et la commutation par les switches. La gestion des VLAN, etc...
Outils de diagnostics
Vérification des tables ARP
par exemple :
2.3 Couche 3 : Réseau
La couche réseau est la plus connue et manipulée directement par les administrateurs réseaux et systèmes.
Il s'agit de la couche qui permet de faire abstraction de la couche matérielle afin de construire des topologies réseau logiques.
Celles-ci pourront de ce fait être cartographiées et des 'routes' permettrons d'interconnecter ces topologies entres elles.
C'est à ce niveau là qu'interviens le protocole IP et que l'on retrouve nos adresses logiques uniques sur le réseau.
Réseau - Adressage IPV4
Réseau - Adressage IPv6
A ce niveau, l'on parle de trames ip. Ces trames ont une taille limite de 65536 Octets. Mais celle-ci ne sera que rarement atteinte, car elle va être limitée par la taille maximale que les réseaux qui la portent peuvent supporter.
Cela se négocie grâce au MTU (Maximum Transfer Unit). Passé cette taille, les trames seront fragmentées.
Cette fragmentation est gérée par le routeur.
Attention : Rien ne garantis à ce stade que les paquets arriveront dans le bon ordre. Cela sera géré sur la couche suivante.
Voici les en-têtes présents sur cette couche :
en-tête
Description
TTL (Time To Live)
ce champs permet de définir une expiration sur les paquets afin que ceux-ci puissent "s'autodétruire" si leur durée de vie est expirée. Empêchant ainsi une saturation du réseau.
SRC (Source address)
Adresse IP de la source de la transmission.
DST (Destination address)
Adresse IP de la destination de la transmission.
Checksum
Somme de contrôle IP.
C'est sur cette couche que sont géré entre autre le routage, le diagnostic et les tests de connectivité (avec ICMP).
Outils de diagnostics
ping
general failure : problème sur la pile TCP ou pas de signal
vérifier câble et configuration IP
host unreachable : le ping n'est pas parvenu à l'hôte de destination
vérifier l'état de la passerelle, les configuration IP et le routage
Request timed out : l'hôte de destination a bien reçu la requête mais n'a pas renvoyé de réponse.
pare-feu ? route retour ?
TTL expired in transit : le paquet a dépassé le nombre de saut maximum (sans doute une boucle de routage).
Anwer from <host> : OK
tracert / traceroute : permet de voir les sauts pour vérifier la route empruntée
2.4 Couche 4 : Transport
La couche 4 sert à faire passer des communication à travers le réseau IP.
On y retrouve principalement 2 protocoles de transfert :
TCP (Transmission Control Protocol) : un protocole permettant un transfert de donnée contrôlé avec une gestion des erreurs.
UDP (User Datagram Protocol) : un protocole sans contrôle d'erreur, mais permettant des interactions plus rapide.
La différence majeure entre les deux tient au fait que TCP gère la transmission, là ou UDP se contente d'envoyer des paquets sans aucun contrôle de la transmission.
2.4.1 TCP
Un paquet TCP est appelé un Segment.
TCP prends en charge la gestion des erreurs. A chaque trame transmise, des informations de contrôle y sont adjointes.
Ces informations permettent ainsi au récepteur de pouvoir s'assurer du numéro de paquet dans la transmission, du fait que le paquet soit complet et reçu sans erreur, de gérer les erreur éventuelles en demandant un nouvel envoi de paquet et enfin de savoir quand la transmission est complétée.
Cela le rends donc idéal pour tous les protocoles nécessitant que la donnée soit reçue de façon certaine. Par exemple pour le FTP, SFTP, SMB, HTTP, etc...
Un échange TCP se déroule de la façon suivante :
Etape
Message
Description
1
SYN
Un message SYN est envoyé par la machine 1, dans le cadre d'un processus appelé 'handshake'. Ce paquet est issu afin d'initier la connexion et synchroniser les deux machines.
2
SYN / ACK
Ce paquet est envoyé par la machine 2 après réception du paquet de la machine 1 permettant de valider la réception de la demande d'échange.
3
ACK
Ce message sera ensuite envoyé après chaque transmission, afin d'en valider la réception.
4
DATA
Une fois la connexion établie, les données sont transmises à travers des messages data, qui seront 'acknowledged'.
5
FIN
A la fin de la transmission, ce paquet est utilisé pour clôre proprement la session.
#
RST
Ce paquet est utilisé en lieu et place du paquet FIN si il y a eu un problème durant la transmission. Celui-ci terminera alors de façon abrupte la communication.
Ainsi, les données importantes présentes dans les trames TCP Sont :
en-tête
Description
SRC (Source address)
Adresse IP de la source de la transmission.
DST (Destination address)
Adresse IP de la destination de la transmission.
SRC port
Le port source de la transmission.
DST port
Le port de destination de la transmission.
Sequence Number
Lors de l'établissement de la connexion, le premier paquet reçois un numéro initial aléatoire. il constituera le premier numéro de la séquence à transmettre.
ACK Number
Après l'envoi d'un bloc de donnée ayant reçu un Sequence Number, le nombre du prochain bloc reçois le nombre de séquence + 1 et ainsi de suite.
Checksum
Somme de contrôle, pour vérifier l'intégrité du paquet.
Data
Là où se situe la donnée envoyée dans la trame.
Flag
Ce champ détermine comment la trame doit être traitée par les deux machines durant le processus de Handshake. ( SYN / ACK / FIN / RST )
Cela permet de s'assurer que la transmission se déroule bien, de gérer les erreurs.
2.4.1 UDP
Un paquet UDP est appelé un Datagrame.
Contrairement à TCP, le protocole UDP ne prends pas en charge de contrôle de transmission ou d'erreur. Ce qui rends la perte de paquet irrémédiable.
Mais cette absence de contrôle en fait également son point fort. En effet, du fait de sa simplicité, il est très utile pour gérer des flux continus.
Cela rends UDP parfait pour des transmissions continues et massive, comme par exemple des flux vidéos, VoIP ou autres...
Outils de diagnostics
Outils
DIgnostics
netstat
Ports, sessions, TCP states
ss
Sockets, queues, states
tcpdump
Flags, handshake, resets
Wireshark
analyse complète
lsof
Process ↔ port mapping
telnet / nc
Disponibilité du port
curl / wget
TCP errors, resets
(PowerShell) test-netconnection
Windows TCP diagnostics
iperf
Throughput, retransmissions
ssldump
TLS handshake issues
2.5 Couche 5 : Session
La couche 5 permet le contrôle des 'sessions' de communications entre les applications.
C'est ici que les échanges vont être commencé, suivis, terminés entre les interlocuteurs.
C'est également ici que les erreurs de communications, les mises en attentes de paquets vont être gérées.
2.6 Couche 6 : Présentation
La couche 6 permet la mise en forme préalable des données de la couche suivante, soit sa 'présentation'.
C'est sur cette couche que ce fait par exemple le chiffrement du flux de données avant l'envoi de la trame (SSL / TLS).
C'est donc aussi sur cette couche que s'opèrera le déchiffrement.
Si des algorithmes de compression de flux sont mis en œuvre, ils se reposeront aussi sur cette couche pour la compression et décompression des flux.
2.7 Couche 7 : Application
C'est enfin sur cette couche que passe la communication des différents services et application.
C'est là que se retrouvent l'ensemble des protocoles liés aux applications comme le DNS, DHCP, NTP, HTTP, etc...
Outils de diagnostics
Côté client, tester la connexion TCP avec telnet, netcat ou autre.
Telnet
III. Conclusion
Lors d'un diagnostic sur un problème réseau, il est important d'avoir ce modèle en tête et de réfléchir au problème couche par couche en partant de la plus basse.
Cela permet de gagner du temps sur la résolution d'un problème.
A moins bien sûr que la couche qui pose problème soit clairement identifiée au départ par le retour obtenu ou le message d'erreur.
Basiquement, pour une résolution de problème sur la connectivité des VM, les questions à se poser sont :
La carte réseau existe et est connectée
Je suis situé sur le bon Vswitch (VMBR)
Je suis dans la bonne plage IP des deux côté
Les pare-feu / routeurs sont bien configurés
Si le signal est OK et que le ping passe, 
Le service est démarré sur le serveur,
Le port est ouvert
la configuration de mon service est correcte
le contenu est accessible.

Réseau - Protocole DHCP
Difficulté : Novice
Résumé :
OSI : couche 7 (Application) sur couche 4 (Transport)
Type : UDP
Port : 67, 68
I. Introduction
Le protocole DHCP (Dynamic Host Configuration Protocol) est un protocole permettant la configuration réseau automatique d'un ou plusieurs hôtes par un serveur.
Cela permet de gérer un grand nombre d'hôtes sans nécessiter une intervention des administrateurs.
Les échanges entre le client et le serveur se font entre la couche 5 et 7 du modèle OSI.
II. Diagramme 
1 - DHCP Discover
L'hôte configuré en DHCP envoie un broadcast général. Il place son adresse MAC dans le paquet.
Il utilise l'ip 0.0.0.0 en source et envoie son broadcast à 255.255.255.255 en destination.
Cela lui permet d'adresser toutes les machines présentes sur le réseau.
Si un serveur DHCP se trouve à portée, il captera le broadcast et répondra alors.
2 - DHCP Offer
Le serveur DHCP reçoit la requête et, comme le PC de destination n'a pas d'adresse IP, il va alors répondre également en broadcast.
Info : Certains clients acceptent une réponse en unicast. Le DHCP pourra alors être configuré pour leur répondre en unicast.
Il va envoyer dans le paquet la configuration réseau (ip, masque, passerelle, dns, etc...) ainsi qu'une durée de bail et l'adresse MAC du pc demandeur.
Si plusieurs serveurs DHCP sont présents, selon leurs configuration, l'un d'entre eux ou tous répondront à la requête et le client fera son choix (généralement basé sur la réponse la plus rapide).
3 - DHCP Request / DHCP Decline
L'ensemble des hôtes présents sur le réseau reçoivent la réponse.
Comme le demandeur avais placé son adresse MAC dans le paquet, il comprends que la réponse lui est adressée. Les autres hôtes lisent l'adresse MAC, et comme ce n'est pas la leur, ignorent le message.
Si plusieurs serveurs DHCP ont répondus, le client fera alors son choix (généralement basé sur la réponse la plus rapide).
Ensuite, deux scénarii :
Le client vérifie sa configuration, voit que la configuration proposée correspond à son besoin et ne rentre pas en conflit avec l'une de ses configuration déjà existantes. Il demandera alors au serveur si il peut utiliser cette configuration avec un message DHCP Request.
Le client vérifie sa configuration et voit que la configuration proposée rentre en conflit avec l'une de ses configuration. Il refuse donc l'offre et renvoie un message DHCP Decline. Puis l'échange s'arrête là.
4 - DHCP Ack
Le serveur qui a reçu le message de requête va alors la prendre en compte et renvoyer au client un message en lui indiquant qu'il a bien Validé cette demande.
Suite à cet échange
Une fois cet échange terminé le serveur va alors enregistrer dans sa base l'adresse MAC du PC ayant fait la demande ainsi que la configuration qui lui a été attribuée ainsi que la durée du bail.
Un compteur se met alors en route. A la fin de celui-ci, le bail étant terminé, le serveur va libérer cette configuration et la remettre dans son pool de disponibilité. Elle pourra donc ensuite être réattribuée à un autre hôte qui fera une demande.
III. Configuration
Lors de la configuration d'un serveur DHCP, il va falloir un minimum d'informations :
l'adresse IP de début de plage (la première qui sera proposée aux hôtes)
l'adresse IP de fin de plage (la dernière qui sera proposée)
toutes les adresses IP qui seront entre les deux constitueront la Plage DHCP ou le Pool d'adresses.
le masque de sous-réseau
l'adresse de la passerelle
Il est possible de fournir au client plus de configurations :
Les serveurs de noms (DNS)
Les serveurs de temps (NTP)
Les serveurs TFTP (serveurs de démarrage réseau, pour faire booter un PC sur une image situé sur le réseau)
etc...
IV. Autres principes
Réservation : Il est possible de réserver une configuration. Lorsqu'un hôte obtient une configuration, on pourra demander au serveur de lui réattribuer systématiquement la même.
Plage d'exclusion : Il est également possible de définir à l'intérieur des plages d'adresses des exclusions, afin de préciser que certaines adresses ne doivent pas être distribuées.
IV. Relais DHCP
Comme vu plus haut, le DHCP s'appuie essentiellement sur des broadcasts. Hors, le problème est que les broadcast ne passent pas les routeurs.
Si l'on veut distribuer des adresses sur un ou plusieurs réseaux se situant derrière des routeurs, il faudra donc utiliser un relai DHCP.
Le rôle de celui-ci sera de prendre le broadcast envoyé par le client et de le renvoyer sous forme d'unicast au serveur DHCP. Puis de récupérer la réponse de celui-ci et de la retransmettre en broadcast dans le réseau d'origine.
Ainsi :
V. Cas de plusieurs réseaux
Dans le cas où un serveur devrait servir plusieurs étendues réseaux, lors du passage du relais, celui-ci glisse dans le paquet (champ giaddr) son adresse IP.
En se basant sur cette adresse, le serveur DHCP choisit alors l'étendue adaptée et fait une proposition dans ce sens.
C'est ainsi que le tri se fait entre les demandes.
Info : A noter que si le relai DHCP peut être une machine dans le réseau, certains routeurs proposent nativement cette fonctionnalité.

Réseau - Protocole DNS
Difficulté : Novice
Résumé :
OSI : couche 4, 6 & 7
Type : UDP (parfois TCP)
Port : 53 (853 DNSsec)
I. Introduction
Le protocole DNS (Domain Name System) permet de traduire les noms de domaine lisibles par l’homme (comme 
www.example.com) en adresses IP compréhensibles par les machines (
192.0.2.1). Il joue un rôle fondamental dans la navigation sur Internet et dans la résolution de noms au sein des réseaux locaux.
Les échanges DNS se situent entre les couches 5 à 7 du modèle OSI, bien qu’ils reposent sur des mécanismes de transport en UDP ou TCP selon le contexte.
II. Diagramme
1 - Vérification locale (cache)
Lorsqu'une résolution est nécessaire ; effectuée par l'utilisateur ou le système ; la machine va dans un premier temps consulter son cache local.
Si l'enregistrement s'y trouve, il va utiliser celui-ci.
Si l'enregistrement ne s'y trouve pas :
2 - Vérification locale (fichier)
Le client va vérifier si ses fichiers 'Hosts' contiennent l'enregistrement.
Si oui, il sera lu et mis en cache puis l'utiliser.
Si non :
3 - DNS Query
Le client va interroger le(s) serveur(s) déclarés dans sa configuration réseau.
Il existe 3 types de requêtes :
Source : geeksforgeeks
Requête récursive : Si le resolver (client) ne trouve pas l'enregistrement il va interroger le(s) DNS paramétré(s) et attends une réponse complète.
Le serveur va alors interroger ses forwarder et ainsi de suite jusqu'à ce qu'une réponse revienne au client.
Requête Itérative : Si le resolver (client) ne trouve pas l'enregistrement, il va interroger le(s) DNS paramétré(s) et attend une réponse au moins partielle.
Le serveur va alors chercher un autre serveur qui a une information plus complète et renvoyer son adresse au client, qui pourra alors lui adresser sa requête, ainsi de suite jusqu'à résolution complète.
Requête non récursive : Si le resolver (client) ne trouve pas l'enregistrement il va interroger le(s) DNS paramétré(s) et demande de consulter le cache.
Le serveur regarde dans son cache, soit il a l'information et la transmet au client, soit il n'a pas l'information et renvoie qu'il ne l'a pas. La recherche s'arrête là.
Dans tous les cas, si un serveur ne dispose pas de la réponse, il vérifiera si l'un de ses forwarder ou si les serveurs racine ont la réponse et soit fera la recherche pour le client (Récursive) soit lui donnera l'adresse d'un forwarder ou serveur racine (itérative).
4-5 - Vérification du cache
Tout comme le client effectue de son côté une vérification de son cache et de ses fichiers locaux aux étapes 1 et 2, les serveurs relais vont effectuer la même opération. Cela permettra une réponse plus rapide.
6 - Mise à jour du cache
Une fois la réponse obtenue, le cache local du resolver est mis à jour.
Ces enregistrements resterons mis en cache pour la durée du TTL.
III. Principes de bases
3.1 Le cache DNS
Chaque enregistrement DNS dispose d'un TTL (Time To Live). Lorsqu'un enregistrement est mis en cache, il périmera à l'expiration du TTL. Celui-ci sera alors supprimé du cache et rajouté à nouveau lors d'une prochaine requête.
Astuce : Tous les systèmes disposent de commandes pour vider manuellement ce cache.
Info : C'est cette mécanique qui est utilisée lors des attaques par empoisonnement de cache DNS (DNS poisoning).
3.2 La hiérarchie des serveurs DNS
L’architecture DNS se compose d’un système de résolution de nom hiérarchique et décentralisé pour les ordinateurs, les services ou toute autre ressource connectée à Internet ou à un réseau privé. Il stocke les différentes informations associées des noms de domaine attribués à chacune des ressources.
La hiérarchie DNS repose sur plusieurs niveaux qui peuvent intervenir lors d’une résolution DNS :
Tout en haut : Les serveurs DNS racines
Ceux qui gèrent les domaines de niveaux supérieurs.
Puis en dessous les serveurs de domaine de premier niveau
Les domaines nationaux par exemple .fr, .eu, etc... (ou encore d'autres comme .com, .net, etc...).
Au niveau intermédiaire les serveurs DNS d'autorité
Les serveurs faisant autorité pour les domaines complets comme mfrstegreve.fr ou labs404.com (souvent ceux du registar)
Puis les DNS récursifs et itératives
Ce sont les serveurs enregistrés dans les paramètres de la connexion (souvent ceux du FAI ou les DNS locaux).
Liste des serveurs racines
Actuellement, il existe 13 serveurs DNS racines dont une grande majorité se trouvent aux USA.
 
 
 
 
 
 
 
 
Serveurs DNS racines
Adresse IPv4
Adresse IPv6
Opérateur
A
198.41.0.4
2001:503:ba3e::2:30
VeriSign
B
192.228.79.201
2001:478:65::53
USC-ISI
C
192.33.4.12
2001:500:2::c
Cogent Communications
D
199.7.91.13
2001:500:2d::d
University of Maryland
E
192.203.230.10
 
NASA
F
192.5.5.241
2001:500:2f::f
ISC
G
192.112.36.4
 
U.S. DoD NIC
H
128.63.2.53
2001:500:1::803f:235
US Army Research Lab
I
192.36.148.17
2001:7FE::53
Autonomica
J
192.58.128.30
2001:503:c27::2:30
VeriSign
K
193.0.14.129
2001:7fd::1
RIPE NCC
L
199.7.83.42
2001:500:3::42
ICANN
M
202.12.27.33
2001:dc3::35
WIDE Project
 
 
 
 
 
 
 
 
 
3.3 Les types de domaines
Il en existe 3 types :
Les domaines Génériques : Des domaines sans rattachements géographiques mais mondialement reconnus et utilisés.
.org, .com, .net, ...
Les domaines Nationaux ou Coutry Code Domain : Domaines attachés à une origine géographique.
.fr, .uk, .au, .ru, .us, ...
Les domaines inverses : Utilisé pour les 'Reverse lookup'. Les recherches inversées. Notamment utilisés pour vérifier qu'une IP est bien dans le domaine recherché.
.arpa
IV. Types d'enregistrements DNS
Les enregistrements DNS sont des parties importantes de la Système de nom de domaine (DNS). Il existe plus de 30 types d'enregistrements, chacun servant de saisie de base de données qui fournit des informations spécifiques sur un domaine, y compris son adresse IP, ses serveurs de messagerie et sa sécurité. Ces enregistrements sont stockés dans des fichiers DNS Zone et gérés par les serveurs DNS.
4.1 Terminologie DNS
Avant de voir les types de dossiers DNS spécifiques, il est utile de comprendre une terminologie DNS de base.
Voici quelques termes clés utiles dans la compréhension de DNS Records.
Enregistrement des ressources: L'élément de données de base dans le DNS. Chaque enregistrement spécifie des informations sur un domaine.
Nom: Le nom de domaine auquel l'enregistrement s'applique.
TTL (temps de vie): La durée pour laquelle le dossier est mis en cache par les DNS Resolvers.
Classe: Spécifie la famille du protocole. Dans (Internet) est le plus courant.
Taper: Le type d'enregistrement DNS (par exemple, a, aaaa, cname).
Donnés: Les données spécifiques de l'enregistrement, telles qu'une adresse IP.
Fichiers de zone: Fichiers contenant des mappages entre les noms de domaine et les adresses IP.
Nom du serveur: Un serveur qui gère les enregistrements DNS pour un domaine.
4.2 Types d'enregistrements DNS les plus courants
Chaque type d'enregistrement DNS a une fonction spécifique, ce qui aide à gérer les noms de domaine et à garantir un approvisionnement approprié du trafic Internet.
source : Wikipedia
4.3 Champs spécifiques
Certains protocoles se basent sur l'utilisation de champs spécifiques. La plupart du temps, il s'agit de champs TXT devant être formatés de manière très précise.
C'est le cas par exemple pour la vérification des serveurs de messageries qui peuvent utiliser les champs DMARK et SPF.
Ou la VoIP.
V. Principes avancés
5.1 Recherche inversée
Tout comme il est possible avec le DNS de savoir quelle adresse IP corresponds à quel nom d'hôte, il est également possible d'effectuer une recherche inversée pour avoir les noms attachés à une adresse IP.
Cela sert dans le cadre de vérification ou de diagnostic.
Cette recherche s'appuie sur une zone de recherche inversée contenant les champs en .arpa.
5.2 DNSsec
Le DNSSEC (Domain Name System SECurity extensions) est une extension du protocole DNS qui ajoute une couche de sécurité en garantissant l'authenticité des réponses DNS.
Chaque zone DNS est signée avec une clé privée.
La clé publique est placée dans l'un des champs de la zone et permet à un client qui ferai une requête de vérifier l'authenticité de la réponse.
Cela permet de se prémunir des attaques de type "DNS spoofing" ou de "cache poisoning".
Attention : Cela permet de garantir l'authenticité de la réponse mais ne chiffre pas les échanges. De plus tous les équipements ne seront pas forcement compatible avec ce protocole.
Les enregistrements spécifiques utilisés sont :
RRSIG : contiens la signature cryptographique d'un enregistrement DNS.
DNSKEY : contient la clé publique utilisée pour vérifier les signatures.
DS : sert à déléguer la vérification entre zones.
5.3 DoH / DoT
Le DoH (Dns Over Https), vise à faire passer les requêtes DNS par le biais d'un canal chiffré par HTTPS. Rendant son interception et sa modification plus difficile.
Si aujourd'hui beaucoup de navigateurs l'intègre nativement, il est très peu présent sur les équipements réseaux.
Le DoT (Dns Over Tls) vise à faire passer les requêtes DNS par le biais d'un canal chiffré par TLS. Les avantages sont les mêmes qu'avec le DoH. Mais il utilise un port à part (853), permettant de le différencier du trafic HTTPS, mais également de faire un filtrage plus fin sur les pare-feu.

Réseau - Protocole RIP
Difficulté : Confirmé
Notions : Protocoles réseaux, routage, routage dynamique.
I. Introduction
Le protocole RIP pour Routing Information Protocol est un protocole permettant aux routeurs d'échanger automatiquement leurs tables de routage. Il fait partie des protocoles IGP (Interior Gateway Protocol) qui sont utilisés à l'intérieur d'un même réseau ou organisation.
C'est un protocole de couche 3.
Cela facilite la gestion du parc, permettant notamment de mettre à jour automatiquement les tables de routages en cas d'ajout ou suppression d'un réseau, rendant celui-ci facilement scalable et simple à administrer.
II. Principes de base
2.1 Fonctionnement
Le principe du RIP est asses simple :
Chaque routeur génère une table de routage composée de ses réseaux connus directement accessibles via ses interface. Il y ajoute les routes connues ainsi que leur distances en nombre de saut.
Puis, régulièrement (par défaut 30 secondes), il envoie cette table à ses partenaires de réplication. Dans la première version du protocole, cela se fait par broadcast. Puis cela a été changé pour du multicast dans les versions suivantes du protocole ( 224.0.0.9 pour RIPv2 en IPV4, puis dans le RIPng pour IPV6 : FF02::9)
Chaque routeur, met ainsi ses tables à jour et peut les propager aux autres. Les doublons sont éliminés et les routes avec un minimum de saut sont conservées afin d'optimiser la performance.
Si une route n'a pas eu d'update dans un délai de 180 secondes, elle est marquée comme invalide. Passé 240 secondes, elle est supprimée.
Ces délais permettent ainsi d'ajouter une purge des routes inutiles en plus des ajouts, permettant de conserver des tables de routages précises.
2.2 Mécanismes internes
Le RIP utilise plusieurs mécanismes en interne pour éviter des boucles dans la topologie.
Split Horizon : un routeur n'anonce pas une route sur l'interface par laquelle il l'a apprise.
Route Poisoning : Une route devenue invalide est supprimée.
Hold-down Timer : Empêche une acceptation trop rapide d'une route potentiellement incorrecte
Voici une liste plus détaillées des timers clés :
Timer
Valeur
Rôle
Update
30 s
Envoi périodique des tables
Invalid
180 s
Route considérée invalide
Hold-down
180 s
Stabilisation
Flush
240 s
Suppression de la route
2.2 Limitations
Le RIP repose essentiellement sur le hop count. Ce compteur de saut est limité à 15 sauts.
Cela le rends inefficace pour de larges topologies et limite donc son usage à des réseaux de petite tailles ou de tailles moyennes.
De plus en terme de priorité de traitement, les requêtes RIP sont les moins prioritaires.
Protocoler
Distance administrative
RIP
120
OSPF
110
EIGRP
90
statique
1
connectée
0
III. Versions de RIP
Il existe 3 versions du protocole RIP :
Feature
RIPv1 (1988)
RIPv2 (1993)
RIPng (1997) for IPv6
Méthode de mise à jour
Broadcast (255.255.255.255)
Multicast (224.0.0.9)
Multicast (FF02::9)
Adressage
Classful (pas d'info de sous réseau)
Classless (inclus le masque)
Classless (IPv6)
Authentification
Pas de support
plain text, MD5
plain text, MD5
Version IP supportées
IPv4
IPv4
IPv6
Protocole / port
UDP 520
UDP 520
UDP 521
IV. Considérations de sécurité
Attention : Le protocole RIP est considéré aujourd'hui comme obsolète. Il est en effet remplacé par d'autres protocoles plus modernes et sécurisés.
Le principal risque du protocole RIP reste l'empoisonnement des routes par un tiers ou un équipement malveillant.
Il est donc primordial de respecter à minima les deux conditions suivante lors de la mise en place :
Utiliser à minima la version 2 du protocole qui permet une authentification
Utiliser une authentification MD5 et pas une authentification plainText.
Il est à noter que le RIP n'utilise pas directement MD5 pour hasher un mot de passe, mais comme fonction de hashage dans un mécanisme d'authentification HMAC-Like.
Aussi, il ne s'agit pas de hasher un mot de passe, mais le paquet RIP complet. Lors de l'échange, les routeurs disposant tous de la même clé, ils vont recalculer localement le hash de la trame reçue afin de certifier qu'elle est bien originaire d'un routeur connu.
V. Conclusion
Même si son usage est déprécié, Il reste intéressant à voir à des fins pédagogiques car il permet d'introduire les principes de routage dynamique avec un protocole simple dans son fonctionnement.
De plus, sur les équipements plus anciens, il s'agit souvent de la seule alternative disponible.

Réseau - Protocole STP/RSTP
Difficulté : Confirmé
 
Notions : Réseau, protocoles, résilience réseau.
I. Introduction
Dans le cadre de la résilience d'une topologie réseau, il est essentiel de redonder des liens afin de palier à une rupture éventuelle.
Plusieurs topologies réseaux spécifiques existent. Dont les deux suivantes :
Topologie Boucle ( ring )
Topologie meshée
Cependant, ces boucles créent également deux problèmes majeurs :
les tempêtes de broadcasts, dues au boucles réseaux présentes dans la topologie.
Des instabilités dans les tables MAC.
Des trames en doublons.
Ce qui peut mener à des dysfonctionnement applicatifs ( rupture de session ), des pertes de performances ( collision de paquets, réadressage MAC ) voire à un effondrement du réseau.
Pour éviter ces problèmes et rendre ce type de topologies possibles, le protocole STP ( Spanning Tree Protocol ) a été créé.
Cependant, dû à ses problèmes de lenteur de cicatrisation réseau ( 30-50 secondes de délai de convergence ), une version plus moderne en a été créée : le protocole RSTP ( Rapid Spanning Tree Protocol ).
Celui-ci réduit les temps de cicatrisation entre 1 et 3 secondes et apporte quelques améliorations :
Simplification des rôles des ports
Meilleure stabilité
rétrocompatible avec STP
II. Fonctionnement STP/RSTP
2.1 Principe général
Le fonctionnement de base du STP / RSTP est le suivant :
2.1.1 Election de la passerelle racine ( root bridge )
Chaque switch envoie une trame d'un type spécifique appelée BPDU ( Bridge Protocol Data Unit ).
Cette trame contient les informations de priorité, d'adresse MAC et de coût du chemin racine.
Une fois ces trames reçues, le switch ayant la priorité ave la valeur la plus basse devient le switch racine.
Info : En l'absence de priorité définies sur les switch, c'est la valeur des adresses MAC qui est prise en compte et fait office de valeur de priorité.
Une fois ce processus d'élection achevé, les trames continuent à être envoyées de manière continue. Si un switch apparaît avec une priorité plus élevée, ce rôle lui sera transféré.
Conseil : C'est ce qui rend la résilience possible et l'architecture scalable. Si le root bridge tombe, celui avec la meilleure priorité disponible est automatiquement élue. Si un switch avec une meilleure priorité est ajouté à la topologie, il est également automatiquement élu et récupère le rôle de root bridge.
2.2.2 Détermination des ports racine ( root ports )
Chaque switch non-racine détermine ensuite son root port. Il s'agit du port qui a le chemin le plus court pour accéder à la racine.
Ce chemin est calculé en faisant la somme des coûts pour chaque chemin.
Le coût est calculé en fonction de la rapidité des liens. Voici un tableau avec les valeurs de références.
Débit du lien
Coût STP (802.1t)
10 Mb/s
2 000 000
100 Mb/s
200 000
1 Gb/s
20 000
10 Gb/s
2 000
100 Gb/s
200
1 Tb/s
20
Info : En cas d'égalité entre deux chemins, c'est le voisin avec le bridge ID le plus faible qui l'emporte. Si l'égalité persiste, c'est le Port ID le plus faible qui est choisi.
Ce port sera donc tagué comme actif.
Exemple : Switch A est le Root Bridge. Switch B peut atteindre A via deux chemins :
Chemin 1 : B → C → A
B–C : 1 Gb/s → coût 20 000
C–A : 1 Gb/s → coût 20 000
Total = 40 000
Chemin 2 : B → D → A
B–D : 10 Gb/s → coût 2 000
D–A : 1 Gb/s → coût 20 000
Total = 22 000
Le Root Port de B sera le port vers D, car 22 000 < 40 000.
2.2.3 Désignation des switches et ports désignés ( designated ports )
Sur chaque segment de la topologie, un switch deviens Designated Bridge et ces ports non root participants à la topologie deviennent des designated ports. Ces switches et ces ports serviront de forwarders aux switches suivants sur la topologie, ceux qui sont plus loin que la racine.
2.2.4 Blocage des ports redondants ( Redundant ports )
Les ports participant à la topologie mais n'étant désignés ni comme root, ni comme designated seront alors bloqués et deviendrons des blocked ports. Ces ports pourront être activés en cas de dysfonctionnement de l'un des ports actif.
En attendant, ceux-ci :
ne transfèrent plus le trafic,
n'apprennent plus d'adresses MAC,
n'écoutent plus de trafic, hormis les trames BPDU.
C'est comme cela que les switches de la topologie se prémunissent des boucles réseaux et c'est ce fonctionnement qui explique également les latences de cicatrisation.
On a donc 5 états possibles pour un port :
Disabled
Blocking (20 seconds)
Listening (15 seconds)
Learning (15 seconds)
Forwarding
2.2 Les améliorations de RSTP
Pour simplifier le fonctionnement du protocole et accélérer les temps de cicatrisation réseau, le RSTP va apporter quelques changements à ce fonctionnement.
L'ajout d'un nouveau type de port dit edge port (PortFast), permettant de relier des équipements actifs ou des terminaux sans que cela ne déclenche un recalcul de topologie.
Des négociations plus rapides lors des élections de switch et de détermination des status des ports basés sur un mécanisme de Proposal/Agreement :
Un switch propose un port comme Designated port.
Les voisins directs approuvent.
Les deux ports passent automatiquement en mode forward.
Pour vulgariser, lorsqu'un switch reçois un BPDU de son voisin, il peut décider :
"Ce voisin a un meilleur chemin vers le root que moi" --> Je deviens Root port
"J'ai un meilleur chemin que lui" --> Je deviens Designated Port
Détail de la négociation
Un switch reçois une BPDU "meilleure" : Il comprend que son port doit devenir 'root port'.
Il bloque temporairement tous ses 'designated ports' : Ce qui évite les boucles.
Il envoie un 'agreement' à son voisin : Si il peut garantir que cela ne créée pas de boucle.
Le voisin passe son port en forwarding : Pas de délai d'attente comme en stp classique.
Le switch débloque tous ses 'designated ports' : La topologie converge ainsi en quelques milisecondes.
Voici un comparatif des deux protocoles permettant de se faire un ordre d'idée
Fonctionnalité
STP (802.1D)
RSTP (802.1w)
Convergence
30–50s
1–3s
Etat de ports
5
3
Rôle de ports
3
4
BPDU
seul le root envoie
tous les switchs envoient
Détection de dysfonctionnement
Lent
Fast Handshake
Edge ports
Optionnel
Concept Natif
III. Caractéristiques des ports
3.1 Caractéristiques générales
Les ports peuvent être identifiés sur les switches de la façon suivante :
Identification sur le switch
Correspondance
Caractéristiques
RP
Root Port
Un seul par switch.
Non applicable au root bridge.
Représente le chemin le plus court vers le root bridge.
DP
Designated Port
Un par segment.
Transmettent le trafic vers l'aval depuis le root bridge.
AP
Alternate Port
port de backup pour le root port.
Si le RP est coupé, il prends le relai.
BP
Backup Port
port de backup pour un designated port (sur le même switch).
Rare dans les topologies réseaux modernes.
EP
Edge Port (PortFast)
Ne participe pas à la topologie.
Relie un équipement actif.
En RSTP, un port peut avoir trois états fonctionnels ( Au lieu de 5 en STP ) :
Discarding : Ne forwarde pas le trafic, n'apprends pas les MAC.
Learning : Apprends les MAC address.
Forwarding : Forwarde le traffic, port actif.
Les ports ne participant pas à la topologie où les équipements actifs sont connectés sont les Edge Ports (PortFast).
Pas de recalcul ou de changement d'état sur ces ports car ils ne participent pas à la topologie. Ils passent directement en mode forward. Cela permet d'annuler les délais pour les équipements actifs branchés dessus.
2.2 BPDU Guard & Loop Guard
En plus de ce qui a été vu ci-dessus, il existe deux fonctionnalités supplémentaires applicables aux ports en STP/RSTP.
La première est le BPDU Guard : C'est une fonctionnalité qui sert à protéger les Edge Ports des trames BPDU non désirées.
Ces ports ne participant pas à la topologie, ils ne doivent pas traiter de trames BPDU.
Si toutefois, suite à une erreur de manipulation (mauvais branchement par exemple), ces ports reçoivent des trames BPDU, cela veut dire qu'un port RSTP a été branché sur un port ne participant pas à la topologie et donc naturellement non protégé contre les boucles réseaux.
Dans ce cas, le BPDU Guard va automatiquement couper le port pour prévenir la boucle. Le port passe alors en état Err-disable.
La seconde est Loop Guard : C'est une fonctionnalité qui sert à protéger les liens Trunk et les uplinks de boucles unidirectionnelles.
2.2 Rapid-PVST
Le rapid-PVST ou (Per Vlan Spanning Tree) est un RSTP appliqué par VLAN.
Ainsi si plusieurs VLAN co-existent au sein d'une même topologie physique, il est possible de définir une instance de RSTP par VLAN.
Chaque VLAN dispose ainsi de :
Son Root Bridge,
Ses chemins favoris,
Ses propres root ports,
Ses propres designated ports.
Conseil : Cela peut se révéler particulièrement intéressant dans de vastes structures dans lesquelles il est important voire crucial d'optimiser ses chemins réseaux et d'équilibrer la charges sur les différents liens. Ou dans le cas d'usages intensifs de bande passante sur des vlan concurrentiels ( voip / Vidéo )... 
Cependant pour des réseaux à très grande échelle, il sera préférable d'utiliser le protocole MSTP.
Il sera également bon de prendre en compte que vu que le Rapid-PVST est instancié par VLAN, il consomme également plus de CPU.
IV. Les trames BPDU
Comme vu jusqu'ici, le RSTP repose sur l'utilisation de trames spéciales appelées BPDU.
Contrairement au STP classique où seul le root bridge envoie des trames, en RSTP, chaque switch envoie ces trames en plus de forwarder celles du root bridge. C'est cela qui permet des délais de cicatrisation si courts.
 Ces trames se déclinent en deux types.
4.1 Les Configuration BPDU
Il s'agit des paquest BPDU normaux, envoyés toutes les 2 secondes par le Root Bridge.
Celles-ci contiennent :
l'ID du root Bridge
Le coût du chemin vers le root
l'ID du bridge émetteur
l'ID du port émetteur
les différents timers (Hello, Max Age, Forward Delay) si ceux-ci sont utilisés
Leur rôle est de maintenir la topologie. Elles servent également a élire ou ré-élire un root bridge et déterminer les root ports et designated ports.
4.2 Les TCN BPDU ( Topology Change Notification ) en STP
En STP classique, ce sont les trames spéciales envoyées par un switch qui détecte un changement dans la topologie.
( par exemple : Un port qui passe de forwarding à down ou inversement, un lien qui tombe, un switch ajouté ou retiré de la topologie, etc...)
Cela fonctionne de la façon suivante :
Un switch non-root détecte un changement de topologie.
Il envoie une TCN BPDU vers son root port.
Chaque switch intermédiaire accuse réception et relaie vers le root bridge.
Le root bridge active alors le Topology Change Flag dans ses configuration BPDU et diffuse cette information sur l'ensemble du réseau.
Chaque switch va alors réduire le temps le mise en cache des adresse MAC ( aging time) afin de les purger au plus vite.
Info : En RSTP, ces trames sont supprimées et leur mécaniques sont intégrées dans les BPDU normaux, ce qui est beaucoup plus rapide.
4.3 Détection des changements en RSTP
En RSTP, plutôt que d'utiliser des trames dédiées sur un changement de topologie, le Change Flag est intégré dans les trames classiques. Et comme chaque switch émets ses propres trames en permanence en plus de forward celles du root bridge, l'information se diffuse donc bien plus rapidement.
Ainsi, lorsqu'un port change d'état ( Up / Down / Forwarding), le RSTP :
Met immédiatement à jour son rôle (RP, DP, AP, ...)
Envoie une BPDU avec le bit Topology Change activé
Informe dirrectement ses voisins, et ce
sans attendre le Max Age
sans envoyer de TCN BPDU à destination du root bridge
Ses voisins mettent immédiatement à jour leurs tables MAC
Rendant ainsi la propagation de l'information immédiate et bidirectionnelle.
La propagation devient ainsi locale plutôt que globale et les délais de cicatrisation sont ainsi réduits à leur minimum.
Un changement de topologie met désormais entre 1 et 3 secondes à être totalement oppérationnel.
V. Bonnes pratiques
Il est important, compte tenu des mécanismes ci-dessus, de prendre en considération l'ensemble des fonctionnalités dans la construction d'une topologie à la fois résiliente et optimisée.
Toujours définir un Root Bridge soi-même.
Définir les priorité des switches manuellement pour définir des routes "préférées".
Bien déclarer les ports ne participant pas à la topologie en Edge Ports.
Sur ces ports, activer BPDU Guard pour éviter les erreurs de manipulation.
Utiliser préférentiellement un mode 'Point-to-point' sur les trunk.
Activer Loop Guard sur les trunks
Eviter de mixer STP et RSTP.
VI. Conclusion
Le protocole RSTP est primordial dans les architectures réseaux modernes critiques où le réseaux doit à tout prix être stable et fonctionnel. Rendant ainsi centraux les aspects de redondance et de convergence rapide.
Mais il fait entrer beaucoup de notions différentes complexes qu'il est essentiel de bien comprendre et maîtriser afin de rendre son infrastructure la plus optimisée possible.

Réseau - sockets
Difficulté : Débutant
Notions : adressage IP, port, modèle OSI, protocoles réseaux.
I. Introduction
Prérequis : Connaître les notions de modèle OSI et l'adressage IP (à minima V4).
Lorsqu'une machine veut utiliser un protocole pour envoyer ou recevoir des informations sur un réseau, elle va devoir ouvrir un canal de communication.
Comme la machine peut ouvrir plusieurs canaux de communication à la fois, elle va avoir besoin de pouvoir identifier quel canal est utilisé pour quelle communication.
II. Principes du socket
2.1 Définition
En réseau, un socket est un couple d'adresse ip / port basés sur un protocole, permettant d'envoyer ou recevoir des données à travers un réseau informatique.
Il y a 3 choses qui identifient un socket sur le réseau :
Adresse IP : l'adresse IP avec laquelle la machine initie la communication.
Port source : le port source qu'elle va dédier à la communication (selon le protocole, celui-ci peut être fixe, compris dans une plage ou défini aléatoirement).
Protocole : Le protocole utilisé dans la communication.
Pour la machine, un socket se présente comme suit : <ip machine>:<port>.
Par exemple : 192.168.1.10:250458 (TCP)
Il existe trois types de socket, basé sur le protocole utilisé (TCP, UDP, Raw) :
Type
Description
Utilisation type
Stream Socket (TCP)
Fiable et orienté connexion.
navigation web, messagerie, etc...
Datagram Socket (UDP)
Plus rapide mais pas de contrôle
streaming vidéo, VoIP, jeux en ligne, etc...
RAW Socket
Accès direct aux couches basses
Diagnostics réseaux, protocoles personnalisés, etc...
2.1 Limitations
Un socket ne peut être attribué qu'a un seul canal de communication à la fois, donc si la machine veut en ouvrir plusieurs, elle devra utiliser plusieurs sockets différents.
Selon les protocoles utilisés et leurs limitations ou paramétrage, elle ne pourra en ouvrir qu'un nombre simultané limité. Voire un seul.
2.3 Attribution des sockets
Un socket ne peut être attribué qu'a un seul canal de communication à la fois, donc si la machine veut en ouvrir plusieurs, elle devra utiliser plusieurs sockets différents.
Selon les protocoles utilisés et leurs limitations ou paramétrage, elle ne pourra en ouvrir qu'un nombre simultané limité. Voire un seul.
III. Socket client et socket serveur
3.1 Côté serveur
Côté serveur, le socket d'écoute est fixé par le protocole.
Il peut s'agir d'un port fixe : par exemple le 53(UDP/TCP) pour le DNS ou le 123 (UDP) pour le NTP.
Une plage de port : 3478 - 3481 (Microsoft TEAMS)
Souvent, un port unique fait office de point d'entrée et un répartiteur écoutant sur ce port, redirige le client sur un port destination spécifique de la plage.
3.1 Côté client
Côté client, il s'agit le plus souvent d'un port source dynamique 
Sauf fonctionnement spécifique, la plage de port pour un socket côté client s’étend de  49152 - 65535 conformément à ce qui est prévus dans les catégories de ports.
IV. Opérations de diagnostics
4.1 Visualiser les sockets utilisés.
4.1.2 Sur windows
Utiliser les commandes suivantes :
netstat -an
Pour plus de détails :
netstat -anob
Lister seulement les ports en écoutes :
netstat -anob | findstr LISTENING
4.1.2 Sur linux
Utiliser les commandes suivantes :
netstat
Lister seulement les ports en écoutes :
netstat -tunlp
Lister depuis les processus :
lsof -nP -iTCP -sTCP:LISTEN

Réseau - Topologies
DISCLAIMER : Cette page est actuellement en cours de rédaction et son contenu peut être incomplet ou inexact
Difficulté : Débutant
Notions : Topologies réseaux, fondamentaux
I. Introduction
Un réseau est un ensemble de machines interconnectées. Il peut prendre plusieurs formes qui seront appelées 'Topologies'.
Une topologie réseau est la couche structurelle sur laquelle les machines vont s'interconnecter pour former le réseau.
Cela conditionnera en partie les protocoles utilisés pour communiquer, mais aura aussi un impact sur des critères comme :
La performance
La résilience
La scalabitilé
Habituellement la notion de topologie fait autant référence à la couche physique des interconnexions ( câbles, antennes, fibres, etc... )
qu'a la couche logique (comment les chemins réseaux sont organisés).
II. Topologies classiques
2.1 Topologie en étoile
C'est la topologie la plus courante. l'Ensemble des équipements sont reliés à un point central qui servira à distribuer le réseau.
Adapté au réseaux petits à moyens, elle peut rapidement être mise à l'échelle.
2.2 Topologie en étoile étendue ou hiérarchisée.
C'est la topologie la plus courante des que les réseaux grossissent un peu.
L'on part d'un cœur de réseau qui se situe au niveau le plus haut, puis on décentralise sur des équipements périphériques. En fonction de la charge et du nombre, il est possible d'ajouter également des switches sur les autres switches, etc...
Info : Cette topologie en arborescence comporte également une variant plus large pour les grosses structures ou les structures multi-sites. Avec des routeurs plus réguliers et différents niveaux de swiches.
2.3 Topologie meshée
En français topologie 'maillée'.
Certains liens sont redondés et les équipements sont interconnectés. Cette topologie est particulièrement appréciée sur des réseaux où la fiabilité l'optimisation prime sur la simplicité d'installation.
Trivia : Ce qui ressemble très vite à une toile d'araignée. D'où l'origine du 'web';
III. Topologies industrielles
3.1 Topologie en bus
Autrefois utilisée pour les réseaux informatiques à leurs débuts, il s'agit d'une des forme de réseau les plus simples et prévisibles.
Chaque équipement est connecté à un bus et dispose d'un ordre de passage sur le réseau.
Le long du bus, une trame circule d'un bout à l'autre dans les deux sens et fait transiter la donnée.
Trivia : C'est cette notion de bus et de trame qui donneront ensuite les notions de trame réseau et de BUS au sens largeur de bande passante de la connectique.
3.2 Topologie en anneau
Bien que se retrouvant essentiellement dans le milieu industriel, elle peut parfois faire sens dans des réseaux vidéos ou voix sur IP associée à une politique de QoS. Voire même informatique classique dans la mesure où elle permet une forme basique de redondance tout en coûtant sensiblement moins cher que le réseau mesh.
3.1 Topologie en anneau

Rôles / Services
Notions théoriques liées aux services et divers produits sur cette couche.

Active Directory - Méthode AGDLP
Difficulté : Débutant
Notions : Active directory, Organisation, Bonne pratique, méthodologie AGDLP.
I. Introduction
La méthode AGDLP ( Account Global Domain Local Permission ) est une méthode de gestion de droits et permissions à travers les groupes Active Directory et plus largement LDAP.
Cette méthode poursuit un objectif triple :
Management : Cela facilite la délégation des accès et de la gestion de ceux-ci. Le fait de dé-corréler l'utilisateur de ses droits d'accès rends la solution scalable et facilement réversible.
Audit / Respect RGPD : Elle aide également à la conformité RGPD car grâce à elle, il deviens facile et rapide de savoir avec précision qui a accès à quoi. Cela rends la traçabilité plus simple et précise.
Cyber sécurité / Moindre privilège : Elle permet enfin de s'assurer une normalisation des droits d'accès en s'assurant que chaque utilisateur dispose uniquement des droits strictement nécessaires et que la portée de ces droits est correctement ajustée.
La combinaison de ces trois buts résulte en une gestion qui a priori peut sembler complexe à la mise en oeuvre, mais qui se révélera par la suite bien plus simple, transparente et efficiente dans son utilisation courante.
Dans un second temps, il deviendra aussi possible d'encadrer correctement la délégation de la gestion des accès et des privilèges.
Cette méthode peux s'appliquer indépendamment aux serveurs de fichiers, aux différents services et applications de l'entreprise, ainsi que (par le biais du SSO) aux rôles des application fédérées.
Info : Cette méthode prends tout son sens dans un environnement multi-domaines comme c'est de plus en plus fréquent d'en voir avec la logique de tiering.
II. Rappel : Portée des groupes AD
Avant de rentrer plus en détail sur l'application de cette méthode, il est nécessaire de rappeler certaines bases du fonctionnement des groupes Active Directory (ou LDAP) car c'est sur eux que va intégralement s'appuyer cette méthode.
Pour rappel, il exite deux types de groupes :
Security (sécurité) : Ce type de groupe est celui qui va être utilisé dans ce contexte. C'est celui qui permet de gérer les permissions et les droits d'accès ainsi que l'application des GPO.
Distribution : Ce type de groupe sert à gérer les listes de distribution pour les mails.
A cela s'ajoute la portée du groupe. c'est ce point qui va être central dans l'utilisation d'AGDLP. Il s'agit du niveau de visibilité du groupe.
Il y a 3 niveaux de portée :
Domain Local : Le groupe existe dans le domaine local. Mais n'est pas visible depuis les autres domaines.
Ils peuvent contenir : des utilisateurs du domaine, des groupes globaux d'autres domaines, des groupes universels.
Global : Le groupe existe dans le domaine local et est visible depuis les autres domaines de la fôret.
Ils peuvent contenir : des utilisateurs du même domaine, des groupes globaux du même domaine.
Ils peuvent être membre : de groupes locaux dans n'importe quel domaine, de groupes globaux du même domaine, de groupes universel.
Universel : Le groupe existe au niveau de la forêt active directory est est visible partout.
Ils peuvent contenir : utilisateurs de n'importe quel domaines, groupes globaux de n'importe quel domaine, autres groupes universels.
Ils peuvent être membre : de groupes locaux dans n'importe quels domaines, d'autres groupes universels.
III. Fonctionnement de la méthode
3.1 Principe général
Comme vu ci-dessus, les groupes peuvent être imbriqués les uns dans les autres et c'est ce principe là qui va nous intéresser dans l'application de la méthode AGDLP.
L'idée de cette méthode est de dissocier les notions de rôles (droits effectifs attribué à un utilisateur) et de groupes d'appartenance.
Afin de limiter également la portée des droits, il faudra utiliser pour ces rôles des groupes avec une portée minimaliste.
Puis pour octroyer un rôle à un groupe d'utilisateur, il faudra ajouter le groupe des utilisateurs dans le groupe rôle.
Ainsi, si un utilisateur intègre un service dans l'entreprise, son rajout dans le groupe du service lui conférera automatiquement les accréditations (rôles) inhérents à ce service.
3.2 Normalisation
Afin de pouvoir se retrouver dans les noms et types de groupes, il va falloir adopter une normalisation stricte et une convention de nommage claire.
Les bonnes pratiques observées tendent vers la convention suivante :
Le préfixe GRP suivi du séparateur _
Le type de groupe (sécurité, GMSA, liste, ...)
Un caractère de séparation. Ici _
La portée du groupe (local, global, universel).
Un caractère de séparation. Ici _
La finalité de l'utilisation du groupe.
Un séparateur différent. Ici -
Le nom du groupe (ou du dossier pour les groupes de sécurité).
Info : les groupes de sécurités pour l'accès aux dossiers seront suffixé par _RO (read only), _RW (read-write) ou _FC (full control).
Préfixe
Type
Séparateur
Portée
Séparateur
Application
Séparateur
Usage
GRP_
SEC
_
GL
_
GPO_EXL
-
PrintServers
GMSA
GG
GPO-INC
RDSSessionHosts
LST
UN
RDS
Farm1
APP
AppName
VPN
Admins, Users
PROXY
RestrictedUsers, Noaccess, ExtendedAccess
VCSA
LAB1, LAB2
FIL
Comptabilité_RO
...
Conseil : les listes de distributions seront simplement préfixées avec '&' suivi du nom de la liste
GRP-GLO-RDS_AllUsers
GRP-GLO-APP_Sage
GRP-LOC-ROXY_NoInternetAccess
&ServiceComptabilité
IV. Mise en application
4.1 Appliqué au systèmes de fichiers
Exemple : Dans le cadre de son service comptabilité, l'entreprise dispose d'un partage //share/comptabilité.
L'entreprise veux mettre en place 3 niveaux d’accréditation :
Les comptables gèrent le service et doivent avoir accès en contrôle total au dossier partagé.
Les assistants n'ont pas besoin de créer ou supprimer des choses, mais doivent pouvoir réaliser des modification dans les fichiers existants.
Les auditeurs sont des personnes qui viennent auditer les comptes et doivent avoir un regard sur les pièces comptable, mais non pas besoin d'écrire.
Dans ce cas de figure, la première étape consiste à créer le répertoire et les groupes d'autorisations (rôles). En groupe local, car les droits ne s'appliquent que dans ce domaine.
GRP_SEC_GL_FIL_Compta_FC
GRP_SEC_GL_FIL_Compta_RW
GRP_SEC_GL_FIL_Compta_RO
Puis créer les groupes globaux contenant les utilisateurs et les intégrer dans les groupes locaux.
GRP_SEC_GG_Compta-Comptables
GRP_SEC_GG_Compta-Assistants
GRP_SEC_GG_Compta-Auditeurs
Enfin, il suffira d'ajouter / Retirer au besoin les utilisateurs dans les groupes :
Si l'on veut par exemple que le groupe Direction contenant le PDG et les membres du conseil ai également un droit de regard et de modification sur les fichiers de la comptabilité, il faudra ajouter cela de la façon suivante.
A l'inverse, si un même groupe, par exemple de comptables du siège social doit avoir accès aux dossiers comptabilité des autres domaines. Les groupes globaux étant visibles depuis les autres domaines, il faudra l'ajouter dans les groupes locaux sur les autres domaines.
4.2 Appliqué aux applicatifs & services
Il est possible de poursuivre cette logique sur les applicatifs et services. Par exemple dans le cadre d'une ferme RDS, plusieurs applications sont partagées dans différentes collections.
Par exemple :
le service R&D utilise un groupe d'application de conception de produits électronique en RDP.
Le service RH utilise des application pour la gestion des bages, etc...
Les deux services accèdent également à un pool d'applications communes à tout le personnel.
La définition se fera comme suit :
Info : De même que précédemment, les groupes globaux pourront être ajouté dans des groupes locaux d'autres domaines si nécessaires. Cette méthode peut aussi s'appliquer par exemple pour des services comme le proxy, le VPN, etc...
4.3 Appliqué au SSO et aux rôles
Dans la plupart des applications modernes, la notion de rôle est déjà intégrée au sein de l'application et ce rôle peut être appliquée directement à un groupe ou utilisateur.
Ainsi il pourra être mis en place le même principe. Pour attribuer ces rôles automatiquement, cela pourra se faire de deux manières :
Soit à travers le SSO directement qui mappera l'appartenance au groupe au rôle correspondant.
Soit directement dans l'application, auquel cas le système reste le même que précédemment.
Le système SSO intégrera alors dans le jeton d'authentification les appartenances au groupes, ce qui permettra d'effectuer les claims (demande de rôles).
V. Variantes du modèle
5.1 AGUDLP (grosses structures)
Il s'agit de la même méthode, mais incluant également les groupes universels pour gérer les approbation sur l'ensemble des domaines.
Adapté dans un environnement multi-domaine, ou de tiering au sein d'une forêt, elle permet d'avoir par exemple un domaine d'administration et plusieurs domaines clients.
Il faudra alors ajouter les administrateurs dans un groupe global du domaine d'admin, puis ces groupes d'administration seront intégrés dans un groupe universel afin d'en faciliter l'intégration au sein des différents domaines.
5.2 AGLP
Cette variante consiste à utiliser des groupes locaux sur la machine directement au lieu d'un groupe active directory.
Cela peut être nécessaire sur des applications utilisant des groupes locaux des machines ou certains services créant eux-même des groupes locaux sur les machines afin de gérer l'accès aux ressources du services.
Ou encore certaines ressources et services sur linux.
Info : Il existe également d'autres vairantes comme AGUDL P, AGUGDLP, mais celles-ci sont rare et ne constituent pas la norme de l'utilisation.
VI. Bonnes pratiques
Afin de garantir une efficacité optimale de cette méthode, il faut considérer un certain nombre de bonnes pratiques associées.
A commencer par le fait de l'intégrer dans un plan plus large. Cela va de pair avec :
Une convention de nommage claire et explicite (comme vu ci-dessus).
Une documentation des niveaux accréditations et une cartographie des accès.
Une politique d'audits réguliers des groupes et permission afin de s'assurer de leur conformité.
Mettre en place une politique de gestion du cycle de vie des groupes ( validation des ajouts / suppression des membres ).
Eviter les imbrication inutiles et limiter au minimum celles-ci.
Contrôler les délégations sur la gestion de ces groupes.
VII. Erreurs à éviter
De même que les bonnes pratiques garantissent un fonctionnement optimal, de mauvaises pratiques peuvent également venir saper l'efficacité de la méthode :
Donner des permissions directement aux utilisateurs ( bypass de la chaîne d'autorisations).
Utiliser des groupes globaux sur les ACL ( contraire au principe de moindre privilège).
Mélanger rôles, permissions dans un même groupe.
Ne pas nettoyer les groupes, utilisateurs, permissions obsolètes.
Avoir une mauvaise gestion des comptes de services.
VIII. Conclusion
Si cette méthode peut ne pas être intuitive voire pénible à mettre en place, elle facilitera grandement la gestion courante des accès et des droits. Elle permettra également, sous réserve de respect des bonnes pratiques et d'éviter les erreurs, de permettre un audit rapide et efficace des accès effectifs pour un utilisateur ou un service de l'entreprise.
Conseil : De plus, sa mise en oeuvre et son maintient peuvent être grandement améliorées et facilitées par la mise en place de systèmes d'automatisation à travers des scripts ou des catalogues de services IaC. Réduisant ainsi considérablement la marge d'erreur humaine et garantissant la conformité.

Docker - Introduction à la "containerisation"
Difficulté : Intermédiaire
Notions : Containers, systèmes de containers, docker.
I. Introduction
Tout comme la virtualisation avais permis un bond en avant en permettant de placer plusieurs machines virtuelles sur un hôte physique, la containérisation va plus loin en ne virtualisant plus un système entier mais en cloisonnant directement une couche applicative ou un service dans un container.
Basé sur un système d’image, celui-ci permet de virtualiser un morceau de système sur lequel viendront s’appuyer les containers contenant les ressources (binaires, configurations, librairies et dépendances) et auquel il sera possible de connecter des volumes persistant contenant les données.
Cela est une excellente alternative en terme de performance, la mutualisation des images permettant un gain significatif du fait de la non nécessité de virtualiser une couche hardware complète dans la plupart des cas.
Mais également en terme de gestion et de déploiement. Une fois les images créées, elle sont déployables en quelques minutes et utilisables immédiatement. De plus si plusieurs containers utilisent la même image et nécessitent un mise à jour, il sera simple de mettre à jour l’image et la pousser en production. les containers pourront ensuite être liés a cette nouvelle image, réduisant le temps de mise à jour et les indisponibilités.
Enfin en terme de sécurité. Chaque application utilisant son propre environnement cloisonné, il sera très difficile d’infecter les systèmes adjacents et la compromission d’un service aura des effets uniquement sur celui-ci.
De plus, les images étant non persistantes, un rechargement de celle-ci supprimera les éventuelles traces d’attaque et permettra de revenir rapidement à une configuration sûre.
Cela permet également de personnaliser grandement l’architecture des services. Par exemple voici un container web :
Enfin Le dernier avantage et non le moindre, est la grande capacité d’automatisation de l’outil.
Les images et containers, ainsi que des architectures complètes peuvent être créées a partir de fichiers d’instructions (la plupart en YAML) qui seront utilisés comme base à travers des API.
Ce qui permet de faire de “l’infrastructure as code” et de publier en quelques étapes des services voire des infrastructures complètes architecturées en amont.
II. Principes de bases
Les images : Les images sont des versions packagées de services. Elles sont construite à l'aide de fichiers que l'on appelle 'dockerfiles'. Le plus souvent, elle partent d'une couche OS sur laquelle le(s) service(s) et le contenu seront préconfigurés et packagés puis fournis sous forme d'image pour un déploiement rapide et une grande souplesse dans la gestion des containers utilisant ces images. Lors de l'utilisation par un container, le contenu de l'image est dit 'non persistant'. En effet, si le container est arrété ou recontruit, l'image redémarre sur son état initial.
Les volumes et points de montage : Du fait de la non persistance des images, il n'est pas possible d'y stocker des données dites 'vivantes' dans le container. Pour cela, il faudra lui attacher des volumes ou des fichiers. Il s'agit des ressources qui seront partagées entre l'hôte et le container. Cela peut être des fichiers de configurations par exemple qui seront montés dans le container sur un chemin précis ou dans le cas des volumes. Lors de la création de ceux-ci, un espace dédié est créé sur l'hôte et sera utilisé ensuite dans le container sur un point de montage. L'on y placera toutes les données qui feront vivre le service (site web, base de donnée, fichiers du service, logs...)
Les containers : Le container est donc ce qui résulte de l'utilisation des éléments ci-dessus. Il va utiliser une image pour fournir un service et les volumes pour stocker la donnée.
Les services : Sur un cluster (swarm), les containeurs ne sont plus addressés directement en tant que tel mais font partie d'un service. Celui-ci permet de disposer de propriétés de déploiement comme de la haute dispo, des contraintes de placement sur des noeuds du cluster, le nombre de copies de containers, etc...
Les stacks : Une architecture rendant un service peut être constituées de plusieurs containers ou services. par exemple dans le cadre d'un hébergement web, il peut y avoir un container wordpress, puis un container DB et un container SSH, tous constitutifs du 'stack' hebergement.
Les réseaux : Les réseaux permettent à différents services de comuniquer entre eux. Par exemple permettre à un container web de se connecter à un container SQL, ou encore à un reverse proxy d'adresser un serveur web.
L'exposition des ports : Par défaut les containers sont dans des réseaux isolés ou bridgés non accessible de l'extérieur. Il faut pour cela natter des ports. Par exemple un port 8082 en TCP sur le port 80 d'un container. dans ce cas, c'est l'hôte qui devra être addressé avec le port natté (ici: 8082). On parkle alors d'une "exposition de port".
Les secrets : Certaines informations sont par nature sensibles. Les comptes ou mots de passes, des clés, des tokens, etc... Pour se passer ses informations entre les noeuds ou les monter dans un ou plusieurs container sans exposer ces informations il est possibles de créer des secrets. Ce sont des fichiers chiffrés qui sont directement généré à partir d'une saisie d'information protégées et ne seront ensuite utilisable qu'entre les membres du cluster et aux containers. Cela permet d'utiliser ces informations en toute sécurité.
Les dockerfiles : Ce sont des fichiers contenant une séquence d'instructions qui vont être utilisés pour générer une image. Cela sert dans le cadre de l'automatisation. Exemple :
FROM image_name #partir de l'image désignée (ou FROM scratch) pour recompiler une image en partant de zéro.
LABEL label1="valeur1" label2="valeur2" label3="valeur3" #définit les tags de l'image
VOLUME ['/chemin/vers/dossier'] # si pas de volume associé, par défaut monte un volume à cet endroit
ARG ARG1="value" #variable 1
ARG ARG2="value" #variable 2
WORKDIR /chemin/racine #chemin sur lequel on se place pour exécuter les commandes
COPY /chemin/vers/fichier /chemin/dans/container #copie un fichier présent sur la machine dans le container
RUN commande1 # lance une commande dans le container
RUN commande2
RUN commande3
EXPOSE 80/tcp #expose le port voulu dans le protocole voulu
ENTRYPOINT ["command", "arg1", "arg2"] #donne le processur ou service à observer pour le démarrage du container
Pour plus d'informations : Dockerfile reference
Les fichiers compose :  Les fichiers compose sont des fichier descriptif de l'architecture d'un service ou d'un stack. Ils permettent de générer les services/stacks à partir de ce fichier de manière automatisée. Cela rentre dans le cadre de "l'infrastructure as code".
Exemple de fichier compose pour un stack wordpress :
services:
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    command: '--default-authentication-plugin=mysql_native_password'
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
    expose:
      - 3306
      - 33060
  wordpress:
    image: wordpress:latest
    volumes:
      - wp_data:/var/www/html
    ports:
      - 80:80
    restart: always
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress
volumes:
  db_data:
  wp_data:
Le swarm : le swarm est un cluster composant un ensemble de noeuds sous docker. Un swarm est initialisé par un noeud 'manager' et comportera ensuite un ensemble de 'worker'. Cela permettra de répartir des charges de travail et/ou de fiabiliser certains services en les répliquants sur plusieurs noeuds.

Filer - DFS & DFSR
Difficulté : Intermédiaire
Notions : Serveurs de fichiers, partages, Réplication, cluster.
I. Introduction
Le DFS ( Distributed File System ), ou système de fichiers distribué en français, est un rôle serveur permettant de centraliser la gestion et la publication des partages sur différents serveurs de fichiers en s'appuyant sur les espaces de noms.
Le principe est d'avoir un ou plusieurs serveurs gestionnaires de ces espaces de noms qui vont créer une racine 'virtuelle' au sein du domaine depuis laquelle tous les partages seront accessibles. Au niveau de l'utilisateur, ce chemin se substitue au chemin réel vers le dossier partagé. 
Cela permet de dé-corréler l'accès aux fichiers du point de vue utilisateur de l'emplacement réel des données.
Cette dé-corrélation entraîne ainsi plusieurs avantages :
Possibilité d'ajouter de la redondance sur les sources de partages
Possibilité de stocker différents partages sur différents serveurs, augmentant ainsi la segmentation et donc la résilience et la sécurité (pas les même machines en fonction du niveau de sensibilité de la donnée)
Transparent pour les utilisateurs
Enfin, il est possible de coupler ce principe avec de la réplication synchrone ( DFSR ). Ainsi, l'utilisateur accède de façon transparente à un emplacement réseau permettant de faire de la haute disponibilité et de la répartition de charge.
II. Notions importantes
Pour bien cerner les principes clés du DFS et de la réplication associée, il est essentiel de comprendre les trois notions sur lesquelles il va se reposer :
Racine DFS : C'est le point d'entrée principal du système DFS. Cette racine est un emplacement réseau qui contiendra les 'raccourcis' vers les cibles DFS gérée par le serveur. Si le serveur est intégré dans un domaine, cela ressemblera à '\\domaine.ext\racineDFS\' et servira de point d'entrée sur les autres partages.
Dossier : C'est le nom du partage affiché côté client et dans la configuration du serveur. Une liaison sera ensuite faite entre ce dossier et une cible afin de faire le lien entre ces deux éléments. Certains dossiers n'utilisent pas de cible mais sont uniquement présents pour structurer l'arborescence de la racine DFS. Ces dossiers sont également appelés 'Liaisons DFS'.
Cible : Le serveur et le chemin réseau réel pour accéder au dossier partagé. Ce qui permettra lors de l'accès au dossier, de renvoyer l'utilisateur au bon endroit.
III. Architecture
Dans le domaine 'domaine.local', il y a 3 partages qui doivent êtres accessibles aux utilisateurs.
Comptabilité
Informatique
Data 
Sources
Voici comment se présente cette architecture :
Ainsi du point de vue utilisateur, pour accéder aux logiciels, le chemin sera : '\\domaine.local\partages\informatique\logiciels'.
IV. DFSR
La réplication DFS ou DFSR est un système de réplication des fichiers s'appuyant sur DFS et utilisé en complément de celui-ci pour mettre en place de la haute disponibilité sur les partages de manière transparente pour les utilisateurs.
Un groupe de réplication est créé. Celui-ci contient les membres qui sont les serveurs partenaires de réplication.
Dans ce groupe, les dossiers partagés sont publiés avec des sources et des destinations. La réplication pourra se faire alors au choix en sens unique ou de façon bilatérale.
Il existe deux types de topologie de réplication :
Hub and spoke
Full Mesh
Dans ce mode, un serveur central réplique de manière unilatérale vers les autres membres. Cela permet essentiellement de garder des copies des fichiers.
(nécessite 3 nœuds minimum)
Dans ce mode, chaque serveur réplique de manière bilatérale avec ses autres partenaires. Cela permet d'assurer de la haute disponibilité.
Il sera ensuite également possible de décider si les réplications doivent se faire de façon synchrone ou asynchrone (créneaux définis dans un planning).
V. Conclusion
En conclusion, de par son architecture même, le système de racine DFS permet une gestion simple et centralisée de l'accès aux données. Lorsqu'il est en plus couplé à la mise en cache et à la réplication, cela permet aussi :
Simplification de l'administration : Lorsqu'une cible DFS est arrêtée (panne, maintenance, remplacement de serveur), elle peut être facilement déplacée sur un autre serveur sans que cela ne change quoi que ce soit d'un point de vue utilisateur.
Intégration client : La partie client est intégrée à windows ( mise en cache, copie hors ligne ), ce qui évite des installations supplémentaires.
Confort utilisateur : Les données sont facilement accessibles, toujours au même endroit, de façon transparente. La mise en cache et la gestion des fichiers hors ligne permet la mobilité des utilisateurs, couplé à la technique de redirection des profils utilisateurs, cela garantit également à l'utilisateur qu'il accédera toujours à ses données et son environnement de travail, peu importe le terminal sur lequel il se connecte.
Sécurité : Les permissions ne sont plus gérées par les permissions de partage, mais ce sont directement les permissions sur les dossiers / fichiers (ACL) qui s'appliquent.
Performance / Haute disponibilité : Couplé à DFSR et à la mise en cache, cela permet une amélioration des performances ainsi qu'une disponibilité accrue des données. En effet, les données étant présente et synchronisées sur plusieurs serveurs, il est possible de répartir la charge entre ceux-ci et de garantir une bonne tolérance à la panne.

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.
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).
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.
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é.

Sécurité - CIA Triad
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.
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
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
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 quand 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
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
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.
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 (Key Derivation Function) 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 (Initial Vector) 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.
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 (Diffie-Hellman) / 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 (Key Derivation Function) 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
user1
password123
EF92B778BAFE771E89245B89ECBC08A44A4E166C06659911881F383D4473E94F
user2
password123
EF92B778BAFE771E89245B89ECBC08A44A4E166C06659911881F383D4473E94F
Exemple avec salt :
Username
Salt value
String to be hashed
Hashed value = SHA256 (Password + Salt value)
user1
D;%yL9TS:5PalS/d
password123D;%yL9TS:5PalS/d
9C9B913EB1B6254F4737CE947EFD16F16E916F9D6EE5C1102A2002E48D4C88BD
user2
)<,-<U(jLezy4j>*
password123)<,-<U(jLezy4j>*
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
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..
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.
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 :
Le stockage local ( HDD, SSD, NAS, SAN, ...).
Le stockage Offsite ou externalisé ( Bande, disque externe ).
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.
2.2 Bonnes pratiques
Utiliser la règle des 3-2-1 : 3 copies sur au moins 2 médias différents et une copie hors site.
Automatiser les jobs de backup pour réduire le risque d'erreur humaine.
Chiffrer les supports de sauvegardes, plus particulièrement ceux en transit et en stockage hors site.
Effectuer des tests de restauration réguliers pour s'assurer du bon fonctionnement des sauvegardes.
Documenter Clairement et précisément les processus de sauvegardes et de restauration.
II. Rétention et conformité
2.1 Stratégies de rétention
En plus des stratégies de rétention interne, des politiques règlementaires et normatives peuvent s'appliquer.
Voire dans certains cas, des contraintes d'ordre juridique (données liées au douanes, rétention à vie des bulletin de paye).
Il faudra donc adapter les politiques de sauvegarde et moyens de rétention de la donnée afin d'adresser ces problématique.
On distinguera ainsi deux types de stratégies de rétention :
Court terme (jours, semaines, mois)
Long terme (années, décennies, à vie)
On distinguera également deux types de stockage :
Hot storage (stockage à chaud).
disponible rapidement
pouvant être sollicité facilement et souvent si nécessaire
à un coût modéré à élevé selon la quantité et les performances
Cold storage (stockage à froid).
souvent sur des supports de grande capacité
non immédiatement accessible voire hors ligne
assez peu coûteux en prix au GigaOctet.
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 :
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
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 (Plan de Continuité d'Activité) 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) ), l'on devra suivre le schéma de réflexion suivant :
Définir les points critiques à protéger. Les "fonctions vitales" de l'entreprise.
Etablir les scénarii qui entraineraient une rupture de service.
Proposer, pour chaque point, une solution adaptée pour y répondre
Définir les responsabilité et rôles dans la mise en œuvre et le suivi du PCA
Rédiger les process
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 (Plan de Reprise d'Activité) 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) ), l'on devra suivre le schéma de réflexion suivant :
Définir les points critiques à rétablir en priorité. Les "fonctions vitales" de l'entreprise.
Etablir les scénarii qui entraineraient une rupture de service.
Proposer, pour chaque point, une solution adaptée pour y répondre
Définir les responsabilité et rôles dans la mise en œuvre et le suivi du PRA
Rédiger les process
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.
 
V. Conclusion
Pour des stratégies efficaces, il faudra mettre en place à la fois un PCA et un PRA. Car les deux n'adressent pas les mêmes problèmes.
Voici un cours comparatif entre les deux : 
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
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 :
Un utilisateur ou une machine génère une clé privée.
À partir de cette clé, une requête de certificat (CSR) est créée.
Cette requête est soumise à une autorité d’enregistrement.
L’autorité d’enregistrement vérifie l’identité du demandeur et transmet la requête à l’autorité de certification.
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.
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
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.
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.
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.
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.
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).
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.
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.
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é.
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.

Systèmes
Contient les cours et notions théoriques sur les systèmes d'exploitations.

Linux - Gestion des permissions
Difficulté : Novice
Notions : Unix, Linux, gestion de droits.
I. Introduction
En gestion de droits sur les systèmes Unix, il y a 3 notions importantes :
quel est le type de l'objet
qui est propriétaire de l'objet (owner/group)
quelles sont les permissions de l'objet
Lorsque l'on gère les systèmes de fichier, si l'on fait une commande :
ls -al
Celui-ci est affiché de la façon suivante :
 
De gauche à droite :
La première lettre représente de type de l'objet. Les lettres suivantes (rwx), les droits sur les fichiers.
Le chiffre suivant représente le nombre de lien sur l'objet.
Puis l'utilisateur propriétaire et le groupe propriétaire.
La taille du fichier (en octets).
La date de dernière modification.
Le nom de l'objet
Note : dans cet exemple, l'utilisateur et le groupe ont le même nom mais sont bien deux éléments séparés.
 
II. Types d'objets
Sur linux, le principe de base est que tout est fichier.
C'est ensuite l'attribut de l'objet qui déterminera son type; Les plus utilisés sont :
- : Par défaut, un fichier
d : Un répertoire (directory)
s : fichier de socket
l : lien symbolique
Mais il existe aussi :
c : Périphérique de type caractère
b : Périphérique de type bloc
p : Pipeline
Un socket est un type de fichier représentant un socket au niveau réseau.
Un lien symbolique est un lien logique permettant de cibler un répertoire / fichier qui se situe à un autre endroit afin de le rendre disponible dans le répertoire courant sans pour autant en créer un duplicata.
III. Propriété de l'objet
Les objets ont un couple de propriétaires.
Le premier est l'utilisateur propriétaire, le second est le groupe propriétaire.
Pour changer les propriétaires d'un objet, il faut utiliser la commande 
chown <nomDuOwner>:<NomDuGroupe>
Il est possible d'ajouter -R pour rendre la modification récursive.
Exemple :
chown www-data:root index.php
Info : Par défaut, lors de la création d'un objet, l'utilisateur ayant créé l'objet est défini en tant qu'utilisateur propriétaire et son groupe personnel en tant que groupe propriétaire.
IV. Droits de l'objet
4.1 Types de droits :
Les droits UNIX s'articulent autour de trois "actions" possibles :
la lecture (r) : on peut par exemple lire le fichier avec un logiciel. Lorsque ce droit est alloué à un répertoire, il permet d’afficher la liste des fichiers du répertoire (la liste des fichiers présents à la racine de ce répertoire).
l'écriture (w) : on peut modifier le fichier et le vider de son contenu. Lorsque ce droit est alloué à un répertoire, il autorise la création, la suppression et le changement de nom des fichiers qu'il contient, quels que soient les droits d'accès des fichiers de ce répertoire (même s'ils ne possèdent pas eux-mêmes le droit en écriture). Néanmoins le droit spécial sticky bit permet de passer outre ce comportement.
l'exécution (x) : on peut exécuter le fichier s'il est prévu pour, c'est-à-dire si c'est un fichier exécutable. Lorsque ce droit est attribué à un répertoire, il autorise l'accès (ou ouverture) au répertoire.
4.2 Calculs des droits :
Ces lettres, appelés "flags" définiront les droits sur le répertoire. Ces droits sont basés sur un système en binaire sur 3 bits.
Lettre
r
w
x
Valeur binaire
4
2
1
Pour calculer tous les droits, il faudra additionner les valeurs de chaque bits pour en définir la valeur totale.
par exemple, lecture + écriture = r+w = 2+4 = 6
Ainsi, on aura la correspondance suivante :
Valeur Décimale
Droits
1
exécution ( --x )
2
écriture ( --w )
3
écriture + exécution ( -wx )
4
lecture ( r-- )
5
lecture + exécution ( r-x )
6
lecture + écriture ( rw- )
7
tous les droits ( rwx )
Attention : la valeur 7 confère tous les droits et doit être appliquée en connaissance de cause, sous peine de représenter une faille de sécurité.
4.3 Représentation des droits :
Les droits sur les objets seront ensuite représentés sous ce format :
Le premier groupe de 3 lettres sont les permissions de l'utilisateur propriétaire.
Le second groupe représente les droits du groupe propriétaire.
Le 3ème groupe représente les droits appliqués à tout le monde.
4.4 Modification des droits :
Les permissions se modifient avec les commande ci-dessous :
chmod <notation décimale ou lettres> <objet>
Il est possible d'ajouter -R pour rendre la modification récursive.
Exemple :
chmod 755 /var/www/index.php
D'autres commandes existent pour modifier ou ajuster les droits, notamment avec les lettres ou pour ajouter/retirer un droit spécifique à l'utilisateur, au groupe ou à everyone.
Mais la méthode évoquée ci-dessus reste la plus simple et la plus rapide.
V. Droits spéciaux
5.1 Droits SUID :
Ce droit s'applique aux fichiers exécutables, il permet d'allouer temporairement à un utilisateur les droits du propriétaire du fichier, durant son exécution.
En effet, lorsqu'un programme est exécuté par un utilisateur, les tâches qu'il accomplira seront restreintes par ses propres droits, qui s'appliquent donc au programme.
Lorsque le droit SUID est appliqué à un exécutable et qu'un utilisateur quelconque l'exécute, le programme détiendra alors les droits du propriétaire du fichier durant son exécution.
Bien sûr, un utilisateur ne peut jouir du droit SUID que s'il détient par ailleurs les droits d'exécution du programme.
Ce droit est utilisé lorsqu'une tâche, bien que légitime pour un utilisateur classique, nécessite des droits supplémentaires (généralement ceux de root). Il est donc à utiliser avec précaution.
Pour des partitions supplémentaires, il faut activer le bit suid pour pouvoir l'utiliser en le spécifiant dans les options des partitions concernés dans le fichier fstab.
5.2 Droits SGID :
Ce droit fonctionne comme le droit SUID, mais appliqué aux groupes. Il donne à un utilisateur les droits du groupe auquel appartient le propriétaire de l'exécutable et non plus les droits du propriétaire.
VI. Conclusion
Le système de permission Unix est assez simple et équivoque. Mais en contrepartie, il est assez limité.
Il n'est possible, en effet, d'attribuer nativement des autorisation que pour 'utilisateur, groupe, tous les autres'.
Si l'on veut avoir une gestion plus fine et plus complexe, par exemple pour des serveurs de fichiers, il faudra utiliser des logiciels complémentaire qui prendront en charge les listes de contrôle d'accès.

Méthodologie