Aller au contenu

Chiffrement : disques, sauvegardes, clés de récupération

Day 0 · ConcevoirNiveau 2 · OpérerCoursRédigé · à valider en lab

Le chiffrement le plus utile et le plus simple dans un environnement Proxmox est celui des sauvegardes PBS côté client : il protège vos données sur le PBS local comme sur la copie hébergée par le MSP. Le chiffrement des disques des hyperviseurs est possible mais plus contraignant ; il se décide au Day 0, avec une stratégie de clés écrite.

Contre quoi chaque chiffrement protège

Couche Mécanisme Protège contre Ne protège pas contre
Sauvegardes PBS Chiffrement côté client AES-256-GCM, clé détenue par PVE Vol ou lecture du datastore, copie chez le MSP, disque PBS jeté Un attaquant root sur le cluster PVE (il a la clé)
OSD Ceph dm-crypt/LUKS à la création de l'OSD (--encrypted 1) Disque retiré ou renvoyé en garantie Vol du serveur complet, accès root au cluster
Datasets ZFS Chiffrement natif ZFS (encryption=on) Disque ou pool volé Système démarré et dataset déverrouillé
Disques auto-chiffrants (SED) Matériel, géré par le contrôleur ou le BIOS Disque retiré Serveur volé si la clé est stockée dans le serveur
Dans la VM BitLocker, LUKS invité Fichier disque copié hors de la VM Accès console à la VM démarrée
Transport TLS (API, PBS), Ceph msgr2 en mode secure Écoute réseau Compromission d'une extrémité

Sauvegardes : chiffrement côté client PBS

flowchart LR
    A[VM 101 sur pve01] -->|découpage en chunks| B[Client PBS intégré à PVE]
    K[(Clé /etc/pve/priv/storage/pbs-local.enc)] --> B
    B -->|chunks chiffrés AES-256-GCM| C[PBS local : pbs-local]
    C -->|sync job| D[PBS du MSP]
    M[(Clé maître RSA publique)] -.->|chiffre une copie de la clé| C

Points clés :

  • La clé est générée côté PVE (Datacenter → Storage → pbs-local → Edit → Encryption → Auto-generate a client encryption key) et stockée dans /etc/pve/priv/storage/pbs-local.enc, lisible par root seulement, répliquée sur les nœuds.
  • Les chunks arrivent chiffrés sur le PBS : ni le PBS local ni le PBS du MSP ne peuvent lire le contenu. La déduplication reste effective entre sauvegardes chiffrées avec la même clé.
  • Le job verify fonctionne sur les données chiffrées (contrôle d'intégrité des chunks), sans la clé.
  • Sans la clé, aucune restauration n'est possible, y compris par le MSP. Perdre le cluster et la clé en même temps, c'est perdre les sauvegardes.
  • Une clé maître RSA optionnelle (master-pubkey) chiffre une copie de la clé de chaque sauvegarde et la stocke avec elle sur le PBS : la clé privée maître, conservée hors ligne, permet de tout restaurer.

Commandes utiles :

# clé générée par PVE (équivalent de "autogen")
pvesm set pbs-local --encryption-key autogen
# version papier (QR code) de la clé, à imprimer et mettre au coffre
proxmox-backup-client key paperkey /etc/pve/priv/storage/pbs-local.enc --output-format text > pbs-local-paperkey.txt
# clé maître : créée une fois, sur un poste sûr, hors cluster
proxmox-backup-client key create-master-key   # produit master-public.pem et master-private.pem

Le raccordement complet, avec import de clé existante et clé maître, est détaillé dans Raccorder PVE à PBS : chiffrement côté client.

Disques des hyperviseurs

  • Installeur PVE : il ne propose pas de chiffrement du disque système. Un système chiffré exige une installation Debian manuelle puis l'ajout de Proxmox VE, hors standard MSP.
  • ZFS natif : la documentation Proxmox le qualifie d'expérimental. Limites connues : réplication de datasets chiffrés, erreurs de checksum signalées avec snapshots ou zvols, pas de démarrage GRUB sur pool chiffré, déverrouillage au boot à construire soi-même (zfs load-key). Déconseillé sur les architectures ZFS répliqué 2 nœuds.
  • Ceph : case Encrypt OSD à la création de l'OSD (ou pveceph osd create /dev/sdX --encrypted 1). Les clés sont gérées par Ceph dans les moniteurs : utile pour les disques renvoyés en garantie, transparent à l'usage, léger surcoût CPU. L'option ne s'ajoute pas à un OSD existant : il faut le recréer.
  • SAN externe : chiffrement au niveau de la baie, géré par son constructeur.

Recommandations MSP

  • Activer le chiffrement côté client sur tous les stockages PBS dès la création, surtout quand une copie part chez le MSP.
  • Conserver la clé en trois exemplaires hors cluster : gestionnaire de mots de passe de l'entreprise, clé USB au coffre, version papier (paperkey). Le contrat précise si le MSP en détient une copie sous séquestre.
  • Utiliser une clé maître quand plusieurs clusters sauvegardent vers le même PBS.
  • Tester la restauration depuis la copie hors cluster de la clé, pas depuis le cluster lui-même : voir le test de restauration mensuel.
  • Pour les disques : chiffrer les OSD Ceph si la politique de sécurité impose de ne jamais renvoyer un disque lisible ; sinon, prévoir une destruction physique des disques sortants.

Pièges vus en support

  • Clé générée par l'assistant, fenêtre de téléchargement fermée sans sauvegarde : la clé n'existe que dans /etc/pve/priv/. Si le cluster est perdu (ransomware, incendie), les sauvegardes sont illisibles.
  • Clé stockée « en sécurité » sur un partage de fichiers… sauvegardé par ce même PBS.
  • Changement de clé sur le stockage : les nouvelles sauvegardes ne se dédupliquent plus avec les anciennes et les anciennes exigent toujours l'ancienne clé. Archiver chaque clé utilisée.
  • Clé protégée par mot de passe importée dans PVE : non supportée, PVE n'accepte que des clés sans mot de passe pour ses jobs.
  • ZFS chiffré activé « pour la conformité » sur un cluster répliqué : réplication en échec, migration impossible.

Testez-vous

  1. Le PBS du MSP est compromis. Les données de vos VM sont-elles lisibles ?

    Réponse

    Non, si le chiffrement côté client est actif : le PBS ne stocke que des chunks chiffrés, sans la clé.

  2. Où PVE stocke-t-il la clé de chiffrement du stockage pbs-local ?

    Réponse

    Dans /etc/pve/priv/storage/pbs-local.enc, lisible par root uniquement et répliqué dans le cluster.

  3. À quoi sert la clé maître ?

    Réponse

    Sa partie publique chiffre une copie de la clé de chaque sauvegarde, stockée sur le PBS. La partie privée, conservée hors ligne, permet de restaurer même si la clé du cluster est perdue.

  4. Peut-on chiffrer un OSD Ceph existant sans le recréer ?

    Réponse

    Non. Le chiffrement se choisit à la création de l'OSD. Il faut le détruire et le recréer, un OSD à la fois, comme dans le RB-03.

Pour aller plus loin