Infrastructure physique / Déploiement vérifié, durcissement en cours

Proxmox VE sur serveur physique

Premier nœud Proxmox VE physique installé et exploité en mode autonome, avec chaîne de démarrage renforcée, accès d'administration restreints et stockages provisoires documentés.

Proxmox VE Secure Boot LUKS2 FIDO2 RBAC firewall

Architecture publique du premier hôte Proxmox VE physique — Vue publique : hyperviseur autonome, chaîne de confiance, administration bornée, stockages locaux provisoires et dépendances futures.

Inventorier

Qualifier matériel, firmware, interfaces et supports avant de fixer les rôles de stockage et de réseau.

Installer

Déployer l'hyperviseur sur un socle chiffré avec démarrage UEFI et artefact signé.

Durcir

Réduire les services, séparer les identités et limiter SSH et l'interface Web aux sources autorisées.

Valider

Tester démarrage, authentification, filtrage, temps, stockage et retours arrière avant toute charge utile.

Contexte

Le problème réel.

Un hyperviseur physique concentre les accès d'administration, les secrets de démarrage, le stockage et les futures charges du lab. Il devait être durci et qualifié sans prétendre que le cluster, la sauvegarde distante ou le réseau final étaient déjà disponibles.

Objectifs

Ce que la solution devait garantir.

Exploiter un premier hyperviseur physique autonome sans dépendre d'un cluster encore inexistant.
Protéger la chaîne de démarrage et conserver plusieurs voies de récupération testées.
Restreindre l'administration distante à des identités nominatives et à une source explicitement autorisée.
Distinguer les stockages locaux provisoires de la future sauvegarde distante et testée.

Architecture publique

Structure documentée, détails exploitables retirés.

Nœud autonome. Le premier hôte fonctionne seul ; haute disponibilité et cluster restent désactivés tant qu'un second nœud qualifié n'existe pas.
Boot trust. Secure Boot, UKI signée, LUKS2, TPM2, jetons FIDO2 et clé de récupération forment des voies complémentaires.
Plans d'accès. SSH et l'interface Proxmox utilisent des identités séparées et un filtrage limité à la source d'administration transitoire ; la qualification WebAuthn reste différée jusqu'au domaine et au certificat adaptés.
Stockage. Système, données de VM et sauvegardes locales provisoires sont distingués ; la copie distante reste un chantier futur.

Exemples anonymisés

Ce qui peut être montré sans exposer le système réel.

État de la plateforme

Le jalon réel est publié sans version précise, adresse, nom d'hôte ou inventaire matériel exploitable.

hyperviseur        installé sur hôte physique
mode                nœud autonome
boot                UEFI + artefact signé
volume système      chiffré
cluster / HA        non activés
second nœud         différé

Plans d'administration

Les contrôles démontrés restent visibles sans publier les identités, les facteurs ni la source réseau réels.

SSH                 clé matérielle uniquement
compte root distant refusé
interface Web       identité nominative ; WebAuthn différé
pare-feu entrant    politique restrictive
source autorisée    poste transitoire unique
test négatif        autre client refusé

Réalisé et différé

La page distingue l'hyperviseur opérationnel des dépendances encore absentes.

installation        validée
boot trust          validé sur le jalon documenté
stockages locaux    actifs mais provisoires
réseau final        migration à effectuer
backup distant      à construire et tester
audit de clôture    encore ouvert

Runbook public

Commandes et états attendus issus de la documentation privée.

Les commandes ci-dessous sont volontairement anonymisées: chemins, noms de machines, interfaces, dépôts, périphériques et actions destructrices sont remplacés par des placeholders.

Runbook privé: architecture et clôture du hardening Proxmox

Contrôle du nœud

Commandes anonymisées

hostnamectl
pveversion -v
uname -r
systemctl --failed
ip -brief address
ss -lntup

État attendu

identité et version correspondent à la baseline privée
noyau démarré cohérent avec le paquet attendu
aucune unité critique en échec
interfaces et sockets expliqués avant toute mutation

Runbooks privés: OpenSSH, RBAC et pare-feu hôte

Contrôle des accès

Commandes anonymisées

sudo sshd -t
sudo sshd -T | rg 'permitrootlogin|passwordauthentication|authenticationmethods|allowgroups'
sudo pve-firewall status
sudo pveum user list
sudo pveum group list
sudo pveum acl list

État attendu

syntaxe SSH valide
root et mots de passe distants refusés
authentification publique et groupe autorisé confirmés
pare-feu actif
droits hérités par groupe, sans ACL directe inutile

Runbooks privés: boot trust et stockages provisoires

Contrôle boot et stockage

Commandes anonymisées

mokutil --sb-state
sudo cryptsetup luksDump <system-partition>
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
sudo pvesm status

État attendu

Secure Boot actif
jetons LUKS attendus présents sans publier leurs identifiants
volumes et points de montage cohérents
stockages Proxmox actifs mais toujours qualifiés de provisoires

Travail réalisé

Décisions techniques publiables.

Socle installé

Proxmox VE fonctionne sur un hôte dédié avec démarrage signé et volume système chiffré.

Accès durcis

SSH par clé matérielle, refus de root à distance et RBAC Proxmox nominatif ont été qualifiés ; l'étape WebAuthn n'est pas encore déclarée réalisée.

Filtrage validé

Le pare-feu de l'hyperviseur applique une politique entrante restrictive ; les tests positifs et négatifs distinguent la source autorisée du reste du LAN.

Services réduits

Les composants sans usage sur un nœud autonome ont été retirés du démarrage, tandis que les exceptions conservées sont documentées et filtrées.

Validation

Preuves et contrôles retenus.

Version de l'hyperviseur, noyau démarré, unités en échec et interfaces contrôlés sur le nœud réel.
Secure Boot, UKI signée, jetons LUKS2 et voies de récupération inventoriés ; une passphrase temporaire a été retirée après sauvegarde de l'en-tête.
Nouvelles connexions SSH et Web validées depuis la source autorisée, puis refus confirmé depuis une autre machine du LAN.
Synchronisation temporelle, confinement AppArmor et correctif local minimal requalifiés après redémarrage de service.
Stockages locaux déclarés et actifs, tout en restant explicitement insuffisants comme sauvegarde de production.

Résultats publics

Ce que le chantier démontre.

Premier hôte Proxmox VE physique réellement installé, accessible et documenté.
Défense en profondeur du démarrage jusqu'aux accès d'administration.
Nœud autonome simplifié : services de cluster et de stockage inutilisés non présentés comme actifs.
Limites visibles : migration réseau, restauration représentative, sauvegarde distante, second nœud et clôture du hardening restent à réaliser.

Anonymisation

Ce qui reste privé.

Pas d'adresse d'administration, compte réel, empreinte de clé, numéro de série ou inventaire matériel exploitable.
Pas de configuration Proxmox exportée telle quelle.
Pas de règle de pare-feu complète, chemin de secret, identifiant de volume ou procédure destructive.
Les commandes publiées sont des contrôles génériques à placeholders et non une recette de reproduction du nœud privé.

Sources privées

Documentation d'origine.

Architecture privée du premier nœud Proxmox VE.
Runbooks privés de boot trust, OpenSSH, pare-feu et clôture du hardening.
Inventaires factuels du matériel, des services et des stockages provisoires.
Décisions privées relatives au réseau d'administration et à la future sauvegarde.