Renforcer les sauvegardes Velero avant que les ransomwares ne les trouvent

Velero reste l'un des outils open source les plus courants pour sauvegarder, restaurer et migrer les ressources d'un cluster Kubernetes et les volumes persistants. Pour les fournisseurs de services managés qui exploitent de nombreux clusters, la qualité de la configuration de Velero — et pas seulement son installation — détermine si une sauvegarde est réellement utile lors d'un incident.

Une sauvegarde réussie n'est pas une restauration réussie

Une tâche de sauvegarde qui se termine sans erreur prouve que les données ont été capturées, pas qu'elles peuvent être restaurées. Les opérateurs de ransomwares ciblent de plus en plus spécifiquement les identifiants de sauvegarde et les emplacements de stockage, sachant qu'un chemin de restauration fonctionnel fait la différence entre un incident et une panne. Les exercices de restauration, planifiés et consignés comme preuves, sont le seul moyen fiable de savoir qu'une sauvegarde fonctionnera lorsqu'elle sera nécessaire.

Où concentrer les efforts de renforcement

• Restreindre les RBAC accordés au compte de service de Velero à ce que la sauvegarde et la restauration exigent réellement, et non à cluster-admin par défaut.
• Chiffrer les sauvegardes au repos et conserver au moins une copie hors site ou immuable, afin qu'un cluster compromis ne puisse pas aussi détruire ses propres sauvegardes.
• Séparer le chemin de gestion du stockage de sauvegarde du réseau de charge de travail partout où le backend de stockage le permet.
• Faire tourner et limiter la portée des identifiants que Velero utilise pour accéder au stockage d'objets, en privilégiant les jetons à courte durée de vie aux clés statiques à longue durée de vie.
• Traiter le chemin de restauration lui-même comme une capacité d'administration de production — toute personne pouvant déclencher une restauration peut généralement écraser des données en direct.

Ce que Velero ne couvre pas à lui seul

Velero sauvegarde les objets Kubernetes et, avec le bon plugin, les données des volumes persistants — il ne protège pas à lui seul contre un cluster compromis qui altérerait son propre calendrier de sauvegarde, et il ne remplace pas une segmentation au niveau du réseau. L'associer à un stockage immuable et hors site comble la lacune la plus courante que les MSP constatent en pratique : des sauvegardes qui existent mais restent accessibles depuis le même rayon d'impact que le cluster qu'elles protègent.

La base qui compte est peu spectaculaire : des copies chiffrées et hors site, un accès restreint et un exercice de restauration réellement exécuté — pas seulement planifié.

Sources : GitHub — vmware-tanzu/velero, Documentation Velero.