Rapport : laboratoire d'infrastructure sécurisée

octobre 2026 · OPNsense · Active Directory · Debian · Zabbix · VMware

Projet de titre RNCP 6 : une petite infrastructure d'entreprise virtualisée, cloisonnée en zones, durcie, supervisée, puis éprouvée par des incidents simulés.

Contexte et objectifs

Reproduire, sur un seul poste, l'infrastructure d'une petite entreprise et la sécuriser de bout en bout : séparation des zones réseau, annuaire centralisé, serveur Linux durci, supervision, puis traitement d'incidents avec un dossier de preuves.

Période: août à octobre 2026
Cadre: Projet de titre RNCP 6 « Administrateur d’Infrastructures Sécurisées »
Plateforme: 5 machines virtuelles sous VMware Workstation

Architecture

Le pare-feu OPNsense sépare le réseau interne (LAN) de la zone exposée (DMZ).

OPNsense : pare-feu et routeur entre les zones, règles de filtrage explicites
Windows Server 2025 : Active Directory, DNS et DHCP pour le réseau interne
Windows 11 : poste client joint au domaine, qui reçoit les GPO
Debian 13 : serveur durci
Zabbix : supervision des machines et des services

Mise en œuvre

Le pare-feu applique une règle simple : tout est refusé par défaut, puis seuls les flux utiles sont ouverts. La DMZ ne peut pas initier de connexion vers le LAN : si un serveur exposé est compromis, l'attaquant reste enfermé dans sa zone.

Côté Windows, le contrôleur de domaine centralise les comptes et distribue les adresses et les noms. Les stratégies de groupe (GPO) sont appliquées et vérifiées sur le poste Windows 11.

Le serveur Debian est durci : connexion SSH interdite au compte root, pare-feu actif et journalisé.

# /etc/ssh/sshd_config (extrait)
PermitRootLogin no

# pare-feu : on refuse tout, on ouvre SSH, on journalise
ufw default deny incoming
ufw allow 22/tcp
ufw logging on
ufw enable

Tests et résultats

Une connexion de la DMZ vers le LAN est bloquée par OPNsense, et le blocage apparaît dans les journaux
Les GPO sont bien appliquées sur le poste Windows 11 du domaine
Une tentative de connexion SSH en root sur le serveur Debian est refusée
Zabbix remonte l’état des machines et alerte en cas de problème

Incidents simulés

Des incidents ont été provoqués volontairement puis traités comme en entreprise : détection, analyse, correction, puis un dossier de preuves (captures, journaux) et un retour d'expérience pour ne pas reproduire l'erreur.

Ce que j’en retiens

Le cloisonnement réseau limite fortement l’impact d’une compromission
Un test qui prouve le blocage vaut mieux qu’une règle qu’on suppose efficace
La documentation et les preuves font partie du travail, pas d’un « après »