Durcissement de la sécurité Proxmox : guide pratique d’implémentation

Proxmox VE sert souvent de socle de virtualisation pour les laboratoires, les sites edge et les clusters de production. Le durcissement de la sécurité est donc une priorité, pas une réflexion après coup. Ce guide propose des étapes concrètes et des exemples copier‑coller pour verrouiller l’accès, protéger les secrets, restreindre les permissions, réduire l’exposition réseau et valider les changements en toute sécurité. À la fin, vous disposerez d’un workflow clair, d’un petit pilote exécutable localement et d’un processus reproductible pour étendre les mesures à l’ensemble des clusters.

Vue d’ensemble du workflow

Suivez cette séquence pour garder les modifications sûres et compréhensibles :

Établir la référence

Inventorier les nœuds, les versions de Proxmox et les services activés.
Noter qui peut se connecter, comment et depuis où.

Contrôle d’accès

Abandonner l’accès root partagé.
Créer des comptes utilisateur, des groupes et des rôles individuels.
Imposer la 2FA pour les connexions interactives ; limiter les jetons API à l’automatisation.

Secrets et permissions

Stocker les secrets dans des emplacements privés avec le moindre privilège.
Effectuer la rotation et l’audit des jetons et des clés.

Surface OS et Proxmox

Appliquer les correctifs régulièrement ; restreindre l’exposition SSH et de l’interface web.
Activer le pare‑feu Proxmox et les pare‑feu VM avec listes d’autorisation.

Segmentation réseau

Placer l’administration sur un VLAN ou sous‑réseau dédié.
Isoler le stockage (ex. Ceph) et les réseaux VM.

Sécurité des sauvegardes

Utiliser des sauvegardes chiffrées et tester les restaurations.

Valider

Tester les connexions, les jobs de sauvegarde et les opérations VM.
Surveiller les journaux et les métriques pour détecter les régressions.

Déployer

Piloter sur un seul nœud, puis appliquer au cluster lors de fenêtres de changement.

Bases du contrôle d’accès

Créez des utilisateurs individuels et attribuez les rôles via des groupes. Évitez l’utilisation quotidienne de root@pam pour l’interface web ou l’API.

Créer un groupe admins et un utilisateur

pveum group add admins -comment "Administrateurs Proxmox"
pveum user add alice@pve
pveum passwd alice@pve

Accorder au groupe un rôle à la racine

pveum aclmod / -group admins -role Administrator

Conseils

Utilisez les rôles intégrés (ex. PVEAdmin pour l’administration large, PVEAuditor pour la lecture seule). Appliquez‑les au chemin le plus restreint — un pool, un nœud, un stockage ou une VM précise — et non systématiquement à /.
Imposer la 2FA pour le realm utilisateur (TOTP ou WebAuthn) depuis Datacenter → Authentification. L’exiger pour toutes les connexions interactives.
Privilégiez les jetons API par utilisateur pour l’automatisation : créez un jeton pour un utilisateur, attribuez le rôle minimal sur le chemin spécifique dont il a besoin, et évitez les rôles à large portée sur /.
Ne partagez pas les identifiants. Si un jeton fuit, effectuez sa rotation et vérifiez les journaux.

Secrets et permissions

Gérez la portée et le stockage des secrets avec rigueur.

Jetons API

Créez des jetons distincts par outil ou tâche (ex. ci-backup, monitoring).
Limitez chaque jeton aux chemins nécessaires. Exemple : un jeton de sauvegarde n’obtient des droits que sur le stockage et les VM qu’il sauvegarde.
Définissez une date d’expiration et effectuez une rotation planifiée. Supprimez les jetons inutilisés.
Exemple : créer un jeton pour un utilisateur de sauvegarde avec accès uniquement au stockage backup-storage et au pool production :

  pveum user token add backup-user@pve backup-token --privsep 0 --expire 2025-12-31
  pveum aclmod /pool/production -token backup-user@pve!backup-token -role PVEVMAdmin
  pveum aclmod /storage/backup-storage -token backup-user@pve!backup-token -role PVEDatastoreUser

Chiffrement des sauvegardes

Avec Proxmox Backup Server (PBS), activez le chiffrement côté client pour les jobs de sauvegarde.
Protégez la clé de chiffrement : conservez une copie hors ligne dans un coffre sécurisé, et restreignez les permissions du système de fichiers à root sur le nœud où elle est stockée (chmod 600 /etc/proxmox-backup/encryption-key.pem).
Ajoutez une restauration de test périodique pour confirmer que la clé et les sauvegardes sont exploitables.

Permissions des fichiers

Maintenez les fichiers sensibles lisibles uniquement par root. Utilisez chmod 600 et chown root:root pour le matériel de clé lorsque c’est applicable.
Évitez de placer des secrets dans un stockage partagé lisible largement sur plusieurs nœuds, sauf si requis et protégé.

Audit

Listez régulièrement utilisateurs, groupes, rôles et ACL avec les commandes pveum et comparez à une base de référence approuvée.

Exposition réseau

Réduisez la surface d’attaque en limitant ce qui est accessible et depuis où.

Réseau d’administration

Liez l’interface web (port 8006) et SSH à un VLAN ou sous‑réseau d’administration.
Autorisez l’accès uniquement depuis les plages IP d’admin ou un hôte bastion.

Pare‑feu Proxmox

Activez le pare‑feu globalement à Datacenter → Pare‑feu et par nœud à Nœud → Pare‑feu.
Politique entrante par défaut : rejeter, avec règles d’autorisation explicites pour SSH (22/tcp) et l’interface web (8006/tcp) depuis les plages admin.
Activez le pare‑feu VM et utilisez des groupes de sécurité (groupes de règles) pour les motifs courants (ex. allow_ssh_from_admins).

TLS

Utilisez des certificats TLS valides pour l’interface web. Proxmox prend en charge ACME pour obtenir des certificats automatiquement.

Durcissement SSH

Éditez /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Rechargez SSH :

systemctl reload ssh

Employez des clés par utilisateur et sudo pour l’élévation de privilèges.

Trafic cluster et stockage

Maintenez le trafic corosync et le stockage (ex. Ceph) sur des réseaux dédiés. Ne les exposez pas à Internet.

Exposition externe

Évitez de publier l’interface Proxmox directement sur Internet. Si un accès distant est nécessaire, utilisez un VPN et des listes d’autorisation IP.

Vérifications de durcissement sans risque

Validez sans interrompre les opérations.

Vérifications d’accès

Confirmez que les administrateurs peuvent se connecter avec 2FA et effectuer les tâches requises.
Validez que les utilisateurs à moindre privilège ne voient que leurs ressources assignées.

Vérifications réseau

Depuis un poste admin, vérifiez l’accessibilité de 8006/tcp et 22/tcp.
Depuis des réseaux non admin, confirmez que les ports sont bloqués.
Sur les nœuds, listez les écoutes et liaisons :

  ss -tulpen | grep -E "):(22|8006)"

Vérifications pare‑feu

Confirmez que les pare‑feu datacenter et nœud apparaissent activés dans l’interface.
Testez une règle de refus temporaire et supprimez‑la après validation.

Sauvegarde et restauration

Lancez un job de sauvegarde et effectuez un test de restauration au niveau fichier ou complet vers une VM de test.
Vérifiez que le chiffrement fonctionne et que les clés sont accessibles.

Audit et journaux

Examinez les événements d’authentification et d’API récents. Repérez les sources inattendues ou les échecs de connexion.
Conservez une fiche de procédure courte pour chaque changement de durcissement et son annulation.

Plan de pilote local

Pilotez sur un nœud non critique ou un cluster de laboratoire et mesurez les résultats.

Périmètre (étroit et testable)

Utilisateurs et 2FA : créer des comptes par utilisateur, activer la 2FA, désactiver la connexion root à l’interface.
SSH : désactiver l’authentification par mot de passe et le SSH direct root, vérifier l’accès par clé pour l’équipe d’astreinte.
Pare‑feu : activer les pare‑feu datacenter et nœud, autoriser uniquement les sous‑réseaux admin vers 22 et 8006.
Sauvegardes : activer le chiffrement pour un job de sauvegarde et tester une restauration.

Étapes

Référence : capturer les utilisateurs actuels, ACL, ports ouverts et statut des sauvegardes.
Implémenter : appliquer les quatre éléments ci‑dessus avec notes de changement.
Valider : exécuter les vérifications de la section « Vérifications de durcissement sans risque ».
Mesurer : enregistrer le temps de connexion, les tentatives échouées, les ports bloqués et une restauration réussie.
Décider : si stable pendant une semaine, planifier le déploiement sur le nœud suivant.

Critères de passage

Tous les administrateurs se connectent avec 2FA.
L’accès SSH par clé fonctionne pour le personnel d’astreinte.
L’interface et SSH sont bloqués depuis les réseaux non admin.
La restauration de sauvegarde s’achève avec succès.

Plan de retour arrière

Gardez l’accès console prêt (IPMI ou console hyperviseur).
Conservez un sshd_config et un instantané de pare‑feu connus bons pour les réappliquer si nécessaire.

Conclusion

Le durcissement de Proxmox porte rapidement ses fruits lorsqu’on applique une approche claire et progressive. Verrouillez les comptes avec 2FA et le moindre privilège, protégez les secrets et les jetons, limitez l’exposition réseau avec un pare‑feu par défaut « deny », et validez avec de petits tests sûrs. Commencez par le pilote local, mesurez les résultats, puis déployez sur l’ensemble des nœuds en toute confiance. Vos prochaines actions aujourd’hui : créer des comptes par utilisateur, activer la 2FA, restreindre l’interface et SSH à votre réseau admin, et lancer un test de restauration. Cette base vous mènera vers des contrôles plus profonds comme la segmentation des réseaux de stockage et l’audit continu.