Principes fondamentaux de la sauvegarde : réseau, classification et notions de base sur le DPaaS

Trois tendances que je constate régulièrement

Après sept ans d’analyses d’architecture menées auprès de nos clients, trois tendances reviennent si souvent que j’aborde désormais ces points dès le premier entretien. Je vérifie si l’équipe comprend bien ce que la « protection des données en tant que service » est censée couvrir. Quelles questions elles posent aux fournisseurs de solutions de sauvegarde lors de l’évaluation. Et comment elles sécurisent les chemins réseau empruntés par les données de sauvegarde.

La plupart des équipes avec lesquelles je m’entretiens présentent des lacunes dans au moins deux de ces trois domaines. Parfois, dans les trois. Ces lacunes ne sont pas dues à une insuffisance des équipes. Elles s’expliquent par le fait que le secteur a généré un tel brouhaha autour de la sauvegarde que les principes fondamentaux sont noyés sous le positionnement des produits. Cet article correspond à ce que je dirais à un collègue qui me demanderait : « Que dois-je réellement savoir sur l’architecture de sauvegarde avant de signer un contrat ? »

Les bases du DPaaS : ce que couvre réellement la protection des données en tant que service

La protection des données en tant que service (DPaaS) est un modèle de prestation dans lequel la sauvegarde, la restauration, la migration et la reprise après sinistre sont fournies sous forme de service géré. Il ne s’agit pas d’un logiciel que le client installe, configure et entretient. Le client s’abonne. Le service fonctionne.

La question pertinente n’est pas de savoir ce que signifie le DPaaS en tant que catégorie, mais ce qu’une véritable plateforme DPaaS doit réellement offrir. Trois piliers en définissent la portée.

Protection des données

Sauvegarde et reprise cohérentes au niveau de l’application pour chaque charge de travail exécutée dans l’environnement. Machines virtuelles, bases de données, applications conteneurisées, stockage objet et applications SaaS. L’exigence fondamentale est la cohérence entre les environnements. Même cadre de politiques, même modèle de reprise, même gestion, que la charge de travail s’exécute sur site, sur AWS, sur Azure, sur Google Cloud ou dans des applications SaaS telles que Microsoft 365 et Salesforce. 

Migration des données

Les mêmes données de sauvegarde qui protègent une charge de travail permettent également de déplacer cette dernière. Entre un environnement sur site et le cloud, entre différents fournisseurs de cloud ou entre différentes régions. La migration ne constitue pas une catégorie de produit distincte dans le DPaaS moderne. Il s’agit d’une opération de restauration ciblant une destination différente. Environ 95 % des clients du cloud procèdent à une forme ou une autre de migration de charge de travail à tout moment, dans le but d’optimiser les coûts et les performances, ce qui fait de la migration une exigence opérationnelle continue, et non un événement ponctuel. 

Reprise après sinistre

Reprise après sinistre (DR) native du cloud utilisant des régions de cloud public comme cibles de basculement, avec un modèle économique pertinent. Stockez la copie de sauvegarde en continu à moindre coût. Ne consommez des ressources de calcul et de stockage haute performance que lorsque la reprise après sinistre est effectivement déclenchée. Les environnements de réplication fonctionnant en permanence sont coûteux précisément parce qu’ils tournent 24 h/24 et 7 j/7 pour un événement qui pourrait ne jamais se produire. La reprise après sinistre facturée uniquement en cas de déclenchement ne représente qu’une fraction de ce coût.

Le rapport « State of the Cloud 2026 » de Flexera a révélé que 73 % des organisations exploitent des environnements cloud hybrides, l’adoption du multicloud continuant de progresser, souvent sous l’impulsion de fusions, de la prolifération des solutions SaaS et de la décentralisation des équipes plutôt que d’une stratégie délibérée. Une plateforme DPaaS qui ne couvre pas l’ensemble des clouds sur lesquels l’entreprise opère ne constitue pas une stratégie complète de protection des données. Il s’agit d’une stratégie partielle comportant des lacunes que le client est chargé de combler.

Évaluer votre infrastructure de sauvegarde : cinq questions qui font la différence

La plupart des fournisseurs de solutions de protection des données ont simplement reconditionné leurs produits existants sous une image de marque « cloud ». L’architecture sous-jacente — tailles fixes, agents par serveur, déploiements initiaux importants — reste l’approche du centre de données transposée sous une forme hébergée dans le cloud. Cinq questions permettent de voir rapidement au-delà du discours marketing. 

Ces questions révèlent la réalité architecturale qui se cache derrière le discours marketing. Un fournisseur dont les réponses commencent par « cela dépend de votre environnement » ou « nous pouvons vous permettre d’évoluer grâce à des appliances supplémentaires » vend en réalité le modèle sur site sous l’apparence du cloud. 

Considérations relatives au réseau : sécuriser les chemins empruntés par les données de sauvegarde

La protection des données de sauvegarde dépend entièrement de la sécurité des chemins réseau entre les sources, les hôtes et les cibles de stockage. Une architecture de sauvegarde dotée d’un chiffrement robuste au repos mais d’une sécurité réseau faible sur le chemin menant à la cible est tout aussi vulnérable que le maillon le plus faible de cette chaîne. Cinq catégories sont particulièrement importantes.

Configuration multi-homing de la machine virtuelle de sauvegarde

Bien qu’une seule carte réseau virtuelle (vNIC) soit suffisante, la configuration multi-homing de la machine virtuelle de sauvegarde avec deux vNIC (l’une pour la gestion, l’autre pour le réseau de stockage) offre une séparation plus nette et permet aux administrateurs de désactiver le listener Web sur la vNIC de stockage. Le trafic de sauvegarde de production ne doit pas partager d’interface avec l’accès administratif. Si une fuite d’identifiants permet à un attaquant d’accéder à la console Web, vous ne souhaitez pas qu’il se trouve sur le même réseau que les données de sauvegarde.

Sécurisation des connexions aux cibles de stockage

Les différentes cibles de stockage ont des exigences de sécurité réseau différentes.

Bonnes pratiques en matière de certificats et d’authentification

Les certificats auto-signés conviennent pour le déploiement initial, mais doivent être remplacés par des certificats émis par l’autorité de certification (CA) de votre organisation en environnement de production. Les connexions source à la gestion de l’hyperviseur (Nutanix Prism, VMware vCenter) doivent utiliser l’authentification par certificat lorsque cela est pris en charge. L’accès SSH à la machine virtuelle de sauvegarde doit être désactivé après la configuration initiale. L’administration courante doit s’effectuer via l’interface utilisateur Web ou les interfaces de gestion de la plateforme, et non via le shell.

Limitation des accès administratifs

L’accès à Prism Element, vCenter ou à la console du fournisseur de cloud pour les environnements contenant une infrastructure de sauvegarde doit être limité à certains administrateurs et postes de travail spécifiques, et non à l’ensemble de l’équipe informatique. La microsegmentation permet d’assurer cette mise en œuvre. Le réseau de gestion des sauvegardes ne doit être accessible qu’à partir d’hôtes de saut administratifs désignés, et non à partir de postes de travail généraux ou de machines de développeurs.

Des mesures d’hygiène de base qui réduisent considérablement la surface d’attaque

Trois bonnes pratiques permettent d’éliminer la majeure partie de la surface d’attaque réseau contre l’infrastructure de sauvegarde. Pas d’accès à Internet pour les serveurs de production ; acheminement via des proxys et des serveurs bastions. Une hygiène rigoureuse des postes de travail pour les administrateurs détenant des identifiants de sauvegarde, car la voie la plus facile pour la plupart des ransomwares passe par la machine d’un administrateur compromise. Et une sélection des cibles de stockage intégrant des fonctionnalités anti-ransomware (immuabilité, WORM, verrouillage d’objets) au niveau même de la couche de stockage. 

Questions courantes sur les principes fondamentaux de la sauvegarde

Quelle est la différence entre le DPaaS et le BaaS ?

Le « Backup-as-a-Service » (BaaS) est un terme plus restreint, désignant spécifiquement la sauvegarde et la restauration en tant que service géré. La « Data Protection as a Service » (DPaaS) est un concept plus large, couvrant la sauvegarde, la restauration, la migration et la reprise après sinistre en tant que fonctionnalités intégrées au sein d’une seule et même plateforme. La plupart des offres modernes proposent du DPaaS même lorsqu’elles sont commercialisées sous l’appellation BaaS. La distinction réside dans le fait que la plateforme gère ou non la migration et la reprise après sinistre via le même plan de gestion que la sauvegarde.

Comment savoir si un fournisseur de sauvegarde est « cloud-native » ou simplement « cloud-washed » ?

Trois questions de diagnostic. La solution nécessite-t-elle le déploiement et la maintenance d’un appareil virtuel de sauvegarde dans le cloud ? Si oui, l’architecture sur site a simplement été transposée sous une forme hébergée dans le cloud. La tarification évolue-t-elle en fonction de l’utilisation réelle, ou nécessite-t-elle des engagements initiaux en matière de licence et de provisionnement de stockage ? La solution détecte-t-elle automatiquement les nouvelles charges de travail via les API cloud, ou nécessite-t-elle une configuration manuelle pour chaque nouvelle machine virtuelle ? La configuration manuelle et le dimensionnement fixe relèvent du modèle d’exploitation des centres de données.

Quelle est la faille de sécurité réseau la plus courante dans les déploiements de sauvegarde ? 

Le partage de sauvegarde SMB connecté à un trop grand nombre de machines. Les administrateurs configurent une cible SMB, la paramètrent correctement avec un compte de service, puis montent ce même partage sur d’autres serveurs pour des raisons de commodité : serveurs de fichiers, serveurs d’applications, voire postes de travail. Chaque machine sur laquelle le partage est monté devient un vecteur d’attaque potentiel. Les partages cibles de sauvegarde ne doivent être accessibles qu’à partir de la machine virtuelle de sauvegarde elle-même.

Ai-je besoin du protocole CHAP si mon trafic iSCSI reste à l’intérieur d’un réseau privé ?

Oui. Les attaques modernes partent du principe que l’attaquant se trouve déjà à l’intérieur du réseau. Les défenses périmétriques ne constituent plus le modèle de menace. Le protocole CHAP authentifie l’initiateur iSCSI auprès de la cible, de sorte qu’un hôte compromis sur le même réseau ne puisse pas monter le stockage. La configuration ne prend que quelques minutes. La protection est efficace.

Si vous ne devez retenir qu’une seule chose de cet article

Passez en revue les cinq questions d’évaluation avec votre fournisseur de sauvegarde actuel au cours de ce trimestre. Si leurs réponses vous mettent mal à l’aise, ce malaise est un signal qui mérite d’être approfondi. Les fournisseurs capables de répondre clairement à ces questions sont ceux qui ont su s’adapter à l’environnement dans lequel vous évoluez. Ceux qui en sont incapables continueront à vous donner ces réponses dérangeantes tant que vous resterez chez eux.