La fonction « Covert Copy » gagne en intelligence : présentation de la prise en charge des sauvegardes incrémentielles

Il existe un mode opératoire bien documenté que suivent les auteurs de rançongiciels. Ils s’introduisent dans le système, restent discrets et passent des jours, des semaines, voire des mois à cartographier l’environnement. Ils recherchent des données de valeur, ainsi que l’infrastructure de sauvegarde et les données qu’ils peuvent localiser, désactiver et chiffrer. Au moment où la demande de rançon apparaît, les options de récupération ont déjà disparu.

Les menaces internes ou le vol d’identifiants d’administrateur constituent une menace encore plus difficile à contrer. Ces acteurs peuvent simplement se connecter et voler vos données sans déclencher la moindre alerte.

La défense la plus efficace s’avère être la plus simple : rendre la sauvegarde invisible. Une copie de récupération qui n’apparaît pas dans les listes de répertoires, ne répond pas aux appels API et n’existe nulle part où un attaquant analysant l’environnement songerait à chercher. Si la sauvegarde est introuvable, elle ne peut pas être neutralisée. Et même si une personne disposant d’identifiants valides parvient à la localiser, elle ne peut pas accéder aux données sans l’autorisation de plusieurs personnes.

C’est le principe qui sous-tend la technologie Wasabi Covert Copy™ : isolée physiquement du stockage principal, elle n’apparaît pas dans les opérations S3 standard et est protégée par des identifiants root, l’authentification multifactorielle (MFA) et Multi-User Authorization (MUA) dont le déverrouillage nécessite l'intervention de plusieurs personnes. La menace ne trouve rien, s'exécute quand même, et l'organisation se rétablit à partir d'une copie intacte dont l'attaquant ignorait l'existence.

Mais il existe une version de ce scénario au dénouement désastreux, dans laquelle la copie de restauration est intacte, invisible et inaccessible aux pirates, mais également obsolète depuis plusieurs mois. Dans ce cas, la sécurité a parfaitement fonctionné, mais la restauration n’a permis de ramener les opérations qu’à un état qui accusait un retard de plusieurs mois par rapport à ce qu’il aurait dû être.

C’est précisément cette lacune que la dernière amélioration apportée à Covert Copy vise à combler.

Pourquoi l'invisibilité ne suffisait-elle pas ?

Notre première version de Covert Copy créait une copie protégée à un instant donné. Cette copie était véritablement sécurisée, grâce à la mise en place d’une barrière physique et de contrôles d’accès au niveau de l’infrastructure. Mais elle était statique. Si le compartiment source évoluait après la création de la copie Covert Copy, celle-ci ne suivait pas. La seule façon de la mettre à jour consistait à la supprimer et à créer un nouveau compartiment Covert Copy à partir du compartiment source mis à jour.

Pour les organisations disposant d’ensembles de données largement statiques, cette contrainte était gérable. En revanche, pour celles exécutant des charges de travail en temps réel (données d’application qui changent chaque semaine, fichiers de configuration mis à jour à chaque déploiement, magasins d’objets dont la taille ne cesse d’augmenter), Covert Copy n’était pas la solution la plus adaptée. Dans ces cas-là, les clients devaient recourir à Wasabi Object Lock le caractère manuel de la mise à jour d’une « Covert Copy » pouvait conduire certaines organisations à laisser leur « Covert Copy » se désynchroniser excessivement par rapport au compartiment source. Le modèle de sécurité restait intact, la copie demeurant invisible et inaccessible, mais sans intervention manuelle, les données qu’elle contenait s’éloignaient de plus en plus de la source. Un point de restauration datant de trois mois peut encore constituer une bouée de sauvetage. Un point datant de douze mois relève d’une tout autre discussion.

C’est cette lacune opérationnelle que Covert Copy a désormais comblée.

Que fait la dernière version de Covert Copy ?

Lorsqu’un cycle de « Covert Copy » est lancé, le système identifie les versions d’objets nouvellement créées dans le compartiment source qui ne sont pas encore présentes dans le « Covert Copy », puis les réplique. Tout ce qui se trouve déjà dans le « Covert Copy » reste inchangé. Il s’agit d’une réplication delta ciblée, et non d’une reconstruction, qui s’effectue entièrement au sein de l’infrastructure interne de Wasabi.

Tout au long de ce processus, le compartiment Covert Copy reste entièrement isolé (air-gapped), exclu des opérations S3 et soumis aux mêmes contrôles d’accès que ceux qui régissent toute autre interaction avec celui-ci : identifiants root, authentification multifactorielle (MFA) et authentification par le fournisseur de messagerie (MUA). Cette nouvelle fonctionnalité permet à Covert Copy de prendre en charge les sauvegardes incrémentielles.

Il n’y a aucune fenêtre d’exposition. Le compartiment est aussi invisible pendant une actualisation qu’au repos.

Les administrateurs configurent les intervalles d’actualisation à 30, 60 ou 90 jours, en trouvant un équilibre entre les exigences opérationnelles et les objectifs de restauration. Le bon intervalle dépend de la fréquence à laquelle les données sources changent et des exigences en matière de restauration.

Quelles en sont les implications pour la cyber-résilience ?

Le modèle dominant en matière de sécurité des sauvegardes a longtemps été celui de la « défense en profondeur » : des copies redondantes réparties sur plusieurs systèmes qu’un attaquant devrait repérer et neutraliser avant de pouvoir passer à l’action. Le problème est que la notion de « profondeur » suppose toujours une « détectabilité ». Plus il y a de systèmes de sauvegarde, plus il y a de cibles.

Covert Copy repose sur un principe totalement différent. La sécurité ne provient pas de la redondance, mais de l’impossibilité de cibler quelque chose que l’on ne peut pas localiser. Cela reste vrai même lorsque d’autres infrastructures de sauvegarde sont compromises.

Pour les équipes informatiques et de sécurité, le nouveau Covert Copy passe d’une tâche manuelle périodique à une ressource de restauration maintenue en continu. Pour les organisations évoluant dans des secteurs réglementés, cette continuité présente un intérêt direct en matière de conformité. Une architecture de protection des données capable de démontrer l’alignement, horodaté, entre les données de production et une copie de restauration protégée constitue une position plus défendable qu’une architecture documentée par un journal de reconstruction datant de plusieurs mois.

La résilience ne se limite pas à survivre à une attaque. Elle consiste à restaurer les opérations avec une fidélité suffisante pour que l’activité puisse réellement reprendre. Cela nécessite un point de restauration à jour. Covert Copy rend cela possible sans modifier en quoi que ce soit la manière dont les données Covert Copy sont sécurisées.

Qu'est-ce que cela signifie concrètement ?

Pour les équipes informatiques, cette évolution revêt une importance bien plus grande qu’il n’y paraît à première vue. Dans l’ancien modèle, la gestion d’une « Covert Copy » impliquait une dette opérationnelle récurrente : suivre la date de la dernière reconstruction, évaluer si l’écart s’était trop creusé, coordonner les autorisations nécessaires à sa suppression, puis la reconstruire à partir de la source mise à jour. Dans les environnements où ce processus était en concurrence avec toutes les autres tâches en attente, il pouvait se retrouver relégué au second plan. La copie restait cachée et sécurisée, mais l’écart entre celle-ci et les données source actuelles se creusait.

Avec la dernière version de Covert Copy, le cycle de reconstruction est remplacé par un processus planifié et automatisé qui s’exécute sans intervention administrative entre les cycles. Les équipes informatiques n’ont plus besoin de suivre l’écart ni de planifier des fenêtres de maintenance en fonction de celui-ci. La posture de protection reste à jour, et l’effort nécessaire pour la maintenir se résume à configurer un intervalle une seule fois et à le vérifier selon un calendrier défini.

Il en résulte une architecture de restauration plus facile à maintenir et plus fiable lorsque cela compte vraiment. Non pas parce que la sécurité est devenue plus simple, mais parce que la charge opérationnelle liée à sa mise à jour l’est devenue.