Veeam 13 : dépôts immuables et résistance au rançongiciel

Périmètre et règle 3-2-1-1-0

Les rançongiciels actuels visent d’abord la sauvegarde : suppression des points de restauration, réduction des rétentions, effacement des dépôts. La réponse est une copie que le serveur Veeam lui-même ne peut pas effacer avant l’échéance. Ce guide suppose l’architecture posée dans le guide 1.

Veeam formule la cible avec la règle 3-2-1-1-0 dans son guide de bonnes pratiques :

• 3 copies des données au moins ;
• 2 supports différents ;
• 1 copie hors site (tâche de copie de sauvegarde, Cloud Connect ou tiering objet) ;
• 1 copie hors ligne, isolée (air gap) ou immuable ;
• 0 erreur, vérifiée par SureBackup (voir le guide 3).

Dans une PME, la combinaison la plus courante est un dépôt durci local pour la restauration rapide et une copie vers un stockage objet immuable hors site.

Dépôt Linux durci : exigences

Le dépôt durci (hardened repository) est un serveur Linux où les fichiers de sauvegarde reçoivent un attribut d’immuabilité géré par un service local. Deux modes de préparation coexistent en v13.

Avec la Veeam Infrastructure Appliance (recommandé)

• Authentification par certificat obligatoire : SSH ne peut pas être utilisé.
• Veeam recommande fortement de désactiver la web UI Host Management sur ces appliances.
• Le dépôt ne peut pas être joint à un domaine.
• Si les comptes Security Officer sont activés, initialisez le compte Security Officer par défaut avant d’ajouter le dépôt.
• Le stockage (local, iSCSI ou Fibre Channel) se rattache depuis la console Host Management.

Sur un Linux préparé manuellement

• Stockage bloc local ou attaché : partage NFS ou volume SMB monté exclus.
• Système de fichiers supportant les fichiers immuables et les attributs étendus (chattr, setxattr) ; Veeam recommande XFS (block cloning).
• Pour le fast clone XFS, distributions supportées notamment : Debian 12.15 et 13, RHEL 8.10 / 9.2 / 9.4 / 9.6 / 9.8 / 10.2, Rocky Linux 9 et 10, SLES 12 SP5 / 15 SP4+ / 16+, Ubuntu 20.04 / 22.04 / 24.04 / 26.04 LTS.
• Ajout comme serveur géré avec des identifiants à usage unique : compte non root avec répertoire personnel, identifiants non stockés dans la base Veeam ; retirez le compte du fichier sudoers après l’ajout.
• Répertoire de sauvegarde : propriétaire et groupe = ce compte, permissions 0700, pas de sticky bit, pas de lien symbolique dans le chemin.
• Veeam Agent for Linux ne doit pas être installé ; le dépôt ne peut pas être partagé entre plusieurs serveurs Veeam.
• Machine physique à stockage local recommandée ; RAID 1 SSD (100 Go et plus) pour le système, RAID 6/60 avec cache en écriture pour les données, bande RAID de 128 ou 256 Ko, cache interne des disques désactivé.

Fonctionnement de l’immuabilité

Deux services tiennent l’immuabilité : le Veeam Data Mover (veeamtransport, port 6162, utilisateur non root) reçoit la période demandée et la transmet au Veeam Immutability Service (veeamimmureposvc), lancé avec les droits root, qui contrôle les attributs toutes les 20 minutes et les pose ou les retire.

• Période configurable de 7 à 9999 jours. Elle court à partir du dernier point de restauration de la chaîne active et s’étend à toute la chaîne.
• Un fichier .veeam.N.lock et un attribut xattr portent la période sur chaque fichier de sauvegarde. Les métadonnées .VBM ne sont jamais immuables (réécrites à chaque passe).
• Seule la méthode forward incremental avec synthetic full ou active full est acceptée : forever forward et reverse incremental sont exclues.
• Pour rendre immuables les copies de sauvegarde, la rétention GFS doit être activée sur la tâche de copie.
• Protection contre le décalage d’horloge : si la dérive mesurée dépasse 86 400 secondes (24 heures), les opérations de rétention sont bloquées. Un dépôt éteint plus de 24 heures provoque le même blocage.

L’activation peut aussi se faire en PowerShell. La commande suivante modifie la configuration : commencez par la lecture seule.

# 1. Read-only: list standard repositories
Get-VBRBackupRepository | Select-Object Name

# 2. CONFIGURATION CHANGE: enable immutability (default period: 30 days if omitted)
$repo = Get-VBRBackupRepository -Name 'Hardened-01'
Set-VBRBackupRepository -Repository $repo -EnableBackupImmutability -ImmutabilityPeriod 30

Stockage objet et Object Lock

Pour les dépôts objet, Veeam s’appuie sur les mécanismes du fournisseur : Object Lock et versioning pour Amazon S3, S3 compatible, IBM Cloud, Wasabi, 11:11 Cloud Object Storage et Google Cloud Storage ; version-level WORM et versioning de blob pour Azure.

• Période d’immuabilité de 1 à 999 jours. Veeam déconseille de la fixer au-delà de la rétention de la tâche, sous peine de frais supplémentaires.
• Depuis la 13.0.1 P1 (build 13.0.1.1071), le mode par défaut aligne l’immuabilité sur la totalité de la rétention de la tâche.
• Amazon S3 : après création du bucket avec Object Lock, vérifiez que la rétention par défaut est désactivée. Veeam applique lui-même le mode Compliance à chaque objet.
• Ne jamais activer ou désactiver Versioning ou Object Lock sur un bucket déjà ajouté, et ne pas activer de règles de cycle de vie : comportement imprévisible et perte de données possibles.
• Les données du bucket doivent être gérées exclusivement par Veeam.

Security & Compliance Analyzer recommande le mode de rétention Compliance, jugé plus sûr que Governance, pour les dépôts objet immuables. En PowerShell, les objets de dépôt S3, S3 compatible et Azure Blob exposent les propriétés documentées BackupImmutabilityEnabled et ImmutabilityPeriod, lues par le script du guide 5.

Chiffrement

L’immuabilité protège contre l’effacement ; le chiffrement protège contre la lecture d’une copie volée. Le chiffrement au niveau tâche est supporté pour les tâches de sauvegarde, de copie de sauvegarde, de fichiers, de stockage objet, VeeamZIP et de sauvegarde de configuration.

• Veeam Data Cloud Vault comme cible impose le chiffrement de la tâche.
• Si un dépôt durci existe dans l’infrastructure, la sauvegarde de configuration doit être chiffrée, sinon elle ne s’exécute pas.
• Contrôles de l’analyseur : « Backup jobs to cloud repositories should use encryption », « Password loss protection should be enabled », « Network traffic encryption should be enabled in the backup network ».

MFA, quatre yeux, Security Officer

La MFA protège la console et la web UI par un code à usage unique (applications compatibles RFC 4226 et RFC 6238). Seuls les Backup Administrators la gèrent ; elle n’existe pas en Community Edition, ne s’applique qu’aux comptes utilisateurs (pas aux groupes) et ne couvre pas les connexions non interactives comme l’API REST.

L’autorisation à quatre yeux impose l’approbation d’un second utilisateur (rôle Backup Administrator ou Security Administrator) pour les opérations sensibles :

• suppression de fichiers de sauvegarde ou d’instantanés ;
• retrait de dépôts et de stockages ;
• ajout, modification et suppression d’utilisateurs ou de groupes ;
• activation, désactivation ou réinitialisation de la MFA ;
• désactivation de l’immuabilité ou réduction de sa période sur un dépôt Linux ou durci.

Prérequis : au moins deux utilisateurs portant l’un de ces rôles avant l’activation. Veeam rappelle que le dispositif ne protège pas l’infrastructure si le serveur Veeam lui-même est compromis : il complète l’isolation décrite dans le guide 1.

Pièges et cas non supportés

• Dépôt durci virtualisé : l’analyseur recommande une machine physique à stockage local pour réduire la surface d’attaque.
• SSH laissé actif sur le dépôt durci : contrôle « Hardened repositories should have the SSH Server disabled ».
• Dépôt durci utilisé aussi comme proxy : déconseillé par l’analyseur (surface d’attaque élargie).
• Rôle Application Backup Repository combiné sur une appliance durcie : Veeam indique que cela augmente la surface d’attaque sur l’immuabilité.
• NTP mal maîtrisé : une dérive de plus de 24 heures bloque la rétention. Remise en service via « Reset time shift protection » dans la TUI Host Management sur appliance.
• Lifecycle rules ou rétention par défaut sur le bucket S3 : non supportées.
• Tâche en forever forward incremental vers un dépôt durci : refusée.

Vérification

1. 01

   Console : vue Home, nœud Backups, clic droit sur une sauvegarde, Properties, puis sélection de l’objet : la période d’immuabilité des points apparaît.

2. 02

   Security & Compliance Analyzer : le contrôle « Immutable or offline (air gapped) media should be used » doit être « Passed ».

3. 03

   Exécutez Get-VBRDailyReport.ps1 : la colonne d’immuabilité des dépôts objet doit afficher True et la période attendue.

4. 04

   Test de suppression : depuis la console, tentez de supprimer un point immuable d’une sauvegarde de test. Tant que la période court, Veeam n’autorise ni fusion ni suppression du fichier ; avec les quatre yeux, la demande part en approbation.

5. 05

   Consignez la date du test et le résultat dans le dossier de sécurité.

Sources

• Veeam Best Practice Guide : 3-2-1-1-0
• User Guide v13 : Hardened Repository
• User Guide v13 : Hardened Repository, requirements and limitations
• User Guide v13 : Hardened Repository, how immutability works
• User Guide v13 : Adding Hardened Repositories
• User Guide v13 : Backup Repository (system requirements)
• User Guide v13 : How Immutability Works (object storage)
• User Guide v13 : Object storage immutability, limitations
• User Guide v13 : Job Encryption
• User Guide v13 : Multi-Factor Authentication
• User Guide v13 : Four-Eyes Authorization
• User Guide v13 : Security & Compliance Analyzer
• PowerShell Reference v13 : Set-VBRBackupRepository