Une sauvegarde qui existe n’est pas nécessairement récupérable
Un rançongiciel ne s’arrête pas à la production. Après avoir obtenu un compte privilégié, un attaquant peut désactiver les jobs, voler les clés, supprimer les points de restauration accessibles et attendre que les copies saines expirent. Il faut donc protéger le serveur Veeam Backup & Replication (VBR), le dépôt et la procédure de restauration comme trois éléments distincts.
Le dépôt Linux renforcé de Veeam rend des fichiers de sauvegarde immuables pendant une période configurée. C’est une protection précieuse contre l’effacement par les chemins habituels de gestion, mais ce n’est ni une sauvegarde hors site, ni une défense absolue contre une personne qui contrôle l’hôte, le matériel ou la durée de rétention.
Architecture : séparer les domaines de défaillance
Appliquez la règle 3-2-1-1-0 comme cible opérationnelle : plusieurs copies, une copie externe, au moins une copie immuable ou hors ligne, et des tests qui ne révèlent pas d’erreur de restauration. Une copie immuable dans le même bâtiment ne protège pas d’un sinistre physique.
| Composant | Accès attendu | Risque à réduire |
|---|---|---|
| Production et hyperviseur | Comptes d’exploitation de production | Éviter que ces droits administrent le dépôt |
| Serveur VBR | Administrateurs de sauvegarde dédiés, MFA et accès restreint | Un compte volé ne doit pas ouvrir la console partout |
| Dépôt Linux | Identité locale distincte, chemin de données privé | Pas de partage SMB/NFS ni d’identifiant root conservé dans VBR |
| Copie externe | Compte et politique de rétention distincts | Survivre à la perte du site ou de l’hôte de dépôt |
| Clés et configuration | Coffre indépendant, accès de récupération documenté | Ne pas perdre la capacité de déchiffrer ou reconstruire VBR |
Choisir le mode de déploiement : appliance ou Linux manuel
Avec Veeam Infrastructure Appliance configurée comme dépôt renforcé, l’authentification est fondée sur des certificats et SSH n’est pas utilisé. Pour un serveur Linux configuré manuellement, l’assistant peut employer des identifiants à usage unique pour déployer les composants; ces identifiants ne restent pas stockés dans VBR. Il ne faut pas copier une procédure SSH manuelle sur l’appliance en supposant que les écrans et prérequis sont identiques.
Dans les deux cas, limitez les rôles du dépôt, appliquez les mises à jour prises en charge et protégez l’accès physique et hors bande. Veeam recommande un serveur physique avec stockage local pour réduire la surface d’attaque; le stockage bloc attaché est possible selon les prérequis, mais un serveur virtuel dont l’hyperviseur est compromis partage ce risque.
Préparer le stockage sans perdre les fonctions d’immuabilité
Un dépôt renforcé manuel exige un système de fichiers Linux qui prend en charge les fichiers immuables et les attributs étendus. XFS est recommandé par Veeam pour l’efficacité et le clonage de blocs, mais l’exigence n’est pas simplement « installer XFS ». Le dépôt doit utiliser du stockage bloc local ou attaché; un montage NFS ou SMB/CIFS ne convient pas.
Réservez un répertoire de données distinct, détenu par l’identité utilisée pour connecter le serveur Linux, avec permissions 0700 et sans sticky bit. Vérifiez le montage réellement actif avant de créer le dépôt. Ne reformatez jamais un disque ou ne changez pas des permissions récursivement sur un dépôt contenant déjà des sauvegardes en suivant un exemple générique.
findmnt -T /backup/veeam -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
stat -c '%A %a %U:%G %n' /backup/veeam
df -h /backup/veeam
# Ne modifie ni disque, ni droits, ni fichiers.Comptes séparés : éviter le même passe-partout partout
L’immuabilité n’empêche pas un administrateur root ou une personne qui détient le contrôleur de stockage de causer des dommages. Le principe est de ne pas offrir au même compte un accès simultané à la production, à VBR et aux couches sous-jacentes du dépôt.
- Réservez un compte d’administration de sauvegarde à VBR; ne réutilisez pas les identifiants d’administrateur de domaine pour la console et les tâches courantes.
- Pour un Linux manuel, utilisez l’identité locale d’installation prévue par l’assistant et des identifiants à usage unique; après l’intégration, retirez ou désactivez les accès privilégiés d’installation selon la procédure Veeam et votre accès de secours documenté.
- Limitez les droits des comptes invités utilisés pour la sauvegarde applicative et la virtualisation; ne donnez pas des privilèges permanents au-delà des exigences documentées.
- Protégez l’accès console par MFA et rôles Veeam, avec comptes d’urgence distincts et surveillance; restreignez les connexions d’administration aux postes et réseaux prévus.
- Séparez la personne qui gère le stockage physique, le compte qui administre l’hyperviseur et les droits de suppression d’une copie externe.
Ajouter le dépôt et choisir la période d’immuabilité
Dans Backup Infrastructure, ajoutez le serveur Linux ou l’appliance avec la méthode d’authentification correspondant à votre déploiement. Créez le dépôt renforcé sur son chemin de données et activez l’option d’immuabilité dans l’assistant. Validez la version du produit, l’espace, la connectivité et la liste des jobs admissibles avant le premier transfert.
Pour les sauvegardes image de VM et de machines physiques, la documentation Veeam 13 indique un minimum de 7 jours et un maximum de 9999 jours. Ne choisissez pas « le maximum » par défaut : un fichier immuable ne pourra pas être fusionné ou supprimé avant l’échéance. Dimensionnez en fonction du volume quotidien, de la cadence des fulls, des GFS, de la marge de croissance et du temps nécessaire pour détecter une attaque. Une période de 14 ou 30 jours peut servir de scénario de calcul, pas de seuil universel.
Les fichiers d’une chaîne active peuvent voir leur immuabilité prolongée à partir du dernier point créé. Un job échoué peut laisser des fichiers qui n’ont pas encore reçu leur verrou : surveillez les résultats et ne déduisez pas le statut de protection de la seule présence d’un dossier.
Rétention, chaînes et copies : les limites qui surprennent
Un dépôt renforcé manuel ne prend pas en charge tous les modèles de chaîne : Veeam demande un incrémentiel avant avec full actif ou synthétique, et exclut le reverse incremental et le forever-forward. Pour les backup copy jobs qui doivent profiter de l’immuabilité, la documentation impose une politique GFS. Confirmez le format de chaque job avant de pointer sa destination vers le nouveau dépôt.
Les fulls GFS peuvent rester immuables aussi longtemps que leur conservation l’exige, au-delà de la durée de base du dépôt. Les sauvegardes de journaux applicatifs ont leur propre comportement : si leur verrou expire avant la chaîne complète, une restauration à un instant précis peut échouer. Le calcul d’espace doit tenir compte des deux, pas seulement du nombre de VM multiplié par la durée du verrou.
Durcir VBR, la configuration et les clés
Mettez à jour VBR, ses composants et l’OS selon une fenêtre contrôlée. Isolez le plan de gestion du réseau utilisateur, fermez les ports non nécessaires, surveillez les connexions et les modifications de jobs et faites analyser la configuration avec Security & Compliance Analyzer. Les paramètres de MFA et de rôles doivent être testés avec un compte d’urgence avant de fermer l’accès habituel.
Activez une sauvegarde régulière chiffrée de la configuration VBR vers une destination protégée et indépendante. Conservez la phrase de chiffrement et les clés de données dans un coffre séparé, accessible en situation de crise, et vérifiez qu’une nouvelle instance VBR peut lire la configuration et trouver les dépôts. Évitez de laisser l’unique clé ou l’unique export de configuration sur le serveur que vous tentez de reconstruire.
Valider par une restauration, puis simuler la perte de VBR
Consignez le RPO et le RTO réellement mesurés. Pour une cyberattaque, isolez les machines restaurées et vérifiez l’intégrité des points choisis avant toute reconnexion à Active Directory ou à la production. Le voyant « job réussi » ne valide pas la récupérabilité applicative.
| Test | Critère de réussite |
|---|---|
| Job sur dépôt renforcé | Session terminée, points visibles et statut d’immuabilité confirmé |
| Restauration fichier et application | Données lisibles et cohérentes; propriétaire de l’application confirme |
| VM isolée | Démarrage, authentification et dépendances critiques vérifiés sans exposer la production |
| Reconstruction VBR | Configuration et mots de passe accessibles depuis un environnement sain; dépôt redécouvert |
| Copie hors site | Récupération possible si le dépôt local ou le site entier est indisponible |
Déploiement progressif et erreurs à éviter
La bonne question n’est pas seulement « combien de jours sont verrouillés? », mais « qui peut encore rendre toutes nos copies inutilisables et combien de temps nous faut-il pour le constater puis restaurer? »
- Semaine pilote : inventorier les jobs, choisir un serveur et un jeu de données représentatifs, mesurer écriture et restauration, valider les permissions et le verrou.
- Extension : déplacer les jobs par groupes, surveiller capacité, échecs, fenêtres, temps de copie et santé du dépôt; préserver l’ancienne copie jusqu’au test du nouveau parcours.
- Exercice de crise : réinstaller VBR dans une zone saine, récupérer la configuration et un service critique, mesurer le temps puis corriger le plan.
- Ne pas monter un partage NAS SMB/NFS comme s’il devenait immuable parce que Linux le présente sous /mnt; ne pas partager un dépôt entre plusieurs serveurs VBR.
- Ne pas donner root en permanence à VBR, exposer SSH à tout le réseau, utiliser un mot de passe commun ou compter uniquement sur les snapshots de l’hyperviseur.
- Ne pas réduire la période d’immuabilité pour résoudre un manque d’espace en urgence sans comprendre les chaînes et les effets sur les nouvelles sauvegardes.
À propos de l’auteur
Marc-Antoine Lambert
Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.
Discuter de votre environnement →