---
title: "Comment sauvegarder plusieurs zones de sécurité sans compromettre la segmentation du réseau"
published_at: "2026-10-15T07:50:13+00:00"
modified_at: "2026-10-15T07:50:30+00:00"
url: "https://www.baculasystems.com/fr/blog-fr/sauvegarde-sur-plusieurs-zones-de-securite/"
markdown_url: "https://www.baculasystems.com/fr/blog-fr/sauvegarde-sur-plusieurs-zones-de-securite.md"
---

[Bienvenue](https://www.baculasystems.com/fr/)
 > [Blog sur la sauvegarde et la restauration](https://www.baculasystems.com/fr/blog-fr/)
 > Comment sauvegarder plusieurs zones de sécurité sans compromettre la segmentation du réseau

# Comment sauvegarder plusieurs zones de sécurité sans compromettre la segmentation du réseau

Mis à jour 15th octobre 2026, Rob Morrison

La sauvegarde entre plusieurs zones de sécurité doit préserver les limites de confiance imposées par le réseau de production. Utilisez des identifiants spécifiques à chaque zone, des flux réseau à portée restreinte, une séparation entre le trafic de contrôle et le trafic de données, ainsi que des chemins de restauration indépendants. Lorsque la connectivité inter-zones permanente est interdite, recourez à une réplication contrôlée, à un transfert unidirectionnel ou à des supports hors ligne plutôt que d’affaiblir la segmentation du réseau.

Cette note s’adresse aux architectes d’infrastructure et de sécurité ainsi qu’aux administrateurs seniors impliqués dans l’[architecture de sauvegarde d’entreprise](https://www.baculasystems.com/fr/blog-fr/sauvegarde-evolutive/)
 au sein d’environnements délibérément segmentés, tels que la défense, l’aérospatiale, la recherche, les technologies opérationnelles, les infrastructures critiques et les entreprises exploitant des réseaux couvrant différents niveaux de classification ou domaines de confiance. Il peut s’agir de domaines réseau classifiés et non classifiés, de l’informatique d’entreprise par opposition aux technologies opérationnelles en atelier, ainsi que de configurations similaires.

L’accent est mis sur les connaissances en matière de sauvegarde et sur la résolution d’un problème de conception spécifique. Plus précisément, cette note traite de la protection des zones sans créer de nouveaux chemins entre elles.

**Points clés**

- La sauvegarde multizone doit préserver les limites existantes des zones de sécurité.
- Utilisez des identifiants privilégiés spécifiques à chaque zone et des règles de pare-feu à portée restreinte.
- Séparez le trafic de contrôle de la sauvegarde du trafic des données de sauvegarde.
- Maintenez une capacité de restauration locale lorsque les zones doivent fonctionner de manière indépendante.
- Testez la restauration en simulant l’indisponibilité de la connectivité inter-zones, de la gestion centralisée des identités et des catalogues partagés.

## Pourquoi la sauvegarde est-elle difficile à mettre en œuvre sur plusieurs zones de sécurité ?

Les architectures de sauvegarde centralisées peuvent créer des risques de sécurité structurels dans les environnements segmentés. Elles s’appuient souvent sur une connectivité permanente et des privilèges élevés au-delà des frontières entre zones, ce qui peut transformer le système de sauvegarde en une voie potentielle de déplacement latéral.

Les architectures de sauvegarde centralisées, telles que les suites de sauvegarde d’entreprise à console unique et les architectures centralisées de type « pull » basées sur des appliances, partent du principe que le serveur de sauvegarde atteint chaque client, que les clients renvoient les données vers un stockage partagé et que tous peuvent accéder au plan de gestion.

Cette hypothèse fonctionne dans un réseau plat. Cependant, elle ne s’applique pas dans des environnements délibérément segmentés, tels que les réseaux tactiques militaires, les enclaves de recherche en matière de défense, ainsi que les environnements industriels de technologie opérationnelle et de contrôle de supervision et d’acquisition de données (SCADA).

La sauvegarde entre zones de sécurité doit préserver les environnements où la segmentation du réseau est imposée. Lorsque la sauvegarde relie la zone informatique de l’entreprise à un environnement d’ingénierie à accès restreint, la segmentation commence à jouer en défaveur du système de sauvegarde.

Le trafic de sauvegarde complique la situation. Cela concerne plus précisément les connexions volumineuses, régulières et authentifiées qui traversent les frontières entre zones selon un calendrier prévisible. Cela concerne également les identifiants de comptes de service dotés de privilèges élevés aux deux extrémités, ainsi que les copies stockées de toutes les données traitées.

Lorsqu’un composant de sauvegarde est compromis, il permet d’accéder à des données provenant de zones qui ne pouvaient pas être atteintes via le réseau de production.

Depuis octobre 2026, la norme NIST SP 1339 (juin 2026) recommande de créer régulièrement des sauvegardes OT, de les tester et de les vérifier lors d’exercices de restauration.

## Pourquoi l’infrastructure de sauvegarde peut-elle créer un risque inter-zones ?

Un serveur de sauvegarde disposant de connexions autorisées vers plusieurs zones peut communiquer entre ces zones via des chemins autorisés. Lorsque le serveur est compromis, les canaux autorisés existants permettent d’accéder à toutes les zones desservies. Ce phénomène est dû à l’emplacement du serveur, et non à une mauvaise configuration.

## Pourquoi faut-il définir des limites de confiance avant de choisir un logiciel de sauvegarde ?

Cartographiez les limites de confiance, le sens des connexions autorisées et les chemins de communication interdits avant de choisir ou de configurer des produits de sauvegarde. Commencez par concevoir l’architecture ; le produit s’y intégrera ensuite.

L’architecture « Zero Trust » du NIST décrit l’élimination de la confiance implicite fondée uniquement sur l’emplacement réseau. [Guide de démarrage rapide du NIST sur la sauvegarde des technologies opérationnelles (OT) (SP 1339)](https://www.nist.gov/publications/ot-backup-quick-start-guide)
 est le guide de démarrage rapide sur la sauvegarde des technologies opérationnelles (OT) publié par l’Institut national des normes et des technologies (NIST) et le Centre national d’excellence en cybersécurité (NCCoE). Ce guide précise que les organisations doivent établir des procédures claires pour la sauvegarde et la restauration après une attaque par ransomware.

[L’architecture « Zero Trust » du NIST (SP 800-207)](https://www.nist.gov/publications/zero-trust-architecture)
 est une publication officielle de l’Institut national des normes et des technologies qui définit l’architecture « Zero Trust » (ZTA) et établit des lignes directrices afin que la cybersécurité puisse s’affranchir des défenses réseau traditionnelles basées sur le périmètre.

Aucune confiance implicite n’est accordée sur la seule base de l’emplacement physique ou de la localisation réseau. Voici une source gouvernementale faisant autorité traitant des [copies de récupération protégées, hors ligne et immuables](https://www.mydatapath.com/blog/backup-immutability-checklist-ransomware-resilient-it-environments/)
.

Une erreur courante consiste à établir d’abord des relations de confiance, puis seulement à choisir une plateforme de sauvegarde.

Les fonctionnalités des produits, telles que la déduplication et la compression en ligne globales, les instantanés multicloud et l’orchestration des baies de stockage, sont moins essentielles que la compréhension des communications autorisées entre les zones. Les produits de sauvegarde ne peuvent pas passer outre une règle de pare-feu correctement appliquée.

1. Avant toute configuration de sauvegarde, identifiez les zones de sécurité et leur niveau de classification.
2. Ensuite, définissez quels systèmes peuvent se connecter à d’autres.
3. Séparer ensuite le trafic du plan de contrôle de celui du plan de données lors des analyses.
4. De plus, identifier les emplacements où les identifiants sont autorisés à exister.
5. Enfin, cartographier les chemins interdits sur lesquels la conception de la sauvegarde peut fonctionner.

L’emplacement des identifiants relève d’une décision relative aux limites de confiance. Un compte de service de sauvegarde disposant d’un accès en lecture aux systèmes de la zone C ne devrait pas exister sur un système connecté à la zone A.

La portée et l’emplacement des identifiants relèvent de décisions relatives aux limites de confiance.

Référence de référence révisée en octobre 2026 : NIST SP 800-207, publiée en août 2020.

## Quels modèles d’architecture de sauvegarde fonctionnent entre plusieurs zones de sécurité ?

Il n’existe pas de modèle universellement valable. Le modèle approprié dépend des niveaux de classification, des chemins de communication autorisés, des exigences de reprise et du coût opérationnel lié à l’isolation de chaque zone. La sauvegarde multizone ne doit pas créer de nouveaux chemins d’accès inter-zones.

Cinq modèles établis permettent d’effectuer des sauvegardes au-delà des frontières entre zones, par exemple entre le réseau informatique d’entreprise et les installations industrielles de technologie opérationnelle, ou entre les enclaves de production générale dans le cloud et les environnements de traitement des paiements conformes à la norme PCI-DSS (Payment Card Industry Data Security Standard).

Chacun d’entre eux représente un compromis entre simplicité opérationnelle et isolation de sécurité.

| Modèle | Description | Idéal pour | Risque principal |
| --- | --- | --- | --- |
| Centralisé | Un seul serveur de sauvegarde utilise des règles de pare-feu inter-zones pour desservir toutes les zones | Zones présentant des niveaux de sensibilité variables mais le même niveau de confiance | Point de compromission unique disposant d’un accès autorisé à toutes les zones |
| Entièrement distribué | Chaque zone dispose de son propre serveur de sauvegarde, de son propre stockage et de son propre catalogue. Les données ne franchissent pas les limites des zones. | Environnements où les données restent toujours au sein de leur zone. | Duplication de l’infrastructure ; complique la restauration inter-zones |
| Hiérarchique | Infrastructure de sauvegarde au niveau des zones avec réplication optionnelle vers un référentiel central via une passerelle contrôlée. L’infrastructure de sauvegarde ne doit pas affaiblir les frontières de confiance existantes. | Environnements nécessitant une restauration locale et une conservation centralisée | La passerelle devient une cible inter-zones de grande valeur, ce qui en fait une passerelle critique pour la sécurité avec un accès à plusieurs zones. |
| Réplication contrôlée | Sauvegarde locale à la zone ; données transférées via une passerelle, une diode de données ou une ouverture programmée du pare-feu. Une diode de données est un dispositif matériel de sécurité réseau permettant la transmission unidirectionnelle de données entre deux réseaux. | Environnements où les connexions persistantes de sauvegarde inter-zones sont interdites | La fenêtre de transfert constitue une surface d’attaque si elle n’est pas soumise à un contrôle strict. La surface d’attaque désigne les systèmes, les services et les chemins réseau qu’un attaquant pourrait potentiellement exploiter. |
| Entièrement séparé | Les composants ne sont partagés à aucun niveau. Comprend des serveurs, des systèmes de stockage, des catalogues, des chemins d’administration et des procédures de restauration distincts. | Exigences d’isolement absolu ; séparation entre les données classifiées et non classifiées | Coût opérationnel le plus élevé ; capacité de sauvegarde avec duplication complète |

## Quel côté doit initier la connexion de sauvegarde ?

Le sens de connexion privilégié dépend de la limite de confiance. Dans les zones de confiance identique, il peut être approprié d’utiliser des connexions Bacula standard initiées par le Director. Dans les zones restreintes, une connectivité entrante réduite peut entraîner une réduction de la surface d’attaque autorisée, et la configuration Bacula choisie doit être prise en charge et testée.

Dans un déploiement Bacula classique, le Director établit des connexions à la fois avec le File Daemon (sur le client) et le Storage Daemon (sur la cible de stockage). Le flux de données de sauvegarde circule entre le File Daemon et le Storage Daemon. Le Director ne se trouve pas sur le chemin des données.

Dans les environnements où les zones ont le même niveau de confiance et où le Director peut établir des connexions entrantes vers les clients, le modèle standard peut fonctionner sans nécessiter de modifications.

Lorsqu’une frontière de zone n’autorise pas les connexions entrantes provenant du réseau de sauvegarde, la connexion standard initiée par le Director vers le démon de fichiers peut ne pas disposer des autorisations nécessaires.

Bacula prend en charge la connectivité initiée par le démon de fichiers via sa configuration `ConnectToDirector`. Vérifiez la disponibilité et le comportement par rapport à la version de Bacula déployée dans votre environnement, afin de réduire les exigences d’accès entrant vers la zone restreinte. Cela nécessite une planification et des tests spécifiques, qui concernent également la planification et le comportement du contrôle des tâches.

## Comment le sens de la connexion de sauvegarde affecte-t-il le risque inter-zones ?

Le risque de pivot est le risque d’utiliser une connexion de sauvegarde autorisée pour atteindre une autre zone. De quel côté la connexion de sauvegarde doit-elle être initiée ?

Si le Director établit des connexions vers les clients de la zone C à l’aide d’une règle autorisée, un Director compromis dispose d’un chemin d’accès autorisé vers la zone C. Si ce sont les File Daemons de la zone C qui établissent des connexions sortantes, cette surface d’attaque entrante est réduite. Le pare-feu contrôle ce qui peut être maîtrisé, et l’architecture détermine ce qui est autorisé.

La connectivité bidirectionnelle au-delà d’une frontière de zone permet au nombre de chemins de connexion inter-zones autorisés d’augmenter dans les deux sens. Des exigences opérationnelles spécifiques doivent justifier les règles de pare-feu bidirectionnelles associées au trafic de sauvegarde traversant une frontière hautement sensible, sans les laisser par défaut.

## Comment empêcher l’infrastructure de sauvegarde de créer un chemin inter-zones ?

Un serveur de sauvegarde connecté à plusieurs zones peut acheminer le trafic entre celles-ci à l’aide de ses interfaces. Empêchez cela à l’aide de contrôles explicites au niveau de la couche réseau, d’interfaces distinctes par zone, d’un routage inter-interfaces désactivé et d’une empreinte de service minimale.

Un serveur de sauvegarde disposant de connexions autorisées vers plusieurs zones sert de pont entre celles-ci. Le serveur utilise le routage, et non une mauvaise configuration. Si le trafic des zones B et C arrive sur des interfaces différentes, le routage entre celles-ci doit être désactivé ou régi par une politique spécifique.

Chaque zone doit disposer d’une interface réseau distincte. Réduisez au minimum les services sur l’infrastructure de sauvegarde. Considérez chacun d’entre eux comme une surface d’attaque supplémentaire.

L’administration doit s’appuyer sur un chemin de gestion dédié sans traverser les réseaux des zones de production.

## Comment séparer le contrôle de la sauvegarde et le trafic de données ?

L’architecture de Bacula est conçue pour séparer structurellement les plans de contrôle et de données. Le plan de contrôle achemine le trafic lié à la gestion et à l’orchestration des tâches. Le plan de données achemine les données de sauvegarde et de restauration.

Le Director contrôle la planification et l’orchestration des tâches sans acheminer les données de sauvegarde. Le File Daemon envoie les données au Storage Daemon. Il n’y a pas de Director dans le chemin des données.

Cela a des implications spécifiques au niveau du pare-feu : les liaisons Director→Démon de fichiers ([Protocole de contrôle de transmission 9102](https://www.iana.org/assignments/service-names-port-numbers?&page=115)
) et Director→Démon de stockage ([Protocole de contrôle de transmission 9103](https://www.iana.org/assignments/service-names-port-numbers?&page=115)
) acheminent le contrôle des tâches. Le chemin Démon de fichiers→Démon de stockage achemine le flux de sauvegarde.

Il est possible de restreindre l’accès de la console d’administration au Director ([TCP 9101](https://www.iana.org/assignments/service-names-port-numbers?&page=115)
) à un réseau de gestion dédié sans affecter les flux de données de sauvegarde.

Le Director peut rester dans la zone de sauvegarde en utilisant des règles restreintes pour les zones de production (orchestration des tâches uniquement). Les règles du daemon de stockage régissent séparément le chemin de données à plus haut débit.

Lorsqu’une seule règle générale est utilisée pour les deux, l’intérêt architectural de la séparation est perdu. Le trafic de gestion, y compris l’accès à la console et les requêtes de catalogue, doit transiter par un chemin dédié. Il ne doit pas transiter par des interfaces partagées avec les données de sauvegarde.

**Tableau de référence des flux du pare-feu**

| Source | Destination | Port par défaut | Objectif | Direction |
| --- | --- | --- | --- | --- |
| Console | Directeur | TCP 9101 | Gestion | Console → Directeur |
| Directeur | Démon de fichiers | TCP 9102 | Contrôle des tâches | Directeur → FD |
| Directeur | Démon de stockage | TCP 9103 | Contrôle du stockage | Directeur → SD |
| Démon de fichiers | Démon de stockage | TCP 9103 | Données de sauvegarde | FD → SD |

## Comment isoler les identifiants de sauvegarde entre les zones de sécurité ?

Utilisez des identifiants de sauvegarde privilégiés distincts pour chaque zone de sécurité. Veillez à ce que la compromission des identifiants dans une zone ne donne pas automatiquement accès à une autre zone.

Les comptes de service de sauvegarde de la zone C doivent être différents de ceux des zones B et A. Lorsque les identifiants sont partagés, une seule compromission peut étendre l’accès authentifié à toutes les zones utilisant ces identifiants.

Les dépendances de restauration vis-à-vis d’une infrastructure d’identité centralisée, telle qu’Active Directory, le protocole LDAP (Lightweight Directory Access Protocol) et les fournisseurs d’identité (IdP) externes, constituent un point de défaillance architectural courant. Les IdP désignent un système central tel qu’Okta, Microsoft Entra ID ou Google Identity, qui gère les comptes utilisateurs, les authentifications et les autorisations d’accès.

Si la zone C est authentifiée auprès du fournisseur d’identité de la zone A, cette dernière peut aider la zone C à se rétablir. Les comptes de service locaux disposant d’identifiants gérés de manière indépendante éliminent cette dépendance.

Mettez en place un calendrier spécifique pour renouveler les identifiants des comptes de service de sauvegarde. Répondez à la question « La zone C peut-elle être restaurée avec un fournisseur d’identité central hors ligne ? » avant qu’un incident ne se produise.

## Comment les données de sauvegarde doivent-elles circuler entre les zones de sécurité ?

Choisissez le mécanisme de transfert en fonction du niveau de sensibilité de la zone. Une zone restreinte implique que le mécanisme de transfert doit minimiser sa surface d’exposition réseau persistante. Concrètement, cela fait référence au transfert direct via des passerelles et des ouvertures temporaires, ainsi qu’à des supports physiques hors ligne lorsque le chemin réseau inter-zones est interdit ou inacceptable.

Lorsque les données de sauvegarde doivent franchir une frontière de zone à des fins de conservation ou de reprise après sinistre, la méthode de transfert fait partie intégrante de l’architecture de sécurité.

**Le transfert direct** via une règle de pare-feu autorisée est l’option la plus simple. Cependant, cela crée un chemin persistant avec des règles spécifiant des adresses et des ports exacts. Ces règles doivent être consignées.

**Une passerelle contrôlée** peut limiter l’impact d’une compromission lorsque ses destinations, protocoles et fonctions autorisés sont strictement restreints.

**Le stockage et le retransfert avec des ouvertures de pare-feu limitées dans le temps** préservent la capacité de reprise locale, que la fenêtre de transfert soit ouverte ou non.

**Le transfert hors ligne sur support physique** évite toute connexion réseau entre les zones source et de destination pendant le transfert. Les zones hautement isolées peuvent n’accepter que cette option. Les zones isolées doivent disposer d’un chemin de reprise défini lorsque les services partagés sont hors ligne.

Les données de sauvegarde doivent être chiffrées avant de franchir une frontière de zone. Personne ne doit pouvoir accéder aux clés de déchiffrement en dehors de la zone source.

## Pourquoi la reprise inter-zones peut-elle s’avérer plus difficile que la sauvegarde ?

Même si la conception permet d’enregistrer correctement les données de sauvegarde d’une zone à l’autre, la reprise après sinistre peut échouer. La reprise repose sur un environnement cible fonctionnel, des services d’identité, une connectivité réseau et un catalogue opérationnel. Ces dépendances peuvent empêcher la reprise même lorsque les données de sauvegarde elles-mêmes sont intactes. La reprise doit être testée en l’absence de ces dépendances inter-zones.

L’intégrité des zones est également liée à la reprise. Plus précisément, si les données de la zone C sont restaurées dans la zone A, la manière dont les données ont quitté leur zone peut ne pas répondre aux exigences de la frontière. L’intégrité de zone et l’intégrité des données ne constituent pas les mêmes contraintes.

Répondez à ces questions avant qu’un incident ne survienne :

- En l’absence de connectivité inter-zones, chaque zone peut-elle se restaurer de manière indépendante ?
- Si le catalogue de sauvegarde n’est pas disponible, la restauration peut-elle s’effectuer à partir de supports hors ligne ?
- La sauvegarde locale des identifiants est-elle définie et testée en vue d’une restauration si les services d’identité centraux sont indisponibles ?
- Le stockage local est-il suffisamment à jour pour permettre une restauration efficace avec un pare-feu inter-zones fermé ?
- Les sites peuvent-ils fonctionner et se rétablir de manière indépendante sans réseau étendu ?

## Quelle est la différence entre la disponibilité de la sauvegarde et la capacité de reprise ?

L’écriture réussie sur le stockage est considérée comme de la disponibilité. Lorsque les données sont correctement restaurées dans la bonne zone, grâce à une authentification fonctionnelle, dans les délais requis, alors que le pare-feu inter-zones est fermé et que l’identité centrale est hors ligne, il s’agit de capacité de reprise. Il est essentiel de se concentrer sur la conception et le test de la capacité de reprise, et pas seulement sur la disponibilité.

Un système qui écrit sur le stockage est considéré comme disponible. Un système est considéré comme récupérable lorsqu’il utilise une authentification fonctionnelle pour restaurer les données correctes dans la zone appropriée, vers une cible opérationnelle, dans le délai requis, alors que le pare-feu inter-zones est fermé et que l’identité centrale est hors ligne. Il s’agit de propriétés différentes. La seconde doit faire l’objet de tests.

## À quoi ressemble une architecture de sauvegarde à trois zones ?

Ce scénario concerne une conception multizone cohérente où la capacité de récupération des zones correspond à leur niveau d’isolation. Plus précisément, la zone A dépend de la zone de sauvegarde, et la zone B se restaure localement ou à partir de la zone de sauvegarde. La zone C se restaure à partir de composants locaux sans dépendre de systèmes externes.

L’architecture de référence suivante illustre une conception multizone cohérente. La zone C est isolée ; elle ne dispose donc d’aucun chemin réseau entrant ou sortant vers des zones externes. Les fonctions de contrôle et de plan de données sont locales à la zone C. Les données sont transférées via des bandes physiques.

[https://www.baculasystems.com/wp-content/uploads/2026/10/Three-Zone-Backup-Architecture.png](https://www.baculasystems.com/wp-content/uploads/2026/10/Three-Zone-Backup-Architecture.png)

Le terme « air-gapped » désigne un support de sauvegarde physiquement déconnecté, sans connexion réseau active. Il ne s’agit pas d’un stockage isolé logiquement du réseau.

Une réplique de catalogue représente une copie synchronisée d’une partie ou de l’ensemble des enregistrements du catalogue principal, conservée sur une instance de base de données distincte.

**Zone A : Informatique d’entreprise**

Les démons de fichiers transfèrent les données sortantes vers le démon de stockage central. Le directeur utilise un chemin de pare-feu autorisé pour planifier les tâches. Il n’y a pas de stockage de sauvegarde local. Lorsqu’une connexion est disponible, la zone A peut effectuer une restauration à partir de la zone de sauvegarde.

**Zone B : Ingénierie restreinte**

La zone B protège les clusters de calcul haute performance, les charges de travail de simulation, les données de conception assistée par ordinateur et les ensembles de données de recherche. Elle héberge un Director Bacula local, des démons de fichiers, un démon de stockage et un catalogue, permettant ainsi la sauvegarde et la restauration sans connexion à la zone centrale de sauvegarde/restauration.

Les données de sauvegarde sont transférées localement depuis les démons de fichiers vers le démon de stockage de la zone, tandis que le Director local gère les tâches de sauvegarde et de restauration. Les copies de sauvegarde peuvent être répliquées vers la zone centrale de sauvegarde/restauration via une passerelle contrôlée pendant les fenêtres de transfert autorisées. Si la connectivité inter-zones n’est pas disponible, la zone B peut poursuivre ses opérations locales de sauvegarde et de restauration.

**Zone C : hautement isolée**

Aucun chemin réseau vers les zones externes. La zone C héberge son propre Director, ses démons de fichiers, son démon de stockage, son catalogue et sa bibliothèque de bandes. Un processus audité transfère physiquement les bandes vers la zone de sauvegarde pour l’importation dans le catalogue central. La zone C effectue la restauration à partir de son démon de stockage local, sans services d’identité externes ni connectivité réseau.

**Zone de sauvegarde/restauration**

Le Director central, le démon de stockage, le catalogue et la console de gestion se trouvent ici. Elle accepte les connexions de sauvegarde provenant des zones A et B. Aucun routage entre les zones de production. Conservation résistante aux ransomwares grâce à un stockage d’objets immuables. La conservation résistante aux ransomwares désigne le stockage de sauvegarde conçu pour résister à toute suppression ou modification non autorisée.

La bibliothèque de bandes permet la conservation à long terme et l’importation vers la zone C. L’administration s’appuie sur une interface de gestion dédiée inaccessible aux réseaux des zones de production.

## Comment choisir une architecture de sauvegarde multizone ?

Ce tableau permet de comparer les options selon les principaux critères de conception. Chaque ligne représente une décision indépendante. Les choix ne doivent pas nécessairement être uniformes sur tous les critères.

**Comment concevoir une sauvegarde multizone en 7 étapes**

| Question de conception | Option A | Option B | Option C |
| --- | --- | --- | --- |
| Infrastructure de sauvegarde | Centralisée : un seul serveur, toutes les zones | Spécifique à chaque zone : dédié par zone | Hybride : Director central, stockage au niveau des zones |
| Sens de la connexion | Lancée par le serveur : la sauvegarde est récupérée depuis les clients | Lancée par le client : les clients envoient les données vers le stockage | Mixte : varie en fonction de la sensibilité de la zone |
| Stockage de sauvegarde | Central : toutes les zones écrivent sur un stockage partagé | Par zone : chaque zone conserve ses propres données | À plusieurs niveaux : copie locale plus réplication centrale |
| Transfert inter-zones | Direct : règle de pare-feu permanente | Passerelle : transfert limité dans le temps | Hors ligne : support physique, pas de chemin réseau |
| Administration | Partagée : une seule console permet d’accéder à toutes les zones | Segmentée : chemins d’accès distincts par zone | Entièrement isolée : aucune infrastructure d’administration partagée |
| Copie de restauration finale | Disque immuable : en ligne, protégé en écriture | Stockage d’objets avec verrouillage d’objet. Le verrouillage d’objet concerne le contrôle de la conservation qui empêche les données de sauvegarde d’être modifiées ou supprimées pendant une période de protection définie, quel que soit le fournisseur. | Bande / hors ligne : isolation physique par « air gap » |
| Identité pour la restauration | Centralisée : dépend d’Active Directory et d’un fournisseur d’identité externe | Comptes locaux : identifiants préconfigurés | Mixte : principale centralisée, de secours locale |

## À quelles défaillances une architecture de sauvegarde multizone doit-elle résister ?

Examinez les scénarios de défaillance par rapport à l’architecture conçue avant de déployer le logiciel. Les scénarios dont les réponses sont floues ou négatives représentent une lacune de conception que vous devez résoudre avant qu’un incident ne se produise.

| Scénario de défaillance | Question de conception |
| --- | --- |
| Réseau d’entreprise compromis | Les zones B et C peuvent-elles continuer à effectuer des sauvegardes et à se restaurer de manière indépendante ? La compromission de la zone A offre-t-elle un accès à la zone de sauvegarde ? |
| Serveur de sauvegarde compromis | Un attaquant peut-il établir des connexions vers les zones de production ? Les copies de sauvegarde sont-elles immuables afin qu’elles ne puissent pas être supprimées ? |
| Une zone devient inaccessible | Les zones restantes peuvent-elles continuer à effectuer des sauvegardes et à se restaurer ? L’indisponibilité d’une zone affecte-t-elle les catalogues des autres zones ? |
| Infrastructure d’identité hors ligne | Les opérations de sauvegarde et de restauration peuvent-elles s’authentifier sans le fournisseur d’identité central ? |
| Pare-feu inter-zones fermé | Chaque zone peut-elle se restaurer de manière indépendante à partir du stockage local ? Le catalogue local est-il suffisamment à jour ? |
| Stockage principal détruit | Existe-t-il une deuxième copie sur un support différent, situé dans un autre lieu ? Quel est le délai de restauration à partir de la copie secondaire ? |
| Catalogue de sauvegarde indisponible | La restauration peut-elle s’effectuer à partir de supports hors ligne sans l’aide du catalogue ? La procédure est-elle documentée et testée ? |

## Que faut-il vérifier avant de déployer une solution de sauvegarde multizone ?

Cette liste de contrôle est indispensable pour la revue de conception. Les éléments non cochés constituent des lacunes que vous devez combler avant que l’architecture ne soit considérée comme achevée.

- Tout d’abord, les limites de confiance et les classifications des zones sont documentées, puis la conception de l’architecture de sauvegarde commence.
- Un composant compromis dans la zone B ne peut pas accéder à la zone C via les canaux de sauvegarde autorisés ou les règles de pare-feu.
- Les comptes de service de sauvegarde sont isolés pour chaque zone. Aucun identifiant privilégié partagé ne franchit les limites entre les zones.
- Les règles de pare-feu liées à la sauvegarde spécifient précisément la source, la destination, les ports et le sens du trafic.
- Les zones peuvent effectuer la sauvegarde et la restauration localement en l’absence de connectivité inter-zones.
- Au moins une copie de restauration est stockée hors du réseau de production : stockage en ligne immuable ou support hors ligne.
- Il n’est pas nécessaire de disposer de l’infrastructure ou des services d’identité d’une autre zone pour restaurer chaque zone.
- Les procédures de restauration sont testées, y compris dans des scénarios où le catalogue n’est pas disponible.
- Les solutions de secours locales en matière d’identifiants sont testées pour permettre la restauration sans le fournisseur d’identité central. Les identifiants locaux sont des identifiants préconfigurés utilisables en l’absence de services d’identité centralisés.
- Le trafic de sauvegarde traversant les frontières entre zones est consigné au niveau du pare-feu. Les anomalies font l’objet d’une surveillance.

## Comment Bacula prend-il en charge la sauvegarde entre plusieurs zones de sécurité ?

La séparation entre le Director, le Storage Daemon et le File Daemon de Bacula est plus qu’une simple commodité opérationnelle. Il s’agit d’une propriété architecturale permettant de placer différents composants dans des zones distinctes, régies par des règles de pare-feu différentes. De cette manière, ils peuvent prendre en charge les modèles de conception multizones décrits tout au long de cette note.

[L’architecture de sauvegarde de Bacula Enterprise](https://www.baculasystems.com/fr/architecture-de-sauvegarde-de-donnes-dentreprises-de-bacula-enterprise/)
 propose un modèle de composants distribués qui s’adapte naturellement à plusieurs zones. Les utilisateurs peuvent déployer indépendamment le Director, le Storage Daemon et le File Daemon. Les différents composants peuvent se trouver dans des zones distinctes, régies par des règles de pare-feu différentes. Cette séparation des composants permet des modèles de déploiement qui alignent les services Bacula individuels sur différentes zones de sécurité.

[La documentation de configuration du File Daemon de Bacula](https://www.bacula.org/13.0.x-manuals/en/main/Client_File_daemon_Configur.html)
 décrit la communication entre le Director et le Storage Daemon pour sauvegarder les fichiers sur les clients.

Un seul Director situé dans la zone de sauvegarde peut gérer des File Daemons répartis sur plusieurs zones. Les Storage Daemons locaux font office de point d’extrémité du chemin de données au sein des zones. Les données circulent directement entre le File Daemon et le Storage Daemon sans transiter par le Director. C’est pourquoi les exigences en matière de pare-feu pour le Director restent moins strictes. L’emplacement des Storage Daemons peut être déterminé en fonction de la sensibilité de la zone sans dépendre de l’emplacement du Director.

Pour les zones ne disposant pas d’un chemin réseau acceptable vers la zone de sauvegarde, Bacula prend en charge les [bandes](https://www.baculasystems.com/tape-backup-software/)
 et les supports hors ligne en tant que cibles locales à la zone. Concrètement, un démon de stockage écrit localement, et la bande est physiquement transférée vers la zone de sauvegarde pour y être importée, sans qu’un chemin réseau entre les zones soit nécessaire.

Les options de stockage immuable de Bacula, notamment le verrouillage d’objets et les bandes WORM (Write Once, Read Many), permettent de protéger les copies de sauvegarde correctement configurées contre toute suppression ou modification non autorisée.

[La sauvegarde immuable et la restauration après une attaque par ransomware](https://www.baculasystems.com/fr/blog-fr/sauvegarde-immuable/)
 sont essentielles lorsqu’il s’agit d’une zone de production compromise à partir de laquelle un attaquant pourrait tenter de supprimer ou de modifier des copies de restauration accessibles.

Pour les environnements HPC dans des zones restreintes, Bacula prend en charge Lustre, le système de fichiers parallèle général d’IBM (GPFS) et les systèmes de fichiers parallèles à grande échelle. Aucune modification n’est requise pour l’isolation des zones.

Les composants s’exécutent sur site sans dépendre d’une infrastructure de gestion cloud externe. Vérifiez les licences et les dépendances vis-à-vis des services externes par rapport à votre environnement avant d’utiliser le logiciel.

Le comportement du produit Bacula et les options de déploiement prises en charge doivent être vérifiés par rapport à la version déployée. Les références techniques contenues dans cette note d’architecture ont été révisées en octobre 2026.

## Principe clé de l’architecture

La sauvegarde multizone doit préserver la sécurité des limites de l’environnement de production. L’infrastructure de sauvegarde ne doit pas permettre d’accès inter-zones interdits par l’architecture de production. Concevez les flux autorisés, les identifiants et les chemins de restauration indépendants, puis décidez seulement à ce moment-là où les composants Bacula seront déployés.

## Foire aux questions

### Un seul serveur de sauvegarde peut-il protéger en toute sécurité plusieurs zones de sécurité ?

En principe, oui. Un serveur de sauvegarde centralisé peut être approprié lorsque les zones partagent des exigences de confiance compatibles et que ses connexions autorisées, ses identifiants et ses contrôles de routage ne créent pas de risque inter-zones inacceptable.

### Les clients de sauvegarde doivent-ils initier les connexions ?

Dans les zones restreintes, oui. Les connexions sortantes initiées par les clients réduisent la surface d’attaque entrante via les canaux de sauvegarde vers cette zone.

### Le stockage immuable remplace-t-il la sauvegarde hors ligne ?

Non. L’immuabilité protège les données de sauvegarde contre toute modification ou suppression dans le cadre de contrôles de conservation définis, mais elle ne fournit pas, à elle seule, d’isolation réseau. La sauvegarde hors ligne supprime la connexion réseau active tant que le stockage reste hors ligne. Il s’agit de protections distinctes qui répondent à des risques différents et peuvent être utilisées conjointement.

### Une zone isolée peut-elle utiliser une identité centralisée ?

Oui, si cette dépendance est acceptable pendant la restauration. Si la restauration dépend de ce fournisseur d’identité et qu’il n’existe aucune solution de secours d’authentification locale, la perte du fournisseur peut empêcher la restauration.

### Bacula peut-il sauvegarder une zone sans connexion réseau permanente ?

Oui. Un démon de stockage local écrit sur bande à l’intérieur de la zone. La bande est physiquement transférée et importée dans le catalogue central.

À propos de l’auteur

[https://www.linkedin.com/in/rob-morrison-3aa443/](https://www.linkedin.com/in/rob-morrison-3aa443/)

Rob Morrison est le directeur marketing de Bacula Systems. Il a commencé sa carrière dans le marketing informatique chez Silicon Graphics en Suisse, où il a obtenu de bons résultats dans divers rôles de gestion du marketing pendant près de 10 ans. Au cours des 10 années suivantes, Rob a également occupé divers postes de gestion du marketing chez JBoss, Red Hat et Pentaho, assurant la croissance des parts de marché de ces sociétés bien connues. Il est diplômé de l'université de Plymouth, titulaire d'un diplôme spécialisé en médias et communications numériques, et a suivi un programme d'études à l'étranger.

*Postes connexes*

[https://www.baculasystems.com/fr/blog-fr/mongodb-sauvegarde-restauration/](https://www.baculasystems.com/fr/blog-fr/mongodb-sauvegarde-restauration/)
[Guide complet pour la sauvegarde et la restauration des bases de données MongoDB](https://www.baculasystems.com/fr/blog-fr/mongodb-sauvegarde-restauration/)

16 mars 2026

[https://www.baculasystems.com/fr/blog-fr/la-securite-du-cloud-dans-le-secteur-de-la-sante/](https://www.baculasystems.com/fr/blog-fr/la-securite-du-cloud-dans-le-secteur-de-la-sante/)
[Pourquoi la sécurité du cloud dans le secteur de la santé ne peut-elle pas être traitée comme la sécurité standard du cloud d'entreprise ?](https://www.baculasystems.com/fr/blog-fr/la-securite-du-cloud-dans-le-secteur-de-la-sante/)

29 juin 2026

[https://www.baculasystems.com/fr/blog-fr/sauvegarde-et-restauration-des-ordinateurs-centraux/](https://www.baculasystems.com/fr/blog-fr/sauvegarde-et-restauration-des-ordinateurs-centraux/)
[Sauvegarde et reprise sur mainframe : stratégies modernes pour des systèmes d'entreprise résilients](https://www.baculasystems.com/fr/blog-fr/sauvegarde-et-restauration-des-ordinateurs-centraux/)

30 mars 2026

[https://www.baculasystems.com/fr/blog-fr/sauvegarde-ransomware-proteger-ransomware/](https://www.baculasystems.com/fr/blog-fr/sauvegarde-ransomware-proteger-ransomware/)
[Stratégies et bonnes pratiques de sauvegarde contre les ransomwares. Comment protéger les sauvegardes contre les ransomwares ?](https://www.baculasystems.com/fr/blog-fr/sauvegarde-ransomware-proteger-ransomware/)

13 octobre 2025

[https://www.baculasystems.com/fr/blog-fr/sauvegarde-du-centre-de-donnees/](https://www.baculasystems.com/fr/blog-fr/sauvegarde-du-centre-de-donnees/)
[Les 20 meilleures solutions de sauvegarde pour les centres de données](https://www.baculasystems.com/fr/blog-fr/sauvegarde-du-centre-de-donnees/)

2 avril 2024

[https://www.baculasystems.com/fr/blog-fr/sauvegarde-immuable/](https://www.baculasystems.com/fr/blog-fr/sauvegarde-immuable/)
[Qu'est-ce qu'une sauvegarde immuable ? Les sauvegardes immuables comme mesure de sécurité des données](https://www.baculasystems.com/fr/blog-fr/sauvegarde-immuable/)

6 février 2024