Veeam Backup & Replication propose deux méthodes établies pour rendre les données de sauvegarde immuables : un dépôt Linux durci (hardened repository), où le système d’exploitation protège les fichiers de sauvegarde, et un dépôt de stockage objet compatible S3 avec object lock, où la plateforme de stockage refuse toute suppression jusqu’à l’expiration d’une période de rétention. Les deux empêchent un opérateur de ransomware ou un administrateur malveillant d’effacer des points de restauration. Ils diffèrent par l’entité qui applique la protection, par la quantité d’infrastructure que l’équipe sauvegarde exploite, et par leur comportement à mesure que les volumes et les fenêtres de rétention augmentent.
Le choix compte plus qu’auparavant. Les attaquants ciblent tôt l’infrastructure de sauvegarde, et l’immutabilité est passée d’une étape de durcissement optionnelle à une attente de base dans les revues de sécurité et les questionnaires de cyber-assurance. Cet article compare les deux modèles sur le lieu d’application de l’immutabilité, la charge opérationnelle, le chemin de montée en charge, les options multisites, le comportement en restauration, le coût et ce qu’un serveur de sauvegarde compromis peut encore faire, puis examine leur utilisation conjointe.
En termes Veeam, l’immutabilité signifie qu’un point de restauration ne peut être ni modifié ni supprimé pendant une période définie, même par un compte disposant de tous les droits dans la console Veeam. S’appuyer uniquement sur le contrôle d’accès est la réponse simpliste : elle échoue dès qu’un attaquant obtient ces identifiants, ce qui est précisément l’objectif des campagnes de ransomware.
L’immutabilité doit donc être appliquée à un endroit que le serveur de sauvegarde ne peut pas contourner. Le dépôt Linux durci place ce point d’application dans le système de fichiers d’un hôte Linux contrôlé par l’équipe sauvegarde. Un dépôt S3 Object Lock le place dans la plateforme de stockage, qui applique une règle de rétention à chaque objet et rejette les requêtes de suppression ou d’écrasement jusqu’à l’expiration de la règle.
Un dépôt durci est un serveur Linux avec un stockage bloc directement attaché, formaté en XFS. Veeam y écrit les fichiers de sauvegarde et positionne l’attribut immuable du système de fichiers sur chaque fichier pour la période de rétention configurée. Tant que l’attribut est positionné, le fichier ne peut être ni supprimé, ni renommé, ni modifié, même par root, jusqu’à ce qu’un processus planifié sur le dépôt le retire.
Deux choix de conception rendent ce modèle crédible. Le dépôt est enregistré dans Veeam avec des identifiants à usage unique, de sorte que le serveur de sauvegarde ne détient aucune connexion privilégiée persistante à l’hôte. Et l’hôte est censé être isolé : pas de connexion distante par mot de passe, pas d’appartenance à un domaine d’annuaire, SSH restreint, et traitement comme une appliance plutôt que comme un serveur généraliste.
L’équipe sauvegarde devient propriétaire d’un petit parc Linux sensible sur le plan de la sécurité. Quelqu’un doit durcir l’image du système, appliquer les mises à jour du noyau et des paquets, surveiller les dérives, remplacer les disques et contrôler l’accès physique. Rien de tout cela n’est difficile, mais tout est récurrent, et la garantie d’immutabilité dépend de sa réalisation constante.
La montée en charge est verticale : ajouter des disques ou remplacer l’hôte par un plus grand. Plusieurs dépôts durcis peuvent être regroupés comme extents de performance dans un scale-out backup repository, mais chacun reste un hôte indépendant avec ses propres correctifs, son propre domaine de défaillance et son propre plafond de capacité.
Avec le stockage objet, Veeam écrit les données de sauvegarde sous forme d’objets dans un bucket avec versioning et object lock activés, et positionne une date de conservation (retain-until) sur chaque objet. La plateforme applique cette date : les requêtes de suppression ou d’écrasement avant expiration sont refusées quels que soient les identifiants présentés. Veeam prolonge les dates de rétention des objets encore nécessaires aux points de restauration actifs, de sorte que les administrateurs ne touchent jamais aux objets individuels.
Le stockage objet sert Veeam dans deux rôles. Comme niveau de capacité (capacity tier) dans un scale-out backup repository, il reçoit des copies ou des points de restauration déchargés depuis un niveau de performance, généralement pour une rétention plus longue ou une protection hors site. Comme niveau de performance en écriture directe vers l’objet, il reçoit les sauvegardes primaires directement depuis les travaux. Le mécanisme d’immutabilité est identique dans les deux rôles.
L’équipe sauvegarde ne met plus à jour un hôte Linux pour préserver l’immutabilité. L’effort de durcissement se déplace vers le modèle d’accès de la plateforme de stockage : un utilisateur Veeam dédié, des politiques de bucket à moindre privilège, MFA pour l’accès administratif et séparation entre administration des sauvegardes et administration du stockage. Un stockage objet sur site a toujours des hôtes à mettre à jour, mais ce travail relève de la couche stockage et n’affaiblit pas le verrou s’il prend du retard.
La montée en charge est horizontale. Le stockage objet croît par ajout de nœuds ou de disques dans un espace de noms unique, de sorte qu’un bucket peut passer de quelques dizaines de téraoctets à plusieurs pétaoctets sans réarchitecturer les dépôts ni migrer les données entre hôtes.
Dans le modèle du dépôt durci, un serveur Veeam compromis peut supprimer des travaux de sauvegarde, modifier des politiques de rétention et arrêter les sauvegardes futures. Il ne peut pas supprimer ni modifier les fichiers portant l’attribut immuable. Mais si l’attaquant obtient aussi root sur l’hôte Linux, via une vulnérabilité distincte, une configuration SSH faible ou un accès physique, l’attribut peut être retiré et les données détruites. Le dépôt durci n’est solide que dans la mesure du durcissement Linux qui l’entoure.
Dans le modèle object lock, un serveur Veeam compromis peut perturber les sauvegardes futures de la même manière mais ne peut pas raccourcir la rétention des objets déjà verrouillés. Avec un verrouillage de type compliance, même l’administrateur du stockage ne peut pas retirer un verrou avant son expiration. L’attaquant devrait compromettre la plateforme de stockage elle-même : un système distinct avec des identifiants distincts et, idéalement, une équipe distincte. Cette séparation des responsabilités est l’argument de sécurité central de l’object lock.
Les restaurations depuis un dépôt durci se comportent comme depuis tout dépôt en mode bloc : accès aléatoire rapide et prise en charge de la restauration instantanée. Les restaurations depuis le stockage objet dépendent de la plateforme. Un stockage objet sur site bien dimensionné offre un débit élevé sur un réseau local et prend en charge directement la restauration instantanée et les restaurations au niveau fichier. Un stockage objet dans un cloud hyperscale peut ajouter des frais de sortie et des limites de bande passante aux restaurations volumineuses, ce qu’il vaut la peine de modéliser avant d’y engager une rétention longue.
Un dépôt durci est une machine à un emplacement ; la protection hors site implique un second hôte durci ailleurs plus un travail de copie de sauvegarde. Les plateformes de stockage objet répliquent généralement entre sites ou buckets, et certaines étendent un espace de noms unique sur plusieurs emplacements, de sorte que la couche stockage peut produire la seconde copie immuable plutôt que des travaux et des hôtes Veeam supplémentaires.
Un dépôt durci est peu coûteux au démarrage : un serveur, des disques et une distribution Linux. Sa courbe de coût s’infléchit vers le haut avec l’échelle, car chaque hôte ajoute du matériel, de l’espace rack et du temps d’administration. Le stockage objet a un point d’entrée plus élevé pour un petit déploiement mais s’aplatit à mesure que la capacité croît, en particulier lorsque l’erasure coding remplace le miroir et qu’une seule plateforme absorbe une rétention qui nécessiterait autrement plusieurs hôtes. Supposons qu’une organisation doive conserver 90 jours de points de restauration immuables pour 400 To de données source ; une plateforme de stockage unique face à une flotte de serveurs durcis devient une question de coût opérationnel autant que de matériel.
| Dimension | Dépôt Linux durci | Dépôt S3 Object Lock |
|---|---|---|
| Lieu d’application de l’immutabilité | Attribut immuable XFS sur un hôte Linux exploité par l’équipe sauvegarde | Règle de rétention appliquée par la plateforme de stockage objet |
| Charge opérationnelle | Durcissement du système, correctifs, sécurité physique par hôte | Politiques d’accès au niveau du stockage ; maintenance des hôtes assurée par l’équipe stockage |
| Chemin de montée en charge | Montée verticale par hôte ; hôtes supplémentaires comme extents SOBR | Ajout de nœuds ou de disques dans un espace de noms unique |
| Options multisites | Second hôte plus travaux de copie de sauvegarde | Réplication par la plateforme ou buckets étendus |
| Comportement en restauration | Restaurations locales à la vitesse du bloc, restauration instantanée | Rapide sur stockage objet local ; considérations de frais de sortie et de bande passante en cloud public |
| Profil de coût | Coût d’entrée faible, augmente avec le nombre d’hôtes | Point d’entrée plus élevé, s’aplatit à l’échelle |
| Serveur de sauvegarde compromis | Ne peut pas supprimer les fichiers verrouillés ; root sur l’hôte le pourrait | Ne peut pas raccourcir les verrous ; exige une compromission distincte de la plateforme de stockage |
| Cas d’usage idéal | Rétention locale à court terme, sites plus petits, restaurations opérationnelles rapides | Rétention longue, copies hors site, parcs importants ou en croissance |
Les deux modèles ne s’excluent pas mutuellement, et le scale-out backup repository est conçu pour les combiner. Un schéma courant utilise un dépôt durci comme niveau de performance pour les points de restauration récents, là où les restaurations locales rapides comptent le plus, et un bucket object lock comme niveau de capacité pour la rétention longue et la copie hors site. L’immutabilité s’applique aux deux niveaux, de sorte qu’une fenêtre courte sur l’hôte durci ne laisse pas les données plus anciennes exposées.
Questions qui aident à trancher la répartition :
Scality ARTESCA est un stockage objet S3 conçu pour la sauvegarde, validé avec Veeam comme dépôt object lock tant en écriture directe vers l’objet que comme niveau de capacité. L’immutabilité est appliquée par la plateforme, de sorte qu’un serveur Veeam compromis ne peut ni raccourcir ni retirer la rétention des objets verrouillés. Le modèle de sécurité est décrit sur la page sécurité et cyber-résilience d’ARTESCA.
ARTESCA est disponible sous forme de logiciel ou d’appliance matérielle et s’étend de quelques dizaines de téraoctets à plusieurs pétaoctets dans un espace de noms unique, ce qui convient aux rôles de rétention longue et hors site où une flotte de dépôts durcis devient difficile à gérer. Des conseils pour dimensionner un niveau object lock figurent dans l’article sur le dimensionnement du dépôt de sauvegarde, et la liste des applications de sauvegarde validées se trouve sur la page compatibilité sauvegarde.
Quel que soit le modèle choisi, l’étape pratique est la même : décider qui est responsable du point d’application, le documenter, et tester une restauration depuis des données immuables avant qu’un incident n’impose la question.