So sichern Sie mehrere Sicherheitszonen, ohne die Netzwerksegmentierung zu beeinträchtigen

Bei der Datensicherung über mehrere Sicherheitszonen hinweg sollten die vom Produktionsnetzwerk durchgesetzten Vertrauensgrenzen gewahrt bleiben. Verwenden Sie zonenspezifische Anmeldedaten, eng begrenzte Netzwerkflüsse, getrennten Steuerungs- und Datenverkehr sowie unabhängige Wiederherstellungspfade. Wo eine dauerhafte zonübergreifende Konnektivität untersagt ist, sollten Sie kontrollierte Replikation, Einwegübertragung oder Offline-Medien nutzen, anstatt die Netzwerksegmentierung zu schwächen.

Dieser Hinweis richtet sich an Infrastruktur- und Sicherheitsarchitekten sowie leitende Administratoren, die sich mit der Backup-Architektur in Unternehmen in bewusst segmentierten Umgebungen befassen, wie beispielsweise in den Bereichen Verteidigung, Luft- und Raumfahrt, Forschung, Betriebstechnik, kritische Infrastruktur sowie in Unternehmen, die Netzwerke über verschiedene Klassifizierungsstufen oder Vertrauensdomänen hinweg betreiben. Dabei kann es sich um klassifizierte und nicht klassifizierte Netzwerkdomänen handeln, um Unternehmens-IT im Gegensatz zur Betriebstechnik in der Fertigung sowie um ähnliche Konfigurationen.

Der Schwerpunkt liegt auf Backup-Know-how und der Lösung eines bestimmten Designproblems. Konkret geht es in diesem Hinweis um den Schutz von Zonen, ohne neue Verbindungen zwischen ihnen zu schaffen.

Wichtige Erkenntnisse

• Ein zonenübergreifendes Backup sollte bestehende Sicherheitszonengrenzen erhalten.
• Verwenden Sie zonenspezifische privilegierte Anmeldedaten und eng gefasste Firewall-Regeln.
• Trennen Sie den Backup-Steuerungsverkehr vom Backup-Datenverkehr.
• Behalten Sie lokale Wiederherstellungsfähigkeiten bei, wenn Zonen unabhängig voneinander betrieben werden müssen.
• Testen Sie die Wiederherstellung unter der Annahme, dass zonübergreifende Konnektivität, zentralisierte Identitätsverwaltung und gemeinsame Kataloge nicht verfügbar sind.

Warum ist die Datensicherung über mehrere Sicherheitszonen hinweg schwierig?

Zentralisierte Backup-Architekturen können in segmentierten Umgebungen strukturelle Sicherheitsrisiken verursachen. Sie sind oft auf dauerhafte Konnektivität und erweiterte Berechtigungen über Zonengrenzen hinweg angewiesen, was das Backup-System zu einem potenziellen Pfad für laterale Bewegungen machen kann.

Zentralisierte Backup-Architekturen, wie beispielsweise Enterprise-Backup-Suiten mit einer einzigen Konsole und zentralisierte Pull-Architekturen mit Appliances, gehen davon aus, dass der Backup-Server jeden Client erreicht, die Clients Daten an einen gemeinsamen Speicher zurücksenden und alle auf die Verwaltungsebene zugreifen können.

Diese Annahme funktioniert in einem flachen Netzwerk. In bewusst segmentierten Umgebungen, wie beispielsweise taktischen Militärnetzwerken und Enklaven der Verteidigungsforschung sowie industriellen Umgebungen mit Betriebstechnik und Leittechnik (SCADA), funktioniert sie jedoch nicht.

Backups über Sicherheitszonen hinweg sollten Umgebungen mit erzwungener Netzwerksegmentierung erhalten. Wenn durch das Backup die IT-Zone des Unternehmens mit einer eingeschränkten technischen Umgebung verbunden wird, wirkt sich die Segmentierung nachteilig auf das Backup-System aus.

Der Backup-Datenverkehr verkompliziert die Situation. Konkret bezieht sich dies auf große, regelmäßige, authentifizierte Verbindungen, die nach einem vorhersehbaren Zeitplan Zonengrenzen überschreiten. Außerdem bezieht sich dies auf Anmeldedaten von Dienstkonten mit hohen Berechtigungen an beiden Enden sowie auf gespeicherte Kopien aller berührten Daten.

Wird eine Backup-Komponente kompromittiert, ermöglicht dies den Zugriff auf Daten aus Zonen, die über das Produktionsnetzwerk nicht erreichbar wären.

Seit Oktober 2026 empfiehlt NIST SP 1339 (Juni 2026), regelmäßig OT-Backups zu erstellen, diese zu testen und im Rahmen von Wiederherstellungsübungen zu überprüfen.

Warum kann die Backup-Infrastruktur zonenübergreifende Risiken verursachen?

Ein Backup-Server mit autorisierten Verbindungen zu mehreren Zonen kann über zulässige Pfade zwischen diesen Zonen kommunizieren. Wird der Server kompromittiert, gelangen bestehende autorisierte Kanäle in jede bediente Zone. Dies wird durch die Positionierung verursacht, nicht durch eine Fehlkonfiguration.

Warum sollten Sie Vertrauensgrenzen definieren, bevor Sie sich für eine Backup-Software entscheiden?

Legen Sie Vertrauensgrenzen, zulässige Verbindungsrichtungen und verbotene Kommunikationspfade fest, bevor Sie Backup-Produkte auswählen oder konfigurieren. Entwerfen Sie zunächst die Architektur; dann fügt sich das Produkt in diese ein.

Die NIST Zero-Trust-Architektur beschreibt die Beseitigung impliziter Vertrauensbeziehungen, die lediglich auf dem Standort im Netzwerk basieren. NIST OT Backup Quick Start Guide (SP 1339) ist der vom National Institute of Standards and Technology (NIST) und dem National Cybersecurity Center of Excellence (NCCoE) veröffentlichte Schnellstartleitfaden für Backups in der Betriebstechnik (OT). Dieser Leitfaden legt fest, dass Organisationen klare Verfahren für Backups und die Wiederherstellung nach Ransomware-Angriffen festlegen sollten.

NIST Zero Trust Architecture (SP 800-207) ist eine offizielle Veröffentlichung des National Institute of Standards and Technology, die die Zero-Trust-Architektur (ZTA) definiert und Richtlinien erstellt, damit sich die Cybersicherheit von traditionellen, perimeterbasierten Netzwerkabwehrmaßnahmen wegbewegen kann.

Es wird kein implizites Vertrauen gewährt, das ausschließlich auf dem physischen Standort oder der Netzwerkposition basiert. Hier finden Sie eine maßgebliche Regierungsquelle zum Thema geschützte/offline/unveränderliche Wiederherstellungskopien.

Ein häufiger Fehler besteht darin, zunächst Vertrauensbeziehungen aufzubauen und erst danach eine Backup-Plattform auszuwählen.

Produktfunktionen wie globale Inline-Deduplizierung und -Komprimierung, Multi-Cloud-Snapshots und die Orchestrierung von Speicher-Arrays sind weniger wichtig als das Verständnis, welche Kommunikation zwischen Zonen zulässig ist. Backup-Produkte können eine korrekt durchgesetzte Firewall-Regel nicht außer Kraft setzen.

1. Identifizieren Sie vor jeder Backup-Konfiguration die Sicherheitszonen und deren Klassifizierungsstufe.
2. Definieren Sie als Nächstes, welche Systeme sich mit anderen verbinden dürfen.
3. Trennen Sie anschließend während der Analysen den Datenverkehr der Steuerungsebene vom Datenverkehr der Datenebene.
4. Identifizieren Sie darüber hinaus die Orte, an denen Anmeldedaten vorhanden sein dürfen.
5. Erstellen Sie schließlich eine Übersicht über verbotene Pfade, auf denen das Backup-Design ausgeführt werden kann.

Der Speicherort von Anmeldedaten ist eine Entscheidung bezüglich der Vertrauensgrenze. Ein Backup-Dienstkonto mit Lesezugriff auf Systeme der Zone C sollte nicht auf einem System vorhanden sein, das mit Zone A verbunden ist.

Der Geltungsbereich und der Speicherort von Anmeldedaten stellen Entscheidungen bezüglich der Vertrauensgrenze dar.

Referenzleitfaden, überprüft im Oktober 2026: NIST SP 800-207, veröffentlicht im August 2020.

Welche Backup-Architekturmodelle funktionieren über mehrere Sicherheitszonen hinweg?

Modelle sind nicht universell gültig. Das richtige Muster hängt von den Klassifizierungsstufen, den zulässigen Kommunikationspfaden, den Wiederherstellungsanforderungen und den Betriebskosten ab, die für die Isolierung jeder Zone erforderlich sind. Ein zonenübergreifendes Backup sollte keine neuen zonenübergreifenden Zugriffspfade schaffen.

Fünf etablierte Muster ermöglichen Backups über Zonengrenzen hinweg, beispielsweise zwischen dem IT-Netzwerk eines Unternehmens und der industriellen Betriebstechnik in der Fertigung sowie zwischen allgemeinen Produktions-Cloud-Enklaven und Zahlungsabwicklungsumgebungen nach dem Payment Card Industry Data Security Standard (PCI-DSS).

Jedes dieser Muster stellt einen Kompromiss zwischen betrieblicher Einfachheit und sicherheitstechnischer Isolierung dar.

Welche Seite sollte die Backup-Verbindung initiieren?

Die bevorzugte Verbindungsrichtung hängt von der Vertrauensgrenze ab. In Zonen mit gleichem Vertrauensstatus kann es sinnvoll sein, standardmäßige, vom Director initiierte Bacula-Verbindungen zu verwenden. In eingeschränkten Zonen kann eine reduzierte eingehende Konnektivität zu einer verringerten autorisierten Angriffsfläche führen, und die gewählte Bacula-Konfiguration sollte unterstützt und getestet sein.

Bei einer herkömmlichen Bacula-Bereitstellung baut der Director Verbindungen sowohl zum File-Daemon (auf dem Client) als auch zum Storage-Daemon (auf dem Speicherziel) auf. Der Backup-Datenstrom fließt zwischen dem File-Daemon und dem Storage-Daemon. Der Director befindet sich nicht im Datenpfad.

In Umgebungen, in denen Zonen dieselbe Vertrauensstufe aufweisen und der Director eingehende Verbindungen zu Clients herstellen kann, kann das Standardmodell ohne Änderungen betrieben werden.

Wenn eine Zonengrenze eingehende Verbindungen aus dem Backup-Netzwerk nicht zulässt, verfügt die standardmäßige, vom Director initiierte Verbindung zum File Daemon möglicherweise nicht über die erforderliche Berechtigung.

Bacula unterstützt vom File Daemon initiierte Verbindungen über die Konfiguration „ConnectToDirector“. Überprüfen Sie die Verfügbarkeit und das Verhalten anhand der in Ihrer Umgebung eingesetzten Bacula-Version, um die Anforderungen für den eingehenden Zugriff auf die eingeschränkte Zone zu reduzieren. Dies erfordert eine spezifische Planung und Tests, die sich auch auf die Zeitplanung und das Verhalten der Jobsteuerung beziehen.

Wie wirkt sich die Richtung der Backup-Verbindung auf das zonübergreifende Risiko aus?

Das Pivot-Risiko ist das Risiko, eine autorisierte Backup-Verbindung zu nutzen, um eine andere Zone zu erreichen. Welche Seite sollte die Backup-Verbindung initiieren?

Wenn der Director Verbindungen zu Clients in Zone C unter Verwendung einer autorisierten Regel aufbaut, verfügt ein kompromittierter Director über einen bereits bestehenden, zulässigen Pfad in Zone C. Wenn File Daemons in Zone C ausgehende Verbindungen aufbauen, wird diese eingehende Angriffsfläche reduziert. Die Firewall regelt, was unter Kontrolle gehalten werden kann, und die Architektur legt fest, was autorisiert ist.

Eine bidirektionale Konnektivität über eine Zonengrenze hinweg ermöglicht es, dass die Anzahl der zulässigen zonenübergreifenden Verbindungspfade in beide Richtungen zunimmt. Spezifische betriebliche Anforderungen sollten bidirektionale Firewall-Regeln für den Backup-Datenverkehr über eine hochsensible Grenze hinweg rechtfertigen, anstatt diese auf den Standardwerten zu belassen.

Wie verhindert man, dass die Backup-Infrastruktur einen zonenübergreifenden Pfad erstellt?

Ein mit mehreren Zonen verbundener Backup-Server kann den Datenverkehr zwischen diesen über seine Schnittstellen weiterleiten. Verhindern Sie dies durch explizite Kontrollen auf Netzwerkebene, separate Schnittstellen pro Zone, deaktiviertes Routing zwischen den Schnittstellen und einen minimalen Service-Footprint.

Ein Backup-Server mit autorisierten Verbindungen zu mehreren Zonen dient als Brücke zwischen diesen. Der Server nutzt dabei Routing und keine Fehlkonfiguration. Wenn Datenverkehr aus Zone B und Zone C auf unterschiedlichen Schnittstellen eintrifft, sollte das Routing zwischen ihnen deaktiviert oder durch eine spezifische Richtlinie geregelt werden.

Jede Zone sollte über eine separate Netzwerkschnittstelle verfügen. Minimieren Sie die Dienste auf der Backup-Infrastruktur. Behandeln Sie jeden einzelnen als zusätzliche Angriffsfläche.

Die Administration sollte auf einem dedizierten Verwaltungspfad basieren, ohne die Netzwerke der Produktionszonen zu durchqueren.

Wie sollten Backup-Steuerung und Datenverkehr getrennt werden?

Die Architektur von Bacula ist strukturell so ausgelegt, dass die Steuerungs- und die Datenebene voneinander getrennt sind. Die Steuerungsebene überträgt den Datenverkehr für die Jobverwaltung und -koordination. Die Datenebene überträgt Backup- und Wiederherstellungsdaten.

Der Director kontrolliert die Planung und Jobkoordination, ohne Backup-Daten zu übertragen. Der File-Daemon sendet Daten an den Storage-Daemon. Im Datenpfad befindet sich kein Director.

Dies hat konkrete Auswirkungen auf die Firewall: Die Verbindungen Director→File-Daemon (Transmission Control Protocol 9102) und Director→Storage-Daemon (Transmission Control Protocol 9103) dienen der Jobsteuerung. Der Pfad File-Daemon→Storage-Daemon überträgt den Backup-Datenstrom.

Es ist möglich, den Zugriff der Verwaltungskonsole auf den Director (TCP 9101) auf ein dediziertes Verwaltungsnetzwerk zu beschränken, ohne den Datenfluss der Backups zu beeinträchtigen.

Der Director kann mithilfe eng gefasster Regeln für Produktionszonen (nur Auftragsorchestrierung) in der Backup-Zone verbleiben. Die Regeln für den Storage-Daemon regeln den Datenpfad mit höherem Datenaufkommen separat.

Wird eine einzige weit gefasste Regel für beide verwendet, geht der architektonische Nutzen der Trennung verloren. Verwaltungsdatenverkehr, einschließlich Konsolenzugriff und Katalogabfragen, sollte über einen dedizierten Pfad geleitet werden. Er sollte nicht über Schnittstellen laufen, die gemeinsam mit Backup-Daten genutzt werden.

Referenztabelle für Firewall-Datenflüsse

Wie sollten Backup-Anmeldedaten über Sicherheitszonen hinweg isoliert werden?

Verwenden Sie für jede Sicherheitszone separate privilegierte Backup-Anmeldedaten. Stellen Sie sicher, dass eine Kompromittierung der Anmeldedaten in einer Zone nicht automatisch authentifizierten Zugriff auf eine andere Zone ermöglicht.

Backup-Dienstkonten in Zone C sollten sich von denen in Zone B und Zone A unterscheiden. Wenn Anmeldedaten gemeinsam genutzt werden, kann eine einzige Kompromittierung den authentifizierten Zugriff auf jede Zone ausweiten, in der diese Anmeldedaten verwendet werden.

Wiederherstellungsabhängigkeiten von einer zentralisierten Identitätsinfrastruktur wie Active Directory, dem Lightweight Directory Access Protocol (LDAP) und externen Identitätsanbietern (IdPs) stellen einen häufigen architektonischen Schwachpunkt dar. IdPs sind zentrale Systeme wie Okta, Microsoft Entra ID oder Google Identity, die Benutzerkonten, Authentifizierungen und Zugriffsberechtigungen verwalten.

Wenn Zone C über den Identitätsanbieter von Zone A authentifiziert wird, kann Zone A Zone C bei der Wiederherstellung unterstützen. Lokale Dienstkonten mit unabhängig verwalteten Anmeldedaten beseitigen diese Abhängigkeit.

Verwenden Sie einen festgelegten Zeitplan, um die Anmeldedaten der Backup-Dienstkonten zu rotieren. Beantworten Sie die Frage „Kann Zone C mit einem offline geschalteten zentralen Identitätsanbieter wiederhergestellt werden?“ bereits vor dem Auftreten eines Vorfalls.

Wie sollten Backup-Daten zwischen Sicherheitszonen übertragen werden?

Wählen Sie den Übertragungsmechanismus entsprechend dem Sensibilitätsgrad der Zone aus. Eine eingeschränkte Zone bedeutet, dass der Übertragungsmechanismus seine permanente Netzwerkanfläche minimieren muss. Konkret bezieht sich dies auf die direkte Übertragung über Gateways und zeitlich begrenzte Öffnungen sowie auf physische Offline-Medien, wenn ein zonenübergreifender Netzwerkpfad verboten oder inakzeptabel ist.

Wenn Backup-Daten zur Aufbewahrung oder zur Notfallwiederherstellung eine Zonengrenze überschreiten müssen, ist die Übertragungsmethode Teil der Sicherheitsarchitektur.

Direkte Übertragung unter Verwendung einer autorisierten Firewall-Regel ist die einfachste Option. Allerdings entsteht dabei ein dauerhafter Pfad mit Regeln, die genaue Adressen und Ports festlegen. Diese Regeln müssen protokolliert werden.

Ein kontrolliertes Gateway kann die Auswirkungen einer Kompromittierung begrenzen, wenn die zulässigen Ziele, Protokolle und Funktionen streng eingeschränkt sind.

Store-and-Forward mit zeitlich begrenzten Firewall-Öffnungen bewahrt die lokale Wiederherstellungsfähigkeit, unabhängig davon, ob das Übertragungsfenster offen ist oder nicht.

Offline-Übertragung auf physischen Datenträgern vermeidet während der Übertragung eine Netzwerkverbindung zwischen der Quell- und der Zielzone. Stark isolierte Zonen lassen möglicherweise nur diese Option zu. Isolierte Zonen sollten über einen definierten Wiederherstellungspfad verfügen, wenn gemeinsam genutzte Dienste offline sind.

Sicherungsdaten sollten verschlüsselt werden, bevor sie eine Zonengrenze überschreiten. Außerhalb der Quellzone sollte niemand Zugriff auf die Entschlüsselungsschlüssel haben.

Warum kann die zonübergreifende Wiederherstellung schwieriger sein als die Sicherung?

Selbst wenn das Design das Schreiben von Sicherungsdaten über Zonen hinweg erfolgreich umsetzt, kann es bei der Notfallwiederherstellung zu Fehlern kommen. Die Wiederherstellung basiert auf einer funktionsfähigen Zielumgebung, Identitätsdiensten, Netzwerkkonnektivität und einem funktionierenden Katalog. Diese Abhängigkeiten können die Wiederherstellung verhindern, selbst wenn die Sicherungsdaten selbst intakt sind. Die Wiederherstellung muss getestet werden, wenn zonübergreifende Abhängigkeiten nicht verfügbar sind.

Die Zonenintegrität steht ebenfalls im Zusammenhang mit der Wiederherstellung. Insbesondere wenn Daten aus Zone C in Zone A wiederhergestellt werden, entspricht die Art und Weise, wie die Daten ihre Zone verlassen haben, möglicherweise nicht den Anforderungen der Grenze. Zonenintegrität und Datenintegrität sind nicht dieselben Einschränkungen.

Beantworten Sie diese Fragen vor dem Eintreten eines Vorfalls:

• Kann jede Zone unabhängig wiederhergestellt werden, wenn keine zonübergreifende Konnektivität besteht?
• Kann die Wiederherstellung von Offline-Medien aus erfolgen, wenn der Backup-Katalog nicht verfügbar ist?
• Ist die lokale Sicherung von Anmeldedaten für die Wiederherstellung definiert und getestet, falls zentrale Identitätsdienste nicht verfügbar sind?
• Ist der lokale Speicher aktuell genug für eine sinnvolle Wiederherstellung bei geschlossener zonübergreifender Firewall?
• Können Standorte ohne ein Weitverkehrsnetz unabhängig voneinander betrieben und wiederhergestellt werden?

Was ist der Unterschied zwischen Backup-Verfügbarkeit und Wiederherstellbarkeit?

Das erfolgreiche Schreiben auf den Speicher gilt als Verfügbarkeit. Wenn Daten korrekt in die richtige Zone wiederhergestellt werden – über eine funktionierende Authentifizierung, innerhalb der erforderlichen Zeit, bei geschlossener zonübergreifender Firewall und offline befindlichen zentralen Identitätsdiensten –, handelt es sich um Wiederherstellbarkeit. Es ist unerlässlich, den Schwerpunkt auf die Konzeption und das Testen der Wiederherstellbarkeit zu legen, nicht nur auf die Verfügbarkeit.

Ein System, das Daten auf den Speicher schreibt, gilt als verfügbar. Ein System gilt als wiederherstellbar, wenn es mithilfe einer funktionierenden Authentifizierung die richtigen Daten in die richtige Zone auf ein funktionsfähiges Ziel innerhalb der erforderlichen Zeit wiederherstellt, während die zonübergreifende Firewall geschlossen ist und die zentrale Identitätsverwaltung offline ist. Dies sind unterschiedliche Eigenschaften. Die zweite muss getestet werden.

Wie sieht eine Backup-Architektur mit drei Zonen aus?

Bei diesem Szenario handelt es sich um ein kohärentes Mehrzonen-Design, bei dem die Wiederherstellungsfähigkeit der Zonen ihrem Isolationsgrad entspricht. Konkret ist Zone A von der Backup-Zone abhängig, und Zone B führt die Wiederherstellung lokal oder aus der Backup-Zone durch. Zone C führt die Wiederherstellung aus lokalen Komponenten durch, ohne von externen Systemen abhängig zu sein.

Die folgende Referenzarchitektur veranschaulicht ein kohärentes Mehrzonen-Design. Zone C ist isoliert, sodass sie keine eingehenden oder ausgehenden Netzwerkpfade zu externen Zonen besitzt. Kontroll- und Datenebenenfunktionen sind lokal in Zone C angesiedelt. Daten werden über physische Bandübertragung ausgegeben.

„Air-gapped“ bezeichnet physisch getrennte Sicherungsmedien ohne aktive Netzwerkverbindung. Es handelt sich dabei nicht um Speicher, der logisch vom Netzwerk isoliert ist.

Eine Katalogreplik stellt eine synchronisierte Kopie einiger oder aller Datensätze des Primärkatalogs dar, die auf einer separaten Datenbankinstanz gespeichert wird.

Zone A: Unternehmens-IT

Datei-Daemons übertragen Daten ausgehend an den zentralen Speicher-Daemon. Der Director nutzt einen autorisierten Firewall-Pfad, um Jobs zu planen. Es gibt keinen lokalen Backup-Speicher. Bei bestehender Konnektivität kann Zone A aus der Backup-Zone wiederhergestellt werden.

Zone B: Eingeschränkte Entwicklung

Zone B schützt Hochleistungs-Rechencluster, Simulations-Workloads, CAD-Daten und Forschungsdatensätze. Sie beherbergt einen lokalen Bacula-Director, Datei-Daemons, einen Speicher-Daemon und einen Katalog, wodurch Backup und Wiederherstellung ohne Verbindung zur zentralen Backup-/Wiederherstellungszone möglich sind.

Backup-Daten werden lokal von den Datei-Daemons an den Speicher-Daemon der Zone übertragen, während der lokale Director die Backup- und Wiederherstellungsaufträge verwaltet. Backup-Kopien können während autorisierter Übertragungsfenster über ein kontrolliertes Gateway in die zentrale Backup-/Wiederherstellungszone repliziert werden. Ist keine zonübergreifende Verbindung verfügbar, kann Zone B die lokalen Backup- und Wiederherstellungsvorgänge fortsetzen.

Zone C: Hochgradig isoliert

Keine Netzwerkverbindung zu externen Zonen. Zone C verfügt über einen eigenen Director, eigene Datei-Daemons, einen eigenen Speicher-Daemon, einen eigenen Katalog und eine eigene Bandbibliothek. Im Rahmen eines geprüften Prozesses werden die Bänder physisch in die Backup-Zone transportiert, um dort in den zentralen Katalog importiert zu werden. Zone C führt die Wiederherstellung über ihren lokalen Speicher-Daemon durch, ohne externe Identitätsdienste oder Netzwerkverbindung.

Sicherungs-/Wiederherstellungszone

Hier befinden sich der zentrale Director, der Speicher-Daemon, der Katalog und die Verwaltungskonsole. Nimmt Sicherungsverbindungen aus den Zonen A und B entgegen. Kein Routing zwischen Produktionszonen. Ransomware-resistente Aufbewahrung durch unveränderlichen Objektspeicher. Ransomware-resistente Aufbewahrung bezeichnet den Sicherungsspeicher, der so konzipiert ist, dass er unbefugten Löschungen oder Änderungen widersteht.

Die Bandbibliothek ermöglicht die Langzeitaufbewahrung und den Import in Zone C. Die Verwaltung erfolgt über eine dedizierte Verwaltungsschnittstelle, auf die die Netzwerke der Produktionszonen keinen Zugriff haben.

Wie wählt man eine Multi-Zone-Backup-Architektur aus?

Diese Tabelle hilft beim Vergleich der Optionen hinsichtlich der wichtigsten Designaspekte. Jede Zeile steht für eine eigenständige Entscheidung. Die Auswahl muss nicht in allen Aspekten einheitlich sein.

So entwerfen Sie ein Multi-Zone-Backup in 7 Schritten

Welche Ausfälle sollte eine Mehrzonen-Backup-Architektur überstehen?

Prüfen Sie vor der Bereitstellung der Software die Ausfallszenarien anhand der geplanten Architektur. Szenarien mit unklaren oder negativen Antworten stellen eine Lücke im Design dar, die Sie beheben sollten, bevor ein Vorfall eintritt.

Was sollten Sie vor der Einführung eines Multi-Zone-Backups überprüfen?

Diese Checkliste ist für die Entwurfsprüfung unerlässlich. Die nicht abgehakten Punkte stellen Lücken dar, die Sie schließen sollten, bevor die Architektur als vollständig angesehen werden kann.

• Zunächst werden Vertrauensgrenzen und Zonenklassifizierungen dokumentiert, bevor mit dem Entwurf der Backup-Architektur begonnen wird.
• Eine kompromittierte Komponente in Zone B kann Zone C nicht über autorisierte Backup-Kanäle oder Firewall-Regeln erreichen.
• Backup-Dienstkonten sind für jede Zone isoliert. Es gibt keine gemeinsam genutzten privilegierten Anmeldedaten, die Zonengrenzen überschreiten.
• Backup-bezogene Firewall-Regeln legen Quelle, Ziel, Ports und Richtung genau fest.
• Zonen können lokal sichern und wiederherstellen, wenn keine zonübergreifende Konnektivität besteht.
• Mindestens eine Wiederherstellungskopie befindet sich außerhalb des Produktionsnetzwerks: unveränderbarer Online-Speicher oder Offline-Medien.
• Man sollte nicht zwingend auf die Infrastruktur oder Identitätsdienste einer anderen Zone angewiesen sein, um jede Zone wiederherzustellen.
• Wiederherstellungsverfahren werden getestet, einschließlich Szenarien, in denen der Katalog nicht verfügbar ist.
• Lokale Fallback-Anmeldedaten werden für die Wiederherstellung ohne den zentralen Identitätsanbieter getestet. Lokale Anmeldedaten sind vorab bereitgestellte Anmeldedaten, die verwendet werden können, wenn keine zentralisierten Identitätsdienste verfügbar sind.
• Backup-Datenverkehr über Zonengrenzen hinweg wird an der Firewall protokolliert. Anomalien werden überwacht.

Wie unterstützt Bacula Backups über mehrere Sicherheitszonen hinweg?

Die Trennung von Director, Storage-Daemon und File-Daemon bei Bacula ist mehr als nur eine operative Erleichterung. Es handelt sich um eine architektonische Eigenschaft, die es ermöglicht, verschiedene Komponenten in unterschiedlichen Zonen mit unterschiedlichen Firewall-Regeln zu platzieren. Auf diese Weise können sie die in diesem Dokument beschriebenen Designmuster für mehrere Zonen unterstützen.

Die Bacula Enterprise-Backup-Architektur bietet ein verteiltes Komponentenmodell, das sich auf natürliche Weise auf mehrere Zonen abbilden lässt. Benutzer können den Director, den Storage Daemon und den File Daemon unabhängig voneinander bereitstellen. Verschiedene Komponenten können in unterschiedlichen Zonen mit unterschiedlichen Firewall-Regeln verbleiben. Diese Komponententrennung ermöglicht Bereitstellungsmuster, bei denen einzelne Bacula-Dienste auf unterschiedliche Sicherheitszonen abgestimmt werden.

Die Konfigurationsdokumentation zum Bacula File Daemon regelt die Kommunikation zwischen dem Director und dem Storage Daemon, um die Dateien auf den Clients zu sichern.

Ein Director in der Backup-Zone kann File Daemons über mehrere Zonen hinweg verwalten. Lokale Storage Daemons fungieren in den Zonen als Endpunkt des Datenpfads. Der Datenfluss erfolgt direkt zwischen File Daemon und Storage Daemon, ohne den Director zu durchlaufen. Aus diesem Grund sind die Firewall-Anforderungen für den Director geringer. Die Platzierung der Storage Daemons kann sich nach der Sensibilität der Zone richten, ohne vom Standort des Directors abhängig zu sein.

Für Zonen, in denen kein akzeptabler Netzwerkpfad zur Backup-Zone besteht, unterstützt Bacula Band und Offline-Medien als zonenspezifische Ziele. Das heißt, ein Storage-Daemon schreibt lokal, und das Band wird physisch zur Importierung in die Backup-Zone transportiert, ohne dass ein Netzwerkpfad zwischen den Zonen erforderlich ist.

Baculas Optionen für unveränderlichen Speicher, einschließlich Objektsperre und WORM-Bändern (Write Once, Read Many), können entsprechend konfigurierte Sicherungskopien vor unbefugtem Löschen oder Ändern schützen.

Unveränderliche Backups und Ransomware-Wiederherstellung sind wichtig im Umgang mit einer kompromittierten Produktionszone, aus der ein Angreifer versuchen könnte, zugängliche Wiederherstellungskopien zu löschen oder zu verändern.

Für HPC-Umgebungen in eingeschränkten Zonen unterstützt Bacula Lustre, das IBM General Parallel File System (GPFS) sowie groß angelegte parallele Dateisysteme. Für die Zonenisolierung sind keine Änderungen erforderlich.

Die Komponenten werden vor Ort ausgeführt, ohne auf eine externe Cloud-Management-Infrastruktur angewiesen zu sein. Überprüfen Sie vor der Nutzung der Software die Lizenzierung und Abhängigkeiten von externen Diensten in Bezug auf Ihre Umgebung.

Das Verhalten des Bacula-Produkts und die unterstützten Bereitstellungsoptionen sollten anhand der eingesetzten Version überprüft werden. Die technischen Referenzen in diesem Architekturhinweis wurden im Oktober 2026 überprüft.

Zentrales Architekturprinzip

Eine zonenübergreifende Sicherung sollte die Sicherheit der Grenzen der Produktionsumgebung wahren. Die Backup-Infrastruktur sollte keinen zonübergreifenden Zugriff ermöglichen, der durch die Produktionsarchitektur untersagt ist. Entwerfen Sie zulässige Datenflüsse, Anmeldedaten und unabhängige Wiederherstellungspfade und entscheiden Sie erst danach, wo Bacula-Komponenten bereitgestellt werden.

Häufig gestellte Fragen

Kann ein Backup-Server mehrere Sicherheitszonen sicher schützen?

Möglicherweise. Ein zentraler Backup-Server kann geeignet sein, wenn die Zonen kompatible Vertrauensanforderungen teilen und die zulässigen Verbindungen, Anmeldedaten und Routing-Kontrollen kein inakzeptables zonübergreifendes Risiko darstellen.

Sollten Backup-Clients Verbindungen initiieren?

In eingeschränkten Zonen ja. Von Clients initiierte ausgehende Verbindungen reduzieren die Angriffsfläche für eingehende Angriffe über Backup-Kanäle in diese Zone.

Ersetzt unveränderlicher Speicher das Offline-Backup?

Nein. Unveränderlichkeit schützt Backup-Daten unter definierten Aufbewahrungskontrollen vor Änderungen oder Löschungen, bietet jedoch für sich genommen keine Netzwerkisolierung. Beim Offline-Backup wird die aktive Netzwerkverbindung unterbrochen, während der Speicher offline bleibt. Dies sind separate Schutzmaßnahmen, die unterschiedliche Risiken adressieren und gemeinsam genutzt werden können.

Kann eine isolierte Zone eine zentralisierte Identitätsverwaltung nutzen?

Ja, sofern diese Abhängigkeit während der Wiederherstellung akzeptabel ist. Wenn die Wiederherstellung von diesem Identitätsanbieter abhängt und kein lokaler Authentifizierungs-Fallback vorhanden ist, kann der Ausfall des Anbieters die Wiederherstellung verhindern.

Kann Bacula eine Zone ohne dauerhafte Netzwerkverbindung sichern?

Ja. Ein lokaler Speicher-Daemon schreibt auf Band innerhalb der Zone. Das Band wird physisch transportiert und in den zentralen Katalog importiert.