06 — Phase 4 : Réseau et segmentation

Version : 0.2.0 Date : 2026-03-20 Statut : Rédaction initiale — Format CIS hybride Licence : CC BY-SA 4.0 Base de référence : CIS Debian Linux 13 Benchmark v1.0.0, Documentation Proxmox VE Firewall Scénarios du threat model : S1, S4, S8, S9

4.1 — Architecture réseau

4.1.1 Implémenter la segmentation VLAN

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏢🌐 (🏠 simplifié)
Réf. CIS Debian 13	Spécifique infrastructure
CIS Controls v8	12.2 — Establish and Maintain a Secure Network Architecture
MITRE ATT&CK	T1557 (Adversary-in-the-Middle), T1021 (Remote Services), T1040 (Network Sniffing), M1030 (Network Segmentation)
ISO 27001:2022	A.8.22 — Segregation of networks
PCI DSS v4.0	1.2.1 — Restrict inbound/outbound traffic, 1.3.1 — Restrict inbound to CDE
Scénario threat model	S4 (cluster), S5 (BMC), S9 (interception)
Statut PVE 9	✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Nécessite un switch manageable supportant les VLAN 802.1Q. Configuration à faire idéalement avant la mise en production.

🔍 Audit

Audit :

Vérifier les bridges et VLAN configurés

cat /etc/network/interfaces

Résultat attendu : bridges séparés par rôle ou VLAN tagging

Vérifier les interfaces actives

ip -br link show

ip -br addr show

Vérifier la table de routage

ip route show


**Remédiation** :

Architecture VLAN de référence (🏢🌐) :

| VLAN | Nom | Bridge PVE | Rôle | Ports |
|------|-----|-----------|------|-------|
| 10 | Management | vmbr0 | Web UI, SSH, API | 8006, 22 |
| 20 | VM/CT | vmbr1 | Trafic applicatif guests | Variable |
| 30 | Stockage | vmbr2 | NFS, iSCSI, Ceph public | 2049, 3260, 6789 |
| 40 | Cluster | vmbr3 | Corosync, migration | 5405/udp, 60000-60050 |
| 41 | Ceph cluster | vmbr4 | Réplication OSD (si Ceph) | 6800-7300 |
| 99 | OOB | — | BMC/IPMI (port physique dédié) | 443 |

Exemple `/etc/network/interfaces` (2 interfaces physiques, VLAN tagging) :

auto lo

iface lo inet loopback

Interface physique 1 (trunk VLAN)

auto eno1

iface eno1 inet manual

VLAN 10 — Management

auto eno1.10

iface eno1.10 inet static

auto vmbr0

iface vmbr0 inet static

address 10.0.10.11/24

gateway 10.0.10.1

bridge-ports eno1.10

bridge-stp off

bridge-fd 0

VLAN 20 — VM

auto eno1.20

iface eno1.20 inet manual

auto vmbr1

iface vmbr1 inet manual

bridge-ports eno1.20

bridge-stp off

bridge-fd 0

VLAN 40 — Cluster (interface physique 2 si disponible)

auto eno2

iface eno2 inet manual

auto vmbr3

iface vmbr3 inet static

address 10.0.40.11/24

bridge-ports eno2

bridge-stp off

bridge-fd 0


**Alternative — VLAN-aware bridge** (plus flexible, recommandé PVE 9) :

auto vmbr0

iface vmbr0 inet static

address 10.0.10.11/24

gateway 10.0.10.1

bridge-ports eno1

bridge-stp off

bridge-fd 0

bridge-vlan-aware yes

bridge-vids 10 20 30 40


Avec un VLAN-aware bridge, les VM se voient attribuer un VLAN tag dans leur configuration réseau (ex: `tag=20`).

Architecture simplifiée (🏠) :

Un seul bridge, pas de VLAN

auto vmbr0

iface vmbr0 inet static

address 192.168.1.100/24

gateway 192.168.1.1

bridge-ports eno1

bridge-stp off

bridge-fd 0


**Valeur par défaut** : L'installateur PVE crée un seul bridge `vmbr0` avec l'IP de management.

**Rollback** : Modifier `/etc/network/interfaces` et `ifreload -a`. ⚠️ Tester via console OOB — une erreur réseau rend le serveur inaccessible par SSH.

**Spécificité PVE** : Les VLAN-aware bridges sont la méthode recommandée par Proxmox. Chaque VM peut recevoir un tag VLAN dans sa config réseau sans créer de bridges supplémentaires.

---

4.1.2 Configurer un bridge par zone de sécurité

Level 2

Profile Applicability	Level 2 — Server
Applicabilité PVE	🏢🌐
CIS Controls v8	12.2
MITRE ATT&CK	M1030
ISO 27001:2022	A.8.22
Scénario threat model	S4, S9
Statut PVE 9	✅ Validé

Description :

Description :

Rationale :

Rationale :

🔍 Audit

Audit :

Vérifier qu'aucune VM n'est connectée au bridge management

grep -r "bridge=vmbr0" /etc/pve/qemu-server/ /etc/pve/lxc/ 2>/dev/null

Résultat attendu (si vmbr0 = management) : aucune VM connectée à vmbr0

Les VM doivent être sur vmbr1 ou un bridge VM dédié


**Remédiation** : Migrer les VM du bridge management vers un bridge VM dédié. Modifier la configuration réseau de chaque VM dans l'interface PVE (Hardware > Network Device > Bridge).

**Valeur par défaut** : Toutes les VM sur `vmbr0` (même bridge que le management).

---

4.2 — Firewall Proxmox VE

4.2.1 Activer le firewall avec une politique restrictive

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏠🏢🌐
Réf. CIS Debian 13	4.1.x à 4.3.x (firewall)
CIS Controls v8	4.2 — Establish and Maintain a Firewall Rule Set, 4.4 — Implement and Manage a Host-Based Firewall, 4.5 — Implement Application Layer Filtering
MITRE ATT&CK	T1190 (Exploit Public-Facing Application), T1021 (Remote Services), M1037 (Filter Network Traffic)
ISO 27001:2022	A.8.20 — Network security, A.8.21 — Security of network services
PCI DSS v4.0	1.2.1, 1.3.1, 1.3.2, 1.4.1
Scénario threat model	S1, S4
Statut PVE 9	✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Élevé si mal exécuté. Risque de lock-out. Toujours conserver un accès console OOB. Le firewall PVE dispose de règles anti-lockout cachées qui autorisent automatiquement certains trafics depuis les « management hosts ».

⚠️ CORRECTION vs guide HomeSecExplorer : Le guide HSE affirme que la politique INPUT est DROP par défaut quand le firewall est activé. C'est partiellement vrai : la politique est bien DROP, mais les règles anti-lockout automatiques autorisent SSH (22), Web UI (8006), VNC (5900-5999), SPICE (3128) et Corosync (5405-5412) depuis le réseau local management. Ces règles sont invisibles dans l'interface mais présentes dans les iptables.

Comportement du firewall PVE à l'activation :

Trafic	Politique par défaut	Règles anti-lockout
INPUT depuis management LAN → SSH (22)	DROP	✅ Autorisé (anti-lockout)
INPUT depuis management LAN → Web UI (8006)	DROP	✅ Autorisé (anti-lockout)
INPUT depuis management LAN → VNC (5900-5999)	DROP	✅ Autorisé (anti-lockout)
INPUT cluster → Corosync (5405-5412)	DROP	✅ Autorisé (anti-lockout)
INPUT depuis AUTRE réseau → n'importe quoi	DROP	❌ Bloqué
OUTPUT → tout	ACCEPT	—
FORWARD (VM)	—	Géré par les firewall VM individuels

Point critique : les règles DC et les règles VM sont indépendantes. Les règles Datacenter s'appliquent aux nœuds. Les règles VM s'appliquent uniquement aux VM. Il n'y a PAS de cascading automatique.

🔍 Audit

Audit :

Vérifier si le firewall est actif

cat /etc/pve/firewall/cluster.fw 2>/dev/null | grep "enable"

Résultat attendu : enable: 1

Vérifier la politique

cat /etc/pve/firewall/cluster.fw 2>/dev/null | grep "policy"

Résultat attendu : policy_in: DROP

Vérifier les règles iptables actives

iptables -L -n -v | head -30

Résultat attendu : chaînes PVEFW-* présentes

Vérifier le statut du service

systemctl is-active pve-firewall


**Remédiation** :

**Procédure pas à pas (anti lock-out)** :

**Étape 1** — Préparer les règles AVANT d'activer le firewall :

Créer `/etc/pve/firewall/cluster.fw` :

[OPTIONS]

enable: 0

policy_in: DROP

policy_out: ACCEPT

[RULES]

Management — Web UI (restreint au réseau admin)

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 8006 -log nolog

Management — SSH (restreint au réseau admin)

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22 -log nolog

Cluster — Corosync

IN ACCEPT -source 10.0.40.0/24 -p udp -dport 5405:5412 -log nolog

Cluster — Migration live

IN ACCEPT -source 10.0.40.0/24 -p tcp -dport 60000:60050 -log nolog

Monitoring — ICMP ping (optionnel)

IN ACCEPT -p icmp -log nolog


**Étape 2** — Vérifier l'accès OOB (IPMI/iDRAC/console) — en cas de lock-out.

**Étape 3** — Activer le firewall :

Via la CLI :

pvesh set /cluster/firewall/options --enable 1

Ou éditer cluster.fw et passer enable: 1


**Étape 4** — Tester IMMÉDIATEMENT :

Depuis votre poste admin, dans un NOUVEAU terminal :

ssh root@<PVE_IP>

Tester l'accès web UI : https://<PVE_IP>:8006

En cluster : tester pvecm status


**Étape 5** — Activer le firewall par nœud :

Créer `/etc/pve/nodes/<hostname>/host.fw` :

[OPTIONS]

enable: 1


**Valeur par défaut** : Firewall **désactivé**. Aucune règle.

**Rollback** :

Désactiver le firewall immédiatement

pvesh set /cluster/firewall/options --enable 0

Ou éditer /etc/pve/firewall/cluster.fw : enable: 0

Ou via console OOB : pve-firewall stop


**Spécificité PVE** :
- Le firewall PVE est basé sur **iptables** (backend classique) ou **nftables** (nouveau backend `proxmox-firewall`, activable dans Host > Firewall > Options).
- Les règles sont stockées dans `/etc/pve/firewall/` (cluster) et distribuées automatiquement à tous les nœuds.
- Les **management hosts** sont définis par l'IPSet `management` qui inclut automatiquement le réseau du cluster. Cet IPSet peut être personnalisé.

---

4.2.2 Configurer les règles par nœud

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏢🌐
CIS Controls v8	4.2
MITRE ATT&CK	M1037
ISO 27001:2022	A.8.20
PCI DSS v4.0	1.2.1
Scénario threat model	S1, S4
Statut PVE 9	✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

Ports à autoriser par nœud (dans /etc/pve/nodes/<hostname>/host.fw) :

Port	Protocole	Source	Rôle	Obligatoire
22	TCP	Réseau admin	SSH	✅
8006	TCP	Réseau admin	Web UI / API	✅
5405-5412	UDP	Réseau cluster	Corosync	✅ (cluster)
60000-60050	TCP	Réseau cluster	Migration live	✅ (cluster)
5900-5999	TCP	Réseau admin	Console VNC	⚠️ Si noVNC utilisé
3128	TCP	Réseau admin	Console SPICE	⚠️ Si SPICE utilisé
6789	TCP	Réseau stockage	Ceph monitor	⚠️ Si Ceph
6800-7300	TCP	Réseau stockage/Ceph	Ceph OSD	⚠️ Si Ceph
2049	TCP	Réseau stockage	NFS	⚠️ Si NFS
3260	TCP	Réseau stockage	iSCSI	⚠️ Si iSCSI
111	TCP/UDP	Réseau stockage	rpcbind (NFS)	⚠️ Si NFS v3

Exemple /etc/pve/nodes/pve-node01/host.fw :

[OPTIONS]
enable: 1

[RULES]

SSH depuis le réseau admin uniquement

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22

Web UI depuis le réseau admin

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 8006

Corosync depuis le réseau cluster

IN ACCEPT -source 10.0.40.0/24 -p udp -dport 5405:5412

Migration depuis le réseau cluster

IN ACCEPT -source 10.0.40.0/24 -p tcp -dport 60000:60050

Ceph depuis le réseau stockage (si applicable)

IN ACCEPT -source 10.0.30.0/24 -p tcp -dport 6789

IN ACCEPT -source 10.0.30.0/24 -p tcp -dport 6800:7300

ICMP

IN ACCEPT -p icmp

---

4.2.3 Utiliser les Security Groups pour les VM

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏢🌐
CIS Controls v8	4.2, 4.4
MITRE ATT&CK	M1030, M1037
ISO 27001:2022	A.8.20, A.8.22
PCI DSS v4.0	1.2.1, 1.3.1
Scénario threat model	S1, S3
Statut PVE 9	✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Faible. Nécessite de définir les groupes et de les assigner.

🔍 Audit

Audit :

Lister les security groups

pvesh get /cluster/firewall/groups

Vérifier les VM sans firewall activé

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

fw=$(qm config $vmid | grep "firewall=" | head -1)

echo "VM $vmid: $fw"

done

Résultat attendu : firewall=1 sur chaque interface de chaque VM


**Remédiation** :

Créer des Security Groups via l'interface web (Datacenter > Firewall > Security Group) ou via `/etc/pve/firewall/cluster.fw` :

[group web-server]

Serveur web standard

IN ACCEPT -p tcp -dport 80

IN ACCEPT -p tcp -dport 443

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22

[group db-server]

Serveur base de données — accès restreint

IN ACCEPT -source 10.0.20.0/24 -p tcp -dport 3306

IN ACCEPT -source 10.0.20.0/24 -p tcp -dport 5432

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22

[group management-only]

Accès SSH admin uniquement

IN ACCEPT -source 10.0.10.0/24 -p tcp -dport 22

IN ACCEPT -p icmp


Appliquer à une VM : VM > Firewall > Insert: Security Group

**Valeur par défaut** : Aucun Security Group. Firewall VM désactivé par défaut.

**Spécificité PVE** : Les Security Groups sont définis au niveau Datacenter mais appliqués au niveau VM. Ils sont réutilisables sur toutes les VM du cluster.

---

4.2.4 Contrôler la politique FORWARD et son impact cluster

Level 2

Profile Applicability	Level 2 — Server
Applicabilité PVE	🏢
CIS Controls v8	4.2
MITRE ATT&CK	M1037
Scénario threat model	S4
Statut PVE 9	⚠️ Partiel — tester soigneusement

Description :

Description :

Rationale :

Rationale :

Impact : Élevé. FORWARD=DROP sans règles explicites casse la communication inter-VM, y compris les migrations live et la réplication si les VM utilisent le même bridge que le cluster.

⚠️ CORRECTION vs guide HomeSecExplorer : Le guide HSE recommande FORWARD=DROP sans documenter suffisamment les règles nécessaires pour le cluster. En pratique, cette modification casse les migrations si le réseau de migration passe par un bridge qui a aussi des VM.

🔧 Remédiation

Remédiation :

Seul mettre FORWARD=DROP si :

Le réseau de migration est sur un bridge/VLAN séparé des VM
Des règles FORWARD explicites sont configurées pour chaque flux inter-VM nécessaire
Le changement a été testé en lab avec des migrations live

Dans cluster.fw (UNIQUEMENT après tests)

[OPTIONS]

policy_forward: DROP


**Valeur par défaut** : `policy_forward: ACCEPT`

---

4.2.5 Considérer le backend nftables

Level 2

Profile Applicability	Level 2 — Server
Applicabilité PVE	🏢🌐
CIS Controls v8	4.2
Scénario threat model	S1
Statut PVE 9	⚠️ Partiel — fonctionnel mais plus récent

Description :

Description :

Avantages du backend nftables :

Pas de bridges firewall supplémentaires (fwbrX) créés pour les bridges Linux
Architecture plus moderne et performante
Meilleur support futur

Limitations :

REJECT n'est pas disponible pour le trafic guest (trafic droppé à la place)
Plus récent, moins de retour d'expérience communautaire

🔧 Remédiation

Remédiation :

[OPTIONS]
nftables: 1

Valeur par défaut : Backend iptables (pve-firewall).

Spécificité PVE : Ne PAS confondre le backend nftables PVE avec le passage du système de iptables-legacy à nftables au niveau Debian. Le firewall PVE gère sa propre couche, indépendamment du backend nftables Debian.

4.3 — Protection réseau avancée

4.3.1 Contrôler l'IP forwarding

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏠🏢🌐
Réf. CIS Debian 13	3.3.11
CIS Controls v8	4.8, 12.2
MITRE ATT&CK	T1557, M1037
ISO 27001:2022	A.8.20
Scénario threat model	S4, S9
Statut PVE 9	✅ Validé

Description :

Description :

⚠️ Rappel : ip_forward = 1 est requis par Proxmox. Le CIS recommande de le désactiver « si le système n'est pas un routeur », mais un hyperviseur PVE est un routeur pour ses VM. Ne PAS désactiver.

🔍 Audit

Audit :

sysctl net.ipv4.ip_forward

Résultat attendu : = 1 (requis par PVE)

sysctl net.ipv4.conf.all.rp_filter

Résultat attendu : = 1 (anti-spoofing actif)


**Remédiation** : Voir Phase 1 (1.2.2) pour la configuration complète des sysctl réseau.

---

4.4 — Checklist post-Phase 4

ARCHITECTURE RÉSEAU
[ ] 4.1.1 — Segmentation VLAN implémentée (🏢🌐)
[ ] 4.1.1 — Bridges configurés dans /etc/network/interfaces
[ ] 4.1.2 — VM sur bridge séparé du management

FIREWALL PVE
[ ] 4.2.1 — Firewall activé au niveau Datacenter (policy_in: DROP)
[ ] 4.2.1 — Règles d'accès management configurées (SSH, :8006)
[ ] 4.2.1 — Règles cluster configurées (Corosync, migration)
[ ] 4.2.2 — Firewall activé par nœud (host.fw)
[ ] 4.2.3 — Security Groups créés et appliqués aux VM
[ ] 4.2.4 — FORWARD policy évalué (Level 2)
[ ] 4.2.5 — Backend nftables évalué (Level 2)

RÉSEAU
[ ] 4.3.1 — ip_forward = 1 (requis PVE), rp_filter = 1

VALIDATION
[ ] Accès SSH fonctionnel depuis le réseau admin
[ ] Web UI accessible depuis le réseau admin
[ ] VM accessible depuis le réseau VM (pas management)
[ ] En cluster : Corosync fonctionnel (pvecm status)
[ ] En cluster : migration live réussie
[ ] Ceph fonctionnel (si applicable)
[ ] Test : accès Web UI depuis un réseau non-admin → bloqué
[ ] iptables -L -n | grep PVEFW : chaînes présentes

Navigation : ← 05-acces-authentification.md | 07-stockage-chiffrement.md →

-e

07 — Phase 5 : Stockage et chiffrement

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 : S2, S9, S10

5.1 — Chiffrement au repos

5.1.1 Vérifier le chiffrement des données au repos

Level 2

Profile Applicability	Level 2 — Server
Applicabilité PVE	🏢🌐
CIS Controls v8	3.6 — Encrypt Data on End-User Devices
MITRE ATT&CK	T1005 (Data from Local System), M1041 (Encrypt Sensitive Information)
ISO 27001:2022	A.8.24 — Use of cryptography
PCI DSS v4.0	3.5.1
Scénario threat model	S10 (accès physique)
Statut PVE 9	✅ Validé

Description :

Description :

🔍 Audit

Audit :

Vérifier LUKS

lsblk -f | grep -i crypt && echo "LUKS: PASS" || echo "LUKS: non détecté"

Vérifier ZFS encryption

zfs get encryption -r rpool 2>/dev/null | grep -v "off" | grep -v "NAME" && echo "ZFS encryption: PASS" || echo "ZFS encryption: non détecté"

Vérifier que /var/lib/vz est sur un volume chiffré

df /var/lib/vz | tail -1

Croiser avec lsblk -f pour vérifier si le device sous-jacent est chiffré


**Spécificité PVE** : Même si le root filesystem n'est pas chiffré, les données VM peuvent l'être via ZFS native encryption per-dataset. C'est un compromis acceptable pour les environnements où le FDE compliquerait trop les reboots.

---

5.2 — Chiffrement en transit

5.2.1 Activer le chiffrement Ceph en transit (Messenger v2)

Level 2

Profile Applicability	Level 2 — Server
Applicabilité PVE	🏢 (clusters Ceph uniquement)
CIS Controls v8	3.10 — Encrypt Sensitive Data in Transit
MITRE ATT&CK	T1040 (Network Sniffing), T1557 (AitM), M1041
ISO 27001:2022	A.8.24
PCI DSS v4.0	4.2.1
Scénario threat model	S9 (interception trafic)
Statut PVE 9	✅ Validé

Description :

Description :

Rationale :

Rationale :

Impact : Surcoût performance ~5-10% sur le throughput Ceph (dépend du CPU et de la bande passante réseau).

🔍 Audit

Audit :

Vérifier le mode messenger

ceph config get mon ms_cluster_mode 2>/dev/null

Résultat attendu : secure

ceph config get osd ms_cluster_mode 2>/dev/null

Résultat attendu : secure


**Remédiation** :

Forcer le mode secure (chiffré) pour toutes les communications

ceph config set global ms_cluster_mode secure

ceph config set global ms_service_mode secure

ceph config set global ms_client_mode secure

Vérifier

ceph config dump | grep ms_


**Valeur par défaut** : `crc` (intégrité uniquement, pas de chiffrement).

**Rollback** : `ceph config set global ms_cluster_mode crc`

---

5.2.2 Sécuriser les connexions stockage NFS/iSCSI

Level 2

Profile Applicability	Level 2 — Server
Applicabilité PVE	🏢🌐
CIS Controls v8	3.10
MITRE ATT&CK	T1557, M1041
ISO 27001:2022	A.8.24
PCI DSS v4.0	4.2.1
Scénario threat model	S9
Statut PVE 9	✅ Validé

Description :

Description :

🔧 Remédiation

Remédiation :

NFS :

Restreindre les exports par IP : /etc/exports sur le serveur NFS ne doit lister que les IPs des nœuds PVE
Utiliser NFS v4 (pas v3) — supporte Kerberos pour l'authentification
Isoler le trafic NFS sur le VLAN stockage (Phase 4)

iSCSI :

Activer CHAP mutuel (authentification bidirectionnelle)
Restreindre les initiateurs autorisés (LUN masking/zoning)
Isoler sur le VLAN stockage

5.3 — Stockage Proxmox

5.3.1 Isoler `/var/lib/vz` du root filesystem

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏠🏢🌐
CIS Controls v8	4.8
MITRE ATT&CK	T1499.001 (OS Exhaustion), M1022
ISO 27001:2022	A.8.9
Scénario threat model	S2
Statut PVE 9	✅ Validé

Description :

Description :

🔍 Audit

Audit :

findmnt /var/lib/vz && echo "PASS: partition séparée" || echo "INFO: sur le root fs"

df -h /var/lib/vz /


**Remédiation** : Si `/var/lib/vz` est sur le root filesystem (cas de l'installateur ISO avec LVM-thin), envisager de le déplacer sur un volume dédié lors de la prochaine maintenance.

**Spécificité PVE** : L'installateur ISO PVE crée un LVM-thin pool séparé pour les données VM (`data`), mais `/var/lib/vz` (ISOs, templates) reste sur le root LV par défaut. Pour ZFS, un dataset séparé est créé automatiquement.

---

5.3.2 Sécuriser les permissions des datastores

Level 1

Profile Applicability	Level 1 — Server
Applicabilité PVE	🏠🏢🌐
CIS Controls v8	3.3, 6.1
MITRE ATT&CK	T1005, M1022
ISO 27001:2022	A.8.3
PCI DSS v4.0	7.2.1
Scénario threat model	S6
Statut PVE 9	✅ Validé

Description :

Description :

🔍 Audit

Audit :

ls -la /var/lib/vz/

Résultat attendu : propriétaire root, permissions 755 ou plus restrictives

ls -la /var/lib/vz/images/ /var/lib/vz/dump/ 2>/dev/null

---

5.4 — Checklist post-Phase 5

CHIFFREMENT AU REPOS
[ ] 5.1.1 — Chiffrement vérifié (LUKS ou ZFS encryption)

CHIFFREMENT EN TRANSIT
[ ] 5.2.1 — Ceph Messenger v2 en mode secure (si Ceph)
[ ] 5.2.2 — NFS/iSCSI sécurisé (exports restreints, VLAN stockage)

STOCKAGE PVE
[ ] 5.3.1 — /var/lib/vz isolé ou surveillance espace disque
[ ] 5.3.2 — Permissions datastores vérifiées

Navigation : ← 06-reseau-segmentation.md | 08-isolation-vm-ct.md →

-e

← Chapitre 3 — Proxmox & Auth Table des matières Chapitre 5 — Isolation & Monitoring →