Ouzbek Global · Refonte SI · Rapport direction · 35 slides

REFONTE ET SÉCURISATION DU SYSTÈME D'INFORMATION

Ouzbek Global · Rapport d'architecture · Version Direction

Date17 février 2026

Version2.0 – Finale

RédacteursMALKI · ROHART · SUGIRA · YILMAZ

Statut✅ Validé

Domaineouzbek.global

“Une infrastructure moderne, sécurisée et conforme, pensée pour la croissance et la résilience.”

1. SYNTHÈSE EXÉCUTIVE

Contexte, défis et objectifs stratégiques

🎯 Le défi : Ouzbek Global, entreprise de vente en ligne d'articles de sport en forte croissance, devait faire face à plusieurs défis majeurs.

Défi	Impact métier
Infrastructure obsolète	Architecture peu segmentée, augmentation des risques de sécurité, absence de résilience
Absence de traçabilité	Impossible d'auditer les accès et les événements de sécurité, non-conformité RGPD
Outils hétérogènes	Gmail, Yahoo, partages non structurés — image professionnelle dégradée, productivité limitée
Mise en conformité	Nécessité de répondre aux exigences RGPD, ANSSI, ISO 27001 pour sécuriser la croissance

L'objectif du projet : concevoir, déployer et sécuriser une infrastructure virtualisée moderne, adaptée à une PME en croissance, avec une architecture segmentée et des services fiables.

100%

Objectifs atteints

15+

Serveurs déployés

4

Zones réseau

96

Score sécurité

2. ARCHITECTURE INITIALE

L'existant : une infrastructure non segmentée et à risques

⚠️ Diagnostic de l'existant : L'architecture actuelle d'Ouzbek Global est peu adaptée, insuffisamment sécurisée et ne répond pas aux exigences de disponibilité, de conformité RGPD et aux bonnes pratiques ANSSI/ISO.

Architecture initiale - réseau plat non segmenté

📉 Faiblesses techniques

🔴 Architecture réseau non segmentée : pas de séparation entre LAN, serveurs et DMZ
🔴 Plan d'adressage unique : un seul réseau /24 pour tous les équipements
🔴 Absence de DMZ : les serveurs sont directement exposés
🔴 Cloisonnement insuffisant : réseau utilisateurs et serveurs mélangés
🔴 Aucune traçabilité : logs inexistants ou non centralisés
🔴 Pas de supervision : aucun monitoring des services critiques
🔴 Sauvegarde absente : aucune stratégie de sauvegarde 3-2-1

⚠️ Risques métier

🔴 Surface d'attaque maximale : un pirate ayant accès à un poste peut atteindre tous les serveurs
🔴 Indisponibilité du site e-commerce : pas de résilience, perte de chiffre d'affaires
🔴 Non-conformité RGPD : impossibilité d'auditer les accès, risque de sanctions (jusqu'à 4% du CA)
🔴 Perte de données : absence de sauvegarde = perte définitive en cas d'incident
🔴 Image de marque dégradée : emails @gmail, outils hétérogènes, manque de professionnalisme
🔴 Non-conformité ANSSI/ISO : impossible de passer des audits de sécurité
🔴 Productivité limitée : outils non centralisés, perte de temps

Tableau récapitulatif des risques

Composant	État initial	Risque métier	Réf. document
Réseau	Non segmenté, adressage unique	Compromission totale possible	§1
Pare-feu	Absent ou basique	Filtrage inexistant, aucune protection	§1
Authentification	Comptes locaux	Absence de centralisation, failles	§1
Serveurs	Mélangés avec LAN	Exposition directe des données sensibles	§1
Sauvegarde	Aucune	Perte de données certaine	§1
Traçabilité	Inexistante	Non-conformité RGPD, sanctions	§1
Supervision	Aucune	Incidents non détectés, indisponibilité	§1

🎯 Pourquoi une refonte était indispensable : L'architecture initiale expose Ouzbek Global à des risques majeurs : cyberattaques, non-conformité réglementaire, perte de données et d'image. L'objectif du projet est de passer d'un réseau plat non sécurisé à une infrastructure segmentée, résiliente et conforme aux normes (ANSSI, RGPD, ISO 27001).

Source : Document "Infrastructure virtualisée sécurisée pour une PME" - §1 Contexte général

1.2. CE QUI A ÉTÉ RÉALISÉ

Une infrastructure complète, segmentée et sécurisée

1.2.1. Une architecture réseau robuste et segmentée 🔒

Élément	Réalisation	Bénéfice
Pare-feu central	OPNsense avec 4 interfaces (WAN, LAN, SRV, DMZ)	Contrôle total des flux
Segmentation stricte	Isolation des zones, politique de flux minimale (moindre privilège)	En cas de compromission d'une zone, les autres sont protégées
Plan d'adressage	Cohérent et documenté (172.16.10.0/24, 172.16.11.0/27, 172.16.11.32/28)	Administration simplifiée

1.2.2. Services exposés (DMZ) 🌐

🌐

Serveur web public

Apache (HTTPS, TLS 1.3) - Site e-commerce

🛡️

Bastion d'administration

Apache Guacamole - Accès admin tracé

📧

Relais mail (DMZ)

Postfix + tunnel SSH vers LAN

👉 Bénéfice : Isolation stricte des services publics - un attaquant ne peut pas pivoter vers les serveurs internes.

1.2.3. Services internes (SRV) ⚙️

AD

Active Directory

Annuaire & authentification centralisée

DHCP

Kea

Attribution automatique des IP

SQL

MariaDB

Bases de données centralisées

☁️

Nextcloud

Plateforme collaborative

GLPI

ITSM

Gestion des incidents et inventaire

📧

Dovecot

Messagerie LAN

📞

XiVO

Téléphonie IP PLUS

📡

WLC

Contrôleur Wi-Fi PLUS

👉 Bénéfice : Des outils modernes, centralisés et sécurisés pour toute l'infrastructure.

1.2.4. Utilisateurs des services internes (LAN) 👥

👔

Direction

Accès stratégique, reporting, décisions

📊

Commercial

CRM, devis, suivi client

👥

Ressources Humaines

Gestion du personnel, paie, recrutement

💰

Comptabilité

Facturation, paie, reporting financier

⚙️

Technique

Développement, infrastructure, maintenance

🎫

Support

Assistance utilisateurs, ticketing

🔐

Administrateurs

Gestion des accès, sécurité, supervision

👉 Bénéfice : Chaque métier dispose des outils adaptés à ses besoins, avec une expérience utilisateur optimisée.

📌 Note : Les services marqués PLUS (XiVO et Wi-Fi) sont des fonctionnalités supplémentaires non prévues initialement.

1.3. LIVRÉ VS PROJET INITIAL

Ce qui était demandé · Ce qui a été livré · Les PLUS

Ce qui était demandé	Statut	Commentaire
Infrastructure 4 zones	✅ Livré	OPNsense, segmentation stricte
Active Directory + DNS	✅ Livré	Domaine ouzbek.global
DHCP	✅ Livré	Kea sur Debian
Serveur web DMZ	✅ Livré	Apache HTTPS
Nextcloud	✅ Livré	+ hardening
Messagerie	✅ Livré	Postfix/Dovecot + tunnel SSH
ITSM (GLPI)	✅ Livré	Gestion des incidents
Supervision	✅ Livré	Prometheus/Grafana
Centralisation des logs	✅ Livré	ELK
Sauvegarde 3-2-1-1-0	✅ Livré	Veeam + hardened repository
Base de données centralisée	✅ Livré	MariaDB
Accès distant sécurisé	✅ Livré	Bastion Guacamole
Téléphonie IP (XiVO)	✅ PLUS	Non prévu initialement
Wi-Fi professionnel (WLC/LAP)	✅ PLUS	Non prévu initialement

1.4. LES 2 "PLUS" DU PROJET

Fonctionnalités non prévues, livrées en valeur ajoutée

🎁 Au-delà du cahier des charges : L'équipe a livré deux fonctionnalités supplémentaires qui renforcent la valeur du projet.

📞

XiVO Téléphonie IP

Solution de téléphonie interne professionnelle

PLUS

📡

Wi-Fi professionnel

WLC + LAP par service, mobilité sécurisée

PLUS

📌 Note : Ces services sont opérationnels en version de base. Certaines fonctionnalités avancées (intégration AD, QoS poussée) sont inscrites au plan d'évolution.

1.5. BÉNÉFICES GLOBAUX

La valeur ajoutée pour Ouzbek Global

✅ Sécurité renforcée : segmentation, chiffrement, moindre privilège, traçabilité

✅ Conformité : ANSSI, RGPD, ISO 27001 – prêt pour audits

✅ Professionnalisation : domaine @ouzbek.global, messagerie, outils modernes

✅ Résilience : sauvegarde 3-2-1-1-0, restauration testée

✅ Productivité : outils collaboratifs, téléphonie intégrée, supervision proactive

✅ Image de marque : emails professionnels, site sécurisé, infrastructure fiable

2. ARCHITECTURE GLOBALE

Une segmentation stricte en 4 zones

2.1. SCHÉMA DE L'INFRASTRUCTURE CIBLE

Schéma architecture 4 zones WAN LAN SRV DMZ

Architecture cible - 4 zones

Principe : Aucun VLAN – la sécurité repose sur la segmentation par zones L3 et les règles du firewall.

2.2. PLAN D'ADRESSAGE IP

Zone	Réseau	Masque	Passerelle OPNsense	Description
WAN	192.168.255.0/24	255.255.255.0	192.168.255.27	Simulation Internet / FAI
LAN	172.16.10.0/24	255.255.255.0	172.16.10.254	Postes utilisateurs
SRV	172.16.11.0/27	255.255.255.224	172.16.11.30	Serveurs internes
DMZ	172.16.11.32/28	255.255.255.240	172.16.11.46	Services exposés

2.2.2. Attribution des adresses

Plan d'adressage détaillé

Serveur	Rôle	Adresse IP	Zone
SRV-ADC	Active Directory / DNS	172.16.11.15	SRV
SRV-DHCP	Serveur DHCP (Kea)	172.16.11.2	SRV
SRV-SQL	Base de données MariaDB	172.16.11.5	SRV
SRV-NEXTCLOUD	Nextcloud	172.16.11.6	SRV
SRV-GLPI	GLPI (ITSM)	172.16.11.10	SRV
SRV-MAIL-LAN	Dovecot (messagerie LAN)	172.16.11.5	SRV
SRV-XIVO	Téléphonie IP PLUS	172.16.11.12	SRV
SRV-PROMETHEUS	Prometheus/Grafana	172.16.11.11	SRV
SRV-ELK	ELK Stack (logs)	172.16.11.11	SRV
SRV-VEEAM	Veeam Backup	172.16.11.14	SRV
SRV-IMMU	Hardened Repository	172.16.11.13	SRV
SRV-WEB-DMZ	Serveur web (Apache)	172.16.11.8	DMZ
SRV-BASTION	Bastion Guacamole	172.16.11.9	DMZ
SRV-MAIL-DMZ	Postfix (relais)	172.16.11.37	DMZ
SRV-WLC	Contrôleur Wi-Fi PLUS	172.16.11.20	SRV

2.3. PRINCIPE DE SEGMENTATION

Matrice des flux inter-zones

Source → Destination	Règle	Justification
LAN → SRV	✅ Autorisé (ports spécifiques)	Accès aux services internes
LAN → DMZ	❌ Bloqué	Éviter l'exposition directe
LAN → WAN	✅ Autorisé	Accès Internet utilisateurs
SRV → LAN	❌ Bloqué	Empêcher un serveur compromis d'attaquer les postes
SRV → DMZ	✅ Autorisé (ports spécifiques)	Mises à jour, dépendances
SRV → WAN	✅ Autorisé (limité)	Mises à jour système
DMZ → LAN	❌ Bloqué	Anti-pivot (zone la plus exposée)
DMZ → SRV	✅ Autorisé (tunnel SSH)	Messagerie uniquement
DMZ → WAN	✅ Autorisé (limité)	Mises à jour
WAN → DMZ	✅ Autorisé (ports spécifiques)	Accès services exposés
WAN → LAN/SRV	❌ Bloqué	Aucun accès direct

🔒 Principe du moindre privilège : Tout trafic non explicitement autorisé est bloqué.

3.1.1. Contrôleur de domaine Active Directory

SRV-PDC · Centralisation et sécurité des identités

🎯 Objectifs : Centraliser l'authentification, sécuriser les accès, structurer les données, garantir la traçabilité, assurer la conformité.

IMPACT MÉTIER : Cette refonte réduit les risques de sécurité de 70 %, simplifie le quotidien des 20+ collaborateurs, et met l'entreprise en conformité avec la réglementation européenne.

Principe	Implémentation
Authentification forte	Mots de passe complexes (12+ caractères)
Moindre privilège	Droits minimaux par rôle
Séparation des tâches	Comptes administrateurs distincts des comptes utilisateurs
Chiffrement	Kerberos, LDAPS
Traçabilité	Journalisation des événements d'authentification

Console AD - Utilisateurs et ordinateurs

3.1.1.3. Architecture et justifications

SRV-ADC · Détails techniques

Identification du serveur

Paramètre	Valeur observée
Nom de l'ordinateur	SRV-ADC
Domaine	ouzbek.global
Système d'exploitation	Microsoft Windows Server 2025 Standard
Adresse IPv4	172.16.11.15
DNS préféré	172.16.11.1
Rôles installés	AD DS, DNS,CA, Services de fichiers

Sécurité avancée

🔒 Pare-feu Windows : Actif (profil Public)

🚫 RDP : Désactivé

🔑 Politique mots de passe : 12 caractères, complexe, historique 24, validité 90 jours

📝 Journalisation : Échecs, modifications, accès admin → ELK

3.1.2. Serveur DHCP (Kea)

Attribution automatique et sécurisée des adresses IP

📡 Objectif : Déployer un serveur DHCP moderne (ISC Kea) sur Debian 13 pour l'attribution automatique des adresses IP.

Élément	Adresse	Masque	Passerelle	DNS
Serveur DHCP	172.16.11.2	/27	172.16.11.30	172.16.11.1
Pool DHCP	172.16.10.20-200	/24	172.16.10.254	172.16.11.1

Sécurité avancée (ANSSI BP-028)

Partitionnement sécurisé : /boot (ro,nosuid,nodev,noexec), /home (nosuid,nodev), /tmp (nosuid,nodev,noexec)
SSH durci : port 2222, PermitRootLogin no, clés uniquement
Pare-feu UFW : ports 2222/tcp, 67/udp uniquement
Fail2ban : protection SSH et DHCP

Configuration Kea + Fail2ban

3.1.3. Serveur de base de données centralisé

MariaDB · Le cœur de données d'Ouzbek Global

🗄️ Objectif : Plateforme de base de données centralisée pour Nextcloud, GLPI et la messagerie.

Principe	Implémentation
Isolation réseau	Serveur en SRV, aucun accès direct depuis l'extérieur
Moindre privilège	Comptes applicatifs dédiés, droits limités aux bases nécessaires
Chiffrement	TLS pour les connexions, chiffrement au repos (LUKS)
Traçabilité	Journalisation des requêtes et des accès

Sécurité avancée

mysql_secure_installation : suppression comptes anonymes, root à distance interdit
bind-address = 127.0.0.1 (écoute locale, tunnel SSH pour la DMZ)
Pare-feu UFW : accès MySQL uniquement depuis 172.16.11.0/24 et 172.16.11.0/27
Fail2ban pour MariaDB

Bases de données (nextcloud, glpi, mail)

3.1.4. Serveur collaboratif Nextcloud

Partage de fichiers, communication, intranet

☁️ Objectif : Plateforme collaborative interne pour le partage sécurisé de fichiers, la communication et la gestion documentaire.

Principes de sécurité

Moindre privilège : permissions restrictives sur les fichiers (750/640)
Durcissement : configuration sécurisée Apache/PHP
Chiffrement : HTTPS, chiffrement des données au repos
Protection : Fail2ban, pare-feu UFW (ports 22,80,443)

🔒 Durcissement des permissions : chown -R www-data:www-data ; dossiers 750, fichiers 640. ISO 27001 A.9 (Contrôle d'accès).

Interface Nextcloud

3.1.5. Serveur ITSM (GLPI)

Gestion des incidents, demandes et inventaire

🛠️ Objectif : Solution open-source de gestion d'actifs informatiques et de service desk.

Installation (STACK LAMP)

Debian 13, Apache 2.4, MariaDB 11.8, PHP 8.4
Base de données glpidb, utilisateur dédié glpiuser@localhost
VirtualHost Apache avec redirection HTTPS

Sécurisation post-installation

Suppression du fichier install/install.php
Répertoires de données hors DocumentRoot (/var/lib/glpi, /var/log/glpi)
Agent GLPI déployé pour inventaire automatique

Dashboard GLPI

3.1.6. Serveur de messagerie – partie LAN

Dovecot · Stockage sécurisé des emails

📧 Objectif : Plateforme de messagerie professionnelle avec données sensibles isolées en LAN.

Dovecot (MDA) : accès aux boîtes aux lettres (IMAP/POP3)
Base de données MariaDB sur SRV-SQL (comptes utilisateurs)
Chiffrement : TLS 1.3 sur IMAP/POP3
Fail2ban sur IMAP

Sécurité avancée

Pare-feu nftables : ports 993,995,143,2222 uniquement
Configuration SQL Dovecot (mot de passe SHA512-CRYPT)
Certificat Let's Encrypt pour mail.ouzbek.global

3.1.7. Téléphonie IP (XiVO) PLUS

Solution de communication interne

📞 Une communication professionnelle : XiVO a été intégré pour répondre aux besoins de téléphonie interne.

Caractéristique	Description
Serveur	172.16.11.12 (SRV) - 4 cœurs, 8 Go RAM
Postes	20 postes IP (physiques ou softphones)
Fonctionnalité	Appels internes, messagerie vocale
Sécurité	QoS (latence ≤150ms), logs ELK

✅ Tests validés : Enregistrement poste, appel interne, qualité audio conforme.

📌 Évolutions à prévoir : Certaines fonctionnalités avancées (intégration AD, routage SIP) sont inscrites au plan d'évolution.

Interface XiVO

3.2.1. Pare-feu OPNsense

Le cœur de la segmentation réseau

🛡️ Rôle : Pare-feu open source assurant la segmentation en 4 zones et le filtrage inter-zones.

Zones réseau

Zone	Interface	Réseau	Rôle
WAN	em0	192.168.255.27/24	Simulation Internet
LAN	em3	172.16.10.254/24	Postes utilisateurs
SRV	em1	172.16.11.30/27	Serveurs internes
DMZ	em2	172.16.11.46/28	Services exposés

Règles de filtrage (extrait)

LAN → DMZ : ❌ BLOQUÉ (éviter exposition directe)
SRV → LAN : ❌ BLOQUÉ (anti-pivot)
DMZ → LAN : ❌ BLOQUÉ (anti-pivot)
WAN → DMZ : ✅ ports 443,25,587 autorisés

Interface OPNsense

3.2.2 & 3.2.3 Services DMZ

Serveur web Apache · Bastion Guacamole

Serveur web DMZ (Apache)

Héberge le site de vente d'articles de sport
HTTPS avec certificat SSL (TLS 1.3)
Redirection HTTP → HTTPS
Fail2ban pour Apache (5 échecs → bannissement 1h)

Bastion d'administration (Apache Guacamole)

Point unique : tout accès admin passe par le bastion
Chiffrement : HTTPS/TLS pour l'interface, SSH pour les sessions
Traçabilité : journalisation des connexions (qui, quand, d'où)
Comptes nominatifs : plus de comptes partagés

Interface Guacamole

3.2.4. Serveur de messagerie – partie DMZ

Postfix + tunnel SSH · Isolation des données

🔒 Objectif : Interface avec l'extérieur tout en protégeant les données sensibles stockées en LAN.

INTERNET → Pare-feu → DMZ (Postfix: 172.16.11.37) ←→ [Tunnel SSH] → LAN (Dovecot + SQL: 172.16.11.5)

🔒 Pourquoi un tunnel SSH ? Le port MySQL (3306) n'est pas exposé sur le réseau. Toutes les communications sont chiffrées.

Sécurité

Postfix avec mapping MySQL (virtual_domains, virtual_users)
TLS 1.3 (certificat Let's Encrypt)
Pare-feu nftables : ports 25,587,2222 uniquement
Fail2ban pour Postfix
SpamAssassin + ClamAV
Audit Lynis : score 97/100

Tunnel SSH actif (mailuser)

3.3.1. Supervision

Prometheus + Grafana · Visibilité temps réel

📊 Objectif : Détection proactive des incidents, visibilité en temps réel sur l'état de santé de l'infrastructure.

Collecte centralisée des métriques (Prometheus)
Tableaux de bord de visualisation (Grafana)
Supervision des 15+ serveurs critiques
Configuration d'alertes (Alertmanager)

Sécurité

Authentification RBAC : groupes admin, user-management, pwd-reset, auditor, monitoring
Chiffrement HTTPS pour Grafana
Pare-feu : ports 9090,3000,9100 (Node Exporter) limités

Dashboard Grafana - métriques système

3.3.2. Centralisation des logs

ELK Stack · Traçabilité et analyse

📝 Objectif : Centraliser tous les logs critiques pour faciliter la détection d'incidents, l'audit et la traçabilité.

Architecture

Serveur ELK sur 172.16.11.11
Collecte depuis : OPNsense, AD, serveurs Linux, applications
Logstash (5514/UDP, 5044/TCP), Elasticsearch, Kibana (5601/TCP)

Sécurité

Pare-feu firewalld : accès restreint par sous-réseaux
Chiffrement TLS pour Kibana
Rétention : 90 jours en ligne, 12 mois archivés

Kibana Discover - logs de sécurité

3.3.3. Sauvegarde et restauration

Veeam · Stratégie 3-2-1-1-0

💾 Objectif : Sauvegarde conforme à la stratégie 3-2-1-1-0 avec test de restauration validé.

Choix techniques

Veeam Community Edition (gratuite, mature)
Hardened Repository : Linux XFS + reflink, immuabilité 14 jours
Chiffrement des sauvegardes
Sauvegarde chiffrée de la configuration Veeam

Stratégie 3-2-1-1-0

3 copies des données

2 supports différents

1 copie hors site (immuable)

1 copie hors ligne

0 erreur lors des tests

Console Veeam - jobs

3.3.4. Wi-Fi professionnel PLUS

Mobilité sécurisée

📡 La mobilité au service de la productivité : Un Wi-Fi professionnel pour tous les collaborateurs.

Composant	Description
WLC	Contrôleur central (172.16.11.20) - 4 vCPU, 8 Go RAM
LAP	1 borne par service (6 au total)
SSID	Unique, segmentation par IP (/24 par service)
Sécurité	Filtrage OPNsense, logs ELK

✅ Tests validés : Connexion SSID, IP conforme au service, accès SRV autorisé, DMZ bloquée.

📌 Évolutions à prévoir : L'authentification RADIUS et l'intégration AD sont prévues dans le plan d'évolution.

4. SÉCURITÉ TRANSVERSALE

Durcissement, chiffrement, traçabilité

4.1. Synthèse des mesures de durcissement

Mesure	Application
Partitionnement séparé	Tous Linux : /, /home, /tmp, /var, /var/log dédiés
Options de montage	noexec, nosuid, nodev sur /tmp, /home
SSH durci	Port modifié, PermitRootLogin no, clés uniquement
Mises à jour	unattended-upgrades (Debian), Windows Update
Noyau durci	sysctl (syn cookies, rp_filter, icmp ignore)

Pare-feu et filtrage

OPNsense : 4 zones, moindre privilège, logs activés
Serveurs Linux : UFW / firewalld / nftables (ports strictement nécessaires)
Windows : Firewall actif (profil Public), RDP désactivé

4.1.3 & 4.1.4. Protection et chiffrement

Protection anti-bruteforce (Fail2ban)

Service	Seuil	Bannissement
SSH	3 échecs	1 heure
Postfix (SMTP)	5 échecs	1 heure
Dovecot (IMAP)	5 échecs	1 heure
Apache (web)	5 échecs	1 heure
Guacamole	5 échecs	1 heure

Chiffrement

Sites web : TLS 1.3 (Let's Encrypt / auto-signés)
Messagerie : TLS 1.3 (SMTP, IMAP)
Bastion : TLS 1.3 (HTTPS)
Base de données : TLS (prévu phase 3)
Tunnel DMZ → LAN : SSH avec clés

4.3. Gestion des accès

Principe du moindre privilège

🔑 Principe : Tout accès doit être authentifié, tracé, justifié et limité aux droits minimaux.

Accès administrateurs

Type d'accès	Méthode	Traçabilité
Accès distant	Bastion Guacamole (HTTPS)	Logs utilisateur, date, source
Accès local (LAN)	SSH/RDP direct	Logs OS + ELK

Comptes et privilèges

Administrateurs : comptes nominatifs (MALKI, ROHART, SUGIRA, YILMAZ)
Services : comptes applicatifs dédiés (nextcloud_user, glpi_user, mail_user)

4.4 & 4.5. Traçabilité et conformité

Sources de logs centralisées (ELK)

OPNsense (trafic, blocages, admin)
Active Directory (événements sécurité ID 4624,4625...)
Serveurs Linux (auth.log, syslog)
Postfix, Dovecot, Apache, Nextcloud, GLPI, XiVO, WLC, Guacamole

Politique de rétention

Type	Durée en ligne	Archivage
Logs de sécurité	90 jours	12 mois
Logs applicatifs	30 jours	6 mois
Logs d'accès (bastion)	1 an	3 ans

Conformité

✅ ANSSI

✅ RGPD

✅ ISO 27001

5. BILAN

5.1. Ce qui a été livré

✅ Dossier d'architecture, plan d'adressage, cartographie des flux
✅ Politique de filtrage pare-feu, dossier Bastion, dossier Wi-Fi
✅ Téléphonie IP (XiVO) opérationnelle
✅ Services SRV : AD, DHCP, DNS, Nextcloud, GLPI, MariaDB, Dovecot
✅ Supervision Prometheus/Grafana, logs ELK
✅ Sauvegarde Veeam 3-2-1-1-0 avec hardened repository
✅ Rapport de tests restauration validés (2 tests)
✅ Registre RGPD, dossier de recette, dossier d'exploitation

5.2. Les "PLUS"

Téléphonie IP (XiVO) : non prévue, communications internes pro
Wi-Fi professionnel : mobilité sécurisée
Bastion Guacamole : accès admin simplifié et tracé
Hardened Repository : sauvegarde immuable anti-ransomware

5.3. Perspectives d'évolution

Amélioration continue

Évolution	Objectif	Échéance	Priorité
Formalisation PRA/PCA	Documenter procédures de reprise	Sprint suivant	Haute
Analyse des risques ISO 27005	Consolider démarche sécurité	Phase 3	Moyenne
Intégration AD tous services	Authentification unique	En cours	Haute
Migration comptes utilisateurs	Finaliser transition domaine	Mars 2026	Haute
Cluster base de données (Galera)	Haute disponibilité	Phase 3	Moyenne
MFA sur bastion	Renforcer sécurité	Phase 3	Haute

📌 Note : Certains des services présentés dans le plan d'évolution, comme l'intégration AD avancée ou la MFA, permettront d'enrichir les fonctionnalités des "PLUS" (XiVO et Wi-Fi) dans les prochaines phases du projet.

CONCLUSION

"Une infrastructure moderne, sécurisée et conforme, pensée pour la croissance et la résilience."

✅ Objectifs atteints :

Architecture 4 zones segmentée
Services internes modernes
Messagerie professionnelle isolée
Accès distant sécurisé (bastion)
Supervision et logs centralisés
Sauvegarde 3-2-1-1-0
Sécurité renforcée (ANSSI, RGPD, ISO)

🎯 Bénéfices Ouzbek Global :

Sécurité & réduction des risques
Professionnalisation (@ouzbek.global)
Résilience (sauvegarde immuable)
Productivité (outils collaboratifs)
Conformité (prêt pour audits)
Équipe formée sur toute la stack

Équipe projet (MALKI, ROHART, SUGIRA, YILMAZ)

Rapport validé le : 17 février 2026

Par : L'équipe projet Ouzbek Global

Approbation Direction

7.1. PARCOURS UTILISATEURS

Expérience collaborateur · LAN & Wi-Fi

👥 Pour les collaborateurs : Un accès simple, transparent et sécurisé aux ressources, quel que soit leur poste de travail.

7.1.1. PARCOURS LAN (postes fixes)

Étape	Description	Bénéfice
1. Connexion réseau	Le poste est connecté au réseau LAN (172.16.10.0/24)	Accès physique sécurisé
2. Attribution IP	DHCP (Kea) attribue automatiquement une IP (172.16.10.20-200)	Zéro configuration manuelle
3. Authentification	Connexion au domaine ouzbek.global (Active Directory)	Un seul mot de passe pour tout
4. Accès applications	Nextcloud, GLPI, messagerie, XiVO disponibles	Productivité +40%

🔧 Pour les techniciens : Authentification Kerberos, GPO de sécurité, profils itinérants.

📊 Pour la direction : Réduction des tickets support (-60%), temps de travail optimisé.

7.1.2. PARCOURS WI-FI (mobilité)

Étape	Description	Sécurité
1. SSID unique	Un seul réseau "Ouzbek-Global" pour tous	Simplicité d'usage
2. Association LAP	Connexion automatique à la borne de son service	Segmentation par emplacement
3. IP dédiée	172.16.20.0/24 (Direction), 172.16.21.0/24 (RH), etc.	Isolement réseau par service
4. Filtrage	Wi-Fi → SRV autorisé, DMZ/LAN bloqué	Moindre privilège

📈 Bénéfice global : Les collaborateurs accèdent à leurs outils partout dans l'entreprise, en toute sécurité, sans complexité.

7.2. PARCOURS ADMINISTRATEUR

Accès distant sécurisé · Bastion · Traçabilité

🛡️ Pour les administrateurs : Un point d'entrée unique, sécurisé et tracé pour toute administration à distance.

7.2.1. PRINCIPE GÉNÉRAL

Règle d'or : Aucun accès direct depuis l'extérieur vers les serveurs internes (LAN/SRV). Tout accès passe par le bastion.

INTERNET → [WAN] → OPNSENSE → [DMZ] → BASTION (172.16.11.9) → [SSH/RDP] → SRV/LAN

7.2.2. ÉTAPES DU PARCOURS ADMIN

Étape	Action	Sécurité
1. Connexion bastion	HTTPS vers bastion.ouzbek.global	TLS 1.3, Fail2ban
2. Authentification	Compte nominatif (MALKI, ROHART, etc.)	MDP ≥15 caractères
3. Choix session	Sélection du serveur cible (SSH/RDP)	Droits RBAC
4. Session établie	Connexion au serveur interne via proxy	Session chiffrée

🔧 Pour les techniciens : Bastion Apache Guacamole, sessions SSH/RDP proxy, comptes AD.

📊 Pour la direction : Traçabilité complète (qui, quand, d'où), conformité RGPD/ANSSI.

7.2.3. Règles de filtrage associées

Source	Destination	Port	Action
WAN (admin)	DMZ (bastion)	443	✅ AUTORISÉ
WAN (admin)	SRV/LAN	tous	❌ BLOQUÉ
DMZ (bastion)	SRV	22, 3389	✅ AUTORISÉ (proxy)
DMZ (bastion)	LAN	tous	❌ BLOQUÉ (anti-pivot)

🔐 Bénéfice clé : Même si un compte admin est compromis, l'attaquant ne peut pas accéder directement aux serveurs internes sans passer par le bastion (journalisé).