Document d’Architecture Technique

Infrastructure réseau segmentée et hautement disponible

Historique des versions

Sommaire

Convention de statut

Utilisée dans tout le document pour distinguer ce qui est en service de ce qui est conçu mais pas encore déployé. Aucun élément n’est présenté comme opérationnel s’il ne l’est pas.

1 · Introduction

1.1 Objet du document

Ce document décrit l’architecture technique d’une infrastructure réseau segmentée, filtrée et redondée, construite sur un hyperviseur Proxmox VE. Il présente les choix de conception, leur justification, et les conditions d’exploitation de la solution.

Il s’adresse à un lecteur qui doit comprendre, évaluer ou reprendre l’infrastructure sans avoir participé à sa construction.

1.2 Périmètre

Dans le périmètre

• Virtualisation et commutation virtuelle
• Segmentation réseau en VLAN et routage inter-VLAN
• Filtrage pare-feu et matrice des flux
• Services d’infrastructure : DNS, DHCP, NTP, annuaire
• Chaîne applicative web et base de données
• Répartition de charge et réplication de base de données
• Accès distant et administration
• Sauvegarde automatisée, supervision, journaux centralisés et alertes (versions 1.1 à 1.4)
• Détection d’intrusion : agents sur les machines et sonde réseau sur le pare-feu (version 1.5, premier périmètre)
• Stratégies de groupe du domaine, export des bases et copie hors site des sauvegardes (version 1.6)

Hors périmètre

1.3 Comment lire ce document

Ce document est autonome. Il se suffit à lui-même : aucun autre support n’est nécessaire pour comprendre l’architecture, ses choix et ses limites.

Il est volontairement dépourvu de lignes de commande et de copies d’écran : un document d’architecture décrit des choix et leurs conséquences, pas des gestes. Les termes techniques employés sont tous définis à l’annexe A.

Lecture rapide. Un lecteur pressé trouvera l’essentiel dans trois endroits : les six principes directeurs (§3.1), la matrice des flux (§6.3) et le bilan de disponibilité (§8.2).

2 · Contexte, objectifs et exigences

2.1 Contexte

L’infrastructure est hébergée sur un hyperviseur Proxmox VE mutualisé, accessible depuis le réseau de l’établissement. Elle doit être entièrement confinée : aucune trame issue du laboratoire ne doit atteindre le réseau hôte autrement que par un point de passage maîtrisé.

Le projet est conduit de façon incrémentale. Chaque brique est validée par un test tracé avant que la suivante ne soit entreprise, et seules les configurations vérifiées sont documentées.

2.2 Objectifs

2.3 Exigences fonctionnelles

2.4 Exigences non fonctionnelles

2.5 Contraintes

2.6 Hypothèses

• Le réseau de l’établissement fournit un accès Internet sortant et une passerelle stable.
• L’hyperviseur reste disponible ; sa sauvegarde n’est pas du ressort de ce document.
• Les postes utilisateurs du laboratoire sont des machines de confiance.

3 · Principes directeurs et vue d’ensemble

3.1 Les six principes directeurs

Ces principes ont guidé chaque arbitrage. Ils sont rappelés tout au long du document, aux endroits où ils ont tranché une décision.

P1 — Tout est interdit, sauf ce qui est explicitement autorisé

Le pare-feu applique un blocage implicite en fin de chaque jeu de règles. Aucune règle « autoriser tout » ne subsiste en production. Un flux non prévu ne passe pas — et il laisse une trace.

P2 — Une règle décrit un rôle, jamais une machine

Toutes les règles s’appuient sur des alias nommés (SRV_WEB, GALERA_NODES, PORTS_ADMIN…). Remplacer, ajouter ou renommer une machine ne modifie aucune règle : on modifie l’alias. Ce principe a été vérifié concrètement lors du changement de contrôleur de domaine : aucune règle n’a eu à être réécrite, seul le contenu d’un alias a changé.

P3 — La défense se construit en profondeur

Une protection unique est une protection fragile. L’accès à la base de données est contrôlé par trois verrous indépendants de natures différentes : réseau, pare-feu et applicatif (voir §6.5).

P4 — Ajouter un composant doit restreindre, pas élargir

L’introduction du répartiteur de charge en est l’illustration : avant, deux serveurs web joignaient la base ; après, une seule machine y accède. Une couche supplémentaire a réduit la surface exposée.

P5 — Rien n’est documenté qui n’ait été vérifié

Chaque élément présenté comme opérationnel l’est parce qu’un test l’a démontré. Ce qui n’a pas été testé porte le statut ou . Les écarts entre l’attendu et l’observé sont consignés au registre des incidents décrit au §9.4, pas corrigés silencieusement.

P6 — Un compromis se documente, il ne se cache pas

Les écarts par rapport à l’état de l’art sont enregistrés comme dettes techniques numérotées, avec leur motif, leur risque et leur voie de résolution (voir §10.2).

3.2 Vue d’ensemble

                    RÉSEAU DE L'ÉTABLISSEMENT  10.1.0.0/16
                                   │
                                   │  aucun flux entrant autorisé
                                   ▼
                     ┌───────────────────────────┐          ┌──────────────────┐
                     │   PARE-FEU  ·  pfSense    │◄─────────┤  Réseau overlay  │
                     │   routeur inter-VLAN      │  chiffré │  (administration │
                     │   DNS · DHCP · NTP        │          │   distante)      │
                     └─────────────┬─────────────┘          └──────────────────┘
                                   │ trunk 802.1Q
          ┌────────────┬───────────┴───────────┬──────────────┬──────────────┐
          ▼            ▼                       ▼              ▼              ▼
   ┌────────────┐ ┌────────────┐      ┌──────────────┐ ┌─────────────┐ ┌─────────────┐
   │  VLAN 10   │ │  VLAN 20   │      │   VLAN 30    │ │  VLAN 40    │ │  VLAN 50    │
   │    WEB     │ │    BDD     │      │     ADM      │ │   USERS     │ │  VISITEURS  │
   ├────────────┤ ├────────────┤      ├──────────────┤ ├─────────────┤ ├─────────────┤
   │ Répartiteur│ │  Cluster   │      │  Annuaire    │ │  Postes de  │ │  Invités :  │
   │     +      │ │  3 nœuds   │      │  Bastion     │ │  travail    │ │  Internet   │
   │ 2 serveurs │ │            │      │  Sauvegarde  │ │             │ │  seul       │
   │    web     │ │            │      │  Supervision │ │             │ │             │
   │            │ │            │      │  Détection   │ │             │ │             │
   └─────┬──────┘ └─────▲──────┘      └──────────────┘ └──────┬──────┘ └─────────────┘
         │              │                                     │
         └──────────────┘                                     │
            seul le répartiteur                               │
            atteint la base                   ────────────────┘
                                              les postes n'atteignent
                                              que le répartiteur

Lecture du schéma : les cinq zones ne communiquent qu’à travers le pare-feu. Les deux flèches représentent les seuls chemins applicatifs autorisés entre zones. Tout le reste est bloqué. La zone VISITEURS n’atteint aucune autre zone : seulement le DNS du pare-feu et Internet.

3.3 Le choix structurant : le routeur sur bâton

Les cinq VLAN sont portés par une seule interface physique de la machine pare-feu, découpée en sous-interfaces étiquetées 802.1Q.

   pfSense                                    Commutateur virtuel
   ┌──────────────────────┐                   ┌──────────────────┐
   │  vtnet1   (trunk)    │◄─── étiquetée ───►│   VLAN aware     │
   │    ├── vtnet1.10 ────┼── 10.0.10.1/24    │                  │
   │    ├── vtnet1.20 ────┼── 10.0.20.1/24    │  chaque VM reçoit│
   │    ├── vtnet1.30 ────┼── 10.0.30.1/24    │  un port "access"│
   │    ├── vtnet1.40 ────┼── 10.0.40.1/24    │  → elle ignore   │
   │    └── vtnet1.50 ────┼── 10.0.50.1/24    │    tout du VLAN  │
   └──────────────────────┘                   └──────────────────┘

La contrepartie, à énoncer clairement : le pare-feu devient un point de passage obligatoire. S’il tombe, les cinq zones sont isolées les unes des autres. C’est une conséquence directe du modèle, pas un défaut de mise en œuvre — et c’est la dette T-9 (voir §10.2).

Conséquence de conception à retenir : le trafic à l’intérieur d’un VLAN ne traverse pas le pare-feu — il est commuté. Aucune règle ne peut donc le filtrer. C’est ce qui explique que la réplication entre les trois nœuds de base de données ne nécessite aucune règle, et c’est aussi pourquoi le regroupement de machines dans un même VLAN est une décision de sécurité, pas de commodité.

4 · Architecture physique et virtualisation

4.1 Hyperviseur

Nœud unique. Proxmox sait fonctionner en grappe avec bascule automatique ; un seul serveur physique est disponible ici. Toute la redondance décrite dans ce document est donc logique : elle protège de l’arrêt d’un service ou d’une machine virtuelle, pas de la panne du serveur physique. Cette limite est explicite et constitue la dette T-9.

4.2 Commutation virtuelle

Deux commutateurs virtuels aux rôles volontairement disjoints :

vmbr1 n’a ni port physique ni adresse IP, et c’est le cœur du confinement.

• Aucune trame étiquetée ne peut atteindre le réseau de l’établissement : il n’y a pas de chemin physique pour cela.
• L’hyperviseur lui-même ne peut pas joindre les machines du laboratoire : il n’a pas d’adresse sur ce commutateur.
• Le seul équipement raccordé aux deux commutateurs est le pare-feu. Il est, par construction, le point de passage unique.

Le confinement n’est donc pas obtenu par une règle que l’on pourrait désactiver par erreur, mais par une propriété topologique. C’est une protection d’un ordre supérieur.

4.3 Inventaire des machines virtuelles

Infrastructure

Zone WEB — VLAN 10

Zone BDD — VLAN 20

Zone ADM — VLAN 30

Zone USERS — VLAN 40

Zone VISITEURS — VLAN 50

Synthèse : 15 machines en service, toutes supervisées et sauvegardées chaque nuit (sauf le serveur de sauvegarde lui-même, §8.4), avec une copie hors site de la dernière sauvegarde de chacune (05/11 : 14 machines copiées et relues sans erreur) ; 1 prévue (AD-Core-02). Trois machines portent déjà un agent de détection d’intrusion (§6.7) ; les autres suivront après une semaine de mesure du serveur. Le serveur de gestion de parc GLPI est en place depuis le 05/11 sur les deux serveurs web, sans nouvelle machine (§7.6).

Trois des machines en service sont des clones. srv-web-02, srv-mysql-02 et srv-mysql-03 ont été produites par duplication, puis individualisées par régénération de leurs cinq identités — nom, adresse, identifiant système, clés d’hôte et adresse matérielle. Les cinq identités à régénérer sur tout clone, et ce qu’un oubli provoque :

Identité	Conséquence si elle n’est pas régénérée
Nom de machine	Résolution du nom propre incohérente ; journaux indéchiffrables
Adresse IP	Conflit d’adresses — les deux machines deviennent instables
Identifiant système unique	Deux machines confondues par la journalisation et l’attribution d’adresses
Clés d’hôte de la session distante	Deux serveurs se présentent avec la même identité : l’authentification du serveur ne protège plus de rien
Adresse matérielle	Régénérée automatiquement par l’hyperviseur

Un clone n’est pas une nouvelle machine tant que ces identités n’ont pas été régénérées. Pour un nœud de base de données, s’y ajoute la purge des données héritées, afin que la synchronisation initiale les reconstruise depuis le nœud de référence.

4.4 Rattachement des machines au réseau

Deux modes de raccordement coexistent, et la distinction est fondamentale :

Le point de vigilance le plus fréquent. Une machine dont l’étiquette est mal renseignée se retrouve silencieusement dans la mauvaise zone. Dans les VLAN 40 et 50, l’erreur est immédiatement visible — la machine ne reçoit pas d’adresse dans la plage attendue. Dans les autres zones, où l’adressage est statique, elle ne se manifeste que par une absence de connectivité, beaucoup plus difficile à interpréter. Le contrôle de l’étiquette est donc le premier réflexe de diagnostic.

5 · Architecture réseau

5.1 Segmentation

Cinq zones, définies par niveau de sensibilité et non par service :

Pourquoi la base de données est seule dans sa zone. Le trafic interne à un VLAN n’est pas filtré. Placer un serveur web à côté des nœuds de base aurait rendu le pare-feu aveugle sur ce flux : il aurait été commuté directement, sans contrôle possible. La séparation web/base n’est donc pas une question d’organisation, c’est la condition pour que le flux soit filtrable.

5.2 Plan d’adressage

Principe

Un préfixe 10.0.0.0/8 découpé en sous-réseaux /24, où le troisième octet reprend l’identifiant du VLAN.

   10 . 0 . 20 . 10
             │    └── hôte
             └─────── numéro de VLAN

L’adresse devient auto-documentée : 10.0.20.11 se lit immédiatement « deuxième serveur de la zone base de données ». Cette lisibilité réduit directement le risque d’erreur lors de l’écriture des règles de filtrage — un bénéfice de sécurité, pas seulement de confort.

Convention d’attribution dans chaque sous-réseau

Tableau général

L’attribution dynamique n’est activée que dans les zones de postes (USERS et VISITEURS). Un serveur doit avoir une adresse prévisible : elle est inscrite dans des alias, des fichiers de configuration et des enregistrements de noms. Un poste de travail, non. Appliquer le même traitement aux deux serait une erreur de conception.

Conséquence opérationnelle : une machine nouvellement créée dans les zones 10, 20 ou 30 ne reçoit aucune adresse au démarrage. Ce n’est pas une panne — c’est le comportement attendu. L’adresse se saisit manuellement.

Détail du plan d’adressage

Le tableau complet, machine par machine, figure à l’annexe B.

5.3 Routage

Le pare-feu assure :

• le routage inter-VLAN entre les cinq sous-réseaux, soumis au filtrage de §6 ;
• la traduction d’adresses sortante vers le réseau de l’établissement, ce qui rend les adresses internes invisibles de l’extérieur ;
• la route par défaut pour l’ensemble des machines du laboratoire.

   VM du laboratoire ──► passerelle de sa zone (.1)
                            │
                            ├── destination dans une autre zone
                            │       → routage + filtrage
                            │
                            └── destination externe
                                    → traduction d'adresse → 10.1.0.254 → Internet

5.4 Services réseau

Résolution de noms

Décision d’architecture : une résolution centralisée sur le pare-feu.

   Machine du laboratoire
        │  serveur de noms = passerelle de sa zone  (une seule adresse, jamais modifiée)
        ▼
   Pare-feu · résolveur en mode relais
        │
        ├── nom interne  → réponse locale        (ex. www.sio.internal → le répartiteur)
        └── nom externe  → résolveurs publics    (1.1.1.1 · 8.8.8.8)

Pourquoi un seul serveur de noms est distribué aux postes, sans secours public.

Un résolveur public interrogé sur un nom interne ne reste pas silencieux : il répond que le nom n’existe pas. Un poste membre d’un domaine prend cette réponse pour définitive et n’essaie pas ailleurs. Ouvertures de session, stratégies de groupe et réplication deviennent alors intermittentes selon le résolveur interrogé — une panne déroutante, car elle n’est pas systématique.

La redondance n’est pas supprimée pour autant : elle remonte d’un étage. Les postes ne connaissent qu’une adresse ; c’est le pare-feu qui détient deux résolveurs amont et bascule de l’un à l’autre. Un changement de fournisseur se fait à un seul endroit.

Attribution dynamique d’adresses

Active sur les zones USERS et VISITEURS, plage .100 → .199. Les options distribuées désignent la passerelle de la zone comme routeur et comme serveur de noms.

Synchronisation horaire

Le pare-feu sert de référence de temps aux machines du laboratoire. Une horloge cohérente n’est pas un confort : l’authentification Kerberos refuse une dérive de plus de cinq minutes, et des journaux désynchronisés rendent toute corrélation d’incident impossible.

6 · Architecture de sécurité

6.1 Modèle de filtrage

Trois propriétés du moteur de filtrage déterminent l’écriture de toutes les règles. Les méconnaître conduit à des règles qui ne s’appliquent jamais.

① Les règles s’évaluent sur l’interface d’entrée

Une règle autorisant un flux de la zone 10 vers la zone 20 se place sur l’interface de la zone 10 — là où le paquet se présente. C’est l’erreur de débutant la plus fréquente, et elle produit un symptôme trompeur : la règle existe, elle est correcte, et pourtant rien ne passe.

② La première règle qui correspond l’emporte

L’ordre est signifiant. Une règle de rejet placée avant une règle d’autorisation annule cette dernière. Les jeux de règles sont donc ordonnés du plus spécifique au plus général, et une règle de rejet explicite ferme chaque zone avant les autorisations générales.

③ Le filtrage est à états

Seul le premier paquet d’une connexion est évalué. Les réponses sont automatiquement admises. Aucune règle de retour n’est nécessaire — en écrire une révèle une incompréhension du modèle.

Blocage implicite

En l’absence de règle correspondante, le paquet est rejeté silencieusement. Chaque zone se termine donc, de fait, par une interdiction totale.

6.2 Rejet ou blocage : un choix qui se raisonne

Deux manières d’interdire, aux effets très différents :

Le raisonnement. Face à l’extérieur, le silence est préférable : il ne confirme pas l’existence de la machine et ralentit un balayage. À l’intérieur, le silence est nuisible — il transforme une erreur de configuration en attente inexpliquée, et fait perdre un temps considérable en diagnostic.

Ce choix a une vertu inattendue : le type d’échec devient un outil de diagnostic. Un refus immédiat désigne une règle de rejet interne ; une attente qui expire désigne un blocage implicite, donc une règle manquante. Deux causes distinctes, discernables sans consulter aucun journal.

6.3 Matrice des flux autorisés

Deux niveaux de lecture : une vue de synthèse zone à zone, puis le détail règle par règle.

6.3.1 Vue de synthèse

« journaux » : l’envoi des journaux vers le seul serveur srv-supervision, port 514. « agents » (03/11) : l’envoi des événements de sécurité vers le seul serveur srv-wazuh, ports 1514 (événements) et 1515 (enrôlement) ; en zone VISITEURS, le poste de test seul : les appareils des invités n’ont pas d’agent. « sonde d’état » (05/11) : le répartiteur seul interroge, sur le port 9200 de chaque nœud, l’état de synchronisation du nœud (§7.3). La copie hors site des sauvegardes (05/11) sort de la zone ADM vers Internet en HTTPS (443), par la règle de sortie déjà en place : aucune règle ajoutée.

Les cinq enseignements de cette matrice :

6.3.2 Détail des règles, zone par zone

Les règles sont présentées dans leur ordre d’évaluation, qui est signifiant. Les noms en majuscules sont des alias ; <zone> réseau désigne l’ensemble du sous-réseau, <zone> passerelle la seule adresse du pare-feu sur cette interface.

Zone USERS — VLAN 40

Zone VISITEURS — VLAN 50 (30/10)

Le refus vise tous les réseaux privés et non les seules zones du lab : sans cela, la règle 5 laisserait un visiteur joindre en web les machines de l’établissement, hyperviseur compris.

Zone WEB — VLAN 10

Zone BDD — VLAN 20

Zone ADM — VLAN 30

Interface externe

Une seule règle entrante active, depuis le 15/10 : la redirection de port vers le serveur de sauvegarde.

Tout autre flux venant du réseau de l’établissement reste bloqué par l’interdiction implicite. L’ouverture est la plus étroite possible : une source, un port, une destination.

6.3.3 Trois motifs de conception visibles dans ces tables

① Le motif « autorisations ciblées, rejet, sortie large ». Chaque zone suit la même structure : des autorisations précises, puis un rejet de tout l’interne, puis une autorisation de sortie vers l’extérieur. La règle de sortie vise une destination quelconque — qui engloberait les réseaux internes — mais le rejet les a déjà interceptés. Le rejet intermédiaire est ce qui donne son sens à la règle large qui suit.

② Les règles critiques sont écrites d’hôte à hôte, pas de réseau à réseau. L’accès à la base n’est pas accordé à la zone WEB mais au répartiteur seul. Une machine ajoutée demain dans cette zone n’y aura pas accès. C’est l’application concrète du moindre privilège — et la différence est invisible tant qu’on ne lit pas la colonne Source.

③ L’ordre n’est pas cosmétique. La règle de résolution de noms doit précéder le rejet : l’adresse de la passerelle appartient au réseau interne, le rejet l’intercepterait. Sans cette précaution, les machines obtiennent une adresse, atteignent Internet par adresse IP, mais ne résolvent plus aucun nom — une panne classique et déroutante.

Le journal n’est activé que sur les règles de rejet. Journaliser les flux autorisés saturerait les journaux sans rien apprendre. Journaliser les refus produit exactement ce qui est utile : la trace de ce qui a été empêché.

Une matrice ne vaut que par ses tests. Chaque cellule du tableau est vérifiable, et les cellules critiques l’ont été, journal du pare-feu à l’appui. Un pare-feu qui laisse tout passer fonctionne aussi : ce qui prouve qu’il travaille, c’est un flux refusé, tracé.

6.4 Accès distant et administration

Principe

Aucun port n’est ouvert depuis l’extérieur. L’accès distant repose sur un réseau overlay chiffré, établi par une connexion sortante du pare-feu.

   Poste d'administration distant
        │
        │  tunnel chiffré, établi de l'intérieur vers l'extérieur
        ▼
   Pare-feu  ──► routage vers les zones internes

Le bastion

À l’intérieur, l’administration transite par une machine unique de la zone ADM, qui héberge des passerelles web vers SSH et RDP.

Les trois façons de rebondir par un bastion

Un point souvent traité à la légère, alors qu’il détermine la valeur réelle du bastion :

Avec le rebond natif, le bastion est un relais réseau, pas un intermédiaire de confiance. Il relaie un flux déjà chiffré : il constate qu’une connexion a lieu et vers où, sans accéder à son contenu. Aucune clé privée n’y est déposée.

C’est exactement le niveau de confiance qu’il faut accorder à un bastion : il réduit la surface d’attaque à une machine, il ne doit pas concentrer les secrets. Le contrôle se vérifie simplement — l’inventaire des fichiers de clés du bastion doit être vide.

Dette assumée — le réseau overlay traverse la segmentation. Le poste raccordé au réseau chiffré joint les cinq zones sans passer par le bastion, et sans que les règles inter-VLAN s’appliquent. C’est commode en exploitation et contraire au principe P1. La dette T-6 le documente, et sa résolution — restriction par listes de contrôle côté overlay — est identifiée.

6.5 Défense en profondeur : les trois verrous de la base de données

Illustration du principe P3. L’accès aux données est protégé par trois mécanismes de natures différentes, à trois couches différentes.

   ┌─────────────────────────────────────────────────────────────┐
   │  VERROU 1 — RÉSEAU        Le service n'écoute que là où     │
   │                           c'est nécessaire                  │
   ├─────────────────────────────────────────────────────────────┤
   │  VERROU 2 — PARE-FEU      Une seule machine est autorisée   │
   │                           à atteindre le port               │
   ├─────────────────────────────────────────────────────────────┤
   │  VERROU 3 — APPLICATIF    Le compte n'est accepté que       │
   │                           depuis une origine précise        │
   └─────────────────────────────────────────────────────────────┘

La valeur de l’empilement est dans la diversité des natures. Trois verrous de même nature tombent ensemble. Ici, franchir le verrou réseau n’aide en rien face au pare-feu, et franchir le pare-feu n’aide en rien face au contrôle applicatif. Une erreur de configuration sur un verrou ne compromet pas l’ensemble — c’est précisément ce qu’on attend d’une défense en profondeur.

Le verrou 1 a dû être assoupli pour la mise en cluster : la réplication impose au service d’écouter sur plusieurs ports et plusieurs interfaces. C’est la dette T-7. Elle est compensée par le fait que les trois nœuds sont seuls dans leur zone et que les verrous 2 et 3 restent entiers. Le compromis est documenté comme tel, pas dissimulé.

La sonde d’état des nœuds (05/11, §7.3) suit la même logique, sur un second port (9200) : le pare-feu ne l’ouvre qu’au répartiteur, chaque nœud n’accepte de répondre qu’au répartiteur et à lui-même, et la sonde lit l’état du nœud par un accès local, sans aucun compte de base ni mot de passe. Le compte de base qu’utilisait l’ancien contrôle du répartiteur, devenu inutile, a été supprimé : un compte de moins à protéger.

6.6 Protection contre les tentatives répétées

L’interface d’administration du pare-feu applique un blocage automatique après plusieurs échecs d’authentification, avec une durée croissante à chaque récidive.

Limite opérationnelle constatée : la liste d’exemption n’accepte que des adresses explicites, pas des alias. Elle est donc à tenir manuellement — et le poste d’administration doit y figurer, faute de quoi une erreur de mot de passe peut verrouiller l’accès pendant plusieurs minutes. Le secours reste la console de l’hyperviseur, qui ne dépend d’aucune règle réseau.

6.7 Détection d’intrusion (03/11, premier périmètre)

Le filtrage (§6.1 à 6.3) et les alertes de supervision (§9.2) disent ce qui est bloqué et ce qui est en panne. Ils ne disent pas qu’une machine est attaquée quand rien ne casse : un fichier système modifié, un compte créé, une rafale de connexions, un balayage. Deux dispositifs complémentaires y répondent, choisis après comparaison (dossier de choix, phase 16) :

Principes appliqués :

Prévenir (03/11) : les alertes graves de Wazuh (niveau 10 ou plus, et toute création de compte) partent par mail, par le même circuit que les pannes ; les alertes réseau de Suricata arrivent dans Wazuh (un seul écran d’enquête) et, si leur priorité est haute ou moyenne, par mail aussi. Le tableau de bord de production affiche les alertes en cours et les dernières intrusions. Chaque maillon a été prouvé par une attaque simulée, jusqu’au mail reçu.

Ce qui reste (§10.1) : les agents sur les douze autres machines après la semaine de mesure.

Limite assumée : la détection ne bloque rien. Un blocage automatique sur des cartes virtuelles n’a pas été vérifié, et un faux positif couperait un service ; la réponse reste humaine, guidée par l’alerte.

6.8 Machines Windows : stratégies de groupe et antivirus (04-05/11)

Stratégies de groupe (05/11). Deux stratégies de la partie ordinateur, liées à l’unité d’organisation des postes du domaine sio.internal (OU=Ordinateurs,OU=SIO) ; les stratégies par défaut du domaine ne sont pas modifiées : une stratégie par sujet, que l’on peut suspendre sans toucher au reste du domaine. Le contrôleur de domaine, rangé à part, n’est pas concerné.

Les trois règles locales du poste qui acceptaient déjà le ping ont été désactivées : la stratégie est la seule source de la réponse au ping. Posées et vérifiées en PowerShell à distance (le contrôleur est en Server Core, sans console graphique), les deux stratégies sont prouvées : bannière vue à l’écran de connexion, ping accepté depuis la zone ADM, puis refusé quand la plage autorisée est rétrécie à la seule zone USERS (contre-épreuve).

Un effet constaté ne prouve pas qu’une stratégie fonctionne. Le ping passait déjà avant elle, grâce à des règles locales oubliées. Seul le test fait après leur désactivation, avec une seule règle active venue de l’annuaire, et la contre-épreuve sur la plage, prouvent que c’est la stratégie qui décide.

Non vérifié : ce qui reste écrit sur le poste quand une stratégie est retirée — À COMPLÉTER.

Antivirus (04/11). Sur les deux machines Windows (contrôleur de domaine et poste de référence), l’analyse rapide planifiée de l’antivirus intégré (Defender) passe de quotidienne à tous les 15 jours, par une tâche planifiée du lab placée après les sauvegardes de la nuit ; la protection en temps réel et la mise à jour des signatures sont inchangées. Motif : l’antivirus est le processus qui écrit le plus sur ces deux machines, dont les écritures grossissent la sauvegarde de chaque nuit ; pour un laboratoire, une analyse tous les 15 jours suffit (décision d’Axel). Effet sur les sauvegardes : à mesurer sur les nuits suivantes — À COMPLÉTER. L’antivirus et la détection d’intrusion (§6.7) ne font pas doublon : le premier reconnaît et bloque un fichier malveillant, la seconde observe et corrèle les événements.

7 · Architecture applicative

7.1 Vue d’ensemble de la chaîne

   Poste utilisateur  (VLAN 40)
        │  HTTPS
        ▼
   ┌───────────────────────── VLAN 10 — WEB ──────────────────────────┐
   │                                                                   │
   │   RÉPARTITEUR  10.0.10.5                                          │
   │   · termine le chiffrement                                        │
   │   · aiguille selon le chemin demandé                              │
   │                                                                   │
   │        ├── administration du site ──────► srv-web-01   (seul)     │
   │        │                                       │                  │
   │        ├── pages publiques ─── alternance ──► srv-web-01          │
   │        │                                  └─► srv-web-02          │
   │        │                                       ▲                  │
   │        │                   synchronisation ────┘                  │
   │        │                   des fichiers, sens unique              │
   │        │                                                          │
   │        └── accès base de données  10.0.10.5:3306                  │
   └────────────────────────────┬──────────────────────────────────────┘
                                │  seuls flux autorisés vers la zone BDD
                                │  (base 3306 et sonde d'état 9200, répartiteur seul)
   ┌────────────────────────────▼────────── VLAN 20 — BDD ─────────────┐
   │   srv-mysql-01  ◄══╗                                              │
   │   srv-mysql-02  ◄══╬══  réplication synchrone, interne à la zone  │
   │   srv-mysql-03  ◄══╝                                              │
   └───────────────────────────────────────────────────────────────────┘

Contenu du site (05/11). Le site joue le rôle du site de GSB (Galaxy Swiss Bourdin), l’entreprise du cas d’étude du cours : une partie publique qui présente l’entreprise, ouverte à tous, et un intranet INTRALAB réservé aux comptes connectés (une personne non connectée est renvoyée vers la page de connexion, vérifié sur les deux serveurs web). Le contenu vient uniquement de la fiche GSB du formateur et chaque page porte la mention d’un site de démonstration. Mis en place sans aucune extension ni thème téléchargé. Ouverture de l’intranet avec un compte collaborateur : aucun compte de ce type n’existe encore — À COMPLÉTER.

7.2 Le répartiteur de charge

Rôle et positionnement

Le répartiteur est le point d’entrée unique de la chaîne applicative. Il assure quatre fonctions :

Le répartiteur réduit la surface exposée

Illustration du principe P4, et c’est le point à retenir de cette section :

Ajouter un composant a restreint les autorisations au lieu de les élargir. C’est contre-intuitif et c’est le signe d’une bonne position dans l’architecture.

Terminaison du chiffrement

Le chiffrement s’arrête au répartiteur ; le dialogue avec les serveurs web se fait en clair, à l’intérieur de la zone WEB.

Le piège classique de ce montage, rencontré ici. Le serveur web reçoit une requête en clair et en conclut que le visiteur est en clair ; il le redirige donc vers la version chiffrée… que le répartiteur lui retransmet en clair. Boucle infinie.

La solution canonique : le répartiteur ajoute un en-tête indiquant le protocole d’origine, et l’application est configurée pour en tenir compte. C’est une adaptation obligatoire, pas une option — toute application placée derrière un répartiteur avec terminaison doit la recevoir.

Aiguillage de l’administration

Les requêtes d’administration du site sont dirigées vers un seul serveur, les autres sont réparties.

Pourquoi cette asymétrie est nécessaire. Les contenus déposés par un administrateur (médias, extensions) sont écrits sur le disque local du serveur qui traite la requête. Si l’administration était répartie, un fichier déposé sur un serveur serait absent de l’autre, et le site se comporterait différemment selon le serveur qui répond — un défaut intermittent, donc difficile à diagnostiquer.

Épingler l’administration sur un nœud garantit une source unique pour les fichiers. C’est aussi ce qui rend possible une synchronisation à sens unique, bien plus simple et plus sûre qu’une synchronisation bidirectionnelle, qui exigerait de résoudre des conflits.

Les deux décisions se tiennent : l’épinglage justifie le sens unique, et le sens unique impose l’épinglage.

Supervision intégrée

Le répartiteur expose une page d’état donnant, en temps réel, la santé de chaque serveur, le nombre de connexions et l’historique des bascules. Elle constitue le premier niveau de supervision de l’infrastructure (voir §9.2).

7.3 Le cluster de bases de données

Nature de la solution

Un point d’architecture régulièrement mal compris. Le cluster n’est pas une machine : c’est une bibliothèque de réplication activée par configuration sur chaque nœud. Les trois serveurs dialoguent en pair-à-pair, sans aucun intermédiaire.

La différence avec le répartiteur est instructive : le répartiteur intercepte le trafic, il lui faut donc exister sur le chemin — d’où une machine dédiée. Le cluster coordonne des serveurs entre eux — il n’y a rien à placer au milieu.

Réplication synchrone

Garantie obtenue : il n’existe à aucun moment de nœud « en retard ». Une lecture sur n’importe quel nœud renvoie la même donnée. C’est ce qui permet la bascule sans précaution particulière.

Répartir n’est pas basculer

La décision d’architecture la plus importante de cette section.

Le trafic web se répartit : les requêtes sont indépendantes, n’importe quel serveur peut traiter n’importe laquelle.

Le trafic base de données, lui, est configuré en bascule : un nœud actif, deux en attente. Techniquement, les trois pourraient recevoir des écritures — mais des écritures concurrentes sur plusieurs nœuds provoquent des rejets de transaction au moment de la certification, que l’application ne sait généralement pas gérer.

Un même cluster, deux usages, deux configurations différentes. Répartir là où c’est bénéfique, basculer là où la répartition nuirait.

Quorum et protection contre la divergence

Le mécanisme qui justifie à lui seul le choix de trois nœuds.

   3 nœuds, le réseau se coupe en deux :

   ┌─ 1 nœud ─┐                    ┌─ 2 nœuds ─┐
   │   33 %   │   ╳   coupure      │    67 %   │
   │ MINORITÉ │                    │ MAJORITÉ  │
   │ se tait  │                    │ continue  │
   └──────────┘                    └───────────┘

Un groupe ne travaille que s’il détient strictement plus de la moitié des nœuds. Le côté minoritaire refuse les requêtes, même s’il est en parfait état de marche.

Le raisonnement, et c’est contre-intuitif. Le nœud isolé possède les données et fonctionne. Il refuse quand même, parce qu’il ne peut pas distinguer « les autres sont morts » de « les autres sont injoignables ». S’il acceptait des écritures et que les autres en acceptaient aussi, les deux versions de la base divergeraient irrémédiablement.

Le système préfère l’indisponibilité à l’incohérence. C’est un arbitrage explicite, et c’est aussi la réponse à « pourquoi trois nœuds et pas deux » : avec deux, aucun côté n’a la majorité, et la perte d’un seul nœud arrête tout. Un nombre impair est la règle.

Synchronisation d’un nœud

Deux mécanismes, selon l’écart à rattraper :

C’est le mécanisme complet qui permet d’ajouter un nœud sans aucune copie manuelle : on le démarre, il se remplit seul.

Ne confier l’application qu’à un nœud synchronisé (05/11)

Pendant une synchronisation, ou s’il est coupé du groupe, un nœud répond sans avoir les mêmes données que les autres. Le contrôle d’origine du répartiteur (une simple connexion au service de base) ne voyait pas la différence : il aurait pu lui confier l’application.

Chaque nœud expose désormais une sonde d’état (HTTP, port 9200) qui ne répond « bon » que si le nœud est synchronisé ; le répartiteur l’interroge et retire le nœud dès que la réponse change. La sonde est un petit script écrit pour le laboratoire, sans logiciel téléchargé ni compte de base de données (voir §6.5 pour sa protection).

Le contrôle répond désormais à la bonne question. L’ancien demandait « le service tourne-t-il ? », le nouveau « ce nœud a-t-il les mêmes données que les autres ? ». Un nœud qui tourne mais qui est en retard est pire qu’un nœud éteint : il répond avec des données périmées.

Prouvé en sortant volontairement un nœud de secours de l’état synchronisé, sans l’arrêter (le service répondait toujours) : le répartiteur l’a déclaré hors service, le site est resté servi, puis le nœud est revenu dès sa resynchronisation. Ce changement termine la phase de haute disponibilité (05/11).

7.4 Synchronisation des contenus web

Les fichiers déposés par l’administration sont répliqués du serveur de référence vers le second, en sens unique, par surveillance du système de fichiers.

Le confinement de la clé est le point de sécurité de cette section. Une clé d’automatisation est par nature sans phrase de passe : si elle était compromise, elle donnerait un accès complet au serveur cible. En la restreignant à une commande unique et à une arborescence précise, on ramène la portée d’une compromission à l’écriture dans un seul répertoire.

La restriction se valide par un test d’évasion : on tente, depuis le serveur source, d’écrire hors du répertoire autorisé. Le comportement attendu n’est pas un refus mais une réécriture du chemin vers l’intérieur de l’arborescence permise — le résultat est équivalent, et c’est ce qu’il faut vérifier pour affirmer que le confinement tient.

Incident du 29/10 au 05/11, et ce qu’il a changé. La synchronisation s’était arrêtée le 29/10 (cible injoignable au démarrage, puis abandon), alors que le gestionnaire de services l’affichait toujours active : le second serveur web n’était plus mis à jour, sans que rien ne le signale. Corrigée le 05/11 (nouvelles tentatives au lieu de l’abandon), elle est désormais surveillée : la présence du processus est mesurée chaque minute, et une règle d’alerte (§9.2) prévient s’il manque cinq minutes, ou si la mesure elle-même disparaît. Testé par un arrêt réel, mail reçu. Leçon : l’état affiché d’un service ne prouve pas qu’il travaille ; seul le processus le dit.

7.5 Services d’annuaire

Décision du 01/10/2026 : installation en mode Server Core uniquement.

Contrainte technique à connaître. Le mode d’installation d’un Windows Server est définitif depuis l’édition 2016 : une installation graphique ne se convertit pas en Server Core. Le choix se fait à l’installation, ou il faut réinstaller.

7.6 Gestion de parc et assistance : GLPI

Besoin — La mission « Assistance » du cas GSB demande un outil de gestion de parc et de tickets. Il est posé sur l’architecture existante, comme le prévoyait l’avis du formateur : interface par le répartiteur et les deux serveurs web, base dans le cluster. Une seconde application sur le même cluster en fait un service mutualisé.

Démontré le 05/11 : connexion depuis le poste utilisateur ; comptes par défaut changés ; bascule réelle — serveur actif arrêté, retiré par le répartiteur en 7 s, l’utilisateur reste connecté et retrouve son ticket et sa pièce jointe sur le serveur de secours. GLPI est supervisé comme les autres services (disponibilité, temps de réponse, alerte) et sa base fait partie de l’export nocturne.

Incident pendant l’installation : le site GLPI, ajouté sur les serveurs web, est devenu leur site par défaut ; le site de GSB, qui ne déclarait pas son nom public, n’était plus servi : administration du site indisponible 18 min, site public interrompu environ 43 s. Corrigé en déclarant le nom du site. Leçon : sur un serveur à plusieurs sites, chacun déclare tous ses noms. Le fait qu’un serveur retiré par le répartiteur ne déclenche aucune alerte tant que l’autre sert est noté comme point à corriger (§10.2).

Complété le 06/11

Procédures : MO-21 (GLPI), MO-18 (inventaire d’une nouvelle machine), MO-23 (alertes → tickets).

8 · Haute disponibilité et continuité de service

8.1 Niveaux de redondance atteints

8.2 Points de défaillance résiduels

   ┌──────────────── CE QUI EST REDONDÉ ────────────────┐
   │                                                     │
   │   Serveur web        perte d'1 nœud sur 2         │
   │   Base de données    perte d'1 nœud sur 3         │
   │                                                     │
   └─────────────────────────────────────────────────────┘

   ┌───────────── CE QUI NE L'EST PAS ───────────────────┐
   │                                                      │
   │   Répartiteur        son arrêt coupe tout le site  │
   │   Pare-feu           son arrêt isole les 5 zones   │
   │   Contrôleur AD      son arrêt bloque les ouvertures│
   │   Hyperviseur        son arrêt arrête tout         │
   │                                                      │
   └──────────────────────────────────────────────────────┘

L’honnêteté de ce bilan est délibérée, et elle vaut mieux qu’un schéma flatteur.

L’architecture a déplacé les points de défaillance, elle ne les a pas tous supprimés. Le répartiteur en est l’exemple parfait : il rend les serveurs web redondants, et devient lui-même le nouveau point unique. C’est le paradoxe inhérent à toute solution de répartition — et la raison pour laquelle, en production, un répartiteur se déploie toujours en paire avec une adresse flottante.

Savoir où sont ses points de défaillance et pouvoir les énoncer est un meilleur indicateur de maîtrise qu’une architecture présentée comme sans faille.

Voies de résolution identifiées

8.3 Comportement attendu en cas de panne

La bascule n’est jamais instantanée. Un répartiteur ne déclare un serveur hors service qu’après l’échec d’une sonde. Une requête émise pendant cette fenêtre peut échouer. C’est le comportement normal de tout système à sondes — pas un défaut de configuration — et il doit être énoncé tel quel dans un engagement de service.

8.4 Sauvegarde

Une réplication n’est pas une sauvegarde, et la confusion est fréquente.

La réplication protège d’une panne. Elle ne protège pas d’une erreur : une suppression accidentelle de table est répliquée sur les trois nœuds en quelques millisecondes, fidèlement et irrémédiablement.

Seule une sauvegarde antérieure à l’erreur, et conservée hors du cluster, permet de revenir en arrière. C’est le rôle de l’export logique (05/11) : un fichier par base et par nuit, qui se restaure base par base sur n’importe quel serveur, là où la sauvegarde d’une machine oblige à restaurer un nœud entier. Les deux se complètent.

La règle 3-2-1, et pourquoi la copie hors site. Trois exemplaires des données, sur deux supports distincts, dont un hors du site. Jusqu’au 05/11, toutes les sauvegardes étaient dans l’établissement : un sinistre sur place emportait les machines et leurs sauvegardes. La copie hors site comble ce manque.

Choix de la technique : un stockage S3 rattaché directement au serveur de sauvegarde (fonction stable depuis sa version 4.2) plutôt qu’un disque distant monté à travers Internet (lent et fragile pour des milliers de petits fichiers, et il aurait fallu exposer un partage) ou qu’un second serveur de sauvegarde (une machine de plus à maintenir). N’importe quel serveur de sauvegarde peut rattacher ce stockage pour restaurer. Le serveur S3 retenu (SeaweedFS) est libre, installable depuis le catalogue du NAS ; MinIO, passé en maintenance, a été écarté.

Une copie hors site ne vaut que si elle est relisible : c’est la relecture de chaque morceau, empreinte comprise, qui la prouve, pas le simple « envoi réussi ».

Risques acceptés (décision d’Axel, 05/11) : le stockage S3 est joignable depuis tout Internet, sans liste d’adresses autorisées — il reste protégé par ses clés d’accès (refus sans clé prouvé) et par HTTPS ; un vol des clés permettrait d’effacer la copie hors site, pas les sauvegardes de l’établissement. L’interface d’administration du serveur S3 est aussi publiée : à retirer, décision en attente — À COMPLÉTER.

9 · Exploitation

9.1 Administration

La console de l’hyperviseur ne dépend d’aucune règle de filtrage, d’aucun service réseau et d’aucune clé. C’est le seul accès qui survit à une erreur de configuration du pare-feu — et la raison pour laquelle on peut durcir sans crainte. Toute opération risquant de couper l’accès réseau se prépare en gardant cette console ouverte.

9.2 Supervision

Le compteur de connexions actives est l’outil de diagnostic le plus sous-estimé du pare-feu. Il répond immédiatement à la question « mon paquet est-il seulement arrivé ? ». Si le compteur ne bouge pas, le problème est en amont — mauvaise étiquette VLAN, mauvaise passerelle, mauvaise adresse — et chercher dans les règles est une perte de temps.

9.3 Procédures d’exploitation récurrentes

Quatre opérations reviennent au cours de la vie de l’infrastructure. Leurs points de vigilance sont rappelés ici ; ils suffisent à mener l’opération sans se tromper.

Ajouter une machine par clonage

Ajouter un nœud au cluster de bases de données

Modifier la configuration du répartiteur

Gérer les accès par clé

9.4 Gestion des incidents

Tout incident est consigné selon une trame constante : symptôme observé, cause réelle, démarche de diagnostic, correction, enseignement. Le registre compte à ce jour une quarantaine d’entrées.

Ce registre n’est pas une liste de pannes, c’est un capital. Les méthodes de diagnostic qui en ont été dégagées sont réutilisables bien au-delà des incidents qui les ont fait naître :

Méthode	Ce qu’elle permet
Distinguer un refus immédiat d’une attente qui expire	Identifier une règle de rejet explicite plutôt qu’une règle manquante, sans ouvrir un journal
Vérifier si le compteur de connexions bouge	Savoir si le paquet est seulement arrivé jusqu’au pare-feu
Contrôler sur quelle adresse un service écoute	Écarter une fausse piste de filtrage
Identifier quel composant gère réellement une interface	Éviter de modifier un fichier qu’aucun service ne lit
Vérifier d’où part réellement un test	Un test lancé depuis la mauvaise machine ne prouve rien
Lire ce qu’une commande dit avoir fait	La moitié des diagnostics tiennent dans un message déjà affiché

Un piège transversal mérite d’être retenu : une erreur signalée par une application n’a pas la même signification qu’une erreur réseau de même libellé. Une « expiration de connexion » affichée par un client peut n’être qu’un identifiant périmé. Confondre les deux conduit à chercher une règle de pare-feu qui n’a jamais été en cause.

10 · Trajectoire d’évolution et dettes techniques

10.1 Évolutions planifiées

10.2 Registre des dettes techniques

Dettes soldées

Dettes ouvertes

Décisions dérogatoires assumées (05/11)

Pourquoi ce registre figure dans le document d’architecture, et non en annexe technique.

Une dette technique n’est pas une erreur : c’est un choix délibéré, daté et motivé, dont on connaît le coût et la voie de sortie. Ce qui distingue une infrastructure maîtrisée d’une infrastructure subie n’est pas l’absence de compromis — il n’en existe aucune sans — mais le fait que les compromis soient recensés et argumentés.

Trois dettes ont été soldées, treize restent ouvertes, dont une est explicitement non résoluble et compensée par d’autres moyens.

11 · Annexes

Annexe A — Glossaire

Annexe B — Plan d’adressage récapitulatif

Annexe C — Ports et services

Les trois ports de réplication ne font l’objet d’aucune règle de filtrage. Les nœuds étant dans la même zone, leur trafic est commuté et ne traverse jamais le pare-feu. Ils sont néanmoins documentés et regroupés dans un alias, pour deux raisons : une règle serait immédiatement disponible si les nœuds venaient à être répartis sur plusieurs zones, et un lecteur doit pouvoir constater que ces flux ont été identifiés, pas oubliés.

Annexe D — Correspondance exigences / tests

Un test à résultat négatif vaut autant qu’un test à résultat positif. La ligne ENF-1 — un poste utilisateur qui n’atteint pas la base de données — est la preuve que le pare-feu travaille. Un équipement qui laisse tout passer satisferait toutes les autres lignes de ce tableau.

Un résultat de blocage n’est retenu comme preuve que s’il est accompagné de sa ligne de journal : sans elle, rien ne distingue un flux refusé d’un service simplement arrêté.

Fin du document — DAT-SIO-2526-01 v1.9