Partir de zéro pour poser les fondations [2/3] - Architecture cible

Après avoir posé le cadre théorique et analysé les limites de mon architecture actuelle dans la première partie, il est temps de se projeter dans la conception de mon architecture cible.

Sommaire

Architecture cible

Sans forcément dévoiler l’intégralité de mon projet, je dois répondre à un certain nombre de problématiques dans ma future infrastructure. Je vais les lister par domaine.

Réseau & Périmètre

Le réseau est la fondation de toute l’infrastructure. C’est la première couche à poser, et la plus importante à bien concevoir. S’il est mal construit, rien de ce qui vient ensuite ne pourra être sécurisé correctement.
Le périmètre, c’est la frontière entre mon infrastructure et le reste du monde : qui peut entrer, qui peut sortir, et qui doit être bloqué.
Mon architecture actuelle repose sur une box internet qui fait tout à la fois : routeur, pare-feu, point d’accès Wi-Fi… sans aucune segmentation (je vous partagerai son fonctionnement dans un prochain article). Tous les appareils (PC, smartphones, consoles, objets IoT) cohabitent sur le même réseau. C’est simple, mais cela expose une surface d’attaque trop large et incontrôlée.
Pour y remédier, mon architecture cible doit intégrer les composants suivants :

• un Firewall : C’est le gardien de l’entrée. Il remplace la fonction réseau de la box et contrôle l’ensemble des flux entre les différentes zones de l’infrastructure. C’est lui qui décidera ce qui peut communiquer avec quoi.
  Premiers candidats au banc d'essai : OPNsense, pfSense
• une Segmentation réseau par VLAN : Plutôt qu’un réseau unique où tout le monde se voit, je vais créer des zones isolées : LAN familial, Homelab, Production, IoT, DMZ, Management. Un appareil IoT compromis ne pourra pas atteindre mes serveurs de production.
• un Switch managé : Indispensable pour que la segmentation par VLANs soit effective au niveau physique. Sans switch managé, la segmentation VLAN ne peut pas être appliquée correctement sur l’ensemble du réseau physique.
• un VPN : Pour accéder à mon infrastructure depuis l’extérieur de manière sécurisée, sans exposer mes services directement sur Internet.
  Premiers candidats au banc d'essai : WireGuard, OpenVPN, Tailscale
• un DNS filtrant : Il joue le rôle de filtre à l’échelle du réseau : blocage des domaines malveillants, des publicités et des trackers pour tous les appareils connectés, sans rien installer sur chacun d’eux.
  Premiers candidats au banc d'essai : AdGuard Home, Pi-hole
• un Reverse proxy : Lorsqu’un service doit être accessible depuis l’extérieur, le reverse proxy joue le rôle d’intermédiaire. Il reçoit les requêtes entrantes et les redirige vers le bon service en interne, sans jamais exposer directement ce dernier. Il gère également les certificats TLS pour chiffrer les communications.
  Premiers candidats au banc d'essai : Traefik, Nginx Proxy Manager, Caddy

Infrastructure & Virtualisation

L’infrastructure physique est le socle sur lequel tout le reste va reposer. Pour ce projet, j’ai fait le choix d’une approche étape par étape : construire, apprendre, puis consolider, plutôt que d’investir massivement avant même d’avoir validé mes choix techniques.
La couche de virtualisation reposera sur Proxmox VE, une plateforme open source qui permet de gérer des machines virtuelles (VMs) et des conteneurs (LXC) depuis une interface web centralisée. C’est la technologie qui va me permettre de faire tourner plusieurs services et environnements sur un même équipement physique, en les isolant les uns des autres.
Les étapes clés de mon architecture cible sont les suivantes :

Phase 1 — L’architecture de démarrage :
La première étape est volontairement simple, pour me permettre de monter en compétences sans sur-investir dès le départ.

• mon Homelab : il sera créé à partir d’un premier nœud Proxmox. C’est ici que je vais expérimenter, tester des solutions, les valider (et aussi les casser 😅). C’est mon terrain de jeu, et il a le droit d’être instable.
• ma Production : Pour héberger mes premiers services de production, je vais m’appuyer dans un premier temps sur mon serveur NAS récemment acquis (Ugreen DXP4800 Plus et son OS natif, je vous le présenterai dans un prochain article). Ce n’est pas une architecture définitive, mais elle me permet de démarrer avec une base stable et disponible, avant de construire quelque chose de plus robuste.

Phase 2 — L’architecture cible :
L’objectif à terme est de faire évoluer les deux environnements vers quelque chose de plus professionnel.

• mon Homelab : Il grandira naturellement au fil des expérimentations, en ajoutant des nœuds, en testant de nouvelles configurations, en récupérant et en donnant une seconde vie à de vieux PCs.
• un Cluster de Production : La cible est de mettre en place un cluster Proxmox avec 3 nœuds. Ce nombre n’est pas choisi au hasard : 3 nœuds, c’est le minimum pour garantir le quorum, le mécanisme qui permet au cluster de continuer à fonctionner si l’un des nœuds tombe en panne, et de trancher en cas de désaccord entre les membres.
• mes Sauvegardes : J’adopterai la règle du 3-2-1 : 3 copies des données, sur 2 supports différents, dont 1 hors site. Les détails de cette mise en œuvre feront l’objet d’un article dédié.
  

Il ne faudra pas oublier la mise en place d’un Onduleur (UPS) qui sera un équipement indispensable pour protéger l’infrastructure contre les coupures et surtensions électriques. En cas de panne de courant, l’onduleur assurera une alimentation de secours le temps d’effectuer un arrêt propre des serveurs pour éviter ainsi une corruption de données. Il sera également à intégrer à la supervision pour déclencher automatiquement les arrêts si nécessaire.

Identité & Accès

La gestion des identités et des accès est le pilier central d’une approche Zero Trust : plutôt que de faire confiance à un appareil parce qu’il est sur le bon réseau, chaque accès doit être authentifié, autorisé, et tracé, peu importe d’où il vient.
C’est une couche que je vais construire progressivement, en profitant du homelab pour tester et comparer les solutions disponibles avant de retenir celles qui intégreront mon environnement de production.
Les points clés sont les suivants :

• SSO & Annuaire centralisé : Un SSO (Single Sign-On) permet de centraliser l’authentification : un seul compte, une seule connexion, pour accéder à l’ensemble des services. C’est plus confortable pour l’utilisateur, et surtout bien plus simple à sécuriser et à administrer. Mon homelab sera le terrain idéal pour comparer les solutions disponibles.
  Premiers candidats au banc d'essai : Authentik, Keycloak, Lldap
• MFA (Authentification Multi-Facteurs) : Quel que soit l’outil SSO retenu, le MFA sera obligatoire sur tous les accès sensibles. Là encore, le homelab me permettra d’évaluer ce qui offre le meilleur équilibre entre sécurité et praticité au quotidien.
  Premiers candidats au banc d'essai : Ente Auth, clé YubiKey
• Gestion des secrets : Mots de passe, tokens, clés API, credentials de services, tous ces secrets ne doivent jamais traîner en clair dans un fichier de configuration ou un dépôt Git. Deux besoins distincts sont à couvrir :
  • Les secrets applicatifs utilisés par les services et les pipelines CI/CD.
    Premiers candidats au banc d’essai : HashiCorp Vault, Infisical, OpenBao
  • Les mots de passe personnels à gérer dans un gestionnaire auto-hébergé.
    Premiers candidats au banc d’essai : Vaultwarden, Bitwarden
• Certificats TLS : Tout service exposé, même en interne, doit communiquer en HTTPS. La gestion des certificats TLS sera automatisée si possible pour ne jamais avoir à renouveler un certificat manuellement et ne jamais se retrouver avec un service inaccessible à cause d’un certificat expiré.
  Premiers candidats au banc d'essai : Let's Encrypt, cert-manager, Smallstep
• Gestion des accès privilégiés : Mon objectif est de mettre en place une gestion des accès privilégiés rigoureuse : comptes dédiés, droits limités au strict nécessaire, et traçabilité complète des actions sensibles, conformément au principe du moindre privilège.
  Premiers candidats au banc d'essai : Teleport, Boundary

Déploiement & Automatisation

La couche déploiement et automatisation va donner à mon infrastructure sa dimension véritablement DevOps et SRE. J’ai un double objectif : ne plus jamais déployer manuellement, et pouvoir reconstruire l’intégralité de l’infrastructure en quelques clics si nécessaire.
Voici les éléments qui vont m’aider dans mon projet :

• Git (la source de vérité unique) : Tout ce qui constitue mon infrastructure (son code, sa configuration, la définition des services) vivra dans Git. En respectant le principe du GitOps, l’état souhaité de l’infrastructure est décrit dans des fichiers versionnés, et tout changement passe obligatoirement par une modification dans le dépôt.
• IaC (Infrastructure as Code) : Je dois pouvoir recréer une infrastructure en quelques clics. En cas de panne majeure ou de migration vers de nouveaux nœuds, l’infrastructure sera reconstruite de manière identique et reproductible.
  Premiers candidats au banc d'essai : OpenTofu, Terraform, Pulumi
• CaC (Configuration as Code) : Chaque configuration (installation de logiciels, paramètrage, gestion des utilisateurs) est décrite sous forme de playbooks versionnés dans Git.
  Premiers candidats au banc d'essai : Ansible, Salt
• CI/CD (Intégration continue et Livraison continue) : Des pipelines vont automatiser l’installation d’un service depuis son développement jusqu’à sa mise en production. Mon approche sera basée sur un pipeline CI/CD par environnement : un pipeline dédié au homelab, un autre dédié à la production, chacun avec ses propres variables et ses propres règles de déploiement.
  Premiers candidats au banc d'essai : GitHub Actions , Gitea + Forgejo, Woodpecker CI, , GitLab CI
• Orchestration & GitOps : Pour les services conteneurisés, je prévois d’expérimenter K3s (une distribution Kubernetes légère parfaitement adaptée au homelab) pour assurer l’orchestration des conteneurs. Il sera nécessaire ici d’utiliser un outil GitOps pour synchroniser en permanence l’état réel du cluster avec l’état décrit dans Git, afin que chaque modification soit poussée dans le dépôt soit automatiquement appliquée sur l’environnement cible.
  Premiers candidats au banc d'essai (Orchestration de conteneurs) : K3s, Docker Swarm, Nomad
  Premiers candidats au banc d'essai (GitOps) : ArgoCD, Flux

Comme pour les couches précédentes, le homelab sera le terrain de validation de ces choix technologiques avant leur adoption en production (ce qui sera je pense l’occasion de rédiger une bonne série d’articles dédiés 😉).

Sécurité opérationnelle

La couche Sécurité Opérationnelle va donner à mon infrastructure une dimension défensive et proactive. L’objectif est triple : détecter ce qui se passe sur mon réseau, évaluer mon niveau d’exposition, et anticiper les attaques avant qu’elles n’arrivent.
Pour réussir, je vais devoir mettre en place les éléments suivants :

• un IDS et un IPS pour la détection et prévention d’intrusion : Un IDS (Intrusion Detection System) analyse le trafic réseau en temps réel pour détecter des comportements suspects (scans de ports, tentatives d’exploitation, trafic anormal). Un IPS (Intrusion Prevention System) va plus loin : il bloque automatiquement le trafic identifié comme malveillant.
  Premiers candidats au banc d'essai : Suricata, Snort, Zeek
• un SIEM pour la centralisation et la corrélation des événements : Un SIEM (Security Information and Event Management) collecte les logs de l’ensemble de l’infrastructure (firewall, serveurs, services, IDS) et les corrèle pour détecter des patterns d’attaque qu’aucun équipement ne verrait seul. Il joue le rôle de tour de contrôle de la sécurité opérationnelle.
  Premiers candidats au banc d'essai : Wazuh, Elastic Security, Graylog, OpenSearch
• Antivirus et EDR pour la protection des endpoints : chaque machine de l’infrastructure doit être protégée individuellement. Un antivirus pour détecter les menaces connues par signature et un EDR (Endpoint Detection and Response) pour analyser en temps réel ce qui se passe sur chaque endpoint et détecter des activités suspectes, même inconnues jusqu’alors.
  Premiers candidats au banc d'essai : ClamAV, Wazuh, LimaCharlie
• des scan de vulnérabilités pour identifier mes propres failles de sécurité avant qu’un attaquant ne le fasse.
  Premiers candidats au banc d'essai : OpenVAS, Trivy, Nuclei
• Surveiller mon Exposition Externe c’est à dire ce que le monde voit de mon infrastructure, services exposés sur Internet, ports ouverts, bannières de services, certificats TLS. Je vais devoir consulter régulièrement ce que ces outils de scan externe voient de mon infrastructure pour m’assurer que rien n’est exposé involontairement.
  Premiers candidats au banc d'essai : Shodan, Censys, SSL Labs, Security Headers , Have I Been Pwned
• des Honeypots pour tendre des Pièges aux Attaquants : Un honeypot est un leurre (un service ou une machine) qui simule une cible vulnérable pour attirer les attaquants et observer leurs techniques sans risquer l’infrastructure réelle. C’est à la fois un outil de détection précoce et une formidable source d’apprentissage.
  Premiers candidats au banc d'essai : OpenCanary, T-Pot, Cowrie

Comme pour les autres couches, le homelab sera le terrain d’exploration pour tester des solutions, avec en perspective des articles dédiés qui promettent d’être particulièrement animés (surtout si je me fais attaquer 😉).

Observabilité & Fiabilité

L’observabilité est la capacité à comprendre ce qui se passe à l’intérieur d’un système en observant ce qu’il produit de l’extérieur (logs, métriques, traces). Sans elle, gérer une infrastructure revient à conduire les yeux fermés.
L’observabilité repose sur trois sources de données complémentaires :

• Les métriques : des mesures numériques collectées dans le temps comme la consommation CPU, la mémoire disponible, la latence d’un service ou le nombre de requêtes par seconde. Elles permettent de visualiser les tendances et de détecter les anomalies.
• Les logs : des journaux d’événements produits par chaque service et chaque équipement. Ils permettent de comprendre ce qui s’est passé et pourquoi quelque chose ne fonctionne pas correctement.
• Les traces : le suivi du chemin parcouru par une requête à travers les différents services de l’infrastructure. Particulièrement utile dans une architecture distribuée pour identifier l’endroit où une lenteur ou une erreur s’est produite.
  

Je vais devoir choisir la stack d’observabilité que je vais implémenter parmi 2 des approches principales utilisées dans le monde professionnel et dans la communauté homelab :

• Prometheus + Grafana + Loki : Prometheus collecte les métriques, Loki centralise les logs, et Grafana les visualise dans des tableaux de bord personnalisables.
• Elastic Stack (ELK) : Elasticsearch, Logstash et Kibana forment une solution complète mais aussi plus gourmande en ressources.
  

Le homelab permettra de comparer ces deux approches avant de retenir celle qui intégrera l’environnement de production avec bien sûr un article dédié pour détailler ce comparatif.

Je prévois aussi la mise en place d’une solution d’Alerting pour être notifié avant qu’une panne devienne un problème. L’objectif est de mettre en place des alertes intelligentes, pas trop nombreuses pour ne pas créer du bruit, mais suffisamment précises pour intervenir avant qu’une situation dégradée ne devienne une vraie panne. Le canal de notification qu’il soit par email, par notification mobile, ou message sur Discord ou Telegram par exemple, sera expérimenté dans le homelab pour trouver ce qui convient le mieux au quotidien.
Je mettrai quand même quelques limites : pas d’astreinte de nuit ! 😅 Les alertes seront dimensionnées en conséquence pour signaler, tracer, et traiter le lendemain matin.
Premiers candidats au banc d’essai : Alertmanager, Grafana Alerting, ntfy, Gotify

Enfin un service d’Uptime Monitoring sera à installer pour vérifier qu’un service répond correctement depuis l’extérieur, et pas seulement qu’il tourne en interne. C’est la différence entre “le serveur est démarré” et “le service est réellement accessible et fonctionnel pour mes utilisateurs”.
Premiers candidats au banc d’essai : Uptime Kuma, Gatus, Healthchecks.io

Je souhaite également pouvoir monitorer ma consommation électrique et la mesurer dans mon infrastructure, prise par prise.

Pour finir, c’est ici que les notions SRE (SLI, SLO et Budget d’Erreur) vont apparaître pour mesurer, suivre et gérer la fiabilité de mon infrastructure.

Services & Applications

Toutes les couches vues précédemment existent pour une bonne raison : héberger des services utiles au quotidien, pour moi et ma famille. On retrouvera ici les applications que mes utilisateurs vont réellement utiliser.
Mon approche sera de privilégier les solutions open source à chaque fois que c’est possible, pour des raisons de confidentialité, de contrôle des données, de coût, mais aussi parce que la communauté open source produit aujourd’hui des alternatives sérieuses aux grands services cloud du marché.
Voici les premiers services qui trouveront naturellement leur place dans mon architecture cible, une fois les fondations posées :

• Streaming vidéo et audio : pour accéder à mes contenus personnels depuis n’importe quel appareil de la maison, sans dépendre d’un abonnement tiers.
  Premiers candidats au banc d'essai : Jellyfin, Navidrome, Funkwhale
• Gestion de photos : pour centraliser, organiser et partager les photos de famille, en gardant le contrôle total sur mes données personnelles.
  Premiers candidats au banc d'essai : Immich, Photoprism, Pigallery2
• Domotique : Home Assistant s’impose ici comme le choix naturel, plébiscité par la communauté homelab pour son écosystème et sa compatibilité avec une large gamme d’appareils connectés.
• Synchronisation de fichiers : pour une alternative auto-hébergée à Google Drive ou Dropbox, pour synchroniser et partager des fichiers entre tous les appareils de la famille.
  Premiers candidats au banc d'essai : Nextcloud, Seafile, Syncthing
• Gestionnaire de mots de passe : pour centraliser et sécuriser les mots de passe, avec une solution auto-hébergée compatible avec les principaux appareils et navigateurs.
  Premiers candidats au banc d'essai : Vaultwarden, Bitwarden
• Gestion de budget : pour suivre les finances personnelles sans confier ses données bancaires à un service tiers.
  Premiers candidats au banc d'essai : Firefly III, Actual Budget, Maybe
• Émulation de jeux vidéo rétro : parce qu’il faut garder du temps pour s’amuser. 🎮
  Premiers candidats au banc d'essai : EmulatorJS, RetroArch, Romm
• Bibliothèque de livres numériques : organiser et partager des documents sans passer par des services en ligne.
  Premiers candidats au banc d'essai : Calibre-Web, Kavita
• Auto-hébergement de LLM : L’essor des modèles de langage open source ouvre une nouvelle perspective : héberger son propre LLM local, via des outils comme Ollama, pour expérimenter avec l’IA générative sans dépendre d’un service cloud et en gardant le contrôle total sur ses données.
  Premiers candidats au banc d'essai : Ollama, Open WebUI, LM Studio, LocalAI
• Et bien d’autres à venir…
  

L’univers du self-hosting offre des possibilités infinies et de quoi remplir un backlog sans fond ! L’avenir de 🐼 PandaCyberLab.dev est assuré.
Chaque service fera l’objet d’un article dédié, depuis son installation et son test dans le homelab jusqu’à son déploiement en production s’il convient à mon projet.

A suivre

Avoir une cible, c’est bien, mais comment y parvenir ? Dans la troisième et dernière partie, nous verrons concrètement comment matérialiser ce projet à travers une roadmap stratégique.