Architecture Système & Réseau

1. Infrastructure Matérielle & Stockage

Le cœur logique du système repose sur une architecture monocarte à faible consommation d’énergie, optimisée pour le service continu (24/7). Afin de pallier la dégradation rapide des cartes SD soumises à de nombreux cycles d’écriture, une stratégie de déportation du stockage a été implémentée.

Hôte de calcul : Raspberry Pi 5 (Architecture ARM64 v8, OS Linux Debian-based).
Sous-système de stockage : Disque dur externe haute capacité (Western Digital MyBook) monté sur le système de fichiers local.
Répartition des volumes :
- /mnt/bureau/html/wordpress : Racine de production de l’application web.
- /mnt/MyBook/ocis-data/ : Persistance des données et métadonnées du cloud (Proxy et IDP).

2. Topologie Réseau & Configuration DNS

L’infrastructure utilise une adresse IP publique unique. Le routage et le cloisonnement du trafic vers les bons services applicatifs s’effectuent par multiplexage de noms au niveau de la couche application (Modèle OSI, Couche 7).

Zone DNS (Gestionnaire Namecheap)

La zone de nommage est segmentée en deux domaines distincts pour isoler logiquement le site public du cloud de production :

Zone 1 (marieevebaron.com) : Enregistrements de type A pointant vers la passerelle résidentielle, avec alias canonique (www).
Zone 2 (cgmeb.com) : Enregistrement de type A sur le sous-domaine cloud.cgmeb.com configuré pour cibler la même adresse IP publique.

Configuration du Pare-feu (Port Forwarding)

Seuls deux ports WAN sont exposes vers le Raspberry Pi, limitant de fait la surface d’attaque extérieure :

Port 80 (HTTP) : Requis pour les redirections d’utilisateurs et l’interrogation automatique des serveurs de certification.
Port 443 (HTTPS) : Point d’entrée unique pour tous les flux de données chiffrés.

3. Pile Logicielle & Serveur Web

Le serveur HTTP Apache fait office de chef d’orchestre réseau en interceptant toutes les connexions entrantes sur la machine.

Apache VirtualHosts

Deux serveurs virtuels principaux cohabitent. À la réception d’une requête, Apache analyse l’en-tête Host. S’il s’agit du domaine principal, il sert les fichiers de l’application WordPress. S’il s’agit du domaine cloud, il aiguille temporairement le trafic vers le dossier racine requis pour la maintenance de sécurité.

Base de données & PHP

Le moteur WordPress s’appuie sur une pile LAMP classique optimisée (PHP-FPM et serveur MariaDB), dont les caches de base de données et les tables d’indexation résident également sur le stockage externe pour maximiser le taux de transfert (I/O).

4. Sécurisation Cryptographique & Automatisation (Certbot)

La sécurité repose sur l’implémentation de certificats SSL/TLS émis par l’autorité de certification Let’s Encrypt via le protocole ACME.

Mécanisme de défi HTTP-01

L’infrastructure utilise un certificat de type SAN (Subject Alternative Name) englobant tous les domaines en une seule clé. La validation est entièrement automatisée par le client Certbot via le défi HTTP-01 :

Certbot génère un jeton d’authentification éphémère.
Le plugin Apache de Certbot expose ce jeton dans le répertoire public de transit /.well-known/acme-challenge/ de chaque domaine.
Les serveurs de Let’s Encrypt valident le jeton via le port 80, puis émettent le certificat valide pour 90 jours.

Le Pipeline Post-Hook (Automatisation oCis)

Puisque le service Cloud possède son propre magasin de clés cryptographiques déporté sur le volume externe, un script d’infrastructure événementiel (/usr/local/bin/renew-ocis.sh) a été injecté dans le démon Certbot (renewal-hooks/deploy/). Lors de chaque renouvellement réussi, le script exécute la routine automatique suivante :

# Extraction et copie des liaisons logiques (-L)
cp -L /etc/letsencrypt/live/cloud.cgmeb.com/fullchain.pem /mnt/MyBook/ocis-data/proxy/server.crt
cp -L /etc/letsencrypt/live/cloud.cgmeb.com/privkey.pem /mnt/MyBook/ocis-data/proxy/server.key
cp -L /etc/letsencrypt/live/cloud.cgmeb.com/fullchain.pem /mnt/MyBook/ocis-data/idp/server.crt
cp -L /etc/letsencrypt/live/cloud.cgmeb.com/privkey.pem /mnt/MyBook/ocis-data/idp/server.key
# Réalignement des permissions strictes
chown -R root:root /mnt/MyBook/ocis-data/proxy /mnt/MyBook/ocis-data/idp

La surveillance est gérée de manière transparente par un minuteur système (certbot.timer) qui inspecte l’état de validité deux fois par jour.

[ Emplacement de bloc : Schéma 2 – Cinématique du Défi ACME et Déploiement Post-Hook ]

5. Écosystème ownCloud Infinite Scale (oCis)

La plateforme de productivité et de stockage de fichiers repose sur l’architecture moderne ownCloud Infinite Scale écrite en Go. Ce choix technique élimine les goulots d’étranglement des architectures cloud traditionnelles en s’affranchissant des bases de données de type PHP/MySQL au profit d’un système de métadonnées ultra-rapide et décentralisé.

Sécurité & Architecture Micro-Services

L’instance est divisée en plusieurs micro-services étanches, notamment le Proxy (passerelle d’entrée du trafic) et l’IDP (Identity Provider). L’identité et les sessions applicatives sont protégées par le protocole natif OpenID Connect (OIDC) / OAuth 2.0. Les jetons de connexion ne transitent jamais en clair et sont signés par le certificat local mis à jour dynamiquement par le script post-hook.

Écosystème Applicatif Multi-Plateforme

L’accès aux données centralisées sur le disque dur externe MyBook est assuré en temps réel par une synchronisation chiffrée de bout en bout sur l’ensemble des terminaux clients :

📱 Mobilité (iOS & Android)
Accès sécurisé via l’application native d’ownCloud. Authentification unique OIDC, mise en cache locale chiffrée et synchronisation automatique des flux multimédias.

💻 Bureau (Windows)
Intégration transparente au système de fichiers via le client de synchronisation oCis. Gestion des fichiers à la demande (VFS) pour préserver l’espace disque local de la station de travail.

6. Service Courriel & Authentification (Google Workspace)

Afin d’assurer une disponibilité maximale et une séparation étanche entre le serveur web domestique et les communications critiques, la gestion des courriels du domaine principal est déléguée aux infrastructures de Google Workspace.

La validation et la réputation des courriels sortants sont assurées par une triple couche de protocoles cryptographiques injectée dans la zone DNS de Namecheap :

MX (Mail Exchanger) : Enregistrements configurés pour router la réception des flux de messagerie directement vers les serveurs redondants de Google.
SPF (Sender Policy Framework) : Enregistrement TXT spécifiant de manière stricte que seuls les serveurs de l’infrastructure Google sont légitimes pour émettre des e-mails au nom du domaine.
DKIM (DomainKeys Identified Mail) : Clé asymétrique de 2048 bits générée sur la console d’administration Google et publiée dans la zone DNS (sélecteur google._domainkey). Chaque courriel sortant est signé électroniquement par le serveur émetteur, interdisant toute altération du message en cours de transit.

[ Emplacement de bloc : Schéma 3 – Architecture de Messagerie et Flux d’Authentification SPF/DKIM ]

7. Matrice de Routage et Spécifications Logiques

Domaine FQDN	Port Externe	Cible Logicielle	Sécurité / Chiffrement	Point d’Ancrage Stockage
`marieevebaron.com` `www.marieevebaron.com`	80 (Redirection) 443 (HTTPS)	Serveur Web Apache + Pile LAMP	SSL Certbot (Plugin Apache)	Disque Externe (Volume WordPress)
`cloud.cgmeb.com`	80 (Transit ACME) 443 (HTTPS)	ownCloud Infinite Scale (oCis)	SSL Certbot (Script Deploy-Hook)	Disque Externe (Volumes oCis Proxy/IDP)
`marieevebaron.com` (E-mail)	N/A (Flux Cloud)	Google Workspace / Gmail	Enregistrements MX + SPF + DKIM (2048-bit)	Infrastructures de stockage Google

Serveur Multi-Domaine