Pourquoi le chiffrement de bout en bout est crucial aujourd’hui

Lorsque les gens parlent de chiffrement dans les architectures de sauvegarde, ils ont tendance à se focaliser sur les mauvais sujets. Vous entendrez parler de chiffrement en transit, de chiffrement au repos, de chiffrement point à point — des termes rassurants, mais qui ne répondent pas à la seule question qui compte : les données ont-elles été non chiffrées à un moment quelconque entre la production et le stockage final de sauvegarde ? Si la réponse est oui, même brièvement, vous avez introduit un risque de sécurité.  

Le chiffrement de bout en bout élimine cette faiblesse d’architecture. Dès que Veeam lit les données depuis le stockage de production, il les chiffre lorsque le chiffrement des fichiers de sauvegarde est activé. À partir de cet instant, les données ne reviennent jamais à l’état non chiffré jusqu’à ce que Veeam les restaure. Peu importe le nombre de data movers, de passerelles ou de réseaux traversés. Peu importe le nombre de copies que vous faites. Les données sont chiffrées une fois, et elles restent chiffrées, jusqu’à ce que Veeam les restaure. 

C’est l’étalon-or. Tout le reste est un compromis sur la sécurité. C’est pourquoi le chiffrement de bout en bout est exigé par diverses réglementations, organismes de contrôle et contrats d’assurance.

Définir le chiffrement de bout en bout 

 

 

 

 

Dans un modèle de chiffrement de bout en bout, le chiffrement se produit immédiatement à la source. Veeam lit les données de production, génère une clé de session unique pour l’exécution de cette sauvegarde, et chiffre les données au niveau du proxy source. Cette clé n’est jamais partagée avec les réseaux, les équipements de stockage, Object First ni avec quiconque d’autre dans la chaîne. Si quelqu’un intercepte les données, il n’obtient que du texte chiffré. 

C’est aussi pourquoi les appliances de déduplication peinent avec le chiffrement de bout en bout. Elles ont besoin de données non chiffrées pour effectuer la recherche de motifs. Mais dès l’instant où vous autorisez des données non chiffrées en dehors du système de production source, vous avez cassé le modèle de sécurité. Vous avez créé une ou plusieurs fenêtre(s) où des attaquants peuvent voir ou manipuler vos données. C’est pourquoi la déduplication est le contrevenant le plus flagrant aux principes de bout en bout : elle vous oblige à supposer que rien de mauvais ne se produit pendant ces états non chiffrés. 

Ce n’est pas un modèle de confiance sur lequel quiconque devrait s’appuyer aujourd’hui. 

Pourquoi le chiffrement de bout en bout est essentiel pour des sauvegardes résilientes aux rançongiciels 0resilient 

Une conception résiliente aux rançongiciels consiste à éliminer les points faibles. Tout moment où les données sont non chiffrées, ou modifiables, est un moment qu’un attaquant peut exploiter. Si vous chiffrez ici, déchiffrez là, puis rechiffrez ailleurs, vous vous appuyez sur un patchwork de protections et d’hypothèses. Il existe des défis similaires si vous autorisez des données modifiables.  Vous créez un système complexe avec de multiples points de défaillance. Vous créez aussi davantage de clés à gérer, davantage d’états à suivre, et davantage d’opportunités de mauvaise configuration et de complexité lors de la restauration. 

Lorsque les données sont chiffrées de bout en bout, le modèle de sécurité devient nettement plus simple. Si quelqu’un intercepte les données à n’importe quel point, il ne voit que des objets chiffrés. Si quelqu’un compromet des identifiants de stockage ou de bucket, il peut lire le bucket — mais tout ce qu’il verra, ce sont des données chiffrées. Si quelqu’un compromet un serveur intermédiaire ou une passerelle, il ne peut toujours rien déchiffrer. Le chiffrement ne cesse jamais de vous protéger. 

C’est la même logique derrière notre principe de Immutabilité instantanée. Vous voulez que les données soient immuables dès l’instant où elles arrivent sur le stockage et qu’elles soient chiffrées dès l’instant où elles quittent la production. Chaque écart entre ces deux états élargit les surfaces de risque. Le chiffrement de bout en bout réduit cette surface. 

Comment le chiffrement de bout en bout fonctionne entre Veeam et Object First 

Le cycle de vie commence par l’activation du chiffrement des tâches dans Veeam. C’est la fonctionnalité qui active le chiffrement de bout en bout. Lorsqu’une tâche de sauvegarde démarre, Veeam génère une nouvelle clé de session — unique pour cette exécution — et chiffre les données au fur et à mesure qu’il les lit. Même si vous sauvegardez exactement les mêmes données une autre fois, la sortie chiffrée aura un aspect totalement différent, car elle est chiffrée avec une clé différente. Ce modèle de clés tournantes, non réutilisables, est important, car il empêche l’analyse de motifs et renforce la cryptographie. Si vous continuiez à chiffrer les mêmes données avec la même clé, des attaquants pourraient commencer à faire de la recherche de motifs. La rotation des clés bloque cela. 

Une fois chiffrées, les données transitent dans l’infrastructure Veeam — proxies, passerelles, réseaux — et finissent par arriver dans votre dépôt de sauvegarde. À aucun moment, quelqu’un d’autre que Veeam ne possède la clé. Les équipements de stockage ne l’ont pas. Le réseau ne l’a pas. Les proxies ne l’ont pas. Si quelqu’un intercepte les données, il n’obtient que du texte chiffré. 

Lorsque les objets arrivent dans Object First (ou Veeam Data Cloud Vault), nous les stockons exactement tels que nous les recevons. Nous ne savons pas s’ils sont chiffrés ou non chiffrés, et nous n’en avons pas besoin. Cela ne nous aide pas de voir des données non chiffrées, et cela ne nous pénalise pas de stocker des données chiffrées. 

L’intégrité est préservée via plusieurs couches. Veeam, avant le chiffrement, compresse les instances uniques et intègre des sommes de contrôle et des métadonnées dans chaque objet ; ainsi, si quoi que ce soit est altéré, Veeam le sait immédiatement. Par ce biais, Veeam crée une chaîne de traçabilité des données de sauvegarde et des copies. Nous exécutons également nos propres contrôles d’intégrité et analyses. Et comme les données sont immuables, les attaquants ne peuvent ni les modifier ni les supprimer, même s’ils obtiennent des identifiants de stockage. 

Lors de la restauration, notre rôle est volontairement minimal. Nous ne réhydratons rien, ne déchiffrons rien et ne transformons rien. Nous renvoyons simplement l’objet. Veeam gère le déchiffrement, la décompression et la réhydratation. Cette séparation maintient une frontière de chiffrement nette et correspond au modèle ZTDR consistant à séparer le logiciel de sauvegarde du stockage de sauvegarde. 

Ce modèle s’étend aussi proprement à la règle 3-2-1 Sauvegarde. Lorsque Veeam copie des données depuis la sauvegarde primaire vers un niveau de capacité SOBR ou un niveau d’archivage, ou via une tâche de copie, les données restent chiffrées avec la clé de session d’origine. Elles ne sont jamais déchiffrées puis rechiffrées en chemin. C’est tout l’intérêt de faire les choses correctement dès le départ. 

Chiffrement et Immuabilité absolue : réduire le rayon d’impact des rançongiciels 

Le chiffrement et l’Immuabilité absolue sont des composantes indissociables de Résilience des données et de la sécurité. Ils se renforcent mutuellement d’une manière qui change fondamentalement ce qu’un attaquant peut et ne peut pas faire dans votre environnement de sauvegarde. 

Le chiffrement de bout en bout garantit que chaque composant entre la production et le stockage de sauvegarde ne voit jamais que des données chiffrées. Même si quelqu’un les intercepte ou obtient l’accès au bucket, il n’obtient que du texte chiffré. Et comme Veeam fait tourner les clés à chaque session de sauvegarde, même des données identiques n’ont jamais deux fois le même aspect. Il n’y a aucun motif à analyser, aucun point d’appui pour faire de la rétro-ingénierie. 

L’Immuabilité absolue prend le relais là où le chiffrement s’arrête. Dans Object First, l’immutabilité est instantanée dès l’écriture de l’objet, grâce à Technologie S3 Object Lock. Une fois cette rétention définie, personne — pas même un administrateur — ne peut modifier ou supprimer l’objet.  

Le chiffrement empêche les attaquants de comprendre les données ; l’Immuabilité absolue les empêche de les altérer ou de les détruire. L’un protège la confidentialité ; l’autre protège l’intégrité et impose une chaîne de traçabilité. Ensemble, ils neutralisent les deux voies sur lesquelles les acteurs de rançongiciels s’appuient le plus : la corruption des données et l’exfiltration de données. 

Cette combinaison est particulièrement importante dans une approche Assume Breach. Vous devez supposer que quelqu’un — ou un logiciel malveillant — obtiendra des identifiants à privilèges élevés. Vous devez supposer que le bucket sera lu. Vous devez supposer que les défenses échoueront — c’est pourquoi les deux couches sont nécessaires. Si un attaquant compromet des identifiants de stockage, l’Immuabilité absolue l’empêche de modifier ou de supprimer les sauvegardes. S’il tente d’exploiter cette compromission pour exfiltrer des données, le chiffrement garantit qu’il ne peut rien faire de ce qu’il vole. Il comprend rapidement que c’est une perte de temps et reporte son attention sur des cibles plus faciles. 

Le résultat pratique est un modèle de protection des données et de sécurité simple, mais hautement efficace, qui réduit drastiquement le risque. Même dans un scénario du pire — où votre serveur VBR a disparu, où les identifiants de stockage sont compromis et où les attaquants ont une visibilité totale sur votre stockage — vous pouvez toujours reconstruire de zéro l’intégralité de votre environnement logiciel de sauvegarde et reprendre les opérations. Le chiffrement de bout en bout garantit que les données sont inutilisables sauf par Veeam. L’Immuabilité absolue garantit que les données sont intactes. Et comme Veeam maintient la frontière de chiffrement et la chaîne de traçabilité, le processus de restauration reste propre et maîtrisé. 

C’est l’architecture qui maintient les organisations résilientes lors d’événements catastrophiques. Lorsque le chiffrement et l’immutabilité fonctionnent ensemble, les sauvegardes cessent d’être une responsabilité supplémentaire et deviennent la partie la plus sécurisée et la moins complexe de votre environnement.

Mauvaises configurations courantes et pièges 

La plupart des échecs ne sont pas techniques — ce sont des décisions et des processus opérationnels.  

La plus grosse erreur consiste simplement à ne pas activer le chiffrement partout. Cela ajoute votre environnement de sauvegarde à votre matrice de menaces d’exfiltration de données. Avec Veeam, vous pouvez activer le chiffrement pour les tâches de sauvegarde et bénéficier du chiffrement de bout en bout ; ou vous pouvez configurer le chiffrement à plusieurs emplacements, dépôts et équipements de stockage. Dans ce dernier cas, oubliez ou configurez mal une seule étape, et vous avez rompu la chaîne de bout en bout. 

Un autre problème courant est de ne pas séparer le logiciel de sauvegarde du stockage de sauvegarde. Si des attaquants compromettent l’un, ils ne devraient pas compromettre automatiquement l’autre. Les principes Zero Trust et ZTDR s’appliquent ici. 

L’erreur la plus catastrophique est une mauvaise gestion des mots de passe/clés de chiffrement de récupération. Si vous perdez les mots de passe qui amorcent le chiffrement de Veeam, ni Veeam ni Object First ne peuvent vous aider. Ces clés doivent être stockées de manière redondante, physiquement et de façon sécurisée. Il est judicieux de les partager et de les maintenir avec plusieurs cadres seniors, et hors ligne.  Des sauvegardes chiffrées de la configuration doivent être exécutées régulièrement. C’est le coût du chiffrement de bout en bout — non pas le chiffrement lui-même, mais la discipline opérationnelle nécessaire pour le gérer et pour garantir qu’en cas de catastrophe, vous pouvez recréer votre environnement Veeam et lui fournir les mots de passe de chiffrement initiaux afin de terminer la restauration de la configuration. 

L’avenir du stockage chiffré, sauvegarde immuable 

Les rançongiciels évoluent, et le chiffrement aussi. La migration vers un chiffrement sûr face au post-quantique a été engagée par Veeam et est alignée architecturalement sur le rapport NIST IR 8547 « Transition to Post-quantum cryptographic standards », et le basculement vers le chiffrement post-quantique continuera de façonner la manière dont les données de sauvegarde sont protégées.  

À l’avenir, les principes d’architecture qui comptent le plus sont les mêmes que ceux qui comptent aujourd’hui. Créez et maintenez un environnement sûr et simple avec : les principes Résilience des données Zero Trust, une approche Assume Breach, la séparation du logiciel de sauvegarde et du stockage, l’Immuabilité absolue, la règle 3‑2‑1 Sauvegarde, et des tests réguliers. Ce sont ces pratiques qui garantissent que vous pouvez récupérer vos données quoi qu’il arrive.  

La tendance de fond est que les organisations doivent sécuriser toutes les données, pas seulement les données de production. Les sauvegardes sont la dernière ligne de défense — et de plus en plus les premières cibles d’attaque. Le chiffrement de bout en bout, combiné à l’immutabilité, constitue un élément clé pour garder une longueur d’avance sur les rançongiciels.