Expert Cybersécurité & IA
Logo Ayi NEDJIMI Consultants
Accueil Livres Blancs Blog Contact
Livres Blancs › Guide Proxmox VE9 › Chapitre 5

08 — Phase 6 : Isolation VM/CT (couche hyperviseur)

Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Scénarios du threat model : S3, S8 Sources : BSI KVMSec v1.0.1, QEMU Security Documentation, OpenStack Security Guide

Ce chapitre couvre un domaine que les autres guides Proxmox ne traitent pas : le durcissement de la couche de virtualisation elle-même.

6.1 — Isolation QEMU/KVM

6.1.1 Vérifier les filtres seccomp pour QEMU
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v84.1, 10.5
MITRE ATT&CKT1611 (Escape to Host), T1068 (Exploitation for Privilege Escalation), M1050 (Exploit Protection)
ISO 27001:2022A.8.7, A.8.9
PCI DSS v4.06.2.4
Scénario threat modelS3 (VM escape)
Statut PVE 9✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Nul. Seccomp est activé par défaut dans QEMU sur Proxmox.

🔍 Audit

Audit :

Vérifier seccomp sur un processus QEMU en cours

(remplacer <PID> par le PID d'un processus qemu)

QEMU_PID=$(pgrep -f "qemu-system" | head -1)

[ -n "$QEMU_PID" ] && grep -c "Seccomp" /proc/$QEMU_PID/status && echo "Seccomp mode:" && grep "Seccomp" /proc/$QEMU_PID/status || echo "Aucune VM en cours"

Résultat attendu : Seccomp: 2 (filter mode)

Vérifier la ligne de commande QEMU (ne doit PAS contenir -sandbox off)

ps aux | grep qemu | grep -c "sandbox off"

Résultat attendu : 0


**Valeur par défaut** : Seccomp activé par défaut dans QEMU sur PVE 9.

**Spécificité PVE** : Proxmox n'expose pas de paramètre pour désactiver seccomp dans la configuration VM standard. Seul l'ajout d'arguments QEMU custom (`-sandbox off`) via `args:` dans la config VM pourrait le désactiver — auditer les configurations pour s'en assurer.

---
6.1.2 Désactiver KSM en environnement multi-tenant
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v84.1
MITRE ATT&CKT1003 (OS Credential Dumping — side channel), M1050
ISO 27001:2022A.8.9
Scénario threat modelS3 (VM escape — side channel)
Statut PVE 9✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Augmentation de la consommation mémoire (pas de déduplication). Pertinent uniquement en multi-tenant ou si les VM hébergent des tenants non fiables.

⚠️ CORRECTION vs guide HomeSecExplorer : Le guide HSE recommande echo 2 > /sys/kernel/mm/ksm/run mais oublie de désactiver ksmtuned qui peut réactiver KSM automatiquement.

🔍 Audit

Audit :

cat /sys/kernel/mm/ksm/run

Résultat attendu : 0 (désactivé)

systemctl is-active ksmtuned 2>/dev/null

Résultat attendu : inactive


**Remédiation** :

Désactiver KSM immédiatement

echo 0 > /sys/kernel/mm/ksm/run

Désactiver ksmtuned (peut réactiver KSM)

systemctl disable --now ksmtuned 2>/dev/null

Rendre persistant

echo "KSM_ENABLED=0" > /etc/default/ksm 2>/dev/null

cat > /etc/tmpfiles.d/disable-ksm.conf << 'EOF'

w /sys/kernel/mm/ksm/run - - - - 0

EOF


**Valeur par défaut** : KSM activé (`run = 1`) sur PVE pour économiser la mémoire.

**Rollback** : `echo 1 > /sys/kernel/mm/ksm/run`

---
6.1.3 Vérifier l'isolation IOMMU pour le PCI passthrough
Level 1
Profile ApplicabilityLevel 1 — Server (si passthrough utilisé)
Applicabilité PVE🏢🌐
CIS Controls v84.1
MITRE ATT&CKT1611 (Escape to Host), T1068, M1050
ISO 27001:2022A.8.9
Scénario threat modelS8 (PCI/DMA)
Statut PVE 9✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Nul si IOMMU est déjà activé. Peut nécessiter une modification BIOS + paramètre kernel.

🔍 Audit

Audit :

Vérifier IOMMU actif

dmesg | grep -i "IOMMU enabled\|DMAR\|AMD-Vi"

Résultat attendu : lignes indiquant IOMMU activé

Vérifier les groupes IOMMU

find /sys/kernel/iommu_groups/ -type l | head -20

Résultat attendu : groupes avec devices assignés

Vérifier les paramètres kernel

cat /proc/cmdline | grep -o "intel_iommu=on\|amd_iommu=on\|iommu=pt"

Résultat attendu : intel_iommu=on iommu=pt (ou amd_iommu=on)


**Remédiation** :
1. Activer VT-d (Intel) ou AMD-Vi dans le BIOS
2. Ajouter dans `/etc/default/grub` :

Intel :

GRUB_CMDLINE_LINUX_DEFAULT="... intel_iommu=on iommu=pt"

AMD :

GRUB_CMDLINE_LINUX_DEFAULT="... amd_iommu=on iommu=pt"

update-grub && reboot


**Règle** : Ne JAMAIS passer un device PCI à une VM non fiable sans IOMMU vérifié fonctionnel.

---
6.1.4 Optimiser la configuration machine des VM
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v84.8, 16.13
MITRE ATT&CKT1611, M1042 (Disable or Remove Feature)
ISO 27001:2022A.8.9
Scénario threat modelS3
Statut PVE 9✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

Paramètre Recommandation Justification
Machine type q35 Meilleure isolation que i440fx, support IOMMU natif
Floppy Retirer Device legacy inutile, surface d'attaque
Serial/Parallel ports Retirer si non utilisés Réduction surface d'attaque
USB tablet Remplacer par tablet: 0 + VirtIO Évite l'émulation USB
CPU type host ou modèle spécifique host = meilleure performance ; modèle = meilleure compatibilité migration
Ballooning Désactiver si multi-tenant Évite les fuites d'info mémoire

Vérifier la configuration d'une VM

qm config <VMID> | grep -E "machine|cpu|balloon|serial|parallel"


---

6.2 — Isolation LXC

6.2.1 Utiliser des conteneurs non privilégiés par défaut
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v84.1, 5.4
MITRE ATT&CKT1611, M1026
ISO 27001:2022A.8.7, A.8.9
Scénario threat modelS3
Statut PVE 9✅ Validé

Description :

Description :

🔍 Audit

Audit :

Lister les conteneurs et leur mode

for ctid in $(pct list 2>/dev/null | tail -n+2 | awk '{print $1}'); do

unpriv=$(pct config $ctid | grep "unprivileged" | awk '{print $2}')

echo "CT $ctid: unprivileged=$unpriv"

done

Résultat attendu : unprivileged=1 pour tous les conteneurs


**Remédiation** : Lors de la création, toujours cocher « Unprivileged container ». Pour convertir un conteneur existant : recréer (pas de conversion in-place possible).

**Spécificité PVE** :
- Les conteneurs privilégiés sont parfois nécessaires pour NFS mounts, certains modules kernel, ou Docker-in-LXC. Documenter et justifier chaque exception.
- **Docker dans LXC** : préférer Docker dans une VM en environnement sensible. Si LXC est nécessaire, utiliser un conteneur non privilégié avec nesting activé + keyctl.
- ⚠️ Régressions AppArmor + LXC nested sur kernel 6.17 — tester.
6.2.2 Appliquer les limites cgroup v2
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v84.1
MITRE ATT&CKT1499 (Endpoint DoS), M1038 (Execution Prevention)
ISO 27001:2022A.8.9
Scénario threat modelS3
Statut PVE 9✅ Validé

Description :

Description :

🔍 Audit

Audit :

Vérifier les limites d'une VM

qm config <VMID> | grep -E "memory|cores|cpulimit|bwlimit"

Résultat attendu : limites définies (pas de ressources illimitées)


**Remédiation** : Configurer pour chaque VM/CT :
- `memory` : limite mémoire maximale
- `cores` : nombre de vCPU
- `cpulimit` : limite CPU en pourcentage (ex: `cpulimit: 2` = 2 cœurs max)
- `bwlimit` : limite bande passante réseau et I/O (via Options > Bandwidth Limit)

---

6.3 — Checklist post-Phase 6

QEMU/KVM
[ ] 6.1.1 — Seccomp actif sur les processus QEMU
[ ] 6.1.2 — KSM désactivé (multi-tenant)
[ ] 6.1.3 — IOMMU actif et vérifié (si PCI passthrough)
[ ] 6.1.4 — VM en machine type q35, devices inutiles retirés

LXC
[ ] 6.2.1 — Tous les conteneurs en mode unprivileged
[ ] 6.2.2 — Limites cgroup configurées sur chaque VM/CT

VALIDATION
[ ] Vérifier seccomp : grep Seccomp /proc/<QEMU_PID>/status → 2
[ ] Vérifier KSM : cat /sys/kernel/mm/ksm/run → 0
[ ] Vérifier IOMMU : dmesg | grep IOMMU → enabled
[ ] Aucune VM avec args: contenant "-sandbox off"

Navigation : ← 07-stockage-chiffrement.md | 09-monitoring-detection.md →

-e

09 — Phase 7 : Monitoring et détection

Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Scénarios du threat model : S1-S10 (détection transversale)

7.1 — Collecte de métriques et alerting

7.1.1 Déployer une solution de monitoring
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏢🌐 (🟡 recommandé 🏠)
CIS Controls v88.2 — Collect Audit Logs, 8.11 — Conduct Audit Log Reviews
MITRE ATT&CKT1070 (Indicator Removal), M1028 (OS Configuration)
ISO 27001:2022A.8.15, A.8.16 — Monitoring activities
PCI DSS v4.010.4.1
Scénario threat modelTous
Statut PVE 9✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

Option 1 : Proxmox Metric Server intégré (vers InfluxDB ou Graphite)

Configurer dans Datacenter > Metric Server

Option 2 : Prometheus + pve_exporter (recommandé)

Déployer dans une VM dédiée, pas sur l'hyperviseur lui-même

pve_exporter : https://github.com/prometheus-pve/prometheus-pve-exporter


**Alertes critiques à configurer** :

| Alerte | Seuil | Scénario |
|--------|-------|----------|
| Espace disque root < 10% | Warning à 20%, Critical à 10% | S2 |
| Espace stockage VM < 15% | Warning à 25% | S2 |
| Échecs auth > 10/h | Rate | S1 |
| CPU hôte > 90% soutenu 15min | Sustained | S3 |
| Certificat TLS expire < 14j | Days | S1 |
| Nœud cluster unreachable | Quorum | S4 |
| Backup PBS échoué | Boolean | S2 |
| Suppression massive de fichiers | Rate | S2 (ransomware) |

---

7.2 — Détection d'intrusion

7.2.1 Déployer AIDE (Advanced Intrusion Detection Environment)
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v88.5 — Collect Detailed Audit Logs
MITRE ATT&CKT1070 (Indicator Removal), T1554 (Compromise Client Software), M1028
ISO 27001:2022A.8.15, A.8.16
PCI DSS v4.011.5.2
Scénario threat modelS6, S7
Statut PVE 9✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

apt install -y aide aide-common

Initialiser la base de données (APRÈS le hardening, pas avant)

aideinit

cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Programmer un scan quotidien

cat > /etc/cron.daily/aide-check << 'EOF'

#!/bin/bash

/usr/bin/aide --check | mail -s "AIDE report $(hostname)" admin@example.com

EOF

chmod +x /etc/cron.daily/aide-check


**Spécificité PVE** : Initialiser AIDE **après** avoir terminé toutes les phases de hardening. Sinon, la base de référence contiendra l'état non durci et les modifications de hardening seront signalées comme des altérations.

---
7.2.2 Centraliser les logs hors du contrôle des admins PVE
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v88.2, 8.9 — Centralize Audit Logs
MITRE ATT&CKT1070.002 (Clear Linux Logs), M1029 (Remote Data Storage)
ISO 27001:2022A.8.15
PCI DSS v4.010.3.3
Scénario threat modelS6 (insider)
Statut PVE 9✅ Validé

Description :

Description :

Rationale :

Rationale :

🔧 Remédiation

Remédiation :

Option A — rsyslog vers un serveur distant :

Dans /etc/rsyslog.d/remote.conf :

. @@logserver.example.com:514

@@ = TCP (recommandé), @ = UDP


**Option B — Promtail + Loki** (plus moderne) :
Déployer Promtail dans une VM dédiée, configurer la collecte des journaux systemd et des fichiers de log PVE.

**Point critique** : Le serveur de centralisation ne doit PAS être administrable par les mêmes comptes que les nœuds PVE.

---
7.2.3 Exécuter le script d'audit du guide
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v84.1
Scénario threat modelTous
Statut PVE 9🧪 En développement

Description :

Description :

🔧 Remédiation

Remédiation :

Télécharger et exécuter (quand disponible)

git clone https://github.com/<repo>/proxmox-hardening-guide-fr.git

cd proxmox-hardening-guide-fr/scripts

chmod +x audit.sh

./audit.sh

Résultat : rapport JSON + score de conformité

Programmer un audit mensuel

crontab -e

0 6 1 /opt/proxmox-hardening/scripts/audit.sh > /var/log/hardening-audit-$(date +\%Y\%m).json


---

7.3 — Checklist post-Phase 7

MONITORING
[ ] 7.1.1 — Solution de monitoring déployée
[ ] 7.1.1 — Alertes critiques configurées (disque, auth, backup, cluster)

DÉTECTION
[ ] 7.2.1 — AIDE initialisé (après hardening complet)
[ ] 7.2.2 — Logs centralisés vers serveur externe
[ ] 7.2.3 — Script audit.sh planifié mensuellement

Navigation : ← 08-isolation-vm-ct.md | 10-maintenance-continue.md →

-e

10 — Phase 8 : Maintenance et conformité continue

Version : 0.2.0 Date : 2026-03-20 Licence : CC BY-SA 4.0 Scénarios du threat model : Tous

8.1 — Gestion des patches

8.1.1 Veille sécurité Proxmox
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v87.1, 7.4
MITRE ATT&CKM1051 (Update Software)
ISO 27001:2022A.8.8
PCI DSS v4.06.3.1
Statut PVE 9✅ Validé

🔧 Remédiation

Remédiation :

  • Liste de diffusion Proxmox : pve-announce@lists.proxmox.com
  • Forum Proxmox — section Security
  • Flux RSS Debian Security Advisories : https://www.debian.org/security/dsa
  • CVE tracking : https://app.opencve.io (filtrer sur proxmox, qemu, linux kernel)
8.1.2 Procédure de mise à jour documentée
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v87.3
Scénario threat modelS1, S3, S7
Statut PVE 9✅ Validé

Remédiation : Voir Phase 2 (2.4.1) pour la procédure de rolling update détaillée.

Fréquences recommandées :

Type de mise à jour Fréquence Procédure
Sécurité Debian (via unattended-upgrades) Automatique quotidien Automatisé Phase 1
Paquets Proxmox (non-security) Mensuel Test lab → rolling update
Kernel PVE Trimestriel ou sur CVE critique Test lab → rolling update → reboot
Mise à jour majeure (PVE 9 → 10) Annuel Test complet → migration planifiée

8.2 — Revue périodique

8.2.1 Revue trimestrielle des accès et permissions
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏢🌐
CIS Controls v85.1, 6.1, 6.2
MITRE ATT&CKM1026, M1018
ISO 27001:2022A.5.15, A.5.18
PCI DSS v4.07.2.4, 8.6.3
Scénario threat modelS6
Statut PVE 9✅ Validé

🔧 Remédiation

Remédiation :

Checklist de revue trimestrielle :

1. Lister tous les utilisateurs

pveum user list

2. Lister les ACL effectives

pveum acl list

3. Lister les tokens API

for user in $(pveum user list --output-format json 2>/dev/null | jq -r '.[].userid'); do

echo "=== $user ==="

pveum user token list "$user" 2>/dev/null

done

4. Vérifier les utilisateurs inactifs (pas de login récent)

Croiser avec les logs pveproxy

5. Vérifier les règles firewall

cat /etc/pve/firewall/cluster.fw

6. Vérifier la 2FA

cat /etc/pve/priv/tfa.cfg 2>/dev/null | wc -l

Comparer avec le nombre d'utilisateurs actifs


Actions à prendre :
- Désactiver les comptes inutilisés : `pveum user modify <user> --enable 0`
- Révoquer les tokens API inutilisés : `pveum user token remove <user> <token>`
- Documenter les déviations
8.2.2 Rotation des secrets
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v85.2
MITRE ATT&CKT1552, M1027
ISO 27001:2022A.5.17
PCI DSS v4.08.3.9, 8.6.3
Scénario threat modelS1, S6
Statut PVE 9✅ Validé

🔧 Remédiation

Remédiation :

Secret Fréquence de rotation Méthode
Tokens API Annuelle ou sur incident pveum user token remove + add
Clés SSH admin Annuelle Régénérer + redistribuer
Mots de passe root Semestrielle passwd sur chaque nœud
Certificats TLS (ACME) Automatique (90j) Géré par PVE
Certificats auto-signés Annuelle pvecm updatecerts --force

8.3 — Documentation vivante

8.3.1 Maintenir l'inventaire et les schémas à jour
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏢🌐
CIS Controls v81.1, 2.1
ISO 27001:2022A.5.9
Statut PVE 9✅ Validé

Remédiation : Mettre à jour après chaque changement :

  • Inventaire matériel (Phase 0, 0.1.5)
  • Schéma réseau / VLAN
  • Journal des changements (etckeeper, voir Phase 2, 2.5.1)
  • Liste des déviations par rapport à ce guide (avec justification, acceptation du risque, approbation)

8.4 — Checklist post-Phase 8

PATCHES
[ ] 8.1.1 — Veille sécurité activée (mailing list, RSS, CVE tracking)
[ ] 8.1.2 — Procédure de mise à jour documentée et suivie

REVUE
[ ] 8.2.1 — Revue trimestrielle accès/permissions effectuée
[ ] 8.2.2 — Rotation des secrets planifiée

DOCUMENTATION
[ ] 8.3.1 — Inventaire à jour
[ ] 8.3.1 — Schéma réseau à jour
[ ] 8.3.1 — Journal des changements tenu

Navigation : ← 09-monitoring-detection.md | 11-backup-dr.md →

11 — Phase 9 : Sauvegardes et reprise d'activité

Version : 0.2.0 Date : 2026-03-20 Licence : CC BY-SA 4.0 Scénarios du threat model : S2 (ransomware), S10

9.1 — Stratégie de sauvegarde

9.1.1 Implémenter la règle 3-2-1-1-0
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v811.1 — Establish and Maintain a Data Recovery Process, 11.2 — Perform Automated Backups, 11.3 — Protect Recovery Data
MITRE ATT&CKT1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery), M1053 (Data Backup)
ISO 27001:2022A.8.13 — Information backup
PCI DSS v4.09.4.1, 12.10.1
Scénario threat modelS2 (ransomware)
Statut PVE 9✅ Validé

Description :

Description :

  • 3 copies des données
  • 2 types de supports différents
  • 1 copie hors site
  • 1 copie hors ligne ou immuable
  • 0 erreur de restauration vérifiée

🔧 Remédiation

Remédiation :

Architecture de backup recommandée :

Copie Support Emplacement Immutabilité Rétention
1 — Primaire PBS local Même site ⚠️ Non 7 jours
2 — Réplica PBS distant Site secondaire ✅ Retention lock 30 jours
3 — Archive Stockage objet (S3) ou bandes Hors site ✅ WORM/immutable 90+ jours
9.1.2 Configurer PBS avec chiffrement client-side
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v83.6, 11.3
MITRE ATT&CKT1486, T1490, M1053, M1041
ISO 27001:2022A.8.13, A.8.24
PCI DSS v4.03.5.1
Scénario threat modelS2, S10
Statut PVE 9✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

1. Générer une clé de chiffrement

proxmox-backup-client key create /etc/pve/priv/backup-encryption-key.json

2. Configurer le job de backup dans PVE pour utiliser cette clé

Via l'interface web : Datacenter > Backup > Add

Encryption Key : /etc/pve/priv/backup-encryption-key.json

3. ESCROWER LA CLÉ (CRITIQUE)

Copier la clé dans un endroit sécurisé HORS du cluster PVE :

- Password manager hors ligne

- Coffre-fort physique (impression du paperkey)

- HSM

Si la clé est perdue, les backups sont IRRÉCUPÉRABLES

proxmox-backup-client key show /etc/pve/priv/backup-encryption-key.json


**⚠️ Point critique** : L'escrow de la clé de chiffrement est **non négociable**. Le jour de la recovery n'est pas le moment d'improviser. Tester la restauration avec la clé escrow AVANT d'en avoir besoin.
9.1.3 Activer l'immutabilité des backups (anti-ransomware)
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏢🌐
CIS Controls v811.3, 11.4
MITRE ATT&CKT1490 (Inhibit System Recovery), M1053
ISO 27001:2022A.8.13
PCI DSS v4.09.4.1
Scénario threat modelS2 (ransomware)
Statut PVE 9✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

Sur le serveur PBS :

Configurer la protection sur le datastore

Via l'interface PBS : Datastore > Edit > Protection

Ou via CLI :

proxmox-backup-manager datastore update <datastore> --keep-last 7 --keep-daily 30

Les backups dans la fenêtre de rétention ne peuvent pas être supprimés

même avec un token valide


**Mesures complémentaires** :
- Le token PVE utilisé pour les backups ne doit PAS avoir le privilège de suppression sur PBS
- PBS doit être sur un réseau/serveur séparé du cluster PVE
- L'accès admin PBS doit utiliser des credentials différents de PVE

---

9.2 — Sauvegardes hôte

9.2.1 Sauvegarder `/etc/pve` et les configs critiques
Level 1
Profile ApplicabilityLevel 1 — Server
Applicabilité PVE🏠🏢🌐
CIS Controls v811.2
ISO 27001:2022A.8.13
Scénario threat modelS2, S4
Statut PVE 9✅ Validé

🔧 Remédiation

Remédiation :

Sauvegarder les configs réseau et firewall

tar czf /var/backups/network-config-$(date +%Y%m%d).tar.gz \

/etc/network/interfaces \

/etc/pve/firewall/ \

/etc/ssh/sshd_config.d/ \

/etc/sysctl.d/ \

/etc/fail2ban/ \

/etc/default/pveproxy \

2>/dev/null


---

9.3 — Tests de reprise

9.3.1 Effectuer des drills de restauration trimestriels
Level 2
Profile ApplicabilityLevel 2 — Server
Applicabilité PVE🏢🌐
CIS Controls v811.5 — Test Data Recovery
MITRE ATT&CKM1053
ISO 27001:2022A.5.29, A.5.30
PCI DSS v4.012.10.2
Scénario threat modelS2
Statut PVE 9✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

Protocole de drill trimestriel :

  1. Sélectionner une VM de test (ou clone d'une VM de production)
  2. Restaurer depuis PBS vers un nœud de test
  3. Vérifier le démarrage de la VM
  4. Vérifier l'intégrité des données applicatives
  5. Mesurer le temps total de restauration (RTO)
  6. Documenter les résultats :
  • Date du drill
  • VM restaurée
  • Source du backup (local/distant/archive)
  • Clé de chiffrement utilisée (escrow vérifié)
  • RTO mesuré
  • Résultat : succès/échec + notes

Point critique : Le drill DOIT tester la restauration avec la clé escrow (pas la clé sur le nœud PVE). C'est la seule façon de vérifier que l'escrow fonctionne.

9.4 — Checklist post-Phase 9

STRATÉGIE
[ ] 9.1.1 — Règle 3-2-1-1-0 implémentée
[ ] 9.1.2 — PBS configuré avec chiffrement client-side
[ ] 9.1.2 — Clé de chiffrement escrow hors du cluster PVE
[ ] 9.1.3 — Immutabilité activée sur PBS (anti-ransomware)

CONFIGS
[ ] 9.2.1 — /etc/pve sauvegardé (cron quotidien)
[ ] 9.2.1 — Configs réseau/firewall/SSH sauvegardées

TESTS
[ ] 9.3.1 — Drill de restauration effectué et documenté
[ ] 9.3.1 — RTO/RPO mesurés et conformes aux objectifs
[ ] 9.3.1 — Escrow de la clé vérifié lors du drill

Navigation : ← 10-maintenance-continue.md | 12-experimental.md →

-e

← Chapitre 4 — Réseau & StockageTable des matières