Présentation du projet

Contexte de l'entreprise

NexaGroup est une ESN (Entreprise de Services du Numérique) fondée en 2015, spécialisée dans le développement web, l'intégration de solutions métier et le conseil en transformation digitale. L’entreprise compte 75 collaborateurs répartis sur deux sites :

• Site principal — Paris : siège social, 55 salariés, hébergeant l’infrastructure principale.
• Site secondaire — Lyon : antenne régionale, 20 salariés, reliée au siège via VPN site-à-site.

Enjeux et objectifs du projet

Dans un contexte de croissance et de montée en criticité des services numériques, NexaGroup a engagé un projet de modernisation de son infrastructure. Les principaux objectifs sont :

• Assurer la haute disponibilité des services cœur (authentification, données, supervision) via des mécanismes de redondance.
• Renforcer la sécurité par une segmentation fine en VLAN et un contrôle centralisé des flux réseau.
• Améliorer la visibilité et la supervision de l’infrastructure (alertes, tableaux de bord, corrélation d’événements).
• Fournir des services collaboratifs modernes (partage de fichiers, visioconférence, helpdesk) aux équipes internes.

Périmètre de la solution mise en œuvre

Le projet couvre l’infrastructure réseau et serveurs des deux sites (Paris et Lyon), incluant le routage, la sécurité périmétrique, les services Active Directory, la supervision et les outils collaboratifs internes.

Environnement technique

Architecture réseau

L’architecture réseau de NexaGroup est conçue autour d’un cœur redondé basé sur un cluster de pare-feux pfSense HA. Elle s’appuie sur une segmentation par VLAN afin d’isoler les usages (serveurs, postes clients, DMZ, administration et site distant) et de maîtriser les flux inter‑zones.

Vue logique des zones

Plan d'adressage IP

Principes de routage et de flux

• Tout le trafic inter‑VLAN transite par le cluster pfSense (routage + filtrage L3/L4).
• Les flux entre VLAN 20 / 60 (postes) et VLAN 10 (serveurs) sont limités aux ports applicatifs nécessaires.
• La DMZ (VLAN 30) est isolée : aucun accès direct depuis les postes clients ; seuls des flux contrôlés vers les serveurs internes sont autorisés.
• Le site distant (VLAN 50/60) est joint via un tunnel VPN IPsec chiffré, terminé sur les pare‑feux pfSense.

Segmentation VLAN

La segmentation par VLAN permet de cloisonner les usages (postes, serveurs, DMZ, administration, site distant) et de limiter l’impact d’un incident de sécurité à une zone donnée. Chaque VLAN est associé à une politique de filtrage spécifique au niveau du cluster pfSense.

Rôle des principaux VLAN

Schéma de l'infrastructure

Le schéma ci‑dessous représente les principales zones (LAN, DMZ, site distant, Internet), la répartition des VLAN et le rôle du cluster pfSense dans le routage et la sécurisation des flux.

Cluster Pare-feu HA (pfSense) En production

1. Depuis un client, lancer : ping 8.8.8.8 -t
2. Suspendre SRV-PFSENSE-01
3. Résultat attendu : perte de 1 à 2 paquets maximum, puis reprise via SRV-PFSENSE-02 qui passe en statut MASTER.

Contrôleurs de domaine (AD DS / DNS / DHCP) En production

OU=Entreprise
  ├── OU=Utilisateurs
  ├── OU=Ordinateurs
  ├── OU=Groupes
  └── OU=Services (ex: SVC_Nextcloud)

Serveur de données (SRV-BDD) En production

# Port 22 : ALLOW depuis VLAN 40 (Administration)
# Port 3306 : ALLOW depuis 192.168.10.0/24 uniquement
# Politique par défaut : DENY INCOMING

Nextcloud & Talk (SRV-NEXTCLOUD) En production

1. Identification & Rôle

• Nom d'hôte : SRV-NEXTCLOUD
• FQDN : srv-nextcloud.barrault.pb / nextcloud.barrault.pb
• Rôle : Cloud privé collaboratif + communication audio/vidéo (Talk). Architecture : Multi-tiers.

2. Intégration réseau

3. Paramétrage & Configuration

• Serveur Web : Apache2 + module SSL.
• PHP : apcu, gd, imagick, ldap, mysql, zip, intl
• Certificat SSL : Auto-signé (CN: nextcloud.barrault.pb) — requis pour Talk.
• Service TURN (Coturn) : Coïmplanté sur SRV-NEXTCLOUD, Port 3478, auth: static-auth-secret.

Base de données (sur SRV-BDD)

• Nom : db_nextcloud | Utilisateur : usr_nextcloud

Domaines de confiance (config.php)

'trusted_domains' => array (
  0 => '192.168.10.35',
  1 => 'nextcloud.barrault.pb',
),
'overwriteprotocol' => 'https',

4. Sécurité & Règles pare-feu

Intégration Active Directory (LDAP)

• Serveur LDAP : 192.168.10.5 (Port 389)
• Bind DN : CN=SVC_Nextcloud,OU=NEXTCLOUD,OU=Groupe SERVICES,DC=barrault,DC=pb
• Filtre utilisateurs : Groupe "Nextcloud Users"

5. Tests & Validation

Authentification via compte AD fonctionnelle. Appels audio/vidéo Talk opérationnels via le serveur TURN.

SIEM Wazuh (SRV-WAZUH) En production

1. Identification & Rôle

• Nom d'hôte : SRV-WAZUH
• FQDN : wazuh.barrault.pb (A Record sur SRV-AD01)
• Rôle : Gestionnaire de logs centralisé (Manager + Indexer + Dashboard).

2. Intégration réseau

3. Paramétrage & Configuration

• Stockage dédié : Second disque de 50 Go monté sur /var/lib/wazuh-indexer. Point persistant via /etc/fstab.
• Accès Dashboard : https://wazuh.barrault.pb (Login: admin). Certificat auto-signé.
• Données analysées : Journaux Windows (Sécurité/Système), Intégrité FIM, Vulnérabilités.

Déploiement agent (exemple SRV-AD01)

- OS Agent : Windows
- Server address : 192.168.10.40
- Groupe : Default
- Démarrage du service : NET START WazuhSvc

4. Sécurité & Règles pare-feu

Ports ouverts (UFW) :

• 443/tcp : Interface Web
• 1514/tcp : Remontée des logs agents
• 1515/tcp : Enrôlement des agents
• 55000/tcp : API Wazuh

5. Tests & Validation

Remontée des alertes de sécurité Windows réussie. Création d'événements de test FIM détectée et indexée.

GLPI — Gestion de parc & Helpdesk (SRV-GLPI) En production

1. Identification & Rôle

• Nom d'hôte : SRV-GLPI
• FQDN : srv-glpi.barrault.pb
• Rôle : Gestion centralisée du parc informatique (inventaire), ticketing (helpdesk) et suivi des incidents pour l'ensemble des sites NexaGroup.

2. Intégration réseau

VLAN : 10 — IP : 192.168.10.25 — Masque : /24 — GW : 192.168.10.254
DNS : 192.168.10.5 (Prim) / 192.168.10.10 (Sec)

3. Paramétrage & Configuration

Pile applicative

• Serveur Web : Apache2 avec module PHP
• PHP : Extensions requises (curl, gd, intl, ldap, mysql, xml, zip, mbstring)
• Base de données : Externalisée sur SRV-BDD (192.168.10.30)
  • Base : glpidb
  • Utilisateur : glpi_user
  • Accès restreint depuis 192.168.10.25 uniquement

Intégration Active Directory

• Annuaire LDAP configuré vers 192.168.10.5 (port 389)
• Importation automatique des utilisateurs et groupes AD
• Authentification unique via les identifiants du domaine barrault.pb

Fonctionnalités activées

• Inventaire automatique du parc (via agent GLPI / FusionInventory)
• Module Helpdesk : création et suivi de tickets par les utilisateurs
• Gestion des contrats, licences logicielles et fournisseurs

4. Sécurité & Règles pare-feu

Pare-feu local (UFW)

# Port 22  : ALLOW depuis VLAN 40 (Administration SSH)
# Port 80  : ALLOW depuis 192.168.0.0/16 (Accès Web interne)
# Port 443 : ALLOW depuis 192.168.0.0/16 (HTTPS)
# Politique par défaut : DENY INCOMING

5. Tests & Validation

• Accès à l'interface web vérifié depuis les VLAN 20 et 40.
• Authentification LDAP fonctionnelle avec les comptes du domaine.
• Remontee d'inventaire automatique validée sur les postes clients.

Supervision (SRV-ZABBIX) En production

1. Identification & Rôle

• Nom d'hôte : SRV-ZABBIX
• FQDN : srv-zabbix.barrault.pb
• Rôle : Supervision proactive de l'infrastructure : surveillance de la disponibilité des services, des performances système (CPU, RAM, disque, réseau) et génération d'alertes en cas d'anomalie.

2. Intégration réseau

VLAN : 10 — IP : 192.168.10.20 — Masque : /24 — GW : 192.168.10.254
DNS : 192.168.10.5 (Prim) / 192.168.10.10 (Sec)

3. Paramétrage & Configuration

Architecture

• Serveur Zabbix : Collecteur de métriques et moteur d'alertes
• Frontend Web : Apache2 + PHP (accès via https://srv-zabbix.barrault.pb)
• Base de données : Externalisée sur SRV-BDD (192.168.10.30)
  • Base : zabbixdb
  • Utilisateur : zabbix_user

Éléments supervisés

4. Sécurité & Règles pare-feu

• 10050/tcp : Agent Zabbix (passif) — ouvert sur chaque hôte supervisé
• 10051/tcp : Zabbix Server (trapper) — ouvert sur SRV-ZABBIX
• 443/tcp : Frontend Web — depuis VLAN 40 uniquement
• 161/udp : SNMP — interrogation des équipements réseau

5. Tests & Validation

• Remontee des métriques vérifiée pour tous les hôtes enregistrés.
• Déclenchement de triggers testé (simulation de charge CPU, espace disque faible).
• Notifications par e-mail fonctionnelles (via relais SMTP interne).

VLAN 20 — Clients Utilisateurs En production

1. Identification & Rôle

Ce VLAN regroupe les postes de travail (ex: CLT-WIN) des collaborateurs du site principal. Ils accèdent aux ressources internes (VLAN 10) et à internet, tout en étant isolés de la DMZ (VLAN 30) et du domaine d'administration (VLAN 40).

2. Intégration réseau

Adressage IP : Configuré en DHCP avec allocation depuis le cluster de contrôleurs de domaine réseau (SRV-AD01, SRV-AD02).

• Plage DHCP : 192.168.20.10 à 192.168.20.200
• Passerelle : 192.168.20.254 (VIP pfSense)

3. Sécurité

• Le trafic vers les autres VLAN est soumis à des ACL strictes dans pfSense.
• Filtrage internet sortant via proxy/pfSense.

Infrastructure Web & Reverse Proxy (DMZ) En production

1. Identification & Rôle

Hébergement des sites métiers redondés et sécurisation via un frontal (Reverse Proxy / Load Balancer). OS Debian Linux 64 bits.

2. Intégration réseau

3. Paramétrage & Configuration

Configuration Nginx (SRV-RPROXY)

# /etc/nginx/nginx.conf
upstream myapp {
    least_conn;
    server 192.168.30.20;
    server 192.168.30.21;
}

server {
    listen 80;
    location / {
        proxy_pass http://myapp;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

4. Sécurité & Règles pare-feu

Flux inter-VLAN (pfSense)

• VLAN 30 → VLAN 10 (192.168.10.5 + .10) : Port 53 TCP/UDP autorisé (DNS)

Règles pare-feu local

• SRV-RPROXY : Port 80 autorisé depuis réseau client
• SRV-WEB1/WEB2 : Port 80 autorisé UNIQUEMENT depuis 192.168.30.10.

5. Tests & Validation

Load balancing vérifié : requêtes distribuées avec maintien sur nœud disponible via least_conn. Arrêt manuel de WEB1 entraîne la redirection totale vers WEB2 transparente pour le client.

VLAN 40 — Département IT & Administration En production

1. Rôle et Objectif

Ce VLAN est strictement dédié aux administrateurs réseau et système de NexaGroup. Il héberge les postes et outils de gestion, et bénéficie de privilèges d'accès étendus sur l'infrastructure pour la maintenance et la supervision (SSH, RDP, accès Web management).

2. Intégration réseau

• Plage réseau : 192.168.40.0/24
• Passerelle : 192.168.40.254

3. Règles de sécurité

Il est le seul réseau autorisé à accéder aux interfaces d'administration des pare-feu, des hyperviseurs, et au port 22 des divers serveurs Linux (SRV-BDD, SRV-NEXTCLOUD, etc.).

VLAN 50 — Serveur AD Local (RODC) En production

1. Introduction

Le site distant est simulé en laboratoire mais physiquement hébergé sur le même site principal. La liaison entre le réseau centralisé et le site distant virtuel est établie via un tunnel VPN monté sur un routeur pfSense dédié.

2. Spécificités

• Équipement réseau : Le pfSense distant est relié à un switch local qui gère la segmentation des VLANs distants (VLAN 50 et VLAN 60).
• Serveur : AD-HERO (IP: 192.168.50.x)
• Rôle : Contrôleur de domaine en lecture seule (RODC) pour le site de Lyon. Il permet une authentification rapide des profils locaux.
• Avantages : Disponibilité réseau accrue et maintien des authentifications sur le site en cas de perte de connectivité VPN avec Paris.

VLAN 60 — Postes Clients Distants En production

1. Description

Ce VLAN regroupe les postes clients appartenant au site distant. Il est diffusé via le switch relié au pfSense local, garantissant une étanchéité par rapport au réseau serveur distant (VLAN 50).

2. Connectivité réseau

• Authentification garantie par le serveur AD-HERO sur le VLAN 50 (192.168.50.x).
• Le trafic vers les services centraux du siège (serveurs web, messagerie, GLPI) est routé et sécurisé de manière transparente via la connexion VPN site-à-site pfSense.

Tests & Validation

L'ensemble des services a fait l'objet de tests de validation fonctionnelle et de résilience.

Matrice de validation

Bilan & Difficultés rencontrées

Compétences mobilisées

Difficultés rencontrées

Bilan

Réalisation 1 En cours

1. Contexte & Objectif

Détaillez ici le contexte de la première réalisation professionnelle...

2. Environnement Technique

• À compléter

3. Étapes de réalisation

4. Bilan de la réalisation

Résultats obtenus, difficultés rencontrées et solutions apportées.

Réalisation 2 En cours

1. Contexte & Objectif

Détaillez ici le contexte de la deuxième réalisation professionnelle...

2. Environnement Technique

• À compléter

3. Étapes de réalisation

4. Bilan de la réalisation

Résultats obtenus, difficultés rencontrées et solutions apportées.