Infrastructure
& pilotage IT.

Une infrastructure,
plusieurs métiers.

Le système d'information ne se réduit pas à la distribution de contenus vers les bornes. Il porte aussi un outil de monitoring de flotte, une application tierce sous Windows, deux instances GLPI cloisonnées par client, et un plan de management complet permettant aux admins d'opérer l'ensemble à distance et de manière sécurisée. Ce document décrit cette vue d'ensemble.

Objectif du document

Établir une cartographie commune à tous les publics qui ont besoin de comprendre l'infrastructure : équipes techniques au quotidien, pilotage IT pour la gouvernance, direction pour les arbitrages, et auditeurs ou partenaires pour la conformité. Chaque section reste lisible indépendamment, sans nécessiter la lecture des autres.

Lien avec le document ARCHI-001

Le sous-système Distribution de contenus — 4 VM (App, DB, Storage, ProFTPD), V2 backoffice, sync HTTP et SFTP des bornes — est entièrement décrit dans ARCHI-001. Ce dossier-ci se concentre sur tout ce qui l'entoure : ce qui se trouve devant (Front), à côté (services tiers, monitoring) et au-dessus (management, gouvernance).

Panorama
des machines.

Au-delà des 4 VM de la distribution de contenus, l'écosystème compte cinq composants supplémentaires, regroupés en quatre catégories fonctionnelles : entrée réseau, métier, tiers, management.

▸ La VM Proxy Management est hébergée séparément, sur un VPS indépendant — elle n'apparaît pas dans le réseau privé principal et fait l'objet d'une section dédiée (§ 08).

Topologie
globale.

Une entrée Internet unique via la VM Front. Un réseau privé 10.0.0.0/24 qui héberge tous les services. Un plan de management entièrement séparé, sur un VPS externe, accessible par WireGuard.

La VM Front,
porte d'entrée unique.

Toute requête venant d'Internet passe par la VM Front. C'est elle qui gère le multi-WAN, termine le TLS, applique les règles de sécurité, et fait suivre vers le bon service interne. Les autres VM n'exposent rien à l'extérieur.

Responsabilités

Quatre rôles cumulés sur cette unique VM, qui ne portent aucune donnée applicative : tout est passe-plat avec contrôle.

• ① Firewall périmétrique. Seuls les ports 80, 443 et 22 (SFTP) sont ouverts vers l'extérieur. Tout le reste est rejeté en silence.
• ② Multi-WAN : plusieurs IP publiques dédiées. Le Front porte plusieurs IP publiques, une par service exposé — une pour app / sync SFTP / backoffice, une pour Windows, une pour le monitoring, etc. Toutes entrent par le firewall du Front, qui les route vers le bon service interne. Le multi-WAN assure aussi la résilience des liens (bascule sur dégradation).
• ③ Handler HTTPS / terminaison TLS. Tous les certificats Let's Encrypt (et autres) sont gérés ici. Les services internes parlent en HTTP simple — la couche TLS s'arrête au Front.
• ④ Reverse proxy par vhost. Chaque service (backoffice, monitoring, GLPI A, GLPI B…) a son nom de domaine et son vhost. Rate limiting, IP block-list, headers de sécurité appliqués au niveau du Front.

Pourquoi un seul Front ?

Concentration des règles de sécurité, certificats, et politique de routage en un seul endroit. Toute modification de sécurité se fait à un seul endroit, pas à dupliquer sur chaque VM. Single point of failure assumé, mitigé par snapshots fréquents et restore rapide depuis backup.

Distribution
& monitoring de flotte.

Le cœur métier de l'infrastructure regroupe deux blocs : la plateforme de distribution de contenus (entièrement décrite dans ARCHI-001), et le monitoring du parc bornes qui consomme les mêmes données.

VM Monitoring bornes

Service dédié au pilotage du parc bornes. Il ne supervise pas l'infrastructure elle-même (c'est le rôle d'outils sysadmin séparés, hébergés sur la VM Proxy Management) — il s'intéresse uniquement aux bornes : leur état, leur configuration, ce qu'elles diffusent, ce qu'elles ont consommé.

Un modèle strictement passif vis-à-vis des bornes

Point d'architecture essentiel : le monitoring ne se connecte jamais directement à une borne. Il n'existe aucun flux monitoring → borne. Le monitoring écrit des intentions (configuration, planning, commandes) côté serveur ; les bornes les récupèrent d'elles-mêmes à leur prochain auto-refresh, exactement comme elles récupèrent leurs contenus. Même principe pull que la distribution : les bornes tirent, personne ne pousse. Aucune borne n'a besoin d'être joignable, aucun port entrant n'est ouvert côté borne.

Concrètement, le monitoring assure trois fonctions, et il a donc besoin de lire ET d'écrire — pas seulement d'observer :

• R Surveillance (lecture). Lit l'état réel des bornes — dernière sync, contenus consommés, santé — depuis la DB Distribution (files, downloads, users, tags).
• W Gestion de configuration (écriture). Écrit la config des bornes (fréquence d'auto-refresh, planning, comportement) que les bornes viendront chercher à leur prochain cycle.
• + Commandes internes & rapports. Tâches de pilotage, surveillance programmée, génération d'artefacts : screenshots, logs agrégés, rapports PDF/exports.

Le dashboard de pilotage est servi via le Front (vhost dédié, reverse proxy), comme tous les autres services web, et accessible aux équipes de pilotage. La VM Monitoring n'expose donc rien directement vers l'extérieur.

VM Git & déploiement (CI/CD)

La VM Git (10.0.0.90) héberge les dépôts — source de vérité du code — et assure le déploiement : elle détecte les commits et pousse le code vers la VM App, écrasant les sources de l'app concernée. Git est la source, l'App est la cible. La VM est stateless (Alpine/RAM) ; seuls les dépôts vivent sur un volume persistant.

Le point de vigilance — c'est la question ouverte de cette VM — est le SQLite vivant de l'app. Il fait partie des documents / data du client (poussés par le client) et vit donc avec les data persistantes, sur un disque/montage distinct de celui des sources. Le déploiement Git écrase les sources (montage A), jamais les data client (montage B) — le SQLite est donc à l'abri par construction. C'est le même principe que le socle Alpine/RAM : la zone jetable (les sources) et la donnée à préserver (les data client, SQLite inclus, cf. § 10) sont physiquement séparées. Seules les migrations de schéma font évoluer la base — sans jamais l'écraser.

Accès concurrents
& cloisonnement du Storage.

La VM Storage exporte /srv/storage en NFS, monté par plusieurs consommateurs (App, ProFTPD, éventuellement Monitoring). Le partage d'un même export n'est pas un risque en soi : le seul danger réel est deux écritures simultanées sur le même fichier. Toute l'architecture vise donc à garantir un seul écrivain par zone, et cette garantie vient du Storage lui-même — pas de la bonne volonté des clients.

Qui lit, qui écrit

Point clé hérité d'ARCHI-001 : les écritures de contenu ne passent pas par NFS, elles passent par HTTP PUT vers le Nginx du Storage (sérialisé localement). Le NFS sert surtout à lire. Les bornes en HTTP lisent le contenu directement sur le Nginx du Storage via URL signées (sans NFS, I/O locales optimales) pour leur affichage et leur synchro ; en retour, elles poussent leurs statistiques au backoffice (via URL), qui les consolide en MariaDB (cf. § 10) — jamais sur le Storage.

Le modèle deux-montages : un RO, un RW

Plutôt que de jouer sur les permissions dans un arbre partagé, ProFTPD monte deux points NFS distincts depuis le Storage : un /mnt/ro pour servir les contenus, un /mnt/rw pour recevoir les dépôts. Les droits ne se chevauchent jamais parce que ce sont deux montages et deux exports séparés — la garantie est physique, pas logique. Bonus : on peut régler les options différemment (soft sur le RO qui sert, hard,intr sur le RW qui reçoit).

Décision imposée : incoming/ en RW pour le SFTP, RO pour l'App

Pour le dépôt entrant du tiers, le modèle est tranché et imposé afin d'éliminer tout risque par construction : incoming/ est RW pour le SFTP (le tiers, seul écrivain) et RO pour l'App (lecteur occasionnel). Le vchroot ProFTPD du tiers pointe sur incoming/, lui-même monté dans un dossier dédié côté Storage.

Ce choix supprime tout le débat sur les écritures concurrentes : pas de double producteur, pas de collision de noms, pas de verrou hasardeux entre NFS et écriture locale. L'App (Backoffice V2, via son Nginx) ne lit incoming/ qu'à la demande et rarement — de l'ordre d'un cas sur cent — lorsqu'un client ou un traitement en a besoin, en résolvant le bon chemin via le mappage / les liens propres au client. Le reste du temps, le dépôt du tiers n'est pas sollicité. En lecture seule, l'App ne crée ni ne supprime rien dans incoming/ — la zone reste celle du tiers.

Trois barrières de cloisonnement, indépendantes

La garantie « un seul écrivain par zone » et l'étanchéité entre clients reposent sur trois couches cumulatives — si l'une cède, les autres tiennent. Surtout, la décision appartient au Storage : ProFTPD propose, le Storage dispose.

Matrice des exports (modèle retenu)

Exemple pour un client, avec la décision imposée. Chaque sous-zone n'a qu'un seul rw, accordé à une seule IP.

Côté Storage, /etc/exports :

/srv/storage/.../contenus  10.0.0.40(ro,sync,no_subtree_check,root_squash)
/srv/storage/.../contenus  10.0.0.10(ro,sync,no_subtree_check)
/srv/storage/.../incoming  10.0.0.40(rw,sync,no_subtree_check,root_squash)
/srv/storage/.../incoming  10.0.0.10(ro,sync,no_subtree_check)

Vérification automatisable

Pour s'assurer qu'aucune sous-zone n'est exportée rw à deux machines (ce qui réintroduirait le risque), un contrôle simple, posable en CI ou en hook de la VM Logs :

# Liste les zones rw en double — sortie vide = règle d'or respectée
grep -oP '^\S+(?=.*\brw\b)' /etc/exports | sort | uniq -d

Dimensionnement I/O

Le NFS reporte les lectures des consommateurs (ProFTPD, App) sur le disque du Storage. Pour des fichiers de plusieurs Go, prévoir du stockage rapide (SSD/NVMe, au moins pour les fichiers chauds) et un réseau interne dimensionné (viser 10 Gb/s entre Storage et consommateurs ; du 1 Gb/s sature vite). Les bornes en HTTP ne pèsent pas sur le NFS — leurs I/O restent locales au Storage.

Windows
& GLPI multi-scope.

Trois VM portant des services qui ne sont pas le cœur du métier mais dont l'infrastructure assure l'hébergement, l'isolation et l'accès contrôlé. Une VM Windows pour une application propriétaire, et deux GLPI distincts pour deux clients aux périmètres étanches.

VM Windows — Service propriétaire

Hébergement d'une application tierce qui nécessite un OS Windows. Le choix de l'OS est subi (contrainte éditeur), pas choisi. La VM est donc traitée comme une boîte noire à cloisonner :

• ▸ Aucune exposition Internet directe — accès via le Front uniquement
• ▸ Pas d'accès SSH (pas natif Windows) — administration via RDP encapsulé dans Guacamole
• ▸ Backup VM-level (snapshot complet) car backup applicatif fin non maîtrisable
• ▸ Mises à jour OS pilotées séparément du reste de l'infra

VM GLPI — Double instance, deux scopes

Deux clients utilisent GLPI (helpdesk + asset management) avec des besoins, des utilisateurs et des données strictement séparés. Plutôt qu'une instance unique avec multi-tenant fragile, deux instances jumelles totalement isolées :

Avantage de l'isolation par VM : aucune chance qu'une modification ou un bug sur l'instance A impacte l'instance B. Aucun risque qu'un audit du client A expose les données du client B. Aucun couplage de version, de plugin, ou de schéma.

Le plan de management,
hors-bande.

L'administration de l'infrastructure ne passe jamais par les ports publics (HTTPS, SFTP). Elle emprunte un canal séparé, hébergé sur un VPS externe, accessible aux admins via WireGuard, avec Guacamole pour les sessions graphiques et un bastion custom pour les sessions SSH à redirection dynamique.

Pourquoi hors-bande (VPS externe) ?

Le plan de management ne dépend pas de l'infrastructure qu'il administre. Si la VM Front tombe, ou si tout le réseau privé est compromis, les admins gardent accès via le VPS externe. C'est le principe du plan de management hors-bande : on s'administre à côté de ce qu'on administre, pas à travers.

Le VPS lui-même est minimaliste : seuls WireGuard, Guacamole et le bastion tournent dessus. Pas d'application métier, pas de données sensibles stockées. Sa compromission éventuelle n'expose que les sessions en cours, pas les bases de données ou les fichiers métier.

Segmentation réseau : VLAN prod interne, management & backup sur le RPN

Les trois VLAN ne sont pas au même niveau. Le VLAN production est interne à chaque hyperviseur : il sert uniquement à l'intercommunication des VM, n'est pas routé vers l'extérieur et n'apparaît pas sur le réseau inter-serveurs. Les VLAN management et backup, eux, sont portés par le LAN-RPN — le réseau privé inter-serveurs de l'hébergeur (type Scaleway/Online) — qui relie les deux serveurs (prod et backup) et le VPS. Sur ce RPN, management et backup sont deux VLAN distincts.

Les hyperviseurs sont à cheval sur management et backup (via le RPN), jamais sur la production — qui reste confinée dans l'hyperviseur. Le VPS est physiquement sur le RPN, rattaché au VLAN management. Sur le RPN, on distingue trois VLAN : management (administration), backup (exposition des snapshots/dumps) et synchro (réplication des VM de prod vers le serveur backup) — chacun isolé des autres.

Le serveur backup héberge un réplica à froid des mêmes VM que la prod (Front, App, DB, Storage…), prêtes à démarrer mais sans lien Internet (les IP virtuelles ne sont pas basculées). Il n'y a pas de HA : en cas de désastre, on swap manuellement — simple et efficace dans un premier temps. La synchronisation prod→backup est régulière voire continue, via le VLAN synchro dédié.

Évolution prévue : un VLAN HA / intercom VM entre serveurs (live migration, réplication à chaud, cluster) viendra s'ajouter sur le même RPN, sans toucher au cloisonnement existant.

Le cloisonnement d'accès distant repose sur un mécanisme simple : le VPS expose deux endpoints WireGuard distincts, et c'est le tunnel utilisé qui détermine le VLAN atteignable. Le WG admin ne route que le VLAN management ; le WG du backup déporté ne route que le VLAN backup. Un tunnel ne peut pas atteindre le périmètre de l'autre.

Tableau
des flux réseau.

Récapitulatif des flux autorisés. Tout ce qui n'est pas listé est rejeté. La règle est l'isolation, l'exception est la communication explicite.

* Le flux Monitoring → Storage et l'emplacement d'écriture des données du monitoring dépendent des deux décisions d'architecture en suspens (voir § 05). La ligne ci-dessus reflète l'option « stockage sur la VM Storage », privilégiée pour sa cohérence avec l'existant.

** Le serveur de backup déporté n'atteint que le VLAN backup, via l'endpoint WG backup du VPS — jamais d'accès direct, ni à la production ni au management. Les hyperviseurs y exposent snapshots et dumps, que le serveur distant tire en pull chiffré (cf. § 08 et FIG. 06).

Principes de sécurité directeurs

Alpine en RAM,
systèmes immuables.

Les VM stateless tournent sur Alpine Linux avec la racine / montée en tmpfs — tout le système vit en mémoire. À chaque redémarrage, la VM repart d'un état connu et propre. La configuration est persistée localement, les données vivent sur le stockage central. Rien d'important ne réside dans la RAM volatile.

Le principe : diskless, run-from-RAM

Alpine est démarré puis sa racine est basculée en tmpfs : le système d'exploitation, les binaires et le runtime s'exécutent entièrement en mémoire. Le disque ne sert qu'à amorcer et à conserver une petite couche de configuration (mécanisme lbu / apkovl d'Alpine). Le système devient immuable : toute modification non explicitement persistée disparaît au reboot.

Quelles VM, et pourquoi

Seules les VM stateless passent en Alpine/RAM : elles ne portent aucune donnée propre, donc rien n'est perdu au reboot. Les VM à état restent sur disque classique.

Modèle de persistance à trois couches

Sur une VM stateless en RAM, on distingue clairement ce qui est volatile, ce qui est persisté localement, et ce qui vit ailleurs.

Stockage des données : le bon support pour chaque usage

La couche 3 ci-dessus (« data, jamais en local ») recouvre en réalité deux supports très différents, à ne pas confondre. NFS partage un système de fichiers (niveau fichier) ; iSCSI expose un disque brut (niveau bloc). Chacun a un usage précis.

La règle qui en découle, et qui désambiguïse la couche data :

Deux natures de données : fonctionnel local vs consolidé central

La migration des apps vers SQLite ne signifie pas que tout part en local. Le partage des responsabilités est net :

• L SQLite (par app) — fonctionnel local. L'état de fonctionnement courant de l'app, ce dont elle a besoin pour tourner. Embarqué, autonome, sans dépendance au serveur central. Régénérable — ce n'est pas une source de vérité à préserver.
• C MariaDB (Backoffice V2) — consolidé central. Les statistiques remontées par les apps, le multi-scope, tout ce qui doit être agrégé, requêté transversalement et archivé. Les stats ne restent pas dans le SQLite : elles sont remontées au backoffice et stockées en base. C'est la donnée qui compte vraiment, sauvegardée et soignée.

Conséquence sur le dimensionnement : une seule VM MariaDB (10.0.0.20, sur disque), dédiée au Backoffice V2 et à son multi-scope logique — pas une instance par client (l'isolation est assurée dans le schéma, pas par duplication de VM). Les apps, elles, n'encombrent plus le serveur central une fois migrées sur SQLite.

Bénéfices

• ▸ Immutabilité. Une compromission qui n'a pas atteint la couche de config disparaît au reboot. L'état connu est garanti.
• ▸ Surface d'attaque réduite. Alpine est minimaliste (musl, busybox), quelques dizaines de Mo, peu de paquets, peu de CVE.
• ▸ Déploiement reproductible. La config tient dans l'apkovl, versionnable. Recréer une VM identique est trivial — utile pour la HA future (cf. ARCHI-001).
• ▸ Rapidité & légèreté. Tout en RAM, démarrage rapide, empreinte disque minime.

Points d'attention

• ! Logs volatils. La RAM est effacée au reboot — les logs doivent être envoyés en syslog distant (collecteur central, ou plan de management) pour ne pas être perdus.
• ! Config à externaliser & versionner. L'apkovl doit être committé (lbu) et idéalement géré hors-VM (Git / Ansible) pour survivre à la perte de la VM.
• ! RAM à dimensionner. / en tmpfs consomme de la mémoire — à provisionner selon les besoins de chaque VM.
• ! Discipline « rien en local ». Toute donnée persistante doit aller sur le stockage central. Un fichier oublié sur / est perdu au prochain reboot.

Corollaire : une VM dédiée aux logs

Le point « logs volatils » ci-dessus impose un collecteur central. Les VM en RAM doivent envoyer leurs journaux ailleurs en temps réel, sinon ils disparaissent au reboot. C'est le rôle de la VM Logs & supervision (10.0.0.80), qui s'appuie sur une stack Elasticsearch.

Toutes les VM (RAM comme disque) y poussent leurs logs en syslog. La stack indexe, permet la recherche et la corrélation d'événements, et assure la rétention nécessaire à l'audit. C'est aussi le socle d'une supervision transverse : détection d'anomalies, tableaux de bord techniques, traçabilité de sécurité.

Stratégie de sauvegarde : la règle 3-2-1

Les sauvegardes suivent le principe 3-2-1 : trois copies des données, sur deux supports différents, dont une hors-site. La troisième copie est assurée par un petit serveur de backup déporté, physiquement situé dans un lieu différent.

Le serveur déporté ne reçoit que les données essentielles : bases de données, configurations, apkovl des VM RAM, métadonnées critiques. Il ne duplique pas les gros volumes facilement régénérables ou déjà redondés ailleurs — l'objectif est la survie au sinistre physique (incendie, dégât des eaux, vol, panne site), pas la copie exhaustive.

Pour la sécurité, le serveur déporté n'est raccordé ni à la production, ni au VLAN d'administration. Il vit sur un réseau parallèle dédié, monté en parallèle du VLAN management, dont le seul périmètre visible est un point de collecte de backups exposé par l'hyperviseur : snapshots / exports de VM et dumps applicatifs (DB, config, apkovl). Il ne voit rien d'autre — ni les VM vivantes, ni le management, ni les données applicatives en ligne.

Conséquence : une compromission de la production ne donne aucun chemin vers la copie hors-site, et une compromission du VLAN admin n'expose pas davantage le serveur déporté (réseau séparé, périmètre séparé, accès restreint aux seuls backups). Double protection contre les ransomwares qui cherchent à détruire les sauvegardes.

Une lecture
par public.

Cette infrastructure a quatre lecteurs naturels : ceux qui l'opèrent, ceux qui la pilotent, ceux qui la financent, et ceux qui la contrôlent. Voici ce qu'il faut retenir, selon le rôle.

▸ Pour le détail du sous-système Distribution de contenus (V2 backoffice, migration SFTP→HTTP, gestion des bornes), se référer au document jumeau ARCHI-001.