Architecture homelab
Cette page synthétise l'architecture décrite dans mon rapport technique : un homelab personnel construit autour de Proxmox VE, Debian 13, de VMs séparées par rôle, et d'une logique de durcissement progressive.
L'objectif n'est pas de présenter une architecture parfaite, mais une plateforme de travail maintenable : comprendre ce qui tourne, limiter les privilèges, documenter les choix et automatiser les tâches répétitives.
Base matérielle
Le serveur a été assemblé composant par composant pour disposer d'un environnement de virtualisation dédié aux expérimentations système et sécurité.
| Processeur | Intel Xeon E5-2680 v4 |
|---|---|
| Mémoire | 128 Go DDR4 ECC |
| Plateforme | X99 micro-ATX |
| Stockage données | 2 x 2 To RAID 1, 2 x 4 To RAID 1 |
| Stockage système | SSD NVMe 128 Go dédié à Proxmox VE |
Architecture logique
Le homelab repose sur plusieurs machines virtuelles, chacune associée à un rôle précis. Cette séparation remplace une première approche plus compacte basée sur Ubuntu LTS et Docker.
Le passage à des VMs séparées est moins rapide à déployer, mais il rend chaque service plus lisible : système installé, ports exposés, règles de filtrage, comptes utilisés et données à sauvegarder.
- Proxmox VE comme hyperviseur et point de gestion.
- Debian 13 minimal comme base principale des VMs Linux.
- VM d'administration pour Ansible, accès contrôlés et maintenance.
- Services personnels séparés selon leur rôle : stockage, forge Git, automatisation, supervision.
Modèle de privilèges
L'administration distante directe en root est désactivée. Les accès passent par SSH avec clé, et l'élévation est réservée aux actions qui la nécessitent réellement.
| Niveau | Compte | Usage | Privilèges |
|---|---|---|---|
| 0 | Compte de service | Exécution applicative | Minimum nécessaire |
| 1 | Compte nominatif | Administration courante | Élévation contrôlée via sudo |
| 2 | root | Maintenance exceptionnelle | Tous privilèges |
Template Debian durci
Le template tpl-debian-hardened sert de base commune pour les nouvelles VMs. Il regroupe les premiers réglages de sécurité afin d'éviter de répéter les mêmes actions manuellement.
- Partition racine légère et séparation de /srv pour les données applicatives.
- Montage de /tmp en tmpfs, rotation des journaux et limitation des services installés.
- Mises à jour de sécurité via unattended-upgrades.
- SSH durci : clé uniquement, root distant interdit, utilisateurs autorisés restreints.
- Filtrage nftables en deny by default sur les flux entrants.
Audit et maintien en condition
Les outils de sécurité sont utilisés avec un objectif pratique : comprendre, détecter et maintenir. AIDE et auditd servent à préparer le contrôle d'intégrité et la journalisation, tandis que Lynis fournit des pistes d'amélioration à tester avant généralisation.
Les recommandations ne sont pas appliquées automatiquement : je garde en priorité les mesures utiles dans mon contexte et maintenables sur la durée.
Automatisation Ansible
Ansible est hébergé sur une VM d'administration et sert à homogénéiser les configurations après les premiers déploiements manuels. L'objectif est de réduire les oublis et de garder une base cohérente entre les VMs.
| Élément | Fonction |
|---|---|
| inventory | Liste des machines virtuelles. |
| playbooks | Exécution de tâches groupées. |
| roles | Organisation logique des configurations. |
| tasks | Actions appliquées aux systèmes. |
| templates | Fichiers de configuration dynamiques. |
Mise en perspective
Ce homelab reste volontairement personnel et limité, mais il sert de terrain d'apprentissage concret : construire une première version, observer les limites, corriger, puis documenter les choix.
Le point important est de ne pas appliquer les recommandations de sécurité de manière automatique. Une mesure doit être compréhensible, adaptée au contexte, testable et maintenable.