Renforcer la sécurité Proxmox : guide pratique avec exemples

Intro

Cette version française explique Proxmox security hardening with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Proxmox VE est souvent l'ossature des environnements de virtualisation en labo, en edge et en production. Cela rend le Proxmox hardening une priorité immédiate, pas une réflexion de fin de projet. Ce guide pratique vous propose des étapes concrètes et des exemples à copier-coller pour verrouiller l'accès, protéger les secrets, resserrer les permissions, réduire l'exposition réseau et vérifier vos changements sans risque. À la fin, vous aurez un workflow clair, un petit pilote local et une checklist pour généraliser sur vos clusters.

Vue d'ensemble du workflow

Suivez cette séquence pour garder les changements sûrs et compréhensibles :

1. Baseline

• Inventoriez les nœuds, versions et services activés.
• Notez qui peut se connecter, comment et depuis où.

1. Contrôle d'accès

• Écartez l'accès root partagé.
• Créez des comptes par utilisateur, des groupes et des rôles.
• Imposez la 2FA pour les connexions interactives ; utilisez des jetons API à portée limitée pour l'automatisation.

1. Secrets et permissions

• Stockez les secrets en privé avec le moindre privilège.
• Faites tourner et auditez jetons et clés.

1. Surface OS et Proxmox

• Patchez régulièrement ; restreignez l'exposition SSH et de l'interface web.
• Activez le pare-feu Proxmox et les pare-feux VM avec des allow-lists.

1. Segmentation réseau

• Placez l'administration sur un VLAN ou sous-réseau dédié.
• Isolez le stockage (p. ex. Ceph) et les réseaux VM.

1. Sécurité des sauvegardes

• Utilisez des sauvegardes chiffrées et testez les restaurations.

1. Validation

• Testez les connexions, les jobs de backup et les opérations VM.
• Surveillez journaux et métriques pour détecter les régressions.

1. Déploiement

• Pilotez sur un nœud, puis appliquez au cluster avec des fenêtres de changement.

Bases du contrôle d'accès

Créez des utilisateurs individuels et assignez des rôles via des groupes. Évitez d'utiliser root@pam au quotidien dans l'UI ou l'API.

Exemples :

• Créer un groupe d'administrateurs :

pveum group add admins -comment "Proxmox admins"

• Créer un utilisateur et définir un mot de passe :

pveum user add alice@pve
pveum passwd alice@pve

• Accorder un rôle au groupe à la racine :

pveum aclmod / -group admins -role Administrator

Conseils :

• Utilisez les rôles intégrés (par ex. PVEAdmin pour l'admin étendue, PVEAuditor pour la lecture seule). Appliquez-les au chemin le plus restreint possible (pool, nœud, stockage ou chemin de VM), pas systématiquement « / ».
• Imposez la 2FA pour le realm utilisateur (TOTP ou WebAuthn) depuis Datacenter -> Authentication. Exigez-la pour toutes les connexions interactives.
• Préférez des jetons API par utilisateur pour l'automatisation : créez un jeton par utilisateur, assignez le rôle minimal sur le chemin requis et évitez les rôles trop larges à « / ».
• Évitez de partager des identifiants. Si un jeton fuit, faites une rotation et vérifiez les journaux.

Cette approche améliore la traçabilité (qui a fait quoi, où) et réduit l'impact d'une compromission de compte. Elle garde aussi vos besoins de Proxmox access control et Proxmox permissions visibles dans la configuration.

Secrets et permissions

Cadrez et stockez les secrets avec soin.

• Jetons API
• Créez des jetons distincts par outil ou job (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 VMs qu'il sauvegarde.
• Définissez une date d'expiration et mettez en place une rotation planifiée. Supprimez les jetons inutilisés.

• Chiffrement des sauvegardes
• Avec Proxmox Backup Server (PBS), activez le chiffrement côté client pour les jobs de sauvegarde.
• Protégez la clé : gardez une copie hors ligne dans un coffre-fort et restreignez les permissions du système de fichiers à root sur le nœud où elle est stockée.
• Ajoutez une restauration de test périodique pour confirmer que la clé et les sauvegardes sont utilisables.

• Permissions des fichiers
• Gardez les fichiers sensibles lisibles uniquement par root. Utilisez chmod 600 et chown root: root pour le matériel de clés lorsque c'est pertinent.
• Évitez de placer des secrets sur un stockage partagé largement lisible entre nœuds, sauf si c'est nécessaire et correctement protégé.

• Audits
• Listez périodiquement utilisateurs, groupes, rôles et ACL avec les commandes pveum et comparez-les à une base de référence approuvée.

Ces pratiques alignent Proxmox secrets et Proxmox permissions avec le principe du moindre privilège.

Exposition réseau

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

• Réseau d'administration
• Lieez l'UI web (port 8006) et SSH à un VLAN ou sous-réseau d'administration.
• Autorisez l'accès uniquement depuis des IPs d'admins ou un bastion.

• Pare-feu Proxmox
• Activez le pare-feu globalement (Datacenter -> Firewall) et par nœud (Node -> Firewall).
• Politique entrante par défaut : drop, avec des règles d'autorisation explicites pour SSH (22/tcp) et l'UI (8006/tcp) depuis les plages d'admins.
• Activez le pare-feu des VMs et utilisez des Security Groups (rule groups) pour les motifs communs (ex. allow_ssh_from_admins).

• TLS
• Utilisez des certificats TLS corrects pour l'UI web. Proxmox prend en charge ACME pour obtenir des certificats.

• Durcissement SSH
• Éditez /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

• Rechargez SSH : systemctl reload ssh
• Utilisez des clés par utilisateur et sudo pour l'élévation.

• Trafic cluster et stockage
• Gardez corosync et le trafic de stockage (par ex. Ceph) sur des réseaux dédiés. Ne les exposez pas à Internet.

• Exposition externe
• Évitez de publier l'UI Proxmox directement sur Internet. En cas d'accès distant, privilégiez un VPN et des allow-lists d'IP.

Vérifications de durcissement sûres

Vérifiez sans casser les opérations.

• Contrôles d'accès
• Confirmez que les admins se connectent avec 2FA et peuvent accomplir leurs tâches.
• Validez que les utilisateurs en moindre privilège ne voient que leurs ressources.

• Contrôles réseau
• Depuis un poste admin, vérifiez l'accès à 8006/tcp et 22/tcp.
• Depuis des réseaux non-admin, confirmez que les ports sont bloqués.
• Sur les nœuds, listez les listeners et bindings :

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

• Contrôles pare-feu
• Confirmez dans l'UI que les pare-feux datacenter et nœud sont activés.
• Testez une règle de deny temporaire et retirez-la après validation.

• Sauvegarde et restauration
• Exécutez un job de sauvegarde et effectuez un test de restauration (fichier ou VM complète) sur une VM de bac à sable.
• Vérifiez que le chiffrement fonctionne et que les clés sont accessibles.

• Audit et journaux
• Passez en revue les événements d'auth et API récents. Repérez des sources inattendues ou des échecs.
• Tenez une courte fiche pour chaque changement de durcissement et sa procédure de rollback.

Plan pilote local

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

Périmètre (ciblé et testable) :

• Utilisateurs et 2FA : comptes par utilisateur, 2FA activée, login root à l'UI désactivé.
• SSH : pas d'authentification par mot de passe ni de SSH root direct ; vérifiez l'accès admin par clés.
• Pare-feu : activez les pare-feux datacenter et nœud ; n'autorisez que les sous-réseaux d'admins vers 22 et 8006.
• Sauvegardes : activez le chiffrement sur un job et testez une restauration.

Étapes :

1. Baseline : capturez les utilisateurs, ACL, ports ouverts et l'état des backups.
2. Implémentation : appliquez les quatre éléments ci-dessus avec des notes de changement.
3. Validation : exécutez les vérifications de la section correspondante.
4. Mesure : consignez le temps de connexion, les échecs de login, les ports bloqués et une restauration réussie.
5. Décision : si stable une semaine, programmez le déploiement sur le nœud suivant.

Critères de passage en production :

• Tous les admins se connectent avec 2FA.
• L'accès SSH par clés fonctionne pour l'astreinte.
• L'UI et SSH sont bloqués depuis les réseaux non-admin.
• Une restauration de sauvegarde aboutit.

Plan de rollback :

• Gardez l'accès console prêt (IPMI ou console hyperviseur).
• Conservez un sshd_config et un snapshot de pare-feu connus comme sains à réappliquer si besoin.

Conclusion

Le durcissement de Proxmox security apporte un retour rapide si vous suivez une approche claire et par étapes. Verrouillez les comptes avec 2FA et moindre privilège, protégez secrets et jetons, limitez l'exposition réseau avec un pare-feu en deny-by-default, et vérifiez avec de petits tests sûrs. Démarrez par le pilote local, mesurez les résultats, puis déployez sur les nœuds avec confiance. Vos actions immédiates : créer des comptes par utilisateur, activer la 2FA, restreindre l'UI et SSH à votre réseau d'admins et lancer une restauration de test. Cette base vous mènera vers des contrôles plus profonds comme la segmentation des réseaux de stockage et l'audit continu.