Audit de sécurité Proxmox VE : la méthode pas à pas

1. Définir le périmètre

Un hôte seul et un cluster n’appellent pas les mêmes contrôles. Commencez par lister les nœuds et vérifier l’état du quorum, puis notez les fonctions réellement utilisées : Ceph, haute disponibilité, réplication, SDN, Proxmox Backup Server.

pvecm status
pvecm nodes

Ce relevé sert à classer chaque contrôle. Un contrôle sur Ceph est hors périmètre si le cluster n’utilise pas Ceph. Il est non évaluable si Ceph est présent mais que vous n’avez pas pu lire son état. Confondre les deux revient à présenter une absence de preuve comme un résultat favorable.

2. Comptes, rôles et droits

Proxmox VE stocke les utilisateurs, groupes et permissions dans /etc/pve/user.cfg et les royaumes d’authentification (PAM, Proxmox VE, LDAP, Active Directory, OpenID Connect) dans /etc/pve/domains.cfg. Ces fichiers sont répliqués sur tous les nœuds du cluster.

pveum user list --full
pveum acl list
pveum user permissions jean@pve --path /

Points à relever :

les comptes qui détiennent le rôle Administrator sur /, et ceux à qui le rôle PVEAuditor (lecture seule) suffirait ;
les comptes sans date d’expiration ou inutilisés, en particulier ceux des personnes parties ;
l’usage de root@pam : ce compte est un administrateur sans restriction, il ne peut pas être supprimé et reste toujours accessible par le royaume PAM. Réservez-le aux opérations qui l’exigent et utilisez des comptes nominatifs pour le reste ;
les droits accordés à un utilisateur qui remplacent ceux de son groupe : les permissions effectives se lisent avec pveum user permissions, pas dans la seule liste des ACL. Le rôle NoAccess annule les autres rôles sur un chemin.

3. Authentification multifacteur

Chaque utilisateur peut enregistrer des facteurs TOTP, WebAuthn et des clés de récupération à usage unique. Un royaume peut aussi imposer un second facteur (TOTP ou YubiKey OTP) à tous ses comptes.

pveum user tfa list

Vérifiez que chaque compte disposant de droits d’administration a au moins un second facteur, que les comptes partagés n’existent pas, et que la procédure de déblocage est connue : après huit échecs TOTP, les facteurs TOTP du compte sont désactivés jusqu’à l’usage d’une clé de récupération ou d’un déblocage par un administrateur.

4. Tokens API

Les intégrations (supervision, sauvegarde, automatisation) se connectent par token API. Un token peut avoir une date d’expiration, se révoque sans désactiver son utilisateur et, par défaut, est séparé en privilèges : ses droits effectifs sont l’intersection des droits de l’utilisateur et de ceux du token.

pveum user token list automation@pve
pveum user token permissions automation@pve backup

Relevez les tokens sans expiration, ceux qui ne sont pas séparés en privilèges, ceux rattachés à root@pam, et ceux dont plus personne ne connaît l’usage. Chaque intégration devrait avoir son compte technique et un token limité aux chemins dont elle a besoin.

5. Exposition réseau et pare-feu

Le pare-feu de Proxmox VE est entièrement désactivé par défaut. Il s’active au niveau du datacenter dans /etc/pve/firewall/cluster.fw, puis se règle par hôte dans /etc/pve/nodes/<nœud>/host.fw et par machine dans /etc/pve/firewall/<VMID>.fw.

pve-firewall status
pve-firewall localnet

Une fois la politique d’entrée réglée sur DROP ou REJECT, Proxmox VE laisse passer depuis l’IPSet management l’interface web (TCP 8006), SSH (22), les consoles VNC (5900 à 5999) et SPICE (3128), et les migrations (60000 à 60050), ainsi que corosync (UDP 5405 à 5412) sur le réseau du cluster. Vérifiez donc le contenu de cet IPSet : c’est lui qui décide qui atteint l’administration.

L’accès à l’interface web peut aussi être restreint au niveau du service par ALLOW_FROM, DENY_FROM et POLICY dans /etc/default/pveproxy. Côté machines virtuelles, le filtre d’adresses MAC est actif par défaut ; le filtre IP, activable par machine avec l’option ipfilter, abandonne le trafic sortant dont l’adresse source ne figure pas dans l’ensemble ipfilter-net de l’interface : il sert surtout à empêcher l’usurpation d’adresse.

6. SSH et réseau du cluster

Un cluster Proxmox VE a besoin d’un tunnel SSH sur le port 22 entre ses nœuds. Les clés autorisées pour ces échanges sont dans /etc/pve/priv/authorized_keys : quand un nœud est retiré, sa clé y reste et son empreinte reste dans les fichiers known_hosts des autres nœuds. Un audit doit les retrouver et les faire supprimer.

Côté réseau, la documentation recommande une carte dédiée au trafic corosync, de ne pas partager ce réseau avec le stockage, et au moins un second lien corosync sur un autre réseau physique. Un cluster sans lien redondant n’est pas en faute de sécurité au sens strict, mais une coupure de ce réseau peut faire perdre le quorum.

7. Mises à jour et dépôts

Sur Proxmox VE 9, les dépôts sont décrits au format deb822 dans /etc/apt/sources.list.d/ : pve-enterprise.sources pour le dépôt entreprise (abonnement requis) et proxmox.sources pour pve-no-subscription ou pve-test. Un dépôt pve-test actif sur un hôte de production est un écart à signaler, comme un dépôt entreprise configuré sans abonnement, qui empêche les mises à jour.

apt update
apt full-upgrade

apt upgrade ne suffit pas : il ne peut pas retirer de paquets pour résoudre les dépendances et laisse l’hôte partiellement à jour. Comparez aussi les versions d’un nœud à l’autre : un cluster dont les nœuds n’ont pas la même version est un cluster en cours de mise à jour, ou oublié.

8. Certificats

pvenode cert info

L’interface web utilise /etc/pve/local/pveproxy-ssl.pem s’il existe, sinon le certificat par défaut du nœud (pve-ssl.pem), signé par l’autorité de certification propre au cluster et donc non reconnu automatiquement par les navigateurs ni par les systèmes. Relevez les dates d’expiration et l’émetteur : un certificat non reconnu habitue les utilisateurs à accepter les alertes du navigateur.

9. Sauvegardes

Les tâches de sauvegarde planifiées sont enregistrées dans /etc/pve/jobs.cfg. Vérifiez que chaque machine importante est couverte, que la rétention (prune-backups, par exemple keep-last, keep-daily) correspond à votre politique, et que les sauvegardes sur Proxmox Backup Server utilisent le chiffrement côté client quand la cible est partagée ou distante. Une sauvegarde marquée protégée ne peut pas être supprimée par la rétention.

Un audit ne s’arrête pas à la présence d’une tâche : la preuve utile est une restauration réussie et datée.

10. Traçabilité des actions

Chaque nœud conserve l’historique de ses tâches (démarrages, migrations, sauvegardes et une partie des modifications de configuration).

pvenode task list --errors
pvenode task list --userfilter jean@pve --vmid 104
pvenode task log <UPID>

Ces listes répondent à « qui a lancé quelle tâche et quand ». Elles ne disent pas quelle valeur de configuration a changé, ni sa valeur précédente. Une proposition de « PVE Auditing System » a été discutée sur la liste des développeurs Proxmox en janvier 2026 : elle prévoit de journaliser qui a fait quoi sur quel objet et, en option configurable, l’objet avant et après modification. Ce n’était alors qu’une discussion de conception, sans développement en cours selon son auteur ; à notre connaissance, rien n’est livré. Voir aussi le guide historique des changements Proxmox VE.

Les limites d’un audit manuel

Une photo à un instant donné. L’audit décrit l’état du jour ; un compte ajouté ou une règle désactivée le lendemain passe inaperçu jusqu’au suivant.
Nœud par nœud. Une partie des contrôles se répète sur chaque hôte, et les écarts entre nœuds sont faciles à manquer.
Pas d’avant / après. Sans relevé précédent, on sait qu’un réglage est mauvais, pas depuis quand ni qui l’a changé.
Des preuves dispersées. Sorties de commandes, captures et notes doivent être rassemblées pour l’auditeur, et datées.

Pour passer du constat aux réglages, la checklist de durcissement Proxmox VE reprend ces thèmes avec la commande à appliquer et la précaution à prendre avant chaque changement.

Ce que ProxTrace ajoute

ProxTrace reprend cette démarche et la rend continue. Ses 115 contrôles de bonnes pratiques Proxmox VE couvrent huit domaines : inventaire et visibilité, cluster, plateforme, accès, réseau, stockage, sauvegardes et charges VM et LXC. Chaque contrôle est découpé en sous-points ; chacun présente son observation, les valeurs exactes par nœud, l’action proposée, ses sources et la limite de sa preuve.

Quatre statuts : Valide, Non valide, Non évaluable, Hors périmètre. Une donnée absente n’est jamais comptée comme un succès.
Recalcul automatique toutes les cinq minutes ; rapports scellés, pour consulter l’état d’une date tel qu’il a été évalué ; export depuis la console.
L’historique des changements avec la valeur avant et après, qui répond à la question laissée ouverte par les journaux de tâches.
Un agent en lecture seule installé sur les nœuds, avec un compte de lecture restreint : ProxTrace ne corrige rien lui-même, l’administrateur décide. Le détail des droits est sur la page sécurité du collecteur.

Vous pouvez parcourir ces contrôles sur des données d’exemple dans la démo.

Ce qu’un audit ne remplace pas

Un audit technique documente des écarts et les preuves associées. Il ne remplace ni une analyse de risques, ni un audit indépendant, ni une certification : ProxTrace, comme les commandes ci-dessus, fournit des éléments à cette démarche sans la conclure.