République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université d’Alger 1 Benyoucef Benkhedda
Faculté des Sciences
Département d’Informatique

Mémoire de Projet de fin d’études pour l’obtention du Diplôme de

Master en Informatique

Spécialité : Réseaux et Systèmes Embarqués (RSE)

Thème

Scalabilité des SIEM dans les Environnements

MultiCloud Computing

Présenté et soutenu le 22 Juin 2025 par :

Mr. Mohamed Rachid MAROUF
Mr. Anis TILMATINE

Encadré par :
Dr. Amine ABBAS – Université d’Alger 1 Benyoucef Benkhedda

Devant la commission d’examen formée de :

Dr. Chafika AOUDIA TATA – Université d’Alger 1 Benyoucef Benkhedda – Président
Dr. Mohamed Amine ADOUANE – Université d’Alger 1 Benyoucef Benkhedda – Examinateur

Année universitaire : 2024–2025

 Remerciements
Qu’il nous soit permis avant tout d’exprimer notre profonde gratitude à ALLAH, le
Tout-Puissant, pour nous avoir accordé la force et la patience nécessaires à la Réalisation
de ce Mémoire. C’est grâce à sa guidance et à Sa bienveillance que nous avons pu mener
à bien ce Travail.

Nous tenons également à exprimer notre gratitude à Dr. Amine ABBAS, notre
Encadrant, pour ses conseils avisés, sa patience et sa disponibilité tout au long de l’éla-
boration de ce Mémoire. Sa confiance en ce projet et ses encouragements constants mais
aussi ses remarques constructives et son expertise nous ont permis de mener à bien ce
travail et d’améliorer considérablement la qualité de notre Mémoire.

Nous remercions chaleureusement les membres du jury, Dr. Chafika AOUDIA

TATA, ainsi que Dr. Mohamed Amine ADOUANE, pour avoir Accepté de por-
ter leur regard critique sur ce Mémoire. Leur évaluation rigoureuse et constructive est
essentielle pour notre apprentissage et notre développement.

Nous tenons à adresser nos sincères remerciements à l’ensemble des enseignants du

Département d’Informatique de l’Université d’Alger 1 – Benyoucef Benkhadda pour leur
implication constante dans la formation des étudiants et leur contribution précieuse à
nos apprentissages. Leurs compétences pédagogiques et leur passion ont été une source
d’inspiration et de motivation tout au long de notre cursus.

Une pensée particulière est adressée aux étudiants que nous avons côtoyés quotidien-
nement durant nos années d’étude au Département qui nous ont apporté leur support
moral et intellectuel tout au long de notre Mémoire.

Nous tenons à remercier chaleureusement tous ceux qui ont contribué, d’une manière
ou d’une autre, à la réalisation de ce Mémoire. Plus particulièrement nos familles, votre
soutien et vos encouragements ont et d’une grande importance pour nous. Nous sommes
reconnaissants pour l’intérêt que vous avez porté à notre travail et pour les précieux
conseils que vous nous avez prodigués.

MAROUF Mohamed Rachid et TILMATINE Anis

 Dédicaces

A ma mère, Pour son amour inconditionnel, son soutien indéfectible et ses

encouragements constants tout au long de ce parcours.
A mon père, Pour sa sagesse, ses conseils avisés et sa présence rassurante qui ont été
essentiels dans la réalisation de ce travail.
A ma petite sœur, Pour son exemple, son inspiration et son soutien qui m’ont poussé à
donner le meilleur de moi-même.
A mon binôme, Pour son travail acharné, sa coopération et son soutien tout au long de
ce projet.
A mes amis et mes proches, Pour leur amitié sincère, leur soutien moral et leurs
encouragements constants.

MAROUF Mohamed Rachid

 Dédicaces

A ma mère, Pour son amour inconditionnel, son soutien indéfectible et ses

encouragements constants tout au long de ce parcours.
A mon père, Pour sa sagesse, ses conseils avisés et sa présence rassurante qui ont été
essentiels dans la réalisation de ce travail.
A mes petites fréres, Pour leur inspiration et leur soutien qui m’ont poussé à donner le
meilleur de moi mémé.
A mon binôme, Pour son travail acharné, sa coopération et son soutien tout au long de
ce projet.
A mes amis et mes proches, Pour leur amitié sincère, leur soutien moral et leurs
encouragements constants.

TILMATINE Anis
Résumé
La montée en puissance des environnements MultiCloud Computing permet aux en-
treprises de bénéficier de flexibilité, d’agilité et de performances accrues. Cependant, cette
complexité engendre de nouveaux défis en matière de sécurité des systèmes d’information.
Les solutions SIEM (Security Information and Event Management) doivent être capables
de s’adapter à ces environnements distribués tout en restant performantes et efficaces. Ce
projet de fin d’études a pour objectif d’étudier la scalabilité des SIEM dans les architec-
tures MultiCloud, en mettant en lumière les problématiques d’intégration, de gestion des
flux de données massifs, et de surveillance continue. Une implémentation pratique basée
sur Wazuh, une solution SIEM open-source, est proposée pour démontrer les mécanismes
d’adaptation et de montée en charge dans un contexte MultiCloud. Le projet vise à four-
nir des recommandations pour le déploiement optimal et sécurisé de SIEM évolutifs dans
des environnements hybrides et MultiCloud.

Mots clés : Scalabilité, Elasticité, SIEM, MultiCloud Computing, Cybersécurité

Abstract
The rise of MultiCloud Computing environments offers companies greater flexibility,
agility, and enhanced performance. However, this complexity also introduces new chal-
lenges in securing information systems. SIEM (Security Information and Event Manage-
ment) solutions must be able to adapt to these distributed environments while maintai-
ning high performance and efficiency. This final year project aims to explore the scalability
of SIEM in MultiCloud architectures, highlighting issues related to integration, massive
data flow management, and continuous monitoring. A practical implementation based on
Wazuh, an open-source SIEM solution, is proposed to demonstrate the adaptation and
scalability mechanisms in a MultiCloud context. The goal is to provide recommendations
for the optimal and secure deployment of scalable SIEM systems in hybrid and multi-cloud
environments.

Keywords : Scalability, Elasticity, SIEM, MultiCloud Computing, Cybersecurity

 ‫ﻝ‬ ‫ﺓ‬ ‫ﺕ‬ ‫ﺡ‬ ‫ﺍ‬ ‫ﺕ‪ ،‬ـ‬ ‫ً‬ ‫ﻭ ﻭﺃﺩﺍﺀ ً‬ ‫ﺩﺓ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ُ‬

‫ﺕﺍ ﺯ‬ ‫ﻩﺍ‬ ‫ﻥ ﺃﻥ‬ ‫ﺍﺙ ﺍ‬ ‫ﺕ ﻭﺃ‬ ‫ﻝ ﺇﺩﺍﺭﺓ‬ ‫‪،‬‬ ‫ﺍﺍ‬ ‫ﺕ‪.‬‬ ‫ﺍ‬ ‫ﺃ‬

‫ﻥ‬ ‫ﺍﺙ ﺍ‬ ‫ﺕ ﻭﺃ‬ ‫ﻝ ﺇﺩﺍﺭﺓ‬ ‫ﺍ‬ ‫ﻭﻉ ﺇ ﺩﺭﺍ‬ ‫ﺍﺍ‬ ‫ﻑ‬ ‫‪.‬‬ ‫ﺀﺓ ﻭﺍ ﺩﺍﺀ ﺍ‬ ‫ﺍـ‬ ‫ﻅ‬ ‫ﺍ‬

‫ﺓ‪.‬‬ ‫ﺍ‬ ‫‪ ،‬ﻭﺍ ﺍ‬ ‫ﺕﺍ‬ ‫ﺍ‬ ‫‪ ،‬ﺇﺩﺍﺭﺓ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﺩﺓ‪،‬‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﺍ‬

‫ﺽ‬ ‫ﻑ‬ ‫ﺭ‪،‬‬ ‫ﺡﺍ‬ ‫ﻥ‬ ‫ﺍﺙ ﺍ‬ ‫ﺕ ﻭﺃ‬ ‫ﺇﺩﺍﺭﺓ‬ ‫ﺍﻡ ﻭﺍﺯﻭ‪ ،‬ﻭ‬ ‫ً‬ ‫ً‬ ‫ﻭﻉ‬ ‫ﺍ‬

‫ﺕ‬ ‫ﻭﻉ ﺃ ً ﺇ‬ ‫ﻑﺍ‬ ‫ﺩﺓ‪ .‬ﻭ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﻕ‬ ‫ﻭﺍ‬ ‫ﺍ‬

‫‪.‬‬ ‫ﺩﺓ ﻭﺍ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﺕﺍ‬ ‫ﺍ‬ ‫ﻭ‬ ‫ﺁ‬ ‫ﻥ‬ ‫ﺍﺙ ﺍ‬ ‫ﺕ ﻭﺃ‬ ‫ﻝ ﺇﺩﺍﺭﺓ‬

‫ﺩﺓ‪ ،‬ﺍ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﻥ‪ ،‬ﺍ‬ ‫ﺍﺙ ﺍ‬ ‫ﺕ ﻭﺃ‬ ‫‪ ،‬ﺍ ﻭ ‪ ،‬ﺇﺩﺍﺭﺓ‬ ‫ﺍ‬ ‫‪:‬‬ ‫ﺕﺍ‬ ‫ﺍ‬

‫ﺍ ‪.‬‬ ‫ﺍ‬
Table des matières

Table des matières 10

Table des figures 11

Liste des tableaux 14

Liste des abréviations 16

Introduction Générale 17

1 Contexte Générale, Problématique et Objectifs 19

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.2 Fonctionnalités d’un SIEM . . . . . . . . . . . . . . . . . . . . . . 21
1.2.3 Modes de Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.4 Architecture des SIEM . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.5 Avantages des SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Les Caractéristiques du Cloud Computing . . . . . . . . . . . . . . 25
1.3.3 Les Modèles de Services . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.4 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.5 Avantages du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4 La Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.4.2 Les objectifs de la virtualisation . . . . . . . . . . . . . . . . . . . . 31
 1.4.3 Les hyperviseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4.4 Techniques de virtualisation . . . . . . . . . . . . . . . . . . . . . . 33
1.4.5 Types de Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.6 Avantages de la virtualisation . . . . . . . . . . . . . . . . . . . . . 35
1.5 SIEM dans les Environnements Cloud . . . . . . . . . . . . . . . . . . . . . 35
1.5.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.5.2 Fonctionnalités Principales des SIEM Cloud . . . . . . . . . . . . . 35
1.5.3 Avantages des SIEM Cloud . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.4 Défis des SIEM Cloud . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.6 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.7 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2 Etat de l’Art 39
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2 Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.2 Avantages de Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.3 Types de Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . 41
[Link] Scalabilité Verticale . . . . . . . . . . . . . . . . . . . . . 41
[Link] Scalabilité horizontale . . . . . . . . . . . . . . . . . . . . 41
2.3 Elasticité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.2 La Différence entre Scalabilité et Elasticité . . . . . . . . . . . . . . 42
2.3.3 États du système selon l’élasticité . . . . . . . . . . . . . . . . . . . 43
2.3.4 Classements de l’élasticité . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.5 Métriques et évaluation . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4 L’équilibrage de charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4.2 Approches d’équilibrage de charge . . . . . . . . . . . . . . . . . . . 48
2.4.3 Classements d’équilibrage de charge . . . . . . . . . . . . . . . . . . 49
2.4.4 Métriques et évaluation . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4.5 Algorithmes d’équilibrage de charges . . . . . . . . . . . . . . . . . 50
 2.4.6 Objectifs de l’équilibrage de charge . . . . . . . . . . . . . . . . . . 52
2.5 Les Chalenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6 Vecteurs de Menaces et Techniques d’Attaque . . . . . . . . . . . . . . . . 53
2.6.1 Mitre ATT&CK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.6.2 DDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.6.3 Network Flood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.6.4 Kill Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3 Étude de cas et solution proposée 59

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2 Description de l’Architecture Choisie . . . . . . . . . . . . . . . . . . . . . 60
3.2.1 Composants principaux . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.2 Séparation et routage . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.3 Architecture proposée . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3 Conception du Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.1 Conteneurisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.2 Containerd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3.3 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
[Link] Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
[Link] Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 66
[Link] Composants . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3.4 Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
[Link] Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
[Link] Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 72
[Link] Composants . . . . . . . . . . . . . . . . . . . . . . . . . . 72
[Link] Clustering et haute disponibilité . . . . . . . . . . . . . . 73
[Link] Réponse active et automatisation . . . . . . . . . . . . . . 74
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4 Simulations et Résultats 76
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Présentation d’Environnement de la Simulation . . . . . . . . . . . . . . . 77
 4.2.1 Infrastructure MultiCloud simulée . . . . . . . . . . . . . . . . . . . 77
4.2.2 Composants déployés . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2.3 Matériel Utiliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Scénario 01 : Implémentation sans Scalabilité . . . . . . . . . . . . . . . . . 81
4.3.1 Configuration initiale des services . . . . . . . . . . . . . . . . . . . 81
4.3.2 Execution et déroulement . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.3 Résultats de performances . . . . . . . . . . . . . . . . . . . . . . . 85
4.4 Scénario 02 : Implémentation avec Scalabilité . . . . . . . . . . . . . . . . 88
4.4.1 Configuration de l’autoscaling . . . . . . . . . . . . . . . . . . . . . 88
4.4.2 Execution et déroulement . . . . . . . . . . . . . . . . . . . . . . . 91
4.4.3 Résultats de performances avec scaling . . . . . . . . . . . . . . . . 91
4.5 Discussion et Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.5.1 Comparaison des deux scénarios . . . . . . . . . . . . . . . . . . . . 99
4.5.2 Limites de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Conclusion Générale 101

Bibliographie 109

A 110
A.1 Déploiement Multi-site pour la simulation de 2 éme Scénario . . . . . . . . 110
A.1.1 Déploiement site b . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.1.2 Déploiement site d « site c » . . . . . . . . . . . . . . . . . . . . . . 110
A.2 Collecteur de Métriques Wazuh . . . . . . . . . . . . . . . . . . . . . . . . 111
A.3 Etat des Pods dans le Déploiement Multi site . . . . . . . . . . . . . . . . 112
Table des figures

1.1 Schéma de fonctionnement théorique d’un SIEM . . . . . . . . . . . . . . . 22

1.2 Exemple Architecture SIEM . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4 Modèles de Services Cloud Computing . . . . . . . . . . . . . . . . . . . . 28
1.5 Cloud Privé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.6 Cloud Publique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.7 Cloud Hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.8 MultiCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.9 Hyperviseur de type 1 (natif) . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.10 Hyperviseur de type 2 (logiciel) . . . . . . . . . . . . . . . . . . . . . . . . 33
1.11 La Paravirtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.12 La Virtualisation complète . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.1 Scalabilité verticale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.2 Scalabilité horizontale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3 Comparaison entre les ressources demandées et les ressources fournies . . . 44
2.4 Classification des mécanismes d’élasticité . . . . . . . . . . . . . . . . . . . 46
2.5 Fonctionnement de l’équilibrage de charge (Load Balancing) . . . . . . . . 48
2.6 L’équilibrage de Charge Matériel et Logiciel . . . . . . . . . . . . . . . . . 49
2.7 Fonctionnement de l’algorithme Round Robin . . . . . . . . . . . . . . . . 51
2.8 Fonctionnement de l’algorithme Least Connection . . . . . . . . . . . . . . 51
2.9 Exemeple Attaque DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.10 Étapes de la Cyber Kill Chain Attaque . . . . . . . . . . . . . . . . . . . . 57

3.1 Architecture "Service Provider" FortiSIEM . . . . . . . . . . . . . . . . . . 60

3.2 Architecture MultiCloud (solution proposée) . . . . . . . . . . . . . . . . . 62
3.3 Architecture d’un conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4 Logo Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5 Architecture d’un cluster Kubernetes . . . . . . . . . . . . . . . . . . . . . 66
3.6 Les différents controleurs de Kubernetes . . . . . . . . . . . . . . . . . . . 67
3.7 Fonctionnement d’un Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.8 Les différents Services de Kubernetes . . . . . . . . . . . . . . . . . . . . . 69
3.9 Intégration de HPA dans Kubernetes . . . . . . . . . . . . . . . . . . . . . 70
3.10 Exemple de KEDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.11 Architecture Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.12 Configuration HA Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.1 Infrastructure MultiCloud simulée . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 Composants déployés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Déploiement site a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4 Déploiement Wazuh Dashboard . . . . . . . . . . . . . . . . . . . . . . . . 82
4.5 Déploiement Agent Wazuh . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.6 Déploiement Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.7 Fonction d’envoie des logs . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.8 Types de Logs envoyé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.9 Etat de Système "Arrivé 2000 EPS" . . . . . . . . . . . . . . . . . . . . . . 85
4.10 Résultats Graphe Etat de Système "Arrivé 2000 EPS" . . . . . . . . . . . 86
4.11 Etat de Système "Arrivé 3000 EPS" . . . . . . . . . . . . . . . . . . . . . . 87
4.12 Résultats Graphe Etat de Système "Arrivé 3000 EPS" . . . . . . . . . . . 88
4.13 Déploiement Multi-site (Exemple Site-a) . . . . . . . . . . . . . . . . . . . 89
4.14 Déploiement Avec HPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.15 Déploiement Avec KEDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.16 HPA, Etat de Système "Arrivé 2000 EPS" . . . . . . . . . . . . . . . . . . 91
4.17 Résultats HPA Graphe Etat de Système "Arrivé 2000 EPS" . . . . . . . . 92
4.18 HPA, Etat de Système "Arrivé 3000 EPS" . . . . . . . . . . . . . . . . . . 92
4.19 Résultats HPA Graphe Etat de Système "Arrivé 3000 EPS" . . . . . . . . 93
4.20 KEDA, Etat de Système "Arrivé 2000 EPS" . . . . . . . . . . . . . . . . . 94
4.21 Résultats KEDA Graphe Etat de Système "Arrivé 2000 EPS" . . . . . . . 94
4.22 KEDA, Etat de Système "Arrivé 3000 EPS" . . . . . . . . . . . . . . . . . 95
4.23 Résultats KEDA Graphe Etat de Système "Arrivé 3000 EPS" . . . . . . . 96

A.1 Déploiement Multi-site (Exemple Site-b) . . . . . . . . . . . . . . . . . . . 110

A.2 Déploiement Multi-site (Exemple Site-d « site c ») . . . . . . . . . . . . . . 110
A.3 Script collecteur de Métriques Wazuh . . . . . . . . . . . . . . . . . . . . . 111
A.4 Etat des Pods dans le Déploiement Multi site . . . . . . . . . . . . . . . . 112
Liste des tableaux

1.1 Différences entre SIM, SEM et SIEM . . . . . . . . . . . . . . . . . . . . . 21

2.1 La Différence entre Scalabilité et Elasticité . . . . . . . . . . . . . . . . . . 43

4.1 Résultats "Scenario 1" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.2 Résultats "Scenario 2 : HPA" . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 Résultats "Scénario 2 : KEDA" . . . . . . . . . . . . . . . . . . . . . . . . 98
Liste des abréviations

SIEM Security Information and Event Management

SIM Security Information Management
SEM Security Event Management
DNS Domain Name System
CPU Central Processing Unit
RAM Random Access Memory
AWS Amazon Web Services
VPN Virtual Private Network
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
URL Uniform Resource Locator
SSL Secure Sockets Layer
SSH Secure Shell
TLS Transport Layer Security
NIST National Institute of Standards and Technology
IaaS Infrastructure as a Service
PaaS Platform as a Service
SaaS Software as a Service
XaaS Anything as a Service
NaaS Network as a Service
DRaaS Disaster Recovery as a Service
SLA Service Level Agreement
IDS Intrusion Detection System
IPS Intrusion Prevention System
PCI DSS Payment Card Industry Data Security Standard
SOAR Security Orchestration, Automation and Response
EDR Endpoint Detection and Response
QoS Quality of Service
QoE Quality of Experience
API Application Programming Interface
API REST Application Programming Interface Representational State Transfer
AWS EC2 Amazon Web Services Elastic Compute Cloud
CA Certificate Authority
VM Virtual Machine
HPA Horizontal Pod Autoscaler
KEDA Kubernetes Event Driven Autoscaling
GDPR Règlement Général sur la Protection des Données
DoS Denial of Service
DDoS Distributed Denial of Service
ICMP Internet Control Message Protocol
ARP Address Resolution Protocol
VDOM Virtual Domain
CRI Container Runtime Interface
CNCF Cloud Native Computing Foundation
OCI Open Container Initiative
 Introduction Générale

Introduction Générale

À l’ère de la digitalisation et du Cloud, la sécurité des infrastructures informatiques

est devenue une priorité majeure pour les organisations. Les solutions SIEM, notamment
open-source comme Wazuh, jouent un rôle central en assurant la collecte et l’analyse des
événements de sécurité. Cependant, l’évolution vers des environnements MultiCloud pose
des défis importants en termes de scalabilité, performance et résilience face aux attaques
complexes telles que les DDoS et les chaînes de Kill Chain.
Ce mémoire part de l’hypothèse que l’intégration de mécanismes d’autoscaling et de
clustering Kubernetes peut améliorer significativement la gestion des événements de sé-
curité, en garantissant la disponibilité et la fiabilité du SIEM dans des environnements
dynamiques. Pour cela, nous proposons une architecture élastique et résiliente, validée
par une démarche en cinq étapes : revue bibliographique, conception, implémentation en
MultiCloud, simulations d’attaques, et analyse des performances.
La structure du mémoire comprend quatre chapitres : contexte et objectifs, état de
l’art, étude de cas et architecture proposée, ainsi que résultats des simulations.
Le présent mémoire s’articule autour de quatre chapitres qui sont pésentés comme
suit :

— Le Chapitre 1,« Contexte Générale, Problématique et Objectifs », éta-

blit les bases théoriques du mémoire. Il présente les SIEM, puis examine le Cloud
Computing, Ensuite, il détaille les principes de virtualisation, Le chapitre se conclut
en abordant la problématique du MultiCloud, en mettant en lumière les défis de
scalabilité, performance et couverture fonctionnelle.

— Le Chapitre 2, « État de l’Art », examine les principaux mécanismes de montée

en charge et de résilience dans les environnements Cloud. Il définit la scalabilité,
puis compare la scalabilité à l’élasticité en contexte Cloud, en analysant les états
du système et les méthodes d’évaluation, Ensuite L’équilibrage de charge, avant

17
 Introduction Générale

de conclure par une analyse des principales menaces, notamment Attaques DDoS,
Network Flood et Kill Chain.

— Le Chapitre 3, « Étude de Cas et Solution Proposée », présente la concep-

tion et l’architecture choisies pour le SIEM MultiCloud. Il décrit l’environnement
simulé, ses sites et composants clés, puis détaille la conteneurisation avec contai-
nerd et l’orchestration via Kubernetes, en insistant sur les mécanismes d’autosca-
ling. L’intégration de Wazuh est également abordée, notamment son architecture
interne, son clustering pour garantir la haute disponibilité, ainsi que les workflows
d’automatisation des réponses. Le chapitre se termine par une explication des flux
de données et du routage entre les différents composants.

— Le Chapitre 4, « Simulations et Résultats », détaille la mise en œuvre des

scénarios de test. Le premier scénario, sans autoscaling, illustre la génération de tra-
fic et la collecte des métriques. Le second scénario active les ressources dynamiques
via Kubernetes, permettant de comparer les performances obtenues et d’analyser
l’impact de l’autoscaling. La discussion finale porte sur la comparaison des deux
approches, les limites techniques rencontrées et les enseignements tirés.

18
Chapitre 1

Contexte Générale, Problématique et

Objectifs
Chapitre 1 Contexte Générale, Problématique et Objectifs

1.1 Introduction
Ce premier chapitre présente le contexte des systèmes SIEM dans les environnements
cloud, avec un focus sur les défis propres aux architectures MultiCloud. Il retrace l’évo-
lution des SIEM, souligne leur rôle central en matière de sécurité, et examine les risques,
menaces et implications économiques liés à leur gestion dans le cloud. Enfin, la probléma-
tique et les objectifs du mémoire sont introduits, mettant en avant la nécessité de solutions
scalables, sécurisées et économiquement optimisées.

1.2 SIEM

1.2.1 Définition

Un SIEM (Security Information and Event Management) est une solution de sécurité
informatique qui permet de centraliser, collecter, corréler et analyser en temps réel des
données et des logs provenant de diverses sources (systèmes, applications, réseaux, etc.).
Son objectif principal est de détecter rapidement des activités suspectes ou anormales au
sein d’un environnement informatique, de générer des alertes en cas d’incident et d’aider
à la gestion de la sécurité ainsi qu’à la conformité réglementaire. [6] [7]
Le SIEM est composé de deux concepts qui sont : SEM et le SIM.

— SIM : Fournit la gestion des journaux, la collecte, la création des rapports et ana-
lyse les données des systèmes hôtes et des applications, des périphériques réseau et
de sécurité. Il prend en charge les rapports de conformité réglementaire, la gestion
interne des menaces et surveillance de l’accès aux ressources. SIM s’occupe l’utili-
sateur privilégié et les activités de surveillance de l’accès aux ressources, ainsi que
les besoins des rapports de l’audit interne et les organismes de conformité.

— SEM : Traite les données des journaux et des événements des dispositifs de sécurité,
systèmes et applications en temps réel pour assurer la sécurité la surveillance, la
corrélation des événements et les réponses aux incidents. SIEM soutient les activités
de surveillance des menaces externes et internes de l’organisation de la sécurité
informatique et améliore la gestion des incidents.

20
Chapitre 1 Contexte Générale, Problématique et Objectifs

SIM SEM SIEM

Définition Collecte et Analyse Analyse de SIEM Combine les
de Données liées à Menaces en Temp Capacités de SIM
la sécurité à partir Réel, visualisation et SEM
de journaux et réponse aux
Informatique incidents
Caractéristiques Facile à déployer, Plus complexe à Plus complexe à
puissantes déployer, supérieur déployer,
capacités de dans la surveillance fonctionnalité
gestion des en temps réel complète
journaux
Exemples AlienVault OSSIM NetIQ Sentinel Elastic Stack

Table 1.1 – Différences entre SIM, SEM et SIEM

1.2.2 Fonctionnalités d’un SIEM

— L’Agrégation : L’agrégation des logs est le processus de regrouper plusieurs logs

dans le même log selon des critères bien définis. Elle s’applique sur les logs du
même type et elle facilite les vues du SIEM. L’agrégation a plusieurs avantages
comme la réduction du nombre des logs dans le SIEM, l’accélération des opérations
de recherche et la facilitation des tâches de surveillance. Cependant, la mauvaise
implémentation des règles d’agrégation peut conduire à la perte des informations
importantes. Cela facilite notamment le traitement de l’étape de corrélation, qui
gère alors plus des évènements individuels mais des groupes d’évènements. [8]

— Corrélation : La corrélation correspond à l’analyse d’évènements selon certains

critères. Ces critères sont généralement définis par des règles appelées règles de cor-
rélation. Le but de cette étape est d’établir des relations entre évènements, pour
ensuite pouvoir créer des alertes de corrélations, des incidents de sécurités, des rap-
ports d’activité. [8]. La corrélation se différencie sur plusieurs points :

- Auto-apprentissage et connaissances rapportées : Pour pouvoir fonc-

tionner, les moteurs de corrélation ont besoin d’informations sur les systèmes
et réseaux de l’infrastructure. Ces informations peuvent être collectées auto-
matiquement et/ou saisies manuellement par un opérateur.

21
Chapitre 1 Contexte Générale, Problématique et Objectifs

- Temps réel et données retardées : Dans certains cas, les événements bruts
sont forgés et envoyés directement pour être corrélés en temps réel. Dans
d’autres cas, les événements sont d’abord stockés, et envoyés après un premier
traitement. Leur envoi peut être alors conditionné.
- Corrélation active et passive : La corrélation active a la possibilité de
compléter les évènements reçus en recueillant des informations supplémentaires
pour prendre des décisions. La corrélation passive est une corrélation qui ne
peut pas interagir avec son environnement. Elle reçoit des évènements et prend
des décisions.
— Les Rapports : Les rapports générés contiennent à la fois un résumé des alertes
et un aperçu de la sécurité du système à instant T. SIEM peut également créer et
générer des tableaux de bord et des rapports. Ainsi, différents acteurs administra-
teurs, utilisateurs peuvent connaître le SI (nombre d’attaques, nombre d’alertes par
jour, etc.). [8]

— Tableaux de bord : Les outils SIEM prennent les données des événements et les
transforment en d’événements et les transforment en graphiques informatifs pour
aider à voir les l’activité qui ne forme pas un modèle standard. [8]

— Alertes : Le SIEM fournit l’analyse automatisée des événements corrélés et la

production d’alertes, afin de notifier les destinataires de problèmes immédiats. Le
schéma ci-dessous (figure) représente les fonctionnements d’un SIEM. [8]

Le schéma suivant illustre le fonctionnement général d’un SIEM :

Figure 1.1 – Schéma de fonctionnement théorique d’un SIEM [8]

22
Chapitre 1 Contexte Générale, Problématique et Objectifs

1.2.3 Modes de Fonctionnement

Les équipements et logiciels de sécurité sont nombreux dans un système d’information,

ils gèrent généralement de façon indépendante des informations de sécurité dites locales.
Le principe de l’étape de collecte est de fournir au SIEM des données à traiter. Ces données
peuvent être de nature diverse en fonction de l’équipement ou du logiciel, mais aussi être
envoyées de manières tout à fait différentes. On distingue deux modes de fonctionnement.

— Mode Actif : Le SIEM possède un ou plusieurs agents déployés sur les équipements
à superviser. Ces agents ont pour fonction de récupérer les informations des équi-
pements et logiciels de sécurité et de les envoyer au SIEM. Un élément de sécurité
qui a été conçu nativement pour être un agent du SIEM est appelé une sonde. [8]

— Mode Passif : Le SIEM est en écoute directe sur les équipements à superviser.
Pour cette Méthode, c’est l’équipement ou le logiciel qui envoie des informations
sans intermédiaire au SIEM. [8]

1.2.4 Architecture des SIEM

— Collecteurs et Agents : Ils récupèrent les logs et événements sur les systèmes
cibles. Ces agents peuvent être déployés sur les serveurs, les postes de travail ou les
dispositifs réseau.

— Serveur de Corrélation : Le cœur du SIEM, où sont appliquées des règles de cor-

rélation pour analyser les flux de données et détecter des anomalies ou des schémas
suspects.

— Base de Données et Stockage : Un système de stockage permettant l’archivage

des logs pour les analyses futures et la génération de rapports.

— Interface Utilisateur et Tableau de Bord : Des interfaces graphiques offrant

une vue centralisée et interactive des événements de sécurité, facilitant la surveillance
et la gestion des incidents.

— Moteurs d’Analyse et d’Automatisation : Intégrant parfois des solutions d’in-

telligence artificielle et de machine Learning pour améliorer la détection des menaces
et réduire les faux positifs.

23
Chapitre 1 Contexte Générale, Problématique et Objectifs

Figure 1.2 – Exemple Architecture SIEM

1.2.5 Avantages des SIEM

Les outils SIEM offrent de nombreux avantages qui peuvent contribuer à renforcer
l’état de la sécurité globale d’une organisation [7], notamment :

— Amélioration des capacités de détection des menaces : La capacité du SIEM

à détecter les menaces en temps réel vous aide à rester un pas devant les attaquants,
réduisant la probabilité d’une violation réussie.

— Amélioration des temps de réponse aux incidents : Lorsque qu’un incident

se produit, chaque seconde compte. Le SIEM rationalise le processus d’enquête et
de réponse, minimisant les temps d’arrêt et les dégâts.

— Assistance à la conformité et réglementaire : Répondre à des exigences ré-

glementaires telles que le RGPD, HIPAA ou PCI DSS peut être intimidant, mais le
SIEM simplifie le processus grâce à des rapports de conformité intégrés.

— Gains d’efficacité opérationnelle : En automatisant les tâches répétitives et en

centralisant les données, le SIEM libère votre équipe pour se concentrer sur des
activités à forte valeur ajoutée.

24
Chapitre 1 Contexte Générale, Problématique et Objectifs

1.3 Cloud Computing

1.3.1 Définition

Le Cloud Computing est un concept qui consiste à déporter sur des serveurs distants
des stockages et des traitements informatiques traditionnellement localisés sur des serveurs
locaux ou sur le poste de l’utilisateur. Il consiste à proposer des services informatiques
sous forme de service à la demande, accessible de n’importe où, n’importe quand et par
n’importe qui. [2] [5]

Figure 1.3 – Cloud Computing [10]

1.3.2 Les Caractéristiques du Cloud Computing

— Libre-service à la demande : La notion de libre-service à la demande est pri-

mordiale pour les utilisateurs du cloud. Le libre-service à la demande permet à
l’utilisateur d’être en mesure d’allouer, mais également de libérer des ressources
distantes en temps réel en fonction des besoins, et sans nécessiter d’intervention
humaine. [3] [4]

— Un accès large : L’ensemble des ressources doit être accessible et à disposition de

l’utilisateur universellement et simplement à travers le réseau, quels que soient les
clients utilisés (serveur, PC, client mobile, etc.). Ceci implique trois prédispositions :

- Accès utilisateur : Afin de garantir que l’accès à une solution de cloud soit
perçu comme stable et fiable, il est nécessaire que celle-ci dispose d’un accès
haut débit.

25
Chapitre 1 Contexte Générale, Problématique et Objectifs

- Accès applicatif : En vue de s’assurer que la solution soit en mesure de

mettre à disposition de l’utilisateur les autres fonctionnalités du cloud, l’accès
au réseau doit être disponible au sein même de la solution.
- Accès opérateur : Dans le but de pouvoir maintenir et administrer un sys-
tème cloud correctement, le fournisseur de service cloud doit pouvoir accéder à
celui-ci via le réseau. Ainsi, s’assurer qu’un accès total au réseau est disponible
dans tous les aspects d’une solution de cloud est essentiel pour offrir l’ensemble
des autres caractéristiques.

— Mutualisation des ressources : De multiples ressources matérielles sont regrou-

pées et partagée de là par du fournisseur entre les différents utilisateurs du service.
Ce partage rend l’emplacement exact des données des utilisateurs impossible à dé-
terminer, ce qui peut poser un véritable problème aux entreprises qui sont soumises
à de nombreuses contraintes réglementaires concernant la localisation et le contrôle
des données. En contrepartie, les économies d’échelle réalisées permettent de réduire
les coûts du fournisseur et donc les dépenses des utilisateurs. [3] [4]

— Adaptabilité rapide : L’une des caractéristiques du cloud computing est l’élasti-

cité des ressources. Cette caractéristique permet aux utilisateurs d’allouer rapide-
ment de nouvelles ressources de manière à être en mesure de répondre à une montée
ou à une descente en charge soudaine. Il n’est jamais évident de prévoir les ressources
qui seront nécessaires à la mise en place d’un service informatique quelconque, en
particulier lorsque ce besoin est en constante évolution. Le cloud computing offre
ainsi un moyen de fournir les ressources informatiques nécessaires à une évolution
ou à un pic d’utilisation de ce service. [3] [4]

— Paiement à l’usage : Les systèmes cloud doivent être capables de s’autocontrô-

ler et de se gérer pour permettre l’optimisation interne du système. Pour cela, ils
s’appuient sur des mesures de référence obtenues grâce à divers mécanismes de su-
pervision. Ces mesures précises permettent une juste facturation des utilisateurs ;
ceux-ci ne payeront ainsi que pour les ressources qu’ils ont utilisées et seulement
pour la durée qu’ils les ont utilisées. [3]

26
Chapitre 1 Contexte Générale, Problématique et Objectifs

1.3.3 Les Modèles de Services

— Infrastructure as a Service (IaaS) : Fournit des composants d’infrastructure

aux clients. Les composants peuvent inclure des machines virtuelles, du stockage,
des réseaux, des pares-feux, des équilibreurs de charge, etc. Avec IaaS, les clients
ont un accès direct au matériel de niveau le plus bas de la pile. [9]

— Platform as a Service (PaaS) : Fournit une plate-forme d’applications prédéfinie

au client ; les clients n’ont pas besoin de passer du temps à créer une infrastructure
sous-jacente pour leurs applications. Sur le backend, PaaS s’adapte et provisionne
automatiquement les composants d’infrastructure requis en fonction sur les exi-
gences de l’application. En règle générale, les solutions PaaS fournissent une API
qui comprend un ensemble de fonctions pour la gestion de la plate-forme program-
matique et le développement de solutions. [9]

— Software as a Service (SaaS) : Fournit des solutions logicielles en ligne prêtes

à l’emploi. Le logiciel SaaS fournisseur a le contrôle complet du logiciel d’applica-
tion. Les exemples d’applications SaaS incluent le courrier en ligne. La principale
différence entre le SaaS et le PaaS est que le PaaS représente normalement une
plate-forme pour le développement d’applications, tandis que SaaS fournit des ap-
plications en ligne déjà développées. [9]

— Anything as a Service (XaaS) : Anything-as-a-service, ou XaaS, fait référence à

la diversité croissante des services disponibles sur Internet via le Cloud Computing
par opposition à être fournis localement ou sur site. Anything-as-a-Service dérive
le "X" dans son acronyme XaaS car il s’agit d’un terme du logiciel en tant que
service (SaaS) au stockage en tant que service, bureau en tant que service (DaaS),
récupération après sinistre en tant que service (DRaaS), réseau en tant que service
(NaaS), infrastructure en tant que service (IaaS) et plateforme en tant que service
(PaaS), et même des services émergents tels que le marketing en tant que service et
les soins de santé en tant que service. [9]

27
Chapitre 1 Contexte Générale, Problématique et Objectifs

Figure 1.4 – Modèles de Services Cloud Computing [70]

1.3.4 Modèles de déploiement

Après avoir sélectionné le ou les services de Cloud Computing que vous avez choisis,
vous pouvez choisir entre trois principaux modèles de déploiement de Cloud Computing,
le Cloud Privé, le Cloud Public, le Cloud Hybride et le MultiCloud. [10]

— Cloud Privé : Le Cloud privé est un ensemble des services et des ressources dis-
ponibles à un seul client par exemple une entreprise. Le Cloud privé peut être géré
par l’entreprise elle-même, ou bien avec ses succursales, dans ce cas il s’appelle "Le
Cloud privé Interne", comme il peut être géré par un prestataire externe qu’il est
loué par l’entreprise, dans ce cas s’appelle "Le Cloud privé Externe". Il est accessible
via des réseaux sécurisés de type VPN, par exemple Amazon Virtual Private Cloud
(Amazon VPC). [9] [10]

28
Chapitre 1 Contexte Générale, Problématique et Objectifs

Figure 1.5 – Cloud Privé [68]

— Cloud public : Le Cloud publique est un ensemble des services et des ressources
accessibles par Internet et gérées par un prestataire externe, ces ressources et services
sont partagés entre plusieurs clients, qu’ils les utilisent à la demande et à tout
moment sans savoir où elles existent, Ces services peuvent être gratuits ou payants.
Dans le cas où les services sont payants, il existe des contrats SLA entre les clients
et les fournisseurs. SLA est un document qui définit la qualité de service requise
entre les deux. [9] [10]

Figure 1.6 – Cloud Publique [68]

— Cloud Hybride : Le Cloud hybride est une composition de deux types de Cloud
(Privé et Public). Par exemple l’utilisation des applications dans un Cloud public
mais ces applications nécessitent des données stockées sur un Cloud privé. [10]

29
Chapitre 1 Contexte Générale, Problématique et Objectifs

Figure 1.7 – Cloud Hybride [69]

— MultiCloud : Le multicloud est une stratégie de cloud Computing qui combine les
meilleurs services de plusieurs fournisseurs de cloud pour créer une solution. Cette
stratégie se base sur le travail (workload), à l’entreprise et à la gouvernance des
données. Une solution multicloud qui comprend l’IaaS, le PaaS et le SaaS dans une
architecture étroite et faible. Une solution multicloud bien conçue doit considérer
le réseau, la performance, la sécurité, la gestion des opérations et le coût total. [12]
[13]

Figure 1.8 – MultiCloud [73]

1.3.5 Avantages du Cloud

Le Cloud Computing présente plusieurs avantages par rapport à l’informatique tra-

ditionnelle sur site, où une entreprise doit posséder et entretenir des centres de données
physiques et des serveurs pour accéder à la puissance de calcul, au stockage de données
et à d’autres ressources [10]. Parmi eux, mentionnons :

30
Chapitre 1 Contexte Générale, Problématique et Objectifs

— Accessibilité : Les applications et les données hébergées dans le cloud sont acces-
sibles depuis quasiment tout appareil connecté à Internet.

— Rapidité de mise sur le marché : Le développement dans le Cloud permet aux

utilisateurs de commercialiser rapidement leurs applications.

— Évolutivité : L’infrastructure Cloud est extensible à la demande afin de s’adapter

aux charges de travail changeantes.

— Options de stockage : Les utilisateurs ont la possibilité de sélectionner entre

des offres de stockage public, privé ou hybride, selon leurs exigences en matière de
sécurité et d’autres critères.

— Sécurité des données : Les pannes matérielles n’entraînent pas de perte de don-
nées grâce aux sauvegardes réseau.

1.4 La Virtualisation

1.4.1 Définition

La virtualisation est un processus qui va permettre de masquer les caractéristiques

physiques d’une ressource informatique de manière à simplifier les interactions entre cette
ressource et d’autres systèmes, d’autres applications et les utilisateurs. Elle va permettre
de percevoir une ressource physique comme plusieurs ressources logiques et, inversement,
de percevoir plusieurs ressources physiques comme une seule ressource logique. [14] [15]
La virtualisation repose sur trois éléments importants :

— L’abstraction des ressources informatiques.

— La répartition des ressources par l’intermédiaire de différents outils, de manière à

ce que celles-ci puissent être utilisées par plusieurs environnements virtuels.

— La création d’environnements virtuels.

1.4.2 Les objectifs de la virtualisation

— Rationaliser les évolutions en besoins matériels, en empilant plusieurs serveurs sur

une besoins matériels, en empilant plusieurs serveurs sur une.

— Réduction des coûts de l’infrastructure physique.

31
Chapitre 1 Contexte Générale, Problématique et Objectifs

— Augmentation de la flexibilité et de l’efficacité opérationnelle.

— Disponibilité accrue des applications et amélioration de la continuité d’activité.

— Amélioration de la gestion et de la sécurité des postes de travail.

1.4.3 Les hyperviseurs

Un hyperviseur, également appelé gestionnaire de machine virtuelle, est un permet à

plusieurs systèmes d’exploitation (Windows, Linux, etc..) de partager un seul hôte maté-
riel., On compte deux types d’hyperviseurs : Le type 1 dit natif et le type 2 dit logiciel.
[16] [20]

— Hyperviseur de type 1 (natif ) : Un hyperviseur de type 1 a comme particula-

rité de s’installer directement sur la couche matérielle (à comprendre qu’il est relié
directement au matériel de la machine hôte). Il est alors considéré comme outil de
contrôle du système d’exploitation, c’est à dire qu’il s’agit d’un noyau allégé et op-
timisé pour la virtualisation de machines. Au démarrage de la machine physique,
l’hyperviseur prend directement le contrôle du matériel, et alloue l’intégralité des
ressources aux machines hébergées. [16]

Figure 1.9 – Hyperviseur de type 1 (natif) [16]

— Hyperviseur de type 2 (logiciel) : Un hyperviseur de type 2 est considéré comme

un logiciel, s’installant et s’exécutant sur un système d’exploitation déjà présent sur
la machine physique. Le système d’exploitation virtualisé par un hyperviseur de type
2 s’exécutera dans un troisième niveau au-dessus du matériel, celui-ci étant émulé
par l’hyperviseur. [16]

32
Chapitre 1 Contexte Générale, Problématique et Objectifs

Figure 1.10 – Hyperviseur de type 2 (logiciel) [16]

1.4.4 Techniques de virtualisation

On distingue plusieurs techniques de virtualisation à savoir l’isolation, la paravirtuali-

sation et la virtualisation complète. Ces deux techniques sont détaillées dans ce qui suit :

— La paravirtualisation : La paravirtualisation est une technique de virtualisation

qui présente sur la machine invitée une interface logicielle similaire mais non iden-
tique au matériel réel. Ainsi, elle permet aux systèmes d’exploitation invités d’in-
teragir directement avec le système d’exploitation hôte et donc ils seront conscients
de la virtualisation. [17]

Figure 1.11 – La Paravirtualisation [17]

— La virtualisation complète : La virtualisation complète est une technique de

virtualisation qui permet de créer un environnement virtuel complet. En utilisant
cette technique, le système d’exploitation invité n’interagit pas directement avec le

33
Chapitre 1 Contexte Générale, Problématique et Objectifs

système d’exploitation hôte et donc il croit s’exécuter sur une véritable machine
physique. [17]

Figure 1.12 – La Virtualisation complète [17]

1.4.5 Types de Virtualisation

— Virtualisation du poste de travail : C’est la capacité de pouvoir utiliser le même

environnement de travail indépendamment du matériel utilisé (sur n’importe quel
poste du moment qu’il soit connecté à Internet ou au réseau local dans le cas d’un
Cloud privé). L’infrastructure du Bureau virtuel est une architecture centralisée de
fourniture de bureaux à distance qui permet de centraliser le stockage, l’exécution
et la gestion des bureaux dans le centre de calcul. [18] [19]

— Virtualisation d’Application : La virtualisation d’application est une techno-

logie logicielle qui va permettre d’améliorer la portabilité et la compatibilité des
applications en les isolant du système d’exploitation sur lequel elles sont exécutées.
Elle consiste à encapsuler l’application et son contexte d’exécution système dans un
environnement cloisonné. [19]

— Virtualisation de serveurs : La virtualisation de serveurs consiste à faire fonc-

tionner simultanément sur un seul serveur physique plusieurs serveurs virtuels. [19]

— Virtualisation de réseaux : La virtualisation du réseau consiste à combiner des

ressources réseau matérielles et logicielles dans une seule unité administrative. L’ob-
jectif de la virtualisation du réseau est de fournir aux systèmes et utilisateurs un
partage efficace, contrôlé et sécurisé des ressources réseau. [18] [19]

34
Chapitre 1 Contexte Générale, Problématique et Objectifs

— Virtualisation de stockage : La virtualisation des stockages permet d’exploiter

au maximum les ressources, d’exploiter au mieux le stockage des disques durs. [19]

1.4.6 Avantages de la virtualisation

— Rationalisation des coûts de matériels informatiques.

— Portabilité des serveurs : une machine virtuelle peut être déplacée d’un serveur
physique vers un autre (lorsque celle-ci a, par exemple, besoin de plus de ressources).

— Accélération des déploiements de systèmes et d’applications en entrepris.

— Administration simplifiée de l’ensemble des serveurs.

1.5 SIEM dans les Environnements Cloud

1.5.1 Définition

Un SIEM dans le cloud est une solution de gestion des informations et des événements
de sécurité qui fonctionne sur une infrastructure cloud. Il permet de collecter, stocker,
analyser et corréler les logs et événements de sécurité provenant de différentes sources
pour détecter les menaces et répondre aux incidents. [1]
Contrairement aux SIEM traditionnels installés sur site (on-site), un SIEM Cloud
bénéficie de la scalabilité, de l’accessibilité et de la flexibilité du cloud, permettant une
gestion centralisée et efficace des logs et événements de sécurité dans des environnements
hybrides et MultiCloud. [1]

1.5.2 Fonctionnalités Principales des SIEM Cloud

Un SIEM basé sur le cloud offre des fonctionnalités similaires aux solutions tradition-
nelles, avec des avantages liés au cloud :

— Collecte de logs : Agrégation de journaux de multiples sources (serveurs, appli-

cations, bases de données, pare-feu, IDS/IPS, Endpoint, etc.).

— Corrélation et analyse : Identification de modèles suspects et détection des me-

naces via des règles et de l’IA.

— Gestion des incidents : Génération d’alertes et automatisation des réponses aux

incidents de sécurité.

35
Chapitre 1 Contexte Générale, Problématique et Objectifs

— Conformité et Reporting : Aide à respecter les réglementations (ISO 27001,

GDPR, PCI-DSS, etc.).

— Intégration avec d’autres outils : Compatibilité avec SOAR, EDR, et d’autres

solutions de cybersécurité.

1.5.3 Avantages des SIEM Cloud

— Évolutivité : Capacité à s’adapter aux besoins en ressources (augmentation des

logs, nouvelles sources de données).

— Coût réduit : Pas de matériel physique à gérer, modèle de facturation basé sur
l’usage.

— Déploiement rapide : Configuration simplifiée et mise en œuvre plus rapide que

les SIEM ont-site.

— Accès centralisé : Surveillance et gestion des incidents accessibles depuis n’importe

où.

— Maintenance simplifiée : Mises à jour et maintenance assurées par le fournisseur

du service cloud.

1.5.4 Défis des SIEM Cloud

— Coût à long terme : Peut devenir plus coûteux en fonction du volume de logs
stockés et analysés.

— Dépendance au fournisseur : Nécessité de faire confiance à un fournisseur cloud

pour la sécurité et la disponibilité des données.

— Latence potentielle : Traitement des logs et détection des menaces dépendants

de la connectivité réseau.

— Conformité et confidentialité : Stockage des données sensibles dans le cloud

nécessitant des mesures de protection avancées.

36
Chapitre 1 Contexte Générale, Problématique et Objectifs

1.6 Problématique
La surveillance des infrastructures cloud, notamment dans les environnements Mul-
tiCloud, pose des défis importants liés à la complexité du trafic réseau et à l’ampleur
des ressources nécessaires. L’adaptation des SIEM à ces contextes exige une scalabilité
accrue, mais une simple augmentation des capacités peut engendrer des coûts élevés et
une consommation énergétique accrue, affectant tant les fournisseurs que les clients. Ce
mémoire cherche donc à identifier les risques, les exigences spécifiques et les solutions tech-
nologiques permettant de concevoir un système SIEM à la fois scalable, optimisé, sécurisé
et rentable pour les environnements MultiCloud.

1.7 Objectifs
L’objectif principal de ce mémoire est de proposer une solution complète et innovante
pour la gestion et la surveillance des systèmes de gestion des événements et des informa-
tions de sécurité (SIEM) dans les environnements MultiCloud. Pour atteindre cet objectif
général, plusieurs objectifs spécifiques ont été définis :

A- Identifier les exigences spécifiques des environnements MultiCloud :

— Étudier les variations et les pics de charge.

— Évaluer les besoins en termes de scalabilité et d’élasticité pour répondre aux
exigences de sécurité.

B- Concevoir un système de surveillance SIEM optimisé pour les environ-

nements MultiCloud :

— Intégrer les avancées technologiques en matière de scalabilité et d’optimisation.

— Mettre en place une surveillance proactive pour anticiper les besoins en res-
sources.

C- Garantir la sécurité, la fiabilité, la robustesse et l’efficacité opérationnelle

du système :

— Réduire les coûts supplémentaires liés à la scalabilité tout en maintenant une

sécurité robuste.
— Assurer une utilisation optimale des ressources pour minimiser l’impact écono-
mique et environnemental.

37
Chapitre 1 Contexte Générale, Problématique et Objectifs

En atteignant ces objectifs, ce mémoire vise à fournir une solution qui non seulement
répond aux défis actuels de la surveillance des SIEM dans les environnements MultiCloud,
mais qui contribue également à renforcer la sécurité et la compétitivité des services cloud.

1.8 Conclusion
Cette étude a permis de mieux comprendre les défis de scalabilité des SIEM dans les
environnements MultiCloud, soulignant la nécessité de solutions adaptatives et rentables.
Les travaux futurs porteront sur l’intégration de technologies avancées et d’algorithmes
prédictifs pour concevoir des SIEM performants, sécurisés et économiquement viables.

38
Chapitre 2

Etat de l’Art
Chapitre 2 Etat de l’Art

2.1 Introduction
Ce chapitre présente les bases théoriques de la scalabilité, de l’élasticité et de l’équili-
brage de charge dans les systèmes distribués, notamment en environnement cloud. Il exa-
mine les stratégies d’adaptation des ressources, les performances des algorithmes d’équi-
librage de charge et les vulnérabilités liées à la sécurité, afin de mieux comprendre les
interactions entre gestion des ressources et protection des infrastructures.

2.2 Scalabilité

2.2.1 Définition

La scalabilité désigne la capacité d’un système à s’adapter à une augmentation ou une

diminution de la charge de travail en ajustant les ressources informatiques de manière
efficace et efficiente. Elle est essentielle pour maintenir les performances et la disponibilité
des services face à des variations de la demande. [21] [23]

2.2.2 Avantages de Scalabilité

— Meilleure performance : L’évolutivité peut permettre d’améliorer les perfor-

mances globales d’un système en répartissant la charge de travail sur plusieurs
ressources. Cela peut entraîner des temps de réponse plus rapides, une capacité
de traitement accrue et une meilleure disponibilité du service. En adaptant les res-
sources en fonction des besoins, la scalabilité peut aider à maintenir des perfor-
mances optimales même en cas de demandes fluctuantes. [23]

— Agilité et flexibilité : La scalabilité offre une plus grande flexibilité et agilité

pour faire face aux changements rapides de l’environnement commercial. Elle permet
d’ajouter ou de supprimer rapidement des ressources en fonction des besoins, ce qui
facilite l’expansion, la contraction ou l’adaptation aux conditions changeantes du
marché. Cela permet aux entreprises de réagir plus rapidement aux opportunités
ou aux défis, de lancer de nouveaux produits ou services plus rapidement et de
s’adapter aux demandes des clients. [23]

40
Chapitre 2 Etat de l’Art

— Rentabilité : La scalabilité permet d’optimiser l’utilisation des ressources. Plutôt

que de surdimensionner l’infrastructure pour faire face aux pics de demande oc-
casionnels, il est possible de mettre en place une architecture scalable qui s’ajuste
dynamiquement aux besoins réels. Cela peut réduire les coûts d’exploitation en
évitant les dépenses inutiles liées à l’achat et à la maintenance d’équipements sup-
plémentaires. [23]

2.2.3 Types de Scalabilité

[Link] Scalabilité Verticale

La scalabilité verticale, ou "scale-up", implique l’ajout de ressources supplémentaires à

une seule machine, comme l’augmentation de la mémoire, de la puissance du processeur ou
de la capacité de stockage. Cette méthode est souvent utilisée lorsque les applications ne
peuvent pas être facilement distribuées sur plusieurs serveurs. Cependant, elle est limitée
par les capacités physiques maximales du matériel et peut entraîner des coûts plus élevés.
[21]

Figure 2.1 – Scalabilité verticale [71]

[Link] Scalabilité horizontale

La scalabilité horizontale, également appelée "scale-out", consiste à ajouter ou reti-

rer des unités de ressources, telles que des serveurs ou des machines virtuelles, au sein
d’une infrastructure. Cette approche permet de répartir la charge de travail sur plusieurs

41
Chapitre 2 Etat de l’Art

instances, améliorant ainsi la tolérance aux pannes et la disponibilité du service. [21]

Figure 2.2 – Scalabilité horizontale [71]

2.3 Elasticité
L’élasticité est une caractéristique essentielle du cloud Computing, permettant aux
systèmes de s’adapter dynamiquement aux variations de la charge de travail en ajus-
tant les ressources allouées de manière autonome et efficace. Elle garantit que les res-
sources disponibles correspondent étroitement à la demande actuelle, évitant ainsi le sur-
approvisionnement ou le sous-provisionnement.

2.3.1 Définition

L’élasticité est le degré auquel un système est capable de s’adapter aux demandes en
approvisionnant et désapprovisionnant des ressources de manière automatique, de telle
façon à ce que les ressources fournies soient conformes à la demande du système. [22]

2.3.2 La Différence entre Scalabilité et Elasticité

L’élasticité et la scalabilité sont deux concepts clés du cloud computing, souvent

confondus, mais qui ont des significations distinctes et complémentaires.

42
Chapitre 2 Etat de l’Art

Critère Scalabilité (Scalability) Élasticité (Elasticity)

Définition Capacité d’un système à gérer une Capacité d’un système à allouer et
augmentation ou une diminution de désallouer dynamiquement des
la charge en modifiant la capacité ressources en fonction des besoins
des ressources en temps réel
Objectif Capacité d’un système à allouer et Gérer la croissance à long terme et
principal désallouer dynamiquement des adapter l’infrastructure aux
ressources en fonction des besoins exigences futures
en temps réel
Méthode Peut-être horizontale (ajout de Fonctionne généralement avec
machines) ou verticale (ajout de l’automatisation pour ajuster les
ressources sur une seule machine) ressources en fonction des besoins
changeants
Temps Généralement planifié à l’avance Instantané et automatique, en
d’exécution pour répondre aux besoins réponse aux fluctuations de la
croissants demande
Lien avec le La scalabilité est une capacité L’élasticité est une fonctionnalité
Cloud fondamentale qui permet aux avancée qui permet d’optimiser les
infrastructures cloud d’évoluer coûts et d’éviter la
efficacement surconsommation des ressources

Table 2.1 – La Différence entre Scalabilité et Elasticité

2.3.3 États du système selon l’élasticité

Un système élastique est caractérisé par deux facteurs [22], ce qui entraîne trois états :

— Sur-approvisionnement (Over-provision) : Le système entre dans cet état

lorsque les ressources fournies, appelées offre (S), sont supérieures aux ressources
requises par le consommateur, que nous appelons demande (D). Cela garantit que
la qualité de service QoS est maintenue, mais entraîne des coûts supplémentaires et
inutiles liés à la location des ressources.

43
Chapitre 2 Etat de l’Art

— Sous-approvisionnement (Under-provision) : Dans ce cas, la demande (D) est

supérieure à l’offre (S), ce qui provoque une dégradation des performances et une
violation de l’Accord de Niveau de Service SLA.

— État d’équilibre (Just-in-need) : C’est l’état optimal où la charge de travail est

correctement gérée et où la qualité de service (QoS) est garantie.

Figure 2.3 – Comparaison entre les ressources demandées et les ressources fournies

2.3.4 Classements de l’élasticité

De nombreuses classifications de l’élasticité existent. Elles sont généralement basées

sur les critères suivants : configuration, portée, objectif, mode, méthode et fournisseur
[24]. Voici les principales catégories :

A- Configuration : La configuration correspond à l’allocation des ressources (CPU,

mémoire, réseau, etc.) et à la réservation initiale auprès du fournisseur cloud [24]. Elle se
divise en deux modes :

— Mode rigide : Les ressources provisionnées ont une capacité constante, ce qui les
rend rarement adaptées à la demande.

— Mode configurable : Permet au client de choisir précisément la quantité de res-

sources nécessaires.

44
Chapitre 2 Etat de l’Art

B- Objectif (Purpose) : L’élasticité peut être mise en place pour différents objectifs
tels que l’amélioration des performances, l’augmentation de la capacité des ressources,
l’économie d’énergie, la réduction des coûts et l’assurance de la disponibilité. Elle varie
en fonction du type de service cloud [24] :

— Cloud IaaS (Infrastructure as a Service) : Cherche à maximiser les profits tout

en garantissant une bonne qualité de service (QoS).

— Cloud PaaS (Platform as a Service) : Vise à minimiser les coûts et à améliorer

la qualité d’expérience (QoE).

C- Mode (Policy) : Aussi appelé politique d’élasticité, il représente la manière dont

les actions d’élasticité sont exécutées [24] :

— Mode automatique : Peut être réactif (déclenché par des règles ou une charge de
travail spécifique) ou proactif (utilise des techniques de prévision telles que l’analyse
des séries temporelles ou l’apprentissage par renforcement).

— Mode manuel : Nécessite l’intervention de l’utilisateur. Il inclut un mode program-

mable, où les appels API permettent aux utilisateurs d’interagir avec une interface
fournie par le fournisseur cloud.

D- Méthode (Scaling method) : Il s’agit des méthodes de mise à l’échelle [24] :

— Élasticité horizontale : Ajout ou suppression d’instances (machines virtuelles,

conteneurs, modules, etc.), qui peuvent être situées à différents emplacements. Cette
approche peut entraîner une utilisation inefficace des ressources.

— Élasticité verticale : Permet de redimensionner les instances existantes, offrant

ainsi plus de flexibilité. Cependant, elle est plus complexe que l’élasticité horizontale,
car elle n’est pas prise en charge par tous les hyperviseurs et nécessite parfois une
migration lorsque les ressources disponibles sur la machine hôte sont insuffisantes.

45
Chapitre 2 Etat de l’Art

Figure 2.4 – Classification des mécanismes d’élasticité [24]

2.3.5 Métriques et évaluation

Pour comprendre comment l’élasticité peut être mesurée, deux aspects clés doivent
être définis [25] :

— Vitesse (Speed) : La vitesse de mise à l’échelle vers le haut (scaling up) ou

vers le bas (scaling down) est le temps nécessaire pour passer d’un état sous-
approvisionné (resp. Sur-approvisionné) à un état optimal ou sur-approvisionné
(resp. Sous-approvisionné).

Remarque : Ce temps ne correspond pas directement au temps technique de pro-

visionnement ou de déprovisionnement des ressources.

— Précision (Precision) : La précision de la mise à l’échelle est l’écart absolu entre

la quantité actuelle de ressources allouées et la demande réelle.

Afin de capturer les principaux aspects de l’élasticité, voici quelques définitions : [25]
A : Temps moyen pour passer d’un état sous-approvisionné à un état optimal ou sur-
approvisionné, correspondant à la vitesse moyenne de mise à l’échelle vers le haut.

46
Chapitre 2 Etat de l’Art

Ā : Temps moyen pour passer d’un état sous-approvisionné à un état optimal ou

sur-approvisionné, correspondant à la vitesse moyenne de mise à l’échelle vers le
haut.

ΣA : Temps total accumulé en état sous-approvisionné.

Ū : Quantité moyenne de ressources sous-approvisionnées pendant une période d’in-

suffisance de ressources.

ΣU : Quantité totale de ressources sous-approvisionnées accumulées.

B̄ : Temps moyen pour passer d’un état sur-approvisionné à un état optimal ou

sous-approvisionné, correspondant à la vitesse moyenne de mise à l’échelle vers le
bas.

ΣB : Temps total accumulé en état sur-approvisionné.

Ō : Quantité moyenne de ressources sur-approvisionnées pendant une période d’excès

de ressources.

ΣO : Quantité totale de ressources sur-approvisionnées accumulées.

T : Durée totale de la période d’évaluation.

— Moyenne de la précision de scalabilité verticale (scaling up) Pu :

ΣU
Pu =
T

— Moyenne de la précision de scalabilité horizontale (scaling down) Pd :

ΣO
Pd =
T

— Élasticité de la scalabilité verticale (scaling up) Eu :

1
Eu =
Ā × B̄

— Élasticité de la scalabilité horizontale (scaling down) Ed :

1
Ed =
B̄ × Ō

47
Chapitre 2 Etat de l’Art

2.4 L’équilibrage de charges

2.4.1 Définition

L’équilibrage de charge consiste à répartir les requêtes et la charge de travail entre

plusieurs ressources (serveurs, instances ou services) afin de garantir leur disponibilité, en
dirigeant les demandes uniquement vers celles capables de les traiter rapidement. Cette
technique améliore significativement les performances des applications ou services héber-
gés sur plusieurs nœuds en déviant le trafic des machines surchargées ou défaillantes.
[28]

Figure 2.5 – Fonctionnement de l’équilibrage de charge (Load Balancing) [28]

2.4.2 Approches d’équilibrage de charge

Les approches utilisées pour l’équilibrage de charges se déclinent principalement en

deux grandes catégories [28] :

— Équilibrage de Charge Matériel : Les solutions matérielles (Load balancers

physiques) reposent sur des dispositifs dédiés capables de gérer d’importants volumes
de trafic.

Caractéristiques :

• Performance élevée grâce à du matériel optimisé.

• Fiabilité et robustesse éprouvées dans des environnements de production.
• Coût d’investissement élevé.

48
Chapitre 2 Etat de l’Art

• Flexibilité limitée, notamment dans des environnements dynamiques et évolu-

tifs.

— Équilibrage de Charge Logiciel : Les solutions logicielles s’appuient sur des

applications ou des services (souvent déployés en container ou sur des instances
virtuelles) pour distribuer la charge.

Caractéristiques :

• Coût réduit et déploiement agile.

• Capacité d’intégration avec des environnements cloud et MultiCloud grâce à
des API et des orchestrateurs.
• Dépendance à la virtualisation, pouvant impacter la latence dans certains cas.
• Nécessité d’une bonne configuration pour éviter des goulets d’étranglement.

Figure 2.6 – L’équilibrage de Charge Matériel et Logiciel [72]

2.4.3 Classements d’équilibrage de charge

Les mécanismes d’équilibrage de charge se classent selon plusieurs critères [27] :

A- Classification statique vs dynamique :

— Statique : La répartition est basée sur des règles préétablies et ne tient pas compte
des conditions actuelles du système.

— Dynamique : La distribution s’adapte en temps réel aux variations de charge et à

l’état des serveurs (nombre de connexions actives, charge CPU, etc.).

49
Chapitre 2 Etat de l’Art

B- Répartition par couche réseau vs applicative :

— Au niveau réseau, l’équilibrage peut s’effectuer via des mécanismes de routage ou

de proxy.

— Au niveau applicatif, l’équilibrage intervient souvent directement au niveau des

services ou micro services.

C- Algorithmes de distribution : Certains algorithmes se basent sur la rotation

simple (Round Robin) tandis que d’autres utilisent des méthodes plus sophistiquées tenant
compte de métriques en temps réel.

2.4.4 Métriques et évaluation

Pour évaluer l’efficacité d’une solution d’équilibrage de charges, plusieurs métriques et

indicateurs de performance sont utilisés. Parmi les plus courantes, on retrouve :

— Débit : Cette métrique permet de calculer le nombre de processus terminés par

unité de temps.

— Temps de réponse (latence) : Mesure le délai entre l’envoi d’une requête et la

réception de la réponse.

— Tolérance aux pannes : Détermine la capacité de l’algorithme à équilibrer la

Charge dans l’événement, de certains échecs dans certains nœuds ou des liens.

— Durée de la migration : Durée nécessaire au transfert d’une tâche d’un nœud

surchargé vers un sous-chargé.

— Utilisation des ressources : Suit l’usage du CPU, de la mémoire et de la bande

passante. Des indicateurs permettant d’identifier des surcharges éventuelles sur cer-
tains nœuds.

— Scalabilité et élasticité : Évalue la capacité du système à s’adapter aux variations

de charge, en ajoutant ou en retirant des ressources de manière dynamique.

2.4.5 Algorithmes d’équilibrage de charges

Les algorithmes d’équilibrage de charges constituent le cœur de toute solution de

répartition du trafic. Dans ce document, nous étudierons quatre algorithmes majeurs, en

50
Chapitre 2 Etat de l’Art

détaillant leur fonctionnement, leurs avantages, leurs limites et leur pertinence pour des
environnements MultiCloud.

A- Round Robin (RR) : Cet algorithme est très simple, la première requête est
envoyée au premier serveur, puis la suivante au second, et ainsi de suite jusqu’au dernier.
Ensuite on recommence en attribuant la prochaine requête au premier serveur, etc. [26]

Figure 2.7 – Fonctionnement de l’algorithme Round Robin [28]

B- Least Connection (LC) : Cet algorithme dirige la nouvelle requête vers le serveur
qui gère le moins de connexions actives à un moment donné. Il repose sur une observation
en temps réel de l’état de chaque serveur. [26]

Figure 2.8 – Fonctionnement de l’algorithme Least Connection [28]

C- Weighted Round Robin (WRR) : Le Weighted Round Robin étend l’algorithme

de base en attribuant chaque serveur un poids proportionnel à sa capacité ou à ses perfor-
mances. Ainsi, un serveur plus puissant recevra un nombre de requêtes plus élevé qu’un
serveur moins performant. [26]

51
Chapitre 2 Etat de l’Art

D- Weighted Least Connections (WLC) : Cet algorithme combine les avantages

de l’algorithme Least Connection et du Weighted Round Robin en tenant compte à la fois
du nombre de connexions actives et de la capacité pondérée de chaque serveur. Chaque
requête est dirigée vers le serveur dont le ratio « connexions actives/capacité pondérée »
est le plus faible. [26]

2.4.6 Objectifs de l’équilibrage de charge

— Utilisation optimale des ressources : c’est l’un des objectifs primordiaux de

l’équilibrage de la charge en tant que ressource appropriée l’utilisation est essentielle
pour l’efficacité du modèle de cloud.

— Haut débit : Un débit élevé (caractéristique essentielle d’un système haute perfor-
mance) n’est attainable que si la charge de travail et les ressources sont réparties de
façon uniforme entre les différents nœuds.

— Temps de réponse court : Pour de meilleures performances, la quantité de temps

prise pour réagir par un algorithme d’équilibrage de charge devrait être réduit.

2.5 Les Chalenges

— Flux Massif de Données : Les systèmes SIEM sont essentiels pour les organisa-
tions qui atténuent une multitude de menaces. Le centre opérationnel de sécurité
(SOC) d’une entreprise moyenne recevant plus de 10 000 alertes par jour, et les
plus grandes entreprises comptant plus de 150 000, la plupart des entreprises ne
disposent pas d’équipes de sécurité suffisamment grandes pour suivre le nombre
écrasant d’alertes. Cependant, le risque croissant posé par les cybermenaces tou-
jours plus sophistiquées rend l’ignorance des alertes assez dangereuse. La sécurité
SIEM offre un moyen plus efficace de trier et d’enquêter sur les alertes. [36]

— Sécurité et Conformité Multi-juridictionnelle : Dans un environnement Mul-

tiCloud, les SIEM doivent avant tout garantir la confidentialité des données, assurer
l’intégrité et maintenir la disponibilité. Ces trois piliers, connus sous l’acronyme CIA,
constituent le socle de la sécurité d’un SIEM MultiCloud. Dans le contexte algérien,
notamment la loi n° 18 07 du 10 juin 2018 relative à la protection des personnes
physiques dans le traitement des données à caractère personnel vient renforcer ces

52
Chapitre 2 Etat de l’Art

exigences en encadrant strictement les modalités de collecte, de traitement et de

transfert des données sensibles. [40]

- La Confidentialité « Confidentiality » : La confidentialité a été définie

par l’Organisation internationale de normalisation (ISO) comme « le fait de
s’assurer que l’information n’est accessible qu’à ceux dont l’accès est autorisé
». [37] [38]
- L’Intégrité « Integrity » : L’intégrité des données désigne l’état de don-
nées qui, lors de leur traitement, de leur conservation ou de leur transmission,
ne subissent aucune altération ou destruction volontaire ou accidentelle, et
conservent un format permettant leur utilisation. [38]
- La Disponibilité « Availability » : La disponibilité d’un équipement ou
d’un système est une mesure de performance qu’on obtient en divisant la durée
durant laquelle ledit équipement ou système est opérationnel par la durée totale
durant laquelle on aurait souhaité qu’il le soit. On exprime classiquement ce
ratio sous forme de pourcentage. [38]

Le RNSI 2020, définit un cadre normatif pour les mesures de sécurité obligatoires que
doivent mettre en œuvre les organismes publics et les prestataires cloud. Il impose
la classification des données, l’audit périodique des infrastructures, le chiffrement
des informations sensibles et la formalisation des procédures de gestion des inci-
dents, renforçant ainsi la résilience des SIEM MultiCloud et alignant les pratiques
algériennes sur les standards internationaux.

— Coût de Scalabilité : La scalabilité d’un SIEM se traduit par des coûts directement
corrélés aux volumes de données ingérées, à la puissance de calcul nécessaire au
parsing et à la corrélation des logs, ainsi qu’au stockage à long terme. [39]

2.6 Vecteurs de Menaces et Techniques d’Attaque

2.6.1 Mitre ATT&CK

MITRE ATT&CK répertorie les tactiques, techniques et procédures (TTP) cybercri-

minelles à chaque phase du cycle de vie de la cyberattaque, depuis les comportements
initiaux de collecte d’informations et de planification d’un pirate jusqu’à l’exécution fi-

53
Chapitre 2 Etat de l’Art

nale de l’attaque. [29] Les informations contenues dans MITRE ATT&CK peuvent aider
les équipes de sécurité à :

— Simuler avec précision des cyberattaques pour tester les cyberdéfenses.

— Créer des politiques de sécurité, des contrôles de sécurité et des plans de réponse
aux incidents plus efficaces.

— Choisir et configurer les technologies de sécurité pour mieux détecter, éviter et at-
ténuer les cybermenaces.

2.6.2 DDOS

Definition : Une attaque DDoS (Distributed Denial of Service) est une tentative mal-
veillante de perturber le trafic normal d’un serveur, d’un service ou d’un réseau ciblé en
le submergeant d’un volume excessif de requêtes Internet. Elle repose sur l’utilisation de
multiples systèmes compromis (botnets) diffusant simultanément du trafic vers la cible
afin d’épuiser ses ressources. [30] [32]

Fonctionnement : Les attaquants constituent généralement un botnet en infectant

massivement des machines (ordinateurs, objets IoT. . .) avec des maliciels, [31] [35] afin de
les contrôler à distance pour lancer l’attaque Plusieurs techniques sont employées :

— Attaques volumétriques : inondation massive de trafic (UDP, ICMP. . .) pour

saturer la bande passante ou les tables de routage.

— Attaques protocolaires : exploitation des faiblesses de protocoles (SYN flood,

Ping of Death. . .) pour épuiser les ressources serveurs (CPU, sessions).

— Attaques au niveau applicatif (Layer 7) : envoi de requêtes HTTP/S très

nombreuses et légitimes en apparence pour épuiser la capacité de traitement des
serveurs web.

54
Chapitre 2 Etat de l’Art

Figure 2.9 – Exemeple Attaque DDoS [31]

Risques Associés :

— Impact sur la disponibilité.

— Impact financier.

— Réputation et confiance.

— Risques juridiques et conformité.

— Vulnérabilités accrues.

2.6.3 Network Flood

Definition : Une attaque Network Flood est une forme de déni de service (DoS) qui
consiste à inonder un réseau ou un équipement réseau (switch, routeur, pare feu) avec un
flux excessif de paquets dans le but de saturer ses ressources. Contrairement à une attaque
DDoS centrée sur un service applicatif, le Network Flood se focalise sur l’épuisement de
la bande passante et des tables de commutation ou de routage, provoquant souvent un
mode hub où tous les paquets sont diffusés sur tous les ports. Les types courants incluent
l’inondation ICMP (ping flood), UDP flood, SYN flood, ARP flood et MAC flood. [33]

Fonctionnement : Les attaquants coordonnent généralement un botnet un réseau de

machines compromises pour générer le trafic nécessaire et masquer l’origine de l’attaque.
[34] Les principales variantes sont :

— Inondation ICMP (Ping Flood) : envoi massif de requêtes ICMP Echo Request
pour saturer la bande passante du réseau cible.

— UDP Flood : envoi de paquets UDP à destination de ports aléatoires afin d’épuiser
la bande passante et forcer les équipements à générer des messages d’erreur.

55
Chapitre 2 Etat de l’Art

— SYN Flood (attaque protocolaire) : exploitation du mécanisme de handshake

TCP pour ouvrir de nombreuses connexions incomplètes et saturer la table des
connexions.

— ARP Flooding : envoi de requêtes ARP massives pour remplir la table ARP du
commutateur ou du routeur, provoquant des plantages ou un redémarrage.

— MAC Flooding : envoi de trames Ethernet avec des adresses MAC source diffé-
rentes pour saturer la table CAM du switch, le forçant à entrer en mode hub.

— Broadcast Storm : inondation de trames de diffusion, souvent après un change-

ment de topologie ou un défaut STP, engendrant un trafic de diffusion continu sur
tous les ports.

Risques Associés :

— Indisponibilité et déni de service.

— Épuisement des ressources matérielles.

— Exposition des données et fuites.

— Coûts financiers et réputationnels.

— Fenêtre pour d’autres attaques.

2.6.4 Kill Chain

Definition : Le Cyber Kill Chain est un modèle d’analyse des intrusions développé
en 2011 par Lockheed Martin dans le cadre de son approche Intelligence Driven Defense,
visant à décomposer les attaques en étapes ordonnées et à renforcer la défense en rompant
la chaîne à chaque phase. Cette méthode se base sur l’idée que les attaquants suivent
un cheminement structuré pour parvenir à leurs fins, depuis la phase de reconnaissance
jusqu’aux actions sur l’objectif. Dans son prolongement, le framework MITRE ATT&CK
complète la kill chain en détaillant les tactiques et techniques employées à chaque phase,
fondées sur des observations du monde réel. [66]

Fonctionnement : Le modèle traditionnel comporte 7 étapes principales :

— Reconnaissance : collecte d’informations sur la cible (infrastructure, vulnérabili-

tés, personnels).

56
Chapitre 2 Etat de l’Art

— Armement : création d’un vecteur d’attaque (maliciel, code d’exploitation) adapté

à la cible identifiée.

— Livraison : transmission de l’outil malveillant (phishing, USB, site Web) vers l’en-
vironnement de la cible.

— Exploitation : activation du maliciel exploitant la vulnérabilité pour exécuter du

code non autorisé.

— Installation : mise en place d’une porte dérobée (backdoor) assurant un accès

persistant.

— Commande & Contrôle (C2) : communication entre l’attaquant et les systèmes

compromis pour piloter l’attaque.

— Actions sur l’objectif : réalisation des finalités malveillantes (exfiltration, sabo-

tage, chiffrement).

Figure 2.10 – Étapes de la Cyber Kill Chain Attaque [67]

De nombreuses organisations privilégient la prévention au détriment de la détection

proactive. Les frameworks comme MITRE ATT&CK enrichissent ce modèle en référençant

57
Chapitre 2 Etat de l’Art

finement les tactiques et techniques observées, renforçant les exercices de Red Team et
Purple Team. [66]

Risques Associés :

— Exfiltration de données

— Sabotage et altération

— Perturbation de la disponibilité

— Coûts financiers

— Risques juridiques et conformité

— Fenêtre pour attaques secondaires

2.7 Conclusion
Ce chapitre a analysé les mécanismes de scalabilité, d’élasticité et d’équilibrage de
charge, en mettant en évidence les fondements d’une gestion optimale des ressources
dans le cloud. Il a porté sur les approches algorithmiques d’adaptation aux variations
de charge, tout en abordant les enjeux de disponibilité, de performance et de sécurité.
L’étude a également souligné les vulnérabilités des infrastructures cloud et les risques
liés aux comportements malveillants. Ces éléments servent de base à la conception d’une
solution SIEM adaptée aux exigences des architectures cloud.

58
Chapitre 3

Étude de cas et solution proposée

Chapitre 3 Étude de cas et solution proposée

3.1 Introduction
Ce chapitre examine la scalabilité d’un SIEM MultiCloud via l’orchestration de conte-
neurs avec Kubernetes, en optimisant le déploiement de Wazuh pour garantir performance
et disponibilité. Il présente les mécanismes de scalabilité Kubernetes (Deployments, HPA,
KEDA), détaille les KPI et outils de monitoring pour mesurer l’élasticité du SIEM, puis
aborde les défis et stratégies d’optimisation pour maintenir résilience et sécurité face aux
variations de charge et aux menaces.

3.2 Description de l’Architecture Choisie

Dans cette section, nous présentons l’architecture retenue pour la mise en œuvre de
notre SIEM. Inspirée des solutions multisites distribuées telles que celle proposée par
FortiSIEM (Modèle : Service Provider), l’architecture adopte une approche distribuée et
résiliente, répondant aux exigences de scalabilité et d’élasticité dans un environnement
MultiCloud. [41]

Figure 3.1 – Architecture “Service Provider” FortiSIEM [41]

60
Chapitre 3 Étude de cas et solution proposée

Lorsque FortiSIEM est installé en mode Service Provider, il dispose d’une base de
données et d’une interface pleinement multi tenant aware, permettant de gérer plusieurs
organisations isolées dans un même cluster. (Multitenant, ou multi-entité, désigne un
principe d’architecture logicielle permettant à un logiciel de servir plusieurs organisations
clientes). [41]

3.2.1 Composants principaux

— Supervisor : point central de coordination, hébergeant l’API et la console.

— Worker : nœuds applicatifs répartis en shards et réplicas pour ingérer et indexer

les événements.

— Keeper : nœuds quorum (un ou trois) garantissant la disponibilité et la cohérence.

— Collector : déployés chez chaque client et dans le cœur de réseau, ils collectent
les logs, effectuent pré traitement, compression et upload sécurisé. Séparation et
routage

3.2.2 Séparation et routage

— Collecteurs dédiés chez chaque client pour assurer la séparation des données.

— Collectors multi tenant dans le cœur pour ingérer les logs des dispositifs partagés,
avec un mécanisme d’event-to-organization mapping (ex. labels VDOM).

— Load balancers recommandés entre Collectors et Workers pour rediriger le trafic en

cas de panne et simplifier la configuration des sources de logs.

3.2.3 Architecture proposée

Nous avons repris ces principes dans notre schéma, en remplaçant l’infrastructure
dédiée par des clusters Kubernetes sur trois clouds publics, offrant ainsi une couche
d’abstraction unifiée pour orchestrer nos composants SIEM malgré l’hétérogénéité des
fournisseurs.

61
Chapitre 3 Étude de cas et solution proposée

Figure 3.2 – Architecture MultiCloud (solution proposée)

L’idée maîtresse est de déployer des collecteurs locaux (Wazuh Agents/Manager Wor-
ker) sur plusieurs sites géographiques – ici trois clusters Kubernetes hébergés respective-
ment sur AWS (Site Alger), Google Cloud (Site B) et Azure (Site C) – et de relier ces
collecteurs à un manager central unique, responsable de l’agrégation, du traitement et de
la corrélation globale des événements de sécurité.
L’utilisation de Kubernetes nous permettera de tirer parti de ses mécanismes natifs
d’autoscaling, notamment HPA et KEDA.
Cette combinaison garantit la continuité de service (« zero down time ») de notre
SIEM, même sous forte sollicitation. Pour valider la robustesse et la haute disponibilité,
nous simulerons des attaques issues du référentiel MITRE ATT&CK en les appliquant aux
composants SIEM, démontrant ainsi la résilience de notre architecture face aux tactiques
et techniques adverses documentées par MITRE ATT&CK.

3.3 Conception du Système

La conception de notre système repose sur une approche modulaire et évolutive, per-
mettant une adaptation facile aux besoins changeants et aux exigences futures. Voici les
principaux éléments de notre conception :

62
Chapitre 3 Étude de cas et solution proposée

3.3.1 Conteneurisation

La conteneurisation est un processus de déploiement logiciel qui regroupe le code d’une

application avec tous les fichiers et bibliothèques nécessaires à son exécution, formant un
conteneur autonome. [42]

Figure 3.3 – Architecture d’un conteneur

Architecture :

— Hardware : serveurs physiques ou machines virtuelles (bare metal, EC2, instances

GCP/Azure).

— OS Hôte : le noyau Linux (ou Windows dans des conteneurs Windows) gère direc-
tement les conteneurs.

— Contrôleur : runtime compatible OCI (Docker Engine, CRI O, Containerd) or-

chestrant la création, l’exécution et la gestion des conteneurs à partir des images.

— Appli/Libs : couche applicative empaquetée avec ses bibliothèques, frameworks

et fichiers de configuration, garantissant une reproductibilité absolue du comporte-
ment.

Avantages :

— Portabilité : Les conteneurs partagent le noyau de l’hôte tout en fonctionnant dans

des espaces isolés, éliminant la nécessité d’installer un OS invité complet et assurant
une portabilité transparente entre Linux, Windows, bare metal et divers clouds. [43]

63
Chapitre 3 Étude de cas et solution proposée

— Capacité de mise à l’échelle : Un conteneur, en l’absence de surcharge d’un hy-

perviseur, démarres-en quelques millisecondes et consomme peu de ressources, faci-
litant le déploiement de milliers d’unités sur une même [Link] conteneur,
en l’absence de surcharge d’un hyperviseur, démarres-en quelques millisecondes et
consomme peu de ressources, facilitant le déploiement de milliers d’unités sur une
même infrastructure. [42]

— Tolérance aux pannes : L’isolation des conteneurs garantit qu’un service dé-
faillant n’impacte pas les autres, renforçant la résilience : en cas de crash d’un
conteneur, l’orchestrateur peut automatiquement redéployer le service dégradé sans
interruption globale. [42]

— Hétérogénéité : Les cycles de développement sont raccourcis grâce à l’indépen-

dance entre le code applicatif et l’environnement d’exécution. Les mises à jour et
corrections sont testées et déployées en continu, sans impacter l’infrastructure par-
tagée. [43]

3.3.2 Containerd

Containerd est un démon système open source dédié à l’exécution, la supervision et

la gestion des conteneurs, conforme aux spécifications OCI pour le format d’image et le
runtime. [46] Son architecture modulaire s’appuie sur des plugins pour adapter dynami-
quement le stockage, le réseau et l’observabilité. [47]

Avantages :

— Simplicité et légèreté : runtime minimaliste, sans surcouche hyperviseur, démarre

un conteneur en millisecondes. [48]

— Robustesse : architecture modulable en plugins, facilités de debug (ttrpc/grpc,

logs shim) et reprise automatique après plantage du daemon. [48]

— Portabilité : partage du noyau hôte, interopérabilité Windows/Linux, conforme à

l’OCI, adoptable par tout orchestrateur respectant le CRI. [48]

64
Chapitre 3 Étude de cas et solution proposée

La nature de Containerd minimaliste réduit la consommation de ressources et la sur-

face d’attaque, tandis que son intégration directe au Container Runtime Interface de
Kubernetes assure une orchestration fluide et conforme aux best practices cloud natifs.
[49] Comparé à Docker, containerd supprime la surcharge inutile tout en bénéficiant d’un
support communautaire et industriel, répondant précisément à nos besoins d’efficacité et
de conformité aux standards CNCF. [50]

3.3.3 Kubernetes

Kubernetes constitue le noyau de notre système. Fruit de plus d’une décennie d’expé-
rience de Google, cette plateforme open source offre une API unifiée pour déployer, mettre
à l’échelle et gérer des applications conteneurisées dans le cloud. [51] En s’appuyant sur la
spécification OCI et le Container Runtime Interface, elle permet d’orchestrer de manière
cohérente des conteneurs sur n’importe quel fournisseur, assurant portabilité, tolérance
aux pannes et agilité opérationnelle. [49] De plus, Kubernetes masque l’hétérogénéité des
services cloud en proposant une couche d’abstraction standardisée, véritable socle pour
bâtir une architecture MultiCloud homogène.

[Link] Définition

Kubernetes est une plateforme open source pour déployer, mettre à l’échelle et gérer
des applications conteneurisées, offrant des mécanismes de configuration déclarative et
d’automatisation. Initialement conçu par Google puis open sourced en 2014, il combine
plus de 15 ans d’expérience de production avec les meilleures pratiques de la communauté.
Il n’est pas une alternative à Docker, mais s’appuie sur des runtimes conformes à la CRI
(Container Runtime Interface), dont containerd est le plus répandu. [52]

Figure 3.4 – Logo Kubernetes

65
Chapitre 3 Étude de cas et solution proposée

[Link] Architecture

Figure 3.5 – Architecture d’un cluster Kubernetes

A- Plan de Contrôle (Control Plane) : Le plan de contrôle orchestre l’état du

cluster grâce aux composants suivants [52] :

— API Server : point d’entrée des commandes kubectl et des appels REST.

— etcd : base de données clé-valeur distribuée pour stocker l’état désiré du cluster.

— Scheduler : assigne les Pods aux nœuds disponibles selon les ressources.

— Controller Manager : exécute les boucles de contrôle (réplication, nœuds, end-

points).

B- Plan de Données (Data Plane) : Chaque nœud (worker) exécute [49] [53] :

— kubelet : agent local garantissant l’exécution des Pods et communiquant avec la

CRI.

— containerd : runtime CNCF gérant le cycle de vie des conteneurs, plus léger et
sécurisé que Docker Engine.

— kube proxy : implémente la couche réseau des Services, gère le routage et le load
balancing.

66
Chapitre 3 Étude de cas et solution proposée

[Link] Composants

Figure 3.6 – Les différents controleurs de Kubernetes

A- Controlleurs :

Pods : Un Pod est l’unité la plus petite de déploiement dans Kubernetes. [54] Il en-
capsule un ou plusieurs conteneurs partageant réseau, volumes et espace de noms Linux,
ce qui garantit leur exécution co-localisée et co-ordonnée. [54] Les Pods sont éphémères
et gérés par des contrôleurs plutôt que créés manuellement, car ils ne disposent pas de
mécanismes natifs de réplication ou de mise à jour. [55]

ReplicaSets : Un ReplicaSet veille à maintenir un nombre constant de réplicas d’un

Pod donné. [56] Il utilise un sélecteur de labels pour identifier les Pods à gérer et crée ou
supprime des instances afin d’atteindre l’objectif spécifié, assurant ainsi la haute dispo-
nibilité du workload. [56] En pratique, on le manipule généralement via un Deployment
plutôt que directement.

Deployments : Le Deployment est une abstraction de niveau supérieur qui orchestre

les ReplicaSets. [57] Il offre :

— Des déploiements déclaratifs et des mises à jour progressives (rolling updates) maî-
trisées.

— La gestion des rollbacks en cas d’échec d’une update.

— La scalabilité par simple modification du champ replicas.

— Chaque modification du template Pod déclenche la création d’un nouveau Replica-

Set, tandis que l’ancien est progressivement mis à l’échelle à zéro.

67
Chapitre 3 Étude de cas et solution proposée

StatefulSets : Un StatefulSet gère des applications à état en garantissant [58] :

— Des identités réseau stables (noms DNS persistants).

— Des Volumes Persistants distincts pour chaque Pod, permettant la conservation des
données.

— Un ordonnancement séquentiel au démarrage et à l’arrêt, indispensable pour les

bases de données ou clusters distribués.

B- Connectivité réseau :

Ingress : L’Ingress définit des règles HTTP(S) pour router le trafic vers plusieurs Ser-
vices en fonction d’hôtes et de chemins, et gère la terminaison TLS. [61] Un Ingress
Controller (NGINX, Traefik. . .) implémente ces règles comme add-on, offrant des fonc-
tionnalités avancées (rate limiting, web application firewall).

Figure 3.7 – Fonctionnement d’un Ingress

Services : Un Service expose un ensemble de Pods sous un point d’accès réseau stable,
dissocié du cycle de vie des Pods. [59] [60]

— ClusterIP : IP virtuelle interne, non routable vers l’extérieur.

— NodePort : ouverture d’un port statique sur chaque nœud, redirigeant vers le
ClusterIP.

— LoadBalancer : provis ionnement d’un Load Balancer externe via l’API cloud.

— ExternalName : mappage direct vers un nom DNS externe, sans proxying.

68
Chapitre 3 Étude de cas et solution proposée

Figure 3.8 – Les différents Services de Kubernetes

C- Autoscaling : La capacité à adapter dynamiquement les ressources aux charges

de travail est cruciale. Kubernetes offre des mécanismes d’autoscaling qui permettent
d’ajuster automatiquement le nombre de pods en fonction de la demande, assurant ainsi
une utilisation optimale des ressources et une haute disponibilité du système.

HPA (Horizontal Pod AutoScaling) : Le Horizontal Pod Autoscaler (HPA) est

un contrôleur Kubernetes qui ajuste automatiquement le nombre de pods dans un dé-
ploiement, un ReplicaSet ou un StatefulSet en fonction de métriques observées telles que
l’utilisation du CPU ou de la mémoire. Il fonctionne en surveillant les métriques des pods
à intervalles réguliers (par défaut toutes les 15 secondes) et en comparant ces valeurs à des
seuils définis. Si l’utilisation dépasse ou descend en dessous de ces seuils, HPA augmente
ou diminue le nombre de pods pour maintenir la performance de l’application tout en
optimisant l’utilisation des ressources.

69
Chapitre 3 Étude de cas et solution proposée

Figure 3.9 – Intégration de HPA dans Kubernetes

KEDA (Kubernetes Event-driven AutoScaling) : KEDA est un composant léger

et open-source qui étend les capacités d’autoscaling de Kubernetes en permettant le dé-
clenchement du scaling basé sur des événements externes. Contrairement à HPA, qui se
base principalement sur des métriques internes comme l’utilisation du CPU, KEDA peut
réagir à des événements tels que la longueur d’une file de messages dans une file d’attente,
le nombre de requêtes dans une base de données, ou d’autres indicateurs provenant de
systèmes externes. KEDA fonctionne en tandem avec HPA, en fournissant des métriques
personnalisées à HPA via des adaptateurs, permettant ainsi un autoscaling plus réactif et
adapté à des scénarios spécifiques. [62]

Figure 3.10 – Exemple de KEDA [62]

70
Chapitre 3 Étude de cas et solution proposée

— Collecte des métriques : Le composant Logstash du cluster de monitoring in-

terroge à intervalles réguliers le cluster de production pour extraire les métriques
ciblées (par exemple, le nombre de threads JVM) via l’API Elasticsearch ou d’autres
endpoints appropriés. [62] Cette approche utilise le plugin elasticsearch de Logstash,
capable de récupérer des documents et des métriques depuis une instance Elastic-
search pour les traiter en pipeline.

— Stockage dans Elasticsearch : Une fois extraits, les métriques sont formatées
et indexées dans la base Elasticsearch du cluster de monitoring grâce au plugin
elasticsearch de sortie de Logstash, garantissant que les données sont accessibles via
des requêtes optimisées pour le scaling. [62]

— Scraping des métriques par KEDA : KEDA exécute périodiquement un Sca-

ledObject configuré pour interroger Elasticsearch avec une requête prédéfinie (tem-
plate de recherche) et récupérer la valeur courante de la métrique (p. ex., [Link]).
[62] KEDA utilise son adaptateur Elasticsearch, qui implémente le trigger elastic-
search, pour exposer ce résultat comme métrique externe Kubernetes.

— Décision de scaling : Dès qu’un écart est détecté (la métrique dépasse ou descend
sous le targetValue ou activationTargetValue spécifié), KEDA émet un scale event
en notifiant le HPA interne à Kubernetes pour scale out ou scale in le workload
concerné. [62]

— Exécution du scaling par HPA : Le Horizontal Pod Autoscaler reçoit ce signal

via l’API Metrics Server, compare la métrique externe à la cible définie et ajuste
automatiquement le champ [Link] du Deployment ou StatefulSet, effectuant
ainsi le scale out ou scale in effectif dans le cluster de production. [62]

3.3.4 Wazuh

Afin de tenir notre promesse consistent à fournir un service continuel, il est impératif
de choisir un siem compatible avec l’ecosystem de Kubernetes. En suivant cette logique,
nous avons retenu Wazuh.

71
Chapitre 3 Étude de cas et solution proposée

[Link] Définition

Wazuh est une solution de surveillance et d’analyse des événements de sécurité dérivée
d’OSSEC. Elle permet de collecter, analyser et corréler des données issues de diverses
sources pour détecter des comportements anormaux et générer des alertes en temps réel.

[Link] Architecture

L’architecture de Wazuh repose sur un modèle agent centralisé : chaque agent installé
sur une machine (physique, VM, conteneur) collecte les données de sécurité (logs, inté-
grité de fichiers, comportements suspects. . .) et les transmet au serveur Wazuh, qui les
traite avant de les indexer et de les présenter via un tableau de bord centralisé Wazuh
documentation. [63] Les dispositifs sans agent (pare-feu, routeurs, API cloud) peuvent
également envoyer leurs logs par Syslog, SSH ou API.

Figure 3.11 – Architecture Wazuh

[Link] Composants

L’architecture de Wazuh est conçue pour être modulaire et scalable, facilitant ainsi
son déploiement dans des environnements distribués et MultiCloud. Les principaux com-
posants de cette architecture sont les suivants :

72
Chapitre 3 Étude de cas et solution proposée

A- Agents : Les agents sont déployés sur chacun des points de terminaison (serveurs,
postes de travail, conteneurs, etc.). Leur rôle est de collecter en continu les données (logs,
informations système, changements de fichiers, etc.) et de les transmettre au serveur cen-
tral. Ils assurent ainsi la première ligne de défense en fournissant des informations brutes
nécessaires à l’analyse.

B- Serveur de Gestion (Manager) : Le serveur central, ou manager, reçoit les don-

nées envoyées par les agents, les analyse et applique des règles de corrélation pour dé-
tecter des anomalies ou des comportements suspects. Il gère également la configuration
des agents et la génération des alertes. Ce composant est le cœur du SIEM, assurant la
transformation des données brutes en informations exploitables pour la sécurité.

C- Cluster d’indexation et stockage : Pour garantir une performance optimale dans

l’analyse et la recherche des événements, Wazuh intègre un système d’indexation des
données. Dans certaines implémentations, ce rôle est assuré par des moteurs de recherche
comme Elasticsearch ou des solutions alternatives conçues pour gérer de grands volumes
de données en temps réel.

D- Interface de visualisation : L’interface web permet aux analystes de visualiser les

alertes, d’explorer les logs et de générer des rapports détaillés. Elle joue un rôle essentiel
dans la gestion opérationnelle et la prise de décisions rapides en matière de sécurité.

[Link] Clustering et haute disponibilité

Pour garantir zéro downtime et une évolutivité horizontale, Wazuh peut être déployé
en cluster :

— Master node : orchestre la configuration et reçoit les données des agents.

— Worker nodes : traitent et analysent les flux entrants.

— Load balancer : répartit la charge entre les nœuds.

— Synchronisation des configurations et des données via mécanismes de file d’attente.

73
Chapitre 3 Étude de cas et solution proposée

Figure 3.12 – Configuration HA Wazuh

Cette architecture de cluster, associée au cluster Elasticsearch de l’indexer, assure une

tolérance aux pannes et la montée en charge de bout en bout. [64]

[Link] Réponse active et automatisation

Au delà de l’alerte, Wazuh permet d’automatiser la remédiation : [65]

— Active Response : scripts (bash, PowerShell, Python) déclenchés automatique-

ment pour bloquer IPs, désactiver comptes où redémarrer des services dès qu’une
règle critique est activée.

— Webhooks & API : intégration avec des orchestrateurs externes (SOAR, Ansible)
via HTTP/REST pour lancer des playbooks d’investigation ou de confinement.

— Audit continu : rapports périodiques de conformité (PCI DSS, NIST 800 53)
générés automatiquement pour valider les correctifs appliqués.

Cette boucle de détection → réponse → vérification assure un niveau de zéro downtime

dans notre architecture Kubernetes, en fermant le cycle de sécurité sans intervention
manuelle.

74
Chapitre 3 Étude de cas et solution proposée

3.4 Conclusion
Cette solution repose sur une architecture cloud-native pour un SIEM MultiCloud
hautement disponible. Elle utilise Containerd et Kubernetes pour la gestion et l’orches-
tration des conteneurs. L’autoscaling est assuré par HPA et KEDA selon les métriques et
événements. Wazuh enrichit la détection avec MITRE ATT&CK et des réponses actives.
L’ensemble garantit performance, résilience et sécurité dans un environnement multi-site.

75
Chapitre 4

Simulations et Résultats
Chapitre 4 Simulations et Résultats

4.1 Introduction
Dans ce chapitre, nous présentons l’environnement de simulation mis en place pour
évaluer notre solution de scalabilité et de sécurité dans un contexte MultiCloud. Les
différentes étapes du déploiement, les scénarios simulés, ainsi que l’analyse des résultats
obtenus sont détaillés afin d’apporter une évaluation critique de la solution proposée.

4.2 Présentation d’Environnement de la Simulation

Pour mettre en œuvre la simulation, nous avons construit un environnement distribué
reposant sur Kubernetes, afin de reproduire les principales caractéristiques d’un déploie-
ment multi-cloud (répartition géographique, contrôle centralisé et scalabilité). Dans un
premier temps, nous décrirons la topologie du cluster et la configuration des nœuds, puis
nous détaillerons les composants déployés pour assurer la collecte, le traitement et la
visualisation des événements de sécurité.

4.2.1 Infrastructure MultiCloud simulée

Pour reproduire un environnement multi-cloud, nous avons choisi de créer un cluster

Kubernetes à trois nœuds (“noeuds kubeadm”), répartis sur trois machines distinctes :

Figure 4.1 – Infrastructure MultiCloud simulée

77
Chapitre 4 Simulations et Résultats

— Site A (PC physique) : Ce nœud joue le rôle de nœud Control Plane (maître).
Il exécute le plan de contrôle Kubernetes (kube-apiserver, kube-scheduler, kube-
controller-manager).

— Site B et Site C (PC physique) : Nœuds Worker. Héberge des pods applicatifs
(Wazuh, Prometheus Stack, etc.).

L’ensemble de ces trois nœuds forme un cluster Kubernetes provisionné avec la com-
mande kubeadm init sur Site A, puis kubeadm join sur les nœuds B et C. La topo-
logie multi-site se traduit ici par la distribution des nœuds sur trois emplacements phy-
siques/virtuels différents, simulant l’hétérogénéité inhérente à un déploiement multi-cloud
(chacun pouvant représenter un cloud provider, ou au minimum un datacenter distinct).

4.2.2 Composants déployés

Sur ce cluster Kubernetes, nous avons installé plusieurs composants afin de simuler
le fonctionnement complet d’un SIEM wazuh. Mais aussi, pour assurer simultanément la
collecte, le traitement et la visualisation des événements de sécurité, ainsi que l’autosca-
ling :

Figure 4.2 – Composants déployés

78
Chapitre 4 Simulations et Résultats

A- Wazuh Manager et Wazuh Indexer (StatefulSets) :

Wazuh Manager (StatefulSet) :

— Replicas : 1 à l’initial (Scénario 01), extensible jusqu’à 3 (Scénario 02).

— Volume persistant (PVC) pour chaque pod Manager, stockant la configuration in-
terne et l’historique des alertes.

— Ressources : limits : 400 Mo CPU, 1024 Mi RAM.

Wazuh Indexer (StatefulSet) :

— Replicas : 1 à l’initial (Scénario 01), extensible jusqu’à 3 (Scénario 02).

— Chaque pod Indexer est accompagné d’un PersistentVolume, garantissant la persis-

tance des segments d’index dans OpenSearch.

— Ressources : limits : 500 Mo CPU, 1564 Mi RAM.

B- Wazuh Agents (simulés) :

— Installés hors cluster, sur plusieurs machines externes (au moins quatre) pour générer
un flux d’événements de sécurité.

— Configurés pour cibler le Wazuh Manager du cluster via le port 1514 (TCP/UDP).

— Capacité à produire jusqu’à 5 000 événements/s en crête, représentant la charge

d’un attaquant massif.

C- Monitoring Stack (avec Grafana intégré) : Déployé via les Helm Chart prome-
theus et grafana de prometheus-community et grafana.

Composants inclus :

— Prometheus Operator (CustomResourceDefinitions pour Prometheus, ServiceMoni-

tor, etc.).

— Prometheus Server (StatefulSet monosreplica).

— Alertmanager (Deployment).

— Node Exporter et Kube-State-Metrics (DaemonSets).

— pushgateway.

— Grafana (Deployment) avec des Dashboards prédéfinis pour Kubernetes et Wazuh.

79
Chapitre 4 Simulations et Résultats

Ressources :

— Prometheus Server : requests : 500 m CPU, 1 Go RAM ; limits : 1 CPU, 2 Go

RAM.

— Grafana : requests : 200 m CPU, 300 Mo RAM, limits : 500 m CPU, 1 Go RAM.

— PersistentVolumeClaim pour Grafana (4 Go) afin de stocker les Dashboards, données

de sessions, plugins.

4.2.3 Matériel Utiliser

Matériel Utiliser Pour La Simulation Déploiement « Wazuh » MultiCloud :

PC 01 : Laptop DELL Vostro 3500

— Microprocesseur : Intel(R) Core (TM) i5-1135G7 CPU.

— Nombre de Cœurs et threads : 4 Cœurs, 8 threads.

— Fréquence du processeur : 2.40 GHz.

— RAM : 8 Go DDR4.

— Capacité de stockage : Un seul disque SSD 256 Go.

— Système d’exploitation : Ubuntu 24.04 LTS & Windows 11 Pro x64.

PC 02 : Laptop ACER Aspire E1-571

— Microprocesseur : Intel(R) Core (TM) i3-3120M CPU.

— Nombre de Cœurs et threads : 2 Cœurs, 4 threads.

— Fréquence du processeur : 2,5 GHz.

— RAM : 4 Go DDR3.

— Capacité de stockage : Un seul disque HDD 500 Go.

— Système d’exploitation : Alpine Linux.

PC 03 : Laptop Samsung NP300E4Z

— Microprocesseur : Intel(R) Core (TM) i3-2350M CPU.

— Nombre de Cœurs et threads : 2 Cœurs, 4 threads.

— Fréquence du processeur : 2,3 GHz.

80
Chapitre 4 Simulations et Résultats

— RAM : 4 Go DDR3.

— Capacité de stockage : Un seul disque HDD 500 Go.

— Système d’exploitation : Alpine Linux.

PC 04 : HP Pro 3500 Series (QB290EA#AB6)

— Microprocesseur : Intel(R) Core (TM) i3-2120 CPU.

— Nombre de Cœurs et threads : 2 Cœurs, 4 threads.

— Fréquence du processeur : 3.30 GHz.

— RAM : 6 Go DDR3.

— Capacité de stockage : Un seul disque HDD 500 Go.

— Système d’exploitation : Alpine Linux.

PC 05 : Laptop HP Notebook 15-bw078nia

— Microprocesseur : AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G.

— Nombre de Cœurs et threads : 2 Cœurs, 4 threads.

— Fréquence du processeur : 3.00 GHz.

— RAM : 8 Go DDR4.

— Capacité de stockage : Un seul disque SSD 256 Go.

— Système d’exploitation : Windows 10 Pro x64 & Ubuntu 18.04 LTS.

4.3 Scénario 01 : Implémentation sans Scalabilité

Dans ce premier scénario, tous les composants sont déployés sans mécanismes d’au-
toscaling. Les nombres de replicas sont fixés et ne changent pas pendant toute la durée
des tests. L’objectif est d’établir une référence de performance lorsque le cluster reçoit un
flux d’événements croissant, afin de mettre en évidence les limites du dimensionnement
statique.

4.3.1 Configuration initiale des services

Avant de s’attaquer à la mise en test de la résillience du SIEM, nous devons d’abord

préparer un environnement propice pour l’execution de ce scenario.

81
Chapitre 4 Simulations et Résultats

A- Déploiement site-a pour la simulation de 1 ére Scénario :

Figure 4.3 – Déploiement site a

Le namespace site-a héberge un cluster Wazuh autonome constitué d’un indexer (wazuh-
indexer-0) et de deux managers (master et worker) exposés via des services NodePort pour
l’ingestion des logs (ports 1514, 1515), la réplication inter-nœuds (port 1516) et l’accès
à l’API/aux agents, tandis qu’un service ClusterIP (port 9300) gère la communication
interne de l’indexer.

B- Déploiement Wazuh Dashboard :

Figure 4.4 – Déploiement Wazuh Dashboard

Dans l’espace de namespace site-d, le pod wazuh-dashboard est en cours d’exécution

(1/1 containers prêts) et assure l’interface de visualisation de Wazuh. Le service dash-
board, de type NodePort, lui associe l’IP de cluster [Link] et expose le port HTTPS
443 sur le port externe 30443, permettant un accès sécurisé à la console de supervision
depuis l’extérieur du cluster.

82
Chapitre 4 Simulations et Résultats

C- Déploiement Agent Wazuh :

Figure 4.5 – Déploiement Agent Wazuh

Nous déployons un agent Wazuh via l’interface dédiée du Wazuh Dashboard. Ce ta-
bleau de bord permet de distribuer des agents sur diverses plateformes et architectures.
L’agent, quant à lui, est le composant chargé de collecter et de transférer les journaux
(logs) d’un endpoint vers le cluster que nous avons déployé précédemment.

D- Déploiement Monitoring :

Figure 4.6 – Déploiement Monitoring

Dans le namespace monitoring de Kubernetes, 6 pods (Grafana et divers composants

Prometheus : serveur, kube-state-metrics, node-exporter et pushgateway) sont en cours
d’exécution, tous prêts à collecter et visualiser des métriques. 5 services exposent ces
pods : Grafana et Prometheus-server en NodePort (ports 30092 et 30091) pour un accès
externe, et les autres en ClusterIP (ports 8080, 9100, 9091) pour communication interne,
garantissant ainsi découverte, scalabilité et disponibilité du système de supervision.

83
Chapitre 4 Simulations et Résultats

4.3.2 Execution et déroulement

Afin de simuler la charge du système dans le cadre du premier scénario, nous avons
créé les scripts suivants :

A- Fonction d’envoie des logs pour générer les evenements :

Figure 4.7 – Fonction d’envoie des logs

La fonction flood sert à envoyer un grand nombre de messages UDP vers un hôte et
un port donné, pour simuler une charge. Elle commence par créer une connexion réseau,
récupère le nom de la machine locale et affiche l’heure de début. Ensuite, elle entre dans
une boucle où elle construit et envoie des messages, soit un certain nombre de fois (défini
par l’utilisateur), soit en continu. Chaque message est généré aléatoirement à partir d’un
modèle, puis envoyé. Si une vitesse d’envoi (rate) est définie, la fonction fait une pause
entre chaque message. En cas d’interruption par l’utilisateur, elle affiche combien de mes-
sages ont été envoyés. Enfin, elle indique l’heure de fin, ferme la connexion et résume le
total des messages expédiés.

84
Chapitre 4 Simulations et Résultats

B- Types de Logs envoyé a Wazuh :

Figure 4.8 – Types de Logs envoyé

La liste TEMPLATES contient des modèles de lignes de journal simulant des échecs
d’authentification courants (SSH, sudo, su) que Wazuh peut reconnaître via ses déco-
deurs/règles : chaque chaîne inclut des placeholders comme pid, user, ip, port, hostname,
tty qui seront remplacés dynamiquement pour générer des faux logs représentant par
exemple des tentatives de connexion SSH échouées ou des échecs d’élévation de privilèges,
afin de tester et valider la détection de ces événements par Wazuh.

4.3.3 Résultats de performances

Après l’exécution et le déroulement du premier scénario, les résultats de performance

sont affichés avec Grafana dans les captures d’écran suivantes :

A- Etat de Système au moment d’arrivé 2000 EPS :

Figure 4.9 – Etat de Système "Arrivé 2000 EPS"

85
Chapitre 4 Simulations et Résultats

Au moment de l’arrivée d’environ 2000 événements par seconde, le tableau montre

que le Manager Wazuh est saturé : la file d’attente atteint 100 % d’utilisation, le CPU du
worker dépasse légèrement 100 % (indiquant un dépassement de capacité) et la mémoire
est également au-delà de 100 %, ce qui signifie que le système ne peut plus absorber la
charge supplémentaire sans dégrader ou perdre des événements.

B- Résultats Graphe Etat de Système au moment d’arrivé 2000 EPS :

Figure 4.10 – Résultats Graphe Etat de Système "Arrivé 2000 EPS"

Lorsque le système Wazuh reçoit soudainement 2000 événements par seconde, on ob-
serve une montée rapide des événements reçus mais surtout une explosion des événements
perdus (jusqu’à plus de 7000/s), ce qui signifie que la capacité de traitement est dépassée ;
dès la fin du “flood”, le taux de réception et de perte retombe immédiatement à zéro, mon-
trant que le système revient à la normale mais qu’il n’est pas dimensionné pour absorber
sans perte un tel pic de charge.

86
Chapitre 4 Simulations et Résultats

C- Etat de Système au moment d’arrivé 3000 EPS :

Figure 4.11 – Etat de Système "Arrivé 3000 EPS"

Au moment de l’arrivée d’environ 3000 événements par seconde, le tableau montre

que le manager Wazuh est saturé : la file d’attente atteint 100 % d’utilisation, le CPU du
worker dépasse légèrement 100 % (indiquant un dépassement de capacité) et la mémoire
est également au-delà de 100 %, ce qui signifie que le système ne peut plus absorber la
charge supplémentaire sans dégrader ou perdre des événements. Nous remarquons aussi
que le nombre de réplicas du StatefulSet "wazuh-manager-worker" est tombé à zéro, en
raison du manque de ressources (CPU, RAM) du pod, qui a du mal à gérer la charge à
lui seul.

87
Chapitre 4 Simulations et Résultats

D- Résultats Graphe Etat de Système au moment d’arrivé 3000 EPS :

Figure 4.12 – Résultats Graphe Etat de Système "Arrivé 3000 EPS"

Lorsque le système Wazuh est soumis à 3000 événements par seconde, il ne parvient à
ingérer qu’environ 800–900 événements/s (courbe bleue), tandis que le reste jusqu’à près
de 18000 événements/s est immédiatement perdu (courbe orange), ce qui montre que la
capacité maximale de traitement est très inférieure à la charge injectée ; une fois le “flood”
terminé, les deux taux retombent instantanément à zéro, confirmant que le système revient
à son état normal sans avoir jamais absorbé le pic.

4.4 Scénario 02 : Implémentation avec Scalabilité

Dans ce second scénario, nous ajoutons les mécanismes d’autoscaling (KEDA et HPA)
pour le cluster wazuh manager et indexer, afin d’adapter dynamiquement le nombre de
réplicas en fonction des seuils de charge. Cette section décrit la configuration précise des
ressources, le déroulé du test et les résultats obtenus.

4.4.1 Configuration de l’autoscaling

Dans le but d’observer la resillience de notre architecture, nous mettons en place un

environnement pour tester cette derniere.

88
Chapitre 4 Simulations et Résultats

A- Déploiement Multi-site pour la simulation de 2 éme Scénario :

Figure 4.13 – Déploiement Multi-site (Exemple Site-a)

Trois namespaces distincts (site-a, site-b, site-c) hébergent chacun un indexer et un

manager en mode primaire. Un service wazuh-cluster de type NodePort sur chaque site
permet la réplication croisée des configurations et des alertes.

B- Déploiement Avec HPA :

Figure 4.14 – Déploiement Avec HPA

89
Chapitre 4 Simulations et Résultats

Le Horizontal Pod Autoscaler (HPA) permet d’ajuster automatiquement le nombre de

pods d’un StatefulSet (ici wazuh-manager-worker dans le namespace site-a) en fonction
de la charge. Grâce à la surveillance de la consommation CPU et mémoire (seuils fixés à
70 % dans cet exemple), le HPA fait passer le nombre de pods de 1 à 3 selon les besoins,
assurant ainsi une montée en charge fluide et une utilisation optimisée des ressources.

C- Déploiement Avec KEDA :

Figure 4.15 – Déploiement Avec KEDA

Le ScaledObject KEDA surveille l’usage de la file d’événements via Prometheus et

ajuste automatiquement de 1 à 3 pods wazuh-manager-worker (namespace site-a) toutes
les 30 s, en ajoutant des réplicas dès que l’usage dépasse 25 %, puis en patientant 5
minutes avant de réduire, pour gérer finement la montée et la descente en charge.

90
Chapitre 4 Simulations et Résultats

4.4.2 Execution et déroulement

Afin de simuler la charge du système dans le cadre du deuxième scénario, nous avons
utilisé le meme générateur de log que le premier scenario

4.4.3 Résultats de performances avec scaling

Après l’exécution et le déroulement du deuxième scénario, les résultats de performance

sont affichés avec Grafana dans les captures d’écran suivantes :

1- HPA :

A- Etat de Système avec Déploiement HPA au moment d’arrivé 2000 EPS :

Figure 4.16 – HPA, Etat de Système "Arrivé 2000 EPS"

Le tableau de bord Grafana présente l’état des trois pods wazuh-manager-worker (0,
1 et 2) au pic de 2000 événements par seconde : on y voit les taux d’événements reçus et
rejetés (events_received vs events_dropped), l’utilisation de la queue à 0 %, la consomma-
tion CPU restant très faible (0 %, sauf un worker à 38 %) et une mémoire élevée oscillant
entre 85 % et 88 %. Cet aperçu confirme que le HPA a automatiquement maintenu trois
réplicas pour absorber la charge tout en conservant une marge CPU et en poussant la
RAM à près de sa capacité.

91
Chapitre 4 Simulations et Résultats

B- Résultats HPA Graphe Etat de Système au moment d’arrivé 2000 EPS :

Figure 4.17 – Résultats HPA Graphe Etat de Système "Arrivé 2000 EPS"

Le graphe montre qu’à 2000 événements/seconde, le nombre d’événements reçus (courbe

bleue) grimpe rapidement jusqu’à environ 750 EPS puis redescend à zéro une fois la pé-
riode de « flood » terminée, tandis que les événements rejetés (courbe orange) restent
à zéro tout au long du test. Les secteurs colorés indiquent clairement les phases avant,
pendant et après le pic de charge, attestant que l’HPA a maintenu le service sans perte
d’événements, en adaptant dynamiquement la capacité du cluster.

C- Etat de Système avec Déploiement HPA au moment d’arrivé 3000 EPS :

Figure 4.18 – HPA, Etat de Système "Arrivé 3000 EPS"

92
Chapitre 4 Simulations et Résultats

Au pic de 3000 événements/seconde, le HPA conserve trois réplicas wazuh-manager-

worker et assure toujours un traitement sans perte (events_dropped à zéro). L’utilisation
de la queue reste à 0 %, la CPU de chaque worker grimpe légèrement (autour de 1–3
%) et la mémoire redescend un peu entre 71 % et 84 %, montrant que le cluster absorbe
efficacement la charge sans saturation CPU ni débordement de file d’attente.

D- Résultats HPA Graphe Etat de Système au moment d’arrivé 3000 EPS :

Figure 4.19 – Résultats HPA Graphe Etat de Système "Arrivé 3000 EPS"

Lors du test à 3000 événements/seconde, la courbe bleue atteint un pic d’environ

550 EPS avant de redescendre à zéro une fois le « flood » terminé, tandis que la courbe
orange des événements rejetés reste constamment à 0 EPS. Les zones colorées délimitent
les phases avant, pendant et après la surcharge, démontrant que l’HPA a maintenu le
traitement sans perte d’événements grâce à un ajustement dynamique de la capacité du
cluster.

93
Chapitre 4 Simulations et Résultats

1- KEDA :

A- Etat de Système avec Déploiement KEDA au moment d’arrivé 2000 EPS :

Figure 4.20 – KEDA, Etat de Système "Arrivé 2000 EPS"

Au pic de 2000 événements/seconde, KEDA a provisionné trois réplicas wazuh-manager-

worker (identifiables aux compteurs “1” pour chaque pod). Aucun événement n’est perdu
et l’utilisation de la file d’événements reste à 0 %. Côté ressources, deux pods plus anciens
atteignent près de 80 % de CPU et 80–84 % de RAM, tandis que le pod fraîchement
ajouté tourne à seulement 72 % de CPU et 12 % de RAM, montrant que KEDA scale-out
ajoute d’abord un pod “frais” avant de saturer les ressources existantes.

B- Résultats KEDA Graphe Etat de Système au moment d’arrivé 2000 EPS :

Figure 4.21 – Résultats KEDA Graphe Etat de Système "Arrivé 2000 EPS"

94
Chapitre 4 Simulations et Résultats

Le graphe illustre qu’à 2000 événements/seconde, KEDA porte le débit traité jusqu’à
environ 750 EPS avant la fin du « flood », tout en conservant les événements rejetés
à zéro. Les zones colorées distinguent clairement les phases avant, pendant et après la
charge, montrant que KEDA scale-out a réagi suffisamment vite pour absorber le pic sans
aucune perte d’événements.

C- Etat de Système avec Déploiement KEDA au moment d’arrivé 3000 EPS :

Figure 4.22 – KEDA, Etat de Système "Arrivé 3000 EPS"

Lorsque le pic atteint 3000 EPS, KEDA conserve trois réplicas sans perdre d’événe-
ments et la file d’attente reste à 0 %. En revanche, la charge n’est pas répartie équitable-
ment : le pod nouvellement créé supporte près de 80 % de CPU et 51 % de RAM, tandis
que les deux pods existants sont presque inactifs en CPU (0 %) mais à 89 % de RAM
chacun, ce qui montre que KEDA scale-out privilégie d’abord le pod fraîchement ajouté
avant d’équilibrer la charge.

95
Chapitre 4 Simulations et Résultats

D- Résultats KEDA Graphe Etat de Système au moment d’arrivé 3000 EPS :

Figure 4.23 – Résultats KEDA Graphe Etat de Système "Arrivé 3000 EPS"

Le graphe montre qu’à un afflux de 3000 événements/s, KEDA fait monter le débit
traité jusqu’à environ 450 EPS avant la fin du “flood”, tout en gardant les événements
rejetés à zéro. Les zones colorées (avant, pendant et après la charge) soulignent la réactivité
de KEDA : même si le throughput reste limité autour de 500 EPS pour les trois réplicas,
aucun événement n’est perdu grâce à l’extension automatique de la capacité.

4.5 Discussion et Limites

Après avoir réalisé les simulations pour les deux scénarios (sans scalabilité et avec sca-
labilité), nous dressons dans le tableau ci-dessus un comparatif des résultats obtenus selon
chacun des critères retenus. Cette présentation permet de mettre en évidence l’impact de
la scalabilité sur les performances et la robustesse de notre architecture.
Les métriques collectées, notamment "wazuh_queue_usage", "wazuh_events_received",
et "wazuh_events_dropped", fournissent des insights précieux sur la performance de Wa-
zuh sous charge.

— wazuh_queue_usage : Avant l’attaque, l’utilisation de la file d’attente était re-

lativement stable et faible, indiquant que le système était capable de traiter les
événements entrants sans accumulation significative. Pendant l’attaque, nous avons
observé une augmentation significative de l’utilisation de la file d’attente, ce qui

96
Chapitre 4 Simulations et Résultats

suggère que le système était sous pression et commençait à accumuler des événe-
ments non traités. Après l’attaque, l’utilisation de la file d’attente est revenue à des
niveaux normaux.

— wazuh_events_received : Le nombre d’événements reçus a augmenté de ma-

nière significative pendant l’attaque, ce qui était attendu étant donné que l’attaque
était conçue pour générer une charge supplémentaire. Cette augmentation montre
que Wazuh était capable de recevoir un grand nombre d’événements, mais il est
important de noter comment cela a affecté d’autres métriques.

— wazuh_events_dropped : Une augmentation du nombre d’événements perdus

pendant l’attaque a été observée. Cela indique que, sous une charge élevée, le système
n’était pas capable de traiter tous les événements entrants, entraînant une perte de
données. Cela peut avoir des implications importantes pour la détection et la réponse
aux incidents, car des événements critiques pourraient être perdus.

A- Résultats Scénario 1 :

Scén Test Période EPS Total Usage év év

d’Attaque logs queue reçus perdus
Avant 2000 27000 0 0 0
01 Pendant 2000 27000 0 1260 0
Après 2000 27000 0 0 0
Avant 2000 27500 0 0 0
02 Pendant 2000 27500 47 1044 27500
Après 2000 27500 0 0 0
Avant 2000 30000 0 0 0
Simple 03 Pendant 2000 30000 79 1328 28700
Après 2000 30000 0 0 0
Avant 2000 31000 0 0 0
04 Pendant 2000 31000 100 1037 26234
Après 2000 31000 0 0 0
Avant 3000 30000 0 0 0
05 Pendant 3000 30000 100 822 18136
Après 3000 30000 0 0 0

Table 4.1 – Résultats "Scenario 1"

97
Chapitre 4 Simulations et Résultats

B- Résultats Scénario 2 - HPA :

Scén Test Période EPS Total Usage évent évent

d’Attaque logs queue reçus perdus
Avant 2000 27000 0 0 0
01 Pendant 2000 27000 0 1500 0
Après 2000 27000 0 0 0
Avant 2000 27500 0 0 0
02 Pendant 2000 27500 0 1410 0
Après 2000 27500 0 0 0
Avant 2000 30000 0 0 0
HPA 03 Pendant 2000 30000 0 1090 0
Après 2000 30000 0 0 0
Avant 2000 31000 0 0 0
04 Pendant 2000 31000 0 1200 0
Après 2000 31000 0 0 0
Avant 3000 30000 0 0 0
05 Pendant 3000 30000 0 1030 0
Après 3000 30000 0 0 0

Table 4.2 – Résultats "Scenario 2 : HPA"

C- Résultats Scénario 2 - KEDA :

Scén Test Période EPS Total Usage évent évent

d’Attaque logs queue reçus perdus
Avant 2000 27000 0 0 0
01 Pendant 2000 27000 0 1060 0
Après 2000 27000 0 0 0
Avant 2000 27500 0 0 0
02 Pendant 2000 27500 0 1360 0
Après 2000 27500 0 0 0
Avant 2000 30000 0 0 0
KEDA 03 Pendant 2000 30000 0 1600 0
Après 2000 30000 0 0 0
Avant 2000 31000 0 0 0
04 Pendant 2000 31000 0 1800 0
Après 2000 31000 0 0 0
Avant 3000 30000 0 0 0
05 Pendant 3000 30000 0 1900 0
Après 3000 30000 0 0 0

Table 4.3 – Résultats "Scénario 2 : KEDA"

98
Chapitre 4 Simulations et Résultats

4.5.1 Comparaison des deux scénarios

Nous avons testé deux scénarios différents pour évaluer la performance de Wazuh sous
charge. Le premier scénario impliquait une charge modérée, tandis que le second scéna-
rio impliquait une charge plus élevée, simulant une attaque plus intense. Les métriques
collectées pour chaque scénario sont comparées ci-dessous.

— wazuh_queue_usage : Dans le premier scénario, l’utilisation de la file d’attente

a augmenté modérément pendant l’attaque et est revenue lentement à la normale
et la récupération a pris plus de temps après l’attaque, cela suggère que le sys-
tème a eu plus de difficultés à gérer la charge plus élevée. Dans le second scénario,
l’augmentation a été plus pronunciée et la récupération a pris moins de temps.

— wazuh_events_received : Le nombre d’événements reçus était naturellement

plus élevé dans le second scénario. Cependant, la proportion d’événements reçus
par rapport à la charge simulée était similaire dans les deux scénarios, indiquant
que Wazuh était capable de recevoir des événements de manière cohérente, indépen-
damment de la charge.

— wazuh_events_dropped : Le nombre d’événements perdus est très élevé. Cela

indique que, sous une charge très élevée, le système commence à perdre des évé-
nements, ce qui peut compromettre la détection et la réponse aux incidents. Dans
le second scénario, le nombre d’événements perdus est quasiment nulle grâce aux
mécaniques de scalabilité implémentées qui ont permis au système de gérer la charge
élevée.

Les différences observées entre les deux scénarios peuvent être attribuées à plusieurs
facteurs :

— Charge simulée : Pendant le premier scénario, le système n’a pas pu supporter la

charge, ce qui a entraîné une saturation importante de la file d’attente et la perte de
plusieurs événements. Cependant, grâce aux mécanismes de scalabilité mis en place,
le système a pu supporter les sollicitations du second scénario—et, dans certains
cas, y résister sans dégradation notable.

— Capacité du système : Le système a une capacité de traitement limitée, qui a

été dépassée dans le premier scénario. Cela souligne l’importance d’avoir assez de
ressources en fonction de la charge attendue.

99
Chapitre 4 Simulations et Résultats

— Configuration de Wazuh : La configuration de Wazuh, telle que la taille de

la file d’attente et les paramètres de traitement des événements, peut également
influencer la performance sous charge. Des ajustements de configuration pourraient
potentiellement améliorer la performance dans des scénarios de charge élevée.

4.5.2 Limites de l’étude

— Simulation locale : l’environnement sur 4 PC ne reflète pas entièrement la latence

inter-cloud réelle.

— Nombre de réplicas limité : jusqu’à 3 pods, alors qu’un déploiement réel pourrait
en nécessiter davantage.

— Trigger KEDA : basé sur Prometheus, or d’autres mécanismes pourraient amé-

liorer la réactivité.

— Persistance : les tests n’incluent pas de panne complète d’un nœud, ni de reprise
automatique sur disque.

4.6 Conclusion
Cette simulation a permis de valider l’efficacité des mécanismes de scalabilité et de
détection dans un environnement MultiCloud. Les résultats obtenus sont encourageants
pour une adoption en environnement réel, bien que des optimisations supplémentaires
soient nécessaires pour minimiser les impacts liés à la latence inter-cloud.

100
 Conclusion Générale

Conclusion Générale

Notre projet de fin d’études intitulé « Scalabilité des SIEM dans les Environnements
MultiCloud Computing », vise à deployer un SIEM hautement disponible pour objectif
d’étudier la scalabilité dans les Architectures MultiCloud, Nous avons proposé une solution
innovante intégrant des technologies Cloud telle que Kubernetes, d’Auto Scaling telle que
HPA et KEDA et de traitement des données et de surveillance en temps réel (Prometheus
et Grafana).
Le premier Chapitre présente Le Contexte Génerale, La Problématique et les Objectifs
de notre Projet. Le deuxème Chapitre qui détaille l’état de l’art et les technologies de sca-
labilité existantes ainsi que les defis présents. Ensuite, le troisième Chapitre se concentre
sur la conception du système et l’Architacture choisie. Le quatrième Chapitre présente les
simulations et résultats obtenus.
Cette étude repésente une étape importante dans le développement de ce genre de
systéme et ouvre la voie à des recherches futures et à des innovations dans ce domaine. Il
existe encore des perspectives damélioration et de développement de l’approche proposée :

— Passage à un environnement Multi-Cloud réel : Tester la solution sur AWS,

Azure et GCP permet de valider sa portabilité, d’évaluer la latence inter-régions et
de mesurer les coûts en conditions opérationnelles.
— Simulation des attaques DDoS, Network Flood et Kill Chain : Tester la
solution avec les attaques montioner vu le monque du temps et des ressorces pour
réaliser.
— Évolutivité et redondance géographique : Déployer des clusters Kubernetes
dans plusieurs zones et orchestrer la réplication multi-cluster assure une mise à
l’échelle fluide et un basculement automatique en cas de panne régionale.
— Extension des stratégies d’auto-scaling : Comparer le scaling réactif (HPA,
KEDA, Cluster Autoscaler) aux approches prédictives basées sur la machine lear-

101
 Conclusion Générale

ning, puis implémenter ces algorithmes sur les séries temporelles Prometheus pour
anticiper et absorber les pics de charge.

— Renforcement de la sécurité et de la conformité : Mettre en place une ges-

tion unifiée des identités et accès multi-cloud, des politiques réseaux avancés et du
chiffrement bout à bout, tout en ajoutant des modules IDS/IPS et en testant la
résistance par red-team et chaos engineering.

— Évaluation des coûts et du dimensionnement : Réaliser une analyse coût-

performance par cloud pour optimiser le sizing des nœuds et tirer parti d’instances
spot ou VMs préemptibles afin de réduire significativement les dépenses.

— Automatisation avancée et Infrastructure as Code : Industrialiser tous les

déploiements Kubernetes avec Terraform/Terragrunt et des pipelines GitOps (Argo
CD, Flux) pour versionner et tester automatiquement chaque manifest.

— Scénarios de montée en charge et tests de robustesse : Étendre les tests

de charge à des centaines de nœuds avec des flux de logs réalistes et mener des
expérimentations de chaos engineering pour valider la résilience sous stress.

102
Bibliographie

[1] Data Dog. Cloud SIEM.

[Link] 2024.

[2] Wikipédia. Cloud Computing.

[Link] 2025.

[3] NIST. NIST Cloud Computing Program – NCCP. https:

//[Link]/programs-projects/nist-cloud-computing-program-nccp,
2025.

[4] NIST. NIST Cloud Computing Reference Architecture. [Link]

publications/nist-cloud-computing-reference-architecture, 2025.

[5] Cisco Systems. Le cloud Computing, les attributions et le rôle du département IT

changent, 2020.

[6] Wikipédia. Security information and event management. https:

//[Link]/wiki/Security_information_and_event_management,
2025.

[7] Intervalle Technologies. SIEM : Définition, fonctions et cas d’utilisation.

[Link]
siem-definition-fonctions-et-cas-dutilisation/, 2025.

[8] C. Regagba. Conception et mise en place d’un système de gestion des informations
et des événements de sécurité (SIEM). Master’s thesis, Université de Sidi Bel Abbés
Djillali Liabés, 2023.

[9] A. Chaouche. Conception et réalisation d’un système de sélection des meilleures

 services SaaS dans un environnement MultiCloud. Master’s thesis, Université des
Sciences et de la Technologie Houari Boumediene, 2022.

[10] S. Aguemoun and M. E. Maalem. Déploiement d’une solution stockage Objet dans
le cloud. Master’s thesis, Université de Blida 1 Saad Dahlab, 2024.

[11] Splunk. SIEM : tout comprendre sur la gestion des informations et des événements
de sécurité. [Link]
[Link], 2025.

[12] Google Cloud. Qu’est-ce que le MultiCloud.

[Link] 2025.

[13] Cloudflare. Qu’est-ce que le multicloud ? | Définition du multicloud.

[Link]
2025.

[14] Red Hat. Comprendre la virtualisation.

[Link] 2025.

[15] Wikipédia. Virtualisation. [Link]

2025.

[16] N. Hamdani, S. Kerroum, and N. Ouallouche. Etude et comparaison des failles de

sécurité d’OpenStack et OpenNebula. Master’s thesis, Université Mouloud
Mammeri de Tizi Ouzou, 2019.

[17] T. Yahi and R. Tiguercha. Etude et mise en place d’une solution Cloud Computing
privé au sein d’une entreprise (cas 2int partners). Master’s thesis, Université
Mouloud Mammeri de Tizi Ouzou, 2016.

[18] N. Touti. Introduction à la virtualisation. Master’s thesis, Université Ziane Achour

Djelfa, 2021.

[19] IONOS. Qu’est-ce que la virtualisation ? https:

//[Link]/digitalguide/serveur/configuration/la-virtualisation/,
2025.
[20] Canadian Centre for Cyber Security. La virtualisation de votre infrastructure
(ITSAP.70.011). [Link]
la-virtualisation-de-votre-infrastructure-itsap70011, 2025.

[21] Wikipédia. Extensibilité. [Link]

2024.

[22] Wikipédia. Élasticité (cloud computing).

[Link] 2024.

[23] Go Partner. Scalabilité dans le cloud.

[Link] 2025.

[24] Y. Al-Dhuraibi, F. Paraiso, N. Djarallah, and P. Merle. Elasticity in Cloud

Computing : State of the Art and Research Challenges. IEEE Transactions on
Services Computing, 11(2), March-April 2018.

[25] N. R. Herbst, S. Kounev, and R. Reussner. Elasticity in cloud computing : What it

is, and what it is not. In 10th International Conference on Autonomic Computing
(ICAC 13), 2013.

[26] geeksforgeeks. Load Balancing Algorithms.

[Link] 2025.

[27] Einollah Jafarnejad Ghomi, Amir Masoud Rahmani, and Nooruldeen Nasih Qader.
Load-balancing Algorithms in Cloud Computing : A Survey. Journal of Network
and Computer Applications, 2017.

[28] AppViewX. Load Balancer and Types.

[Link]
2025.

[29] Fortinet. Qu’est-ce que le SIEM.

[Link] 2025.

[30] Fortinet. DDoS Attack. Cyber Glossary.

[Link] 2025.
[31] Cloudflare. What is a distributed denial-of-service (DDoS) attack ? Learning
Center.
[Link] 2025.

[32] Wikipédia. Attaque par déni de service.

[Link] 2025.

[33] Cisco. Unicast Flooding in Switched Campus Networks.

[Link] 2025.

[34] Imperva. What is a TCP SYN Flood | Mitigation Techniques.

[Link] 2025.

[35] NIST. Advanced DDoS Mitigation Techniques.

[Link] 2025.

[36] Wikipédia. Sécurité des infrastructures du cloud.

[Link]
2025.

[37] Wikipédia. Confidentialité.

[Link] 2025.

[38] A. Abbas. MANAGEMENT DE LA SÉCURITÉ DES SYSTÈMES

D’INFORMATION. Cours, Université d’Alger 1 Benyoucef Benkhedda, 2023.

[39] Ministère de la Poste et des Télécommunications (MPT). Référentiel National de

Sécurité de l’Information (RNSI), 2020.

[40] Secrétariat Général du Gouvernement (SGG Algérie). Loi n° 18-07 du 25

Ramadhan 1439, 2018.

[41] Fortinet. FortiSIEM Reference Architecture Using ClickHouse.

[Link]
fortisiem-reference-architecture-using-clickhouse/209158/
service-provider, 2025.

[42] Amazon Web Services. Qu’est-ce que la conteneurisation ? La conteneurisation

expliquée. [Link] 2025.
[43] Red Hat. La conteneurisation, qu’est-ce que c’est ?
[Link] 2025.

[44] Selceon. Conteneurisation en cloud computing. https:

//[Link]/definition-de-la-conteneurisation-en-cloud-computing/,
2025.

[45] IBM. Qu’est-ce que la conteneurisation ?

[Link] 2025.

[46] Containerd. containerd. [Link] 2025.

[47] Github. containerd/containerd.

[Link]
2025.

[48] Sobyte. Understanding the Container Runtime Containerd in one article.

[Link] 2025.

[49] Kubernetes. Container Runtime Interface (CRI).

[Link] 2025.

[50] Docker. Containerd vs Docker.

[Link] 2025.

[51] Red Hat. What is Kubernetes ?

[Link] 2025.

[52] Kubernetes. Overview. [Link]

2025.

[53] Google Cloud. Using containerd for the container runtime.

[Link]
docs/concepts/using-containerd, 2025.

[54] Kubernetes. Pods. [Link]

2025.
[55] Kubernetes. Workloads. [Link]
2025.

[56] Kubernetes. ReplicaSet.

[Link]
2025.

[57] Kubernetes. Deployments.

[Link]
2025.

[58] Kubernetes. StatefulSets. https:

//[Link]/docs/concepts/workloads/controllers/statefulset/, 2025.

[59] Kubernetes. Service.

[Link] 2025.

[60] Kubernetes. Service ClusterIP allocation. [Link]

concepts/services-networking/cluster-ip-allocation/, 2025.

[61] Kubernetes. Ingress.

[Link] 2025.

[62] Verifa. How to scale Kubernetes with any metrics using Kubernetes Event-driven
Autoscaling (KEDA). https:
//[Link]/blog/how-to-scale-kubernetes-with-any-metric-using-keda/,
2025.

[63] Wazuh. Architecture - Getting started with Wazuh · Wazuh documentation.

https:
//[Link]/current/getting-started/[Link],
2025.

[64] Wazuh. Architecture overview - Wazuh server cluster - Wazuh documentation.

[Link]
wazuh-server-cluster/[Link], 2025.
[65] Wazuh. Kubernetes configuration - Deployment on Kubernetes.
[Link]
deploying-with-kubernetes/[Link], 2025.

[66] stormshield. Kill Chain : mieux comprendre pour mieux se protéger.

[Link]
kill-chain-mieux-comprendre-pour-mieux-se-proteger/, 2025.

[67] alphorm. Cyber Kill Chain : Comprendre et renforcer la cybersécurité.

[Link] 2025.

[68] rezau. Les avantages du Cloud Privé VMware face au Cloud Public.
[Link]
les-avantages-du-cloud-prive-vmware-face-au-cloud-public, 2025.

[69] alibabacloud. Qu’est-ce que le cloud hybride ? https:

//[Link]/fr/knowledge/what-is-hybrid-cloud?_p_lc=1, 2025.

[70] redhat. Comparaison entre l’IaaS, le PaaS et le SaaS. https:

//[Link]/fr/topics/cloud-computing/iaas-vs-paas-vs-saas, 2025.

[71] medium. Scalability — Vertical or Horizontal Scaling when Designing Architectures.

[Link]
scalability-vertical-scaling-horizontal-scaling-adb52ff679f, 2025.

[72] datascientest. Load Balancers : Tout savoir sur ce dispositif clé.

[Link] 2025.

[73] orientsoftware. multicloud vs hybridcloud.

[Link] 2025.
Annexe A

A.1 Déploiement Multi-site pour la simulation de 2

éme Scénario

A.1.1 Déploiement site b

Figure A.1 – Déploiement Multi-site (Exemple Site-b)

A.1.2 Déploiement site d « site c »

Figure A.2 – Déploiement Multi-site (Exemple Site-d « site c »)

A.2 Collecteur de Métriques Wazuh

Figure A.3 – Script collecteur de Métriques Wazuh

A.3 Etat des Pods dans le Déploiement Multi site

Figure A.4 – Etat des Pods dans le Déploiement Multi site