{EPITECH}

CIA_

< Déploiement & sécurisation d'une infrastructure hybride avec Proxmox />

CLOUD INFRASTRUCTURE ARCHITECTS · SOUTENANCE FINALE · 22 JUIN 2026
Équipe : Oumar Abdallah Abakar · Aadi · Abderrahmane · Adrien · Théo-Selim

Agenda

Sommaire

01

Contexte & objectifs

La mission CIA, les besoins du client et les contraintes du projet.

02

Architecture

Design HLD/LLD, plan d'adressage et stack technologique.

03

Réseau & sécurité

VPN, pare-feu pfSense, bastion et gestion des secrets.

04

Services

IPAM NetBox, observabilité, DNS et site interne.

05

Automatisation

Infrastructure as Code : Terraform, Ansible, Vault, Git.

06

Démo, DRP & bilan

Démonstration, plan de reprise et perspectives.

{EPITECH}CIA · Soutenance finale

Module T-NSA-810

Contexte & mission

En tant que Cloud Infrastructure Architects, un client nous demande de concevoir, déployer et sécuriser une infrastructure hybride complète, reposant sur deux sites Proxmox interconnectés par VPN, avec une approche scalable pour ajouter de nouveaux sites.

2

sites Proxmox
on-premises + remote

5

briques cœur
VPN · FW · IPAM · logs · web

3

piliers
sécurité · automatisation · observabilité

{EPITECH}01 · Contexte

Cahier des charges

Objectifs principaux

Infra hybride

Deux sites Proxmox : on-premises + remote.

Interconnexion

VPN site-to-site chiffré entre les sites.

Sécurité périmétrique

pfSense + filtrage + kill switch.

Accès distant

Bastion host sur le Site 2.

IPAM automatisé

NetBox synchronisé automatiquement.

Observabilité

Logs centralisés via Elasticsearch.

Service interne

Site web accessible en interne uniquement.

Évolutivité

Architecture prête pour de nouveaux sites.

{EPITECH}01 · Objectifs

Règles du jeu

Contraintes & livrables

// CONTRAINTES NON NÉGOCIABLES

!3 VMs maximum par site Proxmox.
!Stacks activement maintenues par la communauté.
!Aucun serveur exposé directement sur Internet.
!Coupure d'urgence (kill switch) sans empêcher la reprise.

// LIVRABLES DE SOUTENANCE

✓Document technique détaillé (captures).
✓Code versionné : configs réseau + logs.
✓Coffre de secrets (Vault).
✓Schéma final + DRP / runbook.

{EPITECH}01 · Contraintes

{EPITECH}

// PARTIE 01

Architecture
& design

High-Level Design

Architecture globale

SITE 1On-premises · cœur192.168.10.0/24

pfSense · FW · NAT · DNS · VPN

ELK · Elastic · Logstash · Kibana

Vault + NetBox + Nginx · VM mutualisée

VPN site-to-site
IPsec IKEv2 · chiffré

SITE 2Remote · exposition minimale192.168.20.0/24

pfSense · client VPN · FW

Bastion SSH · clés · Fail2ban · rebond

Support · DNS · NTP · Filebeat

🔒 0 serveur exposé sur Internet 📡 Logs → ELK Site 1 via le tunnel ⚡ Kill switch = coupure interface VPN

{EPITECH}02 · Architecture

Low-Level Design

Plan d'adressage

Réseau	Plage	Rôle	Hôtes clés
LAN Site 1	`192.168.10.0/24`	Réseau interne — supervision & gestion	pfSense .1 · Vault .103 · Prometheus .102
LAN Site 2	`192.168.20.0/24`	Réseau interne distant	pfSense .1 · Bastion · DNS/NTP
Tunnel S2S	`IPsec IKEv2`	Interconnexion chiffrée S1 ↔ S2	pfSense ↔ pfSense
VPN distant	`10.8.0.0/24`	OpenVPN client-to-site (admins)	Serveur sur pfSense S1

Les deux LAN se voient comme un même réseau privé à travers le tunnel, tout en restant isolés d'Internet par les pare-feux.

{EPITECH}02 · LLD

Core stack

Stack technologique

Proxmox VE

Virtualisation bare-metal — héberge les VMs.

OpenVPN / IPsec

VPN chiffré : client-to-site + site-to-site.

pfSense®

pfSense

Routeur / pare-feu FreeBSD — filtrage.

NetBox

IPAM/DCIM — source de vérité, via API.

Elastic (ELK)

Centralisation, recherche & analyse des logs.

Terraform · Ansible

Infrastructure as Code + secrets via Vault.

{EPITECH}02 · Stack

{EPITECH}

// PARTIE 02

Réseau
& sécurité

Interconnexion sécurisée

VPN — OpenVPN vs IPsec

Critère	OpenVPN — client-to-site	IPsec — site-to-site
Authentification	Certificats (CA + certificats)	Clé partagée (PSK) / certificats
Fonctionnement	Client / serveur	Pair-à-pair (sites égaux)
Ports	UDP 1194	UDP 500 (IKE) + 4500 (NAT-T)
Protocole	SSL/TLS	IKEv2
Usage retenu	Accès admins distants	Liaison entre les 2 sites

Choix justifié par le besoin : OpenVPN pour l'utilisateur distant (flexible, auth forte), IPsec pour l'interconnexion de sites (performances kernel).

{EPITECH}03 · VPN

Sécurité périmétrique

Pare-feu pfSense & kill switch

✓Filtrage de tous les flux entrants/sortants + NAT.
✓Règles par interface : WAN · LAN · OpenVPN · IPsec.
✓DNS forwarding intégré entre les deux sites.
✓OpenVPN intégré nativement — aucun agent en plus.

Kill switch — coupure d'urgence

En cas d'incident, l'interconnexion est coupée instantanément en désactivant l'interface VPN sur pfSense.

→ Stoppe la propagation sans empêcher la reprise : la config reste intacte, réactivation en un clic.

Firewall → Rules → WAN Firewall → Rules → LAN Firewall → Rules → IPsec VPN → IPsec → Tunnels

{EPITECH}03 · pfSense

Accès distant sécurisé · Site 2

Bastion host

Unique point d'entrée SSH externe de l'infrastructure. Le pare-feu redirige un port WAN vers le bastion, qui sert ensuite de point de rebond vers les machines internes.

Clés SSH

Authentification par clé uniquement — pas de mot de passe.

Fail2ban

Blocage auto des tentatives suspectes.

Journalisation

Toutes les sessions tracées → ELK Site 1.

Rebond

Saut contrôlé vers les hôtes internes.

{EPITECH}03 · Bastion

HashiCorp Vault

Gestion des secrets

Aucun secret n'est stocké en clair. Mots de passe et clés API sont centralisés dans HashiCorp Vault, et récupérés dynamiquement par Terraform & Ansible.

CentralisationRotationAccès contrôléZéro secret en dur

# vault — serveur sur le Site 1
api_addr = "http://192.168.10.103:8200"

$ export VAULT_ADDR='http://192.168.10.103:8200'
$ vault kv get secret/proxmox/api
====== Data ======
token_id = terraform@pve
token_secret = ********************

{EPITECH}03 · Vault

{EPITECH}

// PARTIE 03

Services
& exploitation

Gestion automatisée des IPs

IPAM — NetBox

NetBox est notre source de vérité pour le plan d'adressage IP. Il est mis à jour automatiquement par Terraform via son API à chaque provisionnement.

✓Plan d'adressage toujours à jour.
✓Synchronisation via API, pas de saisie manuelle.
✓Documentation des préfixes & équipements.

# terraform → netbox (API)
resource "netbox_ip_address" "vm" {
  ip_address = "192.168.10.50/24"
  status = "active"
  dns_name = "web-internal.cia.lan"
}
→ apply : NetBox synchronisé automatiquement

{EPITECH}04 · NetBox

Supervision centralisée · Site 1

Observabilité

Toutes les VMs des deux sites embarquent un agent Filebeat léger qui remonte les logs vers le Site 1 à travers le tunnel VPN — visibilité globale et centralisée.

Elasticsearch

Stocke & indexe les logs.

Logstash

Reçoit & traite les flux.

Kibana

Visualisation & alertes.

Prometheus + Grafana

Métriques & dashboards :9090 / :3000.

VM → Filebeat → tunnel VPN → ELK Site 1 Node Exporter :9100

{EPITECH}04 · Observabilité

Résolution croisée

DNS forwarding

Le DNS permet la résolution croisée entre les deux sites via le tunnel VPN : chaque site résout les noms de l'autre comme s'ils étaient locaux.

DNS Forwarder pfSense

Redirige les requêtes vers le bon résolveur selon la zone.

Via le tunnel

S1 ↔ S2 — résolution privée, jamais exposée.

NTP associé

Synchro horaire pour logs & certificats cohérents.

{EPITECH}04 · DNS

Service interne · Nginx

Site web interne

Un site web est hébergé par Nginx (VM mutualisée du Site 1), accessible uniquement depuis les réseaux privés — jamais depuis Internet.

✓Accès filtré par pfSense aux seuls LAN.
✓Atteignable depuis S1 et S2 via le tunnel.
✓Ports distincts — aucun conflit de services.

Capture — site web interne

// à remplacer : screenshot Nginx

{EPITECH}04 · Web interne

Automatisation · GitOps

Infrastructure as Code

Terraform

Provisionne les VMs sur Proxmox + MAJ NetBox.

Ansible

Configure les services à l'intérieur des VMs.

Vault

Secrets récupérés dynamiquement au déploiement.

Git

Tout versionné — traçabilité & reproductibilité.

$ terraform apply # crée les VMs + pousse les IPs dans NetBox
$ ansible-playbook site.yml # configure pfSense, ELK, bastion, web…
→ git commit -m "infra: site 2 bastion + ipsec" # source of truth

{EPITECH}04 · IaC

{EPITECH}

// PARTIE 04

Démo, DRP
& bilan

Live

Démonstration

Tunnel VPN actif

// pfSense status IPsec

Bastion SSH + rebond

// terminal / logs Fail2ban

Kibana — logs centralisés

// dashboard ELK

NetBox synchronisé

// vue IPAM

Grafana — métriques

// dashboard

Kill switch en action

// avant / après

Remplacez chaque cadre par vos captures réelles (glisser-déposer une image, voir le README).

{EPITECH}05 · Démo

Disaster Recovery Plan

DRP & runbook

L'objectif n'est pas de documenter ce qui a été fait, mais comment reconstruire : automatisation + procédures.

1

Sauvegarde

Code IaC dans Git + secrets dans Vault + snapshots Proxmox.

2

Reconstruction

terraform apply → ansible-playbook recrée tout l'environnement.

3

Vérification

Tunnel, bastion, logs ELK, résolution DNS → checklist de reprise.

{EPITECH}05 · DRP

Méthode

Gestion de projet

Follow-up 1

Cadrage, exploration, Gantt, backlog, schéma validé.

Follow-up 2

Premières briques en place, tickets & blocages.

Follow-up 3 — Beta

Infra + appli en version beta, choix techniques figés.

Keynote finale

Livraison, DRP, schéma final & secrets.

Diagramme de Gantt

// capture à insérer

Backlog / tickets

// capture à insérer

Dépôt GitOps

// capture à insérer

{EPITECH}05 · Projet

Conclusion

Bilan & perspectives

// OBJECTIFS ATTEINTS

✓Infra hybride sécurisée, automatisée, observable.
✓Exposition minimale + kill switch opérationnel.
✓100 % Infrastructure as Code & reproductible.

// PERSPECTIVES (BONUS)

→CI/CD : lint IaC, tests, déploiements.
→Golden paths : templates VMs, règles, IPAM.
→Multi-site : onboarding d'un 3ᵉ site clé en main.

{EPITECH}05 · Bilan

{EPITECH}

Merci_

Des questions ?

// projet CIA · infrastructure hybride Proxmox · T-NSA-810