| |
| dossier:manifeste_de_l_architecture_par_blocs_autonomes_etanches [2026/10/09 15:44] – créée bernard.rolland | dossier:manifeste_de_l_architecture_par_blocs_autonomes_etanches [2026/10/09 15:53] (Version actuelle) – supprimée bernard.rolland |
|---|
| [[./accueil| ↩ Retour à l'accueil du projet]] | |
| ====== 1) Manifeste de l'Architecture par Blocs Autonomes & Étanches ====== | |
| |
| Ce document formalise la rupture technologique majeure du projet **VPS Passerelle**. Il acte le passage d'une architecture monolithique centralisée sur l'hôte vers un modèle cellulaire par **Conteneurs Passerelles Isolés**. | |
| |
| Ce manifeste décrit le cheminement intellectuel, les principes directeurs et les garanties de sécurité d'une solution d'hébergement multi-clients hautement paranoïaque. | |
| |
| ===== 1. L'Historique du Pivot : Du Monolithe à la Cellule ===== | |
| |
| Au départ, le projet s'est construit sur un modèle classique en étoile (*Hub-and-Spoke*) : un VPS unique, un seul serveur WireGuard, un seul pare-feu global et un Reverse Proxy Nginx chargé de distribuer tout le trafic web public vers les clients. Bien que cette solution ait abouti et ait été validée en laboratoire, une confrontation critique avec les principes de la **Charte de Sécurité** a mis en lumière des faiblesses structurelles majeures : | |
| |
| * **L'Effet Domino (Risque de contamination latérale) :** Dans un réseau privé unique (''10.66.66.0/24''), si le site web d'un seul client est compromis, le pirate s'installe dans la bergerie. Il peut scanner le réseau interne, attaquer les autres clients connectés ou tenter une escalade de privilèges sur le VPS hôte. | |
| * **La Centralisation des Secrets :** Pour administrer ce monolithe depuis un conteneur de gestion ou un outil distant, il fallait stocker une clé SSH privée "maîtresse" (ou un secret réseau équivalent) à portée de main sur Internet. Un seul maillon qui cédait, et c'est l'intégralité du serveur physique qui s'effondrait. | |
| * **L'Usine à Gaz Opérationnelle :** Chaque ajout ou retrait de client imposait à nos scripts de faire une micro-chirurgie invasive dans les fichiers de configuration actifs du VPS (''nftables.conf'', ''wg0.conf'', configurations Nginx). Le risque d'erreur humaine ou de corruption de fichier était permanent. | |
| |
| Face à ce constat, une intuition a émergé : **Et si on arrêtait de modifier le VPS ?** Et si, au lieu de construire un énorme château fort pour tout le monde, on distribuait à chaque client son propre coffre-fort individuel, autonome et jetable ? Le concept du **Conteneur Passerelle** était né. | |
| |
| ===== 2. Le Principe Réseau du "Tuyau Total" ===== | |
| |
| Dans cette nouvelle architecture, le VPS physique redevient une infrastructure "bête et méchante". Il n'héberge plus aucun script d'administration complexe, plus aucune table de routage globale, plus aucun serveur mail. Il sert uniquement de passerelle de routage brute pour des paires de conteneurs étanches. | |
| |
| Chaque client dispose désormais d'un **Bloc Autonome** composé de deux cellules : | |
| * **La Cellule Réseau (Le Conteneur Passerelle) :** C'est un conteneur minuscule, ultra-léger, qui fait office de bouclier thermique. Il possède sa propre interface WireGuard dédiée (liée à un seul client extérieur) et son propre pare-feu ''nftables'' interne. | |
| * **La Cellule Applicative (Le Conteneur Client) :** C'est la machine qui héberge les services (ex: instance YunoHost, WordPress, etc.). Elle est branchée directement derrière sa passerelle dédiée, via un réseau local virtuel privé et exclusif. | |
| |
| Pour le monde extérieur, le trafic entre par un port UDP public dédié sur le VPS (ex: ''51821''), plonge directement dans le conteneur passerelle correspondant, et est propulsé vers l'application du client. **Il n'y a plus aucun espace réseau commun entre les clients.** | |
| |
| ===== 3. Les Garanties Sécuritaires Absolues ===== | |
| |
| Ce modèle cellulaire apporte des garanties de sécurité qu'aucune architecture classique ne peut offrir : | |
| |
| ==== A. Micro-Segmentation & Confinement Radical ==== | |
| Si le serveur d'un client est piraté, le loup est enfermé dans une cage d'acier. Lorsqu'il tente de scanner son réseau privé ou ses interfaces, il ne voit que lui-même et sa propre passerelle. Il n'a techniquement aucun moyen d'identifier, de scanner ou d'attaquer les autres clients du VPS, car les réseaux sont hermétiquement cloisonnés au niveau du noyau. La contamination latérale est mathématiquement impossible. | |
| |
| ==== B. Sanctuarisation du VPS Hôte ==== | |
| Le conteneur passerelle ne possède aucun droit, aucune clé SSH et aucun accès sur le VPS physique qui l'héberge. C'est un exécutant passif. Si un pirate détruit la passerelle et l'application d'un client, le système d'exploitation du VPS reste totalement intact, introuvable et inviolable. Le berger est à l'abri, même si une brebis est attaquée. | |
| |
| ==== C. Immunité des Outils et Plan de Reprise d'Activité (PRA) Indestructible ==== | |
| Les scripts d'administration (le gestionnaire de **tux**) ne sont plus exposés sur le réseau des clients. Ils restent à l'extérieur de la zone de danger, soit sur le VPS principal, soit sur un réseau d'administration totalement isolé. Si une panne réseau globale touche un client ou une interface WireGuard, les outils d'administration ne sont pas impactés. Mieux encore : comme chaque bloc est un conteneur autonome, la sauvegarde consiste simplement à exporter l'archive du conteneur. En cas de sinistre, on réimporte le conteneur sur n'importe quel VPS vierge en 10 secondes, et le service repart à l'identique. | |
| |
| [[./accueil| ↩ Retour à l'accueil du projet]] | |
| |
