Eine gespeicherte Routerkonfiguration ist erst dann ein belastbarer Wiederherstellungsnachweis, wenn sie zum richtigen Gerät gehört, geschützt verfügbar bleibt und in einer geeigneten Umgebung tatsächlich eingespielt werden kann. Die bloße Meldung „Backup erfolgreich“ beweist weder, dass Schlüssel und Firmware passen, noch dass Routing, Segmentierung und Managementzugang nach dem Restore wie vorgesehen funktionieren. Dieses Prüfprotokoll verbindet Sicherungsversion, Schutz, Wiederherstellungsversuch und fachliche Validierung. Es richtet sich an Netzbetrieb und Sicherheitsverantwortliche, die eine konkrete Wiederanlaufentscheidung belegen müssen.
Der DORA-IKT-Risikomanagementrahmen behandelt die Widerstandsfähigkeit eines Finanzunternehmens über Funktionen und Abhängigkeiten hinweg. Das hier beschriebene Protokoll ist ein einzelner technischer Nachweis. Die BSI-Kompendiumsbausteine NET.3.1 Router und Switches sowie CON.3 Datensicherungskonzept bieten einen methodischen Anker. Welche gesetzlichen oder aufsichtsrechtlichen Pflichten für eine Organisation gelten, ist gesondert festzustellen; die Anwendung einer Grundschutz-Anforderung macht nicht jedes Unternehmen automatisch zu einem DORA-Unternehmen.
Welche Konfiguration gesichert werden muss
Beginnen Sie mit einer eindeutigen Geräteliste: Standort, Rolle, Hersteller, Modell, Seriennummer, Softwarestand, Managementadresse und zuständiges Team. Erfassen Sie virtuelle Netzkomponenten und zentral verwaltete Vorlagen ebenso wie physische Geräte. Eine Vorlage kann mehrere Geräte versorgen, während jedes Gerät zusätzliche lokale Werte besitzt. Eine Sicherung, die nur die gemeinsame Vorlage enthält, kann im Störungsfall unvollständig sein. Kennzeichnen Sie daher, welche Teile vom Controller verteilt und welche unmittelbar auf dem Gerät gespeichert werden.
Unterscheiden Sie aktive, gespeicherte und beabsichtigte Konfiguration. Viele Geräte erlauben laufende Änderungen, die noch nicht in der dauerhaft geladenen Version stehen. Wenn das Backup die falsche Ebene abgreift, stellt ein Restore entweder eine nicht freigegebene Änderung wieder her oder verliert einen notwendigen Fix. Dokumentieren Sie, welche Version nach einem Neustart tatsächlich geladen würde, und verknüpfen Sie sie mit dem Change-Ticket. Bei Geräten mit mehreren Partitionen oder Startprofilen muss das Prüfprotokoll auch diese Auswahl festhalten.
Erfassen Sie Abhängigkeiten, die nicht in einer Konfigurationsdatei liegen: Lizenzen, Zertifikate, Schlüssel, lokale Benutzer, Zeitquellen, Namensauflösung und passende Firmware. Ein Import kann technisch erfolgreich sein, während verschlüsselte Verbindungen wegen fehlender Zertifikate ausfallen. Halten Sie fest, ob Geheimnisse exportiert werden dürfen, wie sie getrennt gesichert werden und wer sie im Notfall freigeben kann. Der allgemeine Wiederherstellungsleitfaden behandelt Kopien und Isolation; Netzgeräte benötigen zusätzlich diese gerätespezifische Vollständigkeitsprüfung.
Sicherungszeitpunkt und Änderungsbezug festlegen
Ein sinnvolles Verfahren sichert regelmäßig und nach wesentlichen genehmigten Änderungen. Die Intervalle folgen Änderungsfrequenz, Kritikalität und toleriertem Rückstand, nicht einer universellen Zahl. Ein selten geänderter Verteiler benötigt möglicherweise andere Abläufe als ein zentraler Firewall-Cluster. Dokumentieren Sie die Entscheidung und prüfen Sie, ob die tatsächlichen Änderungen innerhalb des gewählten Fensters liegen. Der BSI-Baustein NET.3.1 enthält eine Anforderung zur regelmäßigen Sicherung von Router- und Switch-Konfigurationen; wie die eigene Organisation dies konkret umsetzt, gehört in ihr Konzept.
Verbinden Sie jeden Sicherungspunkt mit dem Change-Prozess. Vor einer risikoreichen Änderung ermöglicht eine bekannte funktionsfähige Version den Rückweg. Nach erfolgreicher Implementierung wird die neue genehmigte Version gesichert. Bei einer fehlgeschlagenen Änderung bleibt sichtbar, ob die alte Version tatsächlich wiederhergestellt wurde oder ob einzelne Befehle manuell zurückgenommen wurden. Ohne diesen Bezug kann ein Backup-Repository viele Dateien enthalten und trotzdem keine verlässliche letzte gute Version ausweisen.
Kennzeichnen Sie automatisch ausgelöste Sicherungen und manuelle Notfallkopien. Letztere können wertvoll sein, benötigen aber dieselbe Zuordnung und Schutzprüfung. Eine auf dem Laptop eines Administrators abgelegte Datei darf nicht stillschweigend als Teil des zentralen Notfallbestands gelten. Ihr Zugriff, ihre Integrität und ihre Löschung nach Übernahme müssen geregelt werden. Protokollieren Sie außerdem Fehler der Sicherungsaufgabe: Ein geplanter Job, der wegen abgelaufener Zugangsdaten über Wochen nichts abholt, ist kein laufender Schutz.
Das Prüfblatt für eine Wiederherstellung ausfüllen
Das Protokoll soll den Versuch reproduzierbar machen. Es braucht nicht jeden Gerätebefehl als allgemeinen Mustertext, wohl aber eine stabile Referenz auf freigegebene Betriebsanweisungen. Füllen Sie die Felder schon vor der Übung aus, soweit die Planung sie kennt, und ergänzen Sie beobachtete Zeiten und Ergebnisse danach. Trennen Sie erwartetes Ergebnis und tatsächliche Beobachtung; sonst wird eine improvisierte Anpassung leicht als ursprünglich bestandener Test gelesen.
| Feld | Zu dokumentierender Inhalt |
|---|---|
| Prüfobjekt | Gerätetyp, Seriennummer oder Laborequivalent, Rolle und Softwarestand |
| Sicherung | Dateikennung, Erstellungszeit, Versionsbezug und Integritätswert |
| Schutz | Ablageort, Zugriffsberechtigung, Verschlüsselung und Schlüsselweg |
| Versuch | Verantwortliche, Zeitpunkt, Importmethode und Abweichungen |
| Validierung | Start, Managementzugang, Verbindungen, Regeln und Protokolle |
| Ergebnis | Bestanden, teilweise bestanden, fehlgeschlagen oder nicht geprüft |
| Folge | Fehlerursache, Zuständigkeit, Korrektur und erneuter Prüftermin |
Der Integritätswert kann eine unbeabsichtigte Änderung erkennbar machen. Er bestätigt aber nicht automatisch die Herkunft, wenn Angreifer Datei und Prüfsumme gemeinsam austauschen könnten. Schützen Sie das Sicherungssystem, seine Zugangsdaten und seine Protokolle entsprechend dem Risiko. Halten Sie die Aufbewahrung so fest, dass eine bekannte gute Version verfügbar bleibt, ohne unkontrolliert alte Konfigurationen und Geheimnisse zu sammeln. Die Versionierung muss einen Fehlzustand von einer funktionierenden, freigegebenen Konfiguration unterscheiden können.
Speicherort und Zugang im Notfall prüfen
Ein Backup im gleichen Verwaltungsnetz kann bei dessen Ausfall unerreichbar sein. Prüfen Sie, wie ein berechtigtes Team an Konfiguration und benötigte Schlüssel gelangt, wenn zentrale Identität, Netzwerkverbindung oder Automationsplattform gestört sind. Ein isolierter oder gesondert erreichbarer Sicherungsweg kann nötig sein. Er braucht trotzdem starke Zugriffsregeln und nachvollziehbare Nutzung, denn Konfigurationsdateien enthalten oft sensible Adressen, Zugangsdaten oder Sicherheitsregeln.
Testen Sie den Zugang mit den tatsächlich vorgesehenen Notfallrollen. Eine dokumentierte Administratorgruppe hilft nicht, wenn nur eine ausgeschiedene Person den Schlüssel besitzt. Ebenso wenig reicht eine Ersatzkopie, deren Entschlüsselung denselben ausgefallenen Dienst voraussetzt. Der Business-Continuity-Plan beschreibt Zuständigkeiten und fachliche Ziele; hier wird der konkrete technische Zugang zu einem Netzgerät durchgespielt. Dokumentieren Sie abweichende Notfallrechte, ihre Aktivierung und ihre Rücknahme nach dem Test.
Behandeln Sie das Exportformat als Teil der Wiederherstellbarkeit. Ein proprietärer Binärexport kann an Modell oder Firmware gebunden sein; ein Klartextformat kann Geheimnisse preisgeben oder beim Import nicht alle Eigenschaften abdecken. Prüfen Sie anhand des Herstellers und eines kontrollierten Versuchs, welches Format für Ersatzgeräte geeignet ist. Planen Sie bei auslaufender Hardware die Konfigurationsmigration, bevor ein Fehler den Umstieg erzwingt. Im Protokoll darf „kompatibel“ erst stehen, wenn die relevanten Funktionen im Zielzustand beobachtet wurden.
Eine sichere Testumgebung wählen
Eine Wiederherstellungsprobe sollte den produktiven Dienst nicht unbeabsichtigt unterbrechen. Verwenden Sie nach Möglichkeit ein baugleiches Ersatzgerät, ein geeignetes Labor oder eine isolierte Testumgebung. Stellen Sie fest, welche Eigenschaften dort realistisch geprüft werden können und welche nicht. Eine Simulation kann Syntax und Grundkonfiguration belegen, aber möglicherweise nicht das Verhalten eines physischen Links, einer speziellen Lizenz oder einer Hochverfügbarkeitskopplung. Diese Grenze gehört ins Ergebnis.
Vor dem Import bereiten Sie Rückweg und Abbruchkriterien vor. Wer stoppt den Versuch, wenn die Testumgebung unerwartet produktive Netze erreicht? Welche Schnittstellen müssen deaktiviert bleiben? Wie werden sensible Konfigurationsdaten nach der Probe entfernt? In einem produktionsnahen Wartungsfenster muss zusätzlich die Betriebsseite wissen, welche Unterbrechung möglich ist und wie sie fachlich bewertet wird. Eine erfolgreiche technische Übung, die unbemerkt Kundenverkehr umleitet, wäre kein guter Nachweis.
Führen Sie die Schritte durch die vorgesehene Rolle aus, nicht ausschließlich durch den Spezialisten, der das Verfahren geschrieben hat. Beobachten Sie, an welcher Stelle Vorwissen nötig war. Wenn wichtige Hinweise nur mündlich vorliegen, ergänzen Sie die Betriebsanweisung. Eine zweite Person sollte aus Sicherungskennung, Geräteangaben und Verfahren den Versuch nachvollziehen können. Diese Übertragbarkeit ist besonders relevant bei Ausfall, Schichtwechsel oder wenn ein Dienstleister kurzfristig nicht erreichbar ist.
Nach dem Import Funktionen statt nur Dateien vergleichen
Ein erfolgreicher Importdialog ist der Beginn der Validierung. Prüfen Sie zunächst Startverhalten, Managementzugang und den erwarteten Softwarestand. Danach testen Sie die für die Rolle des Geräts wesentlichen Verbindungen und Regeln: vorgesehene Routen, VLAN-Zuordnung, Filter, dynamische Nachbarschaften und gegebenenfalls redundante Umschaltung. Verwenden Sie festgelegte Testfälle mit erwartetem Ergebnis. Ein allgemeiner Ping beweist weder korrekte Segmentierung noch das Blockieren unerlaubter Verbindungen.
Prüfen Sie negative Tests. Kann ein Netzsegment eine Verbindung aufbauen, die ausdrücklich untersagt sein soll? Werden Verwaltungszugänge aus nicht vorgesehenen Netzen abgewiesen? Funktioniert die Protokollierung und erreicht ein Testereignis die vorgesehene Auswertung? Ein Restore kann eine alte Regel wieder aktivieren, die inzwischen entfernt wurde. Deshalb gehört neben dem Vergleich mit der gesicherten Version auch der Abgleich mit den aktuell freigegebenen Sicherheitsanforderungen ins Protokoll.
Messen Sie die Zeit bis zur fachlich nutzbaren Netzwerkleistung, nicht nur bis zum Ende des Dateimports. Dazu können Freigabe von Schlüsseln, Einbau eines Ersatzgeräts, Leitungsprüfung und Abstimmung mit anderen Teams gehören. Ein Zielwert ist eine organisationsspezifische Entscheidung aus der Auswirkungsanalyse. Die BSI-Methodik für BCM und Notfallmanagement verbindet solche Ziele mit Geschäftsprozessen. Dieses Prüfblatt liefert die beobachtete technische Grundlage, um die Annahme über die Wiederanlaufzeit zu bestätigen oder zu korrigieren.
Fehler in eine überprüfbare Maßnahme übersetzen
Ein teilweise bestandener Test benötigt mehr als „Konfiguration importiert, Nacharbeit erforderlich“. Beschreiben Sie die genaue Abweichung, ihre Wirkung und die wahrscheinlichste Ursache. Vielleicht konnte die Datei importiert werden, aber das Zertifikat war nicht verfügbar. Vielleicht waren die ACLs korrekt, doch eine Routing-Nachbarschaft blieb wegen eines Versionsunterschieds aus. Entscheiden Sie, ob eine neue Sicherung, eine geänderte Betriebsanweisung, eine Ersatzteilstrategie oder eine andere Schlüsselverwaltung nötig ist.
Vergeben Sie Verantwortliche und Termin für Korrektur und erneute Prüfung. Schließen Sie den Befund erst, wenn die relevante Funktion erneut erfolgreich beobachtet wurde. Ein Ticket mit Status „erledigt“ kann den administrativen Abschluss belegen, aber nicht automatisch die Wiederherstellbarkeit. Wenn die Korrektur eine sicherheitsrelevante Konfiguration ändert, führen Sie sie durch den üblichen Change-Prozess und sichern Sie anschließend die neue gültige Version. So wird der Testbefund Teil des Betriebs, statt nur in einem Auditordner zu liegen.
Unterscheiden Sie systematischen Fehler und Einzelfall. Wenn mehrere Geräte denselben Importfehler zeigen, prüfen Sie das Sicherungsverfahren oder die Firmwarestrategie für die Geräteklasse. Ein einzelner veralteter Switch kann eine lokale Ausnahme sein. Die Risikoanalyse nach BSI 200-3 kann helfen, besondere Konstellationen strukturiert zu bewerten, wenn Standardmaßnahmen nicht ausreichen. Sie ersetzt nicht den tatsächlichen Restore-Versuch.
Beispiel: Ersatz eines zentralen Verteilers
Ein Unternehmen sichert die Konfiguration seines zentralen Verteilers nach jeder freigegebenen Änderung und zusätzlich nach einem festgelegten Intervall. Für die Übung steht ein baugleiches Ersatzgerät bereit. Das Team wählt die letzte als gut markierte Sicherung, prüft ihre Kennung und ihren Integritätswert, bereitet Firmware und Zugangsdaten getrennt vor und importiert die Datei. Nach dem Neustart funktionieren Management und mehrere VLANs, aber die Verbindung zur Firewall bleibt aus. Die technische Erfolgsanzeige des Importwerkzeugs ist deshalb kein bestandener Gesamttest.
Die Analyse zeigt, dass eine Lizenz für die benötigte Funktion auf dem Ersatzgerät fehlt. Die Sicherungsdatei war vollständig, der Wiederherstellungsprozess jedoch nicht. Das Team dokumentiert den Befund, beschafft einen gültigen Ersatzweg und ergänzt die Lizenzprüfung in das Protokoll. Beim zweiten Versuch funktionieren erlaubte Verbindungen; ein negativer Test bestätigt, dass ein gesperrtes Segment nicht auf ein Verwaltungsnetz zugreifen kann. Die beobachtete Zeit umfasst auch die Aktivierung der Lizenz. Erst dieses zweite Ergebnis trägt eine belastbare Aussage zur Wiederherstellbarkeit.
Für einen regulierten Finanzdienstleister kann das Ergebnis ein Baustein seiner DORA-Nachweise sein, wenn das Gerät eine betroffene IKT-gestützte Funktion unterstützt. DORA macht aber nicht jedes private oder öffentliche Netzwerkgerät kraft seiner Existenz zu einem eigenen Meldeobjekt. Entscheidend sind Einordnung des Unternehmens, betroffene Funktion und anwendbare Anforderungen. Der Rahmenbeitrag zu DORA hilft, den technischen Befund in die richtige Governance einzubetten, ohne die Prüfkarte zu einer pauschalen Rechtsbescheinigung zu machen.
Das Protokoll über die Übung hinaus aktuell halten
Wiederholen Sie die Prüfung nach wesentlichen Änderungen der Geräteklasse, des Sicherungsformats, der Firmware, des Schlüsselwegs oder der Wiederherstellungsumgebung. Eine starre Jahresaussage genügt nicht, wenn sich die Voraussetzungen kurz nach dem Test ändern. Gleichzeitig sollten Sie Intervalle risikobasiert festlegen und prüfen, ob sie tatsächlich eingehalten werden. Ein Test vor drei Jahren kann noch erklären, wie das Verfahren entworfen wurde, aber nicht beweisen, dass es nach einer Migration unverändert funktioniert.
Bewahren Sie Protokoll, Sicherungskennung, Beobachtungen und Korrekturen so auf, dass sie auch nach Personalwechsel verständlich sind. Sensible Konfigurationsdaten gehören in geschützte Ablagen, nicht als vollständiger Anhang an jeden Prüfbericht. Der Bericht kann auf die geschützte Datei verweisen und die für die Entscheidung relevanten Fakten enthalten. Eine unabhängige Person sollte erkennen können, welches Gerät geprüft wurde, welche Version wiederhergestellt wurde, welche Funktionen tatsächlich liefen und welche Lücken offen blieben. Genau diese nachvollziehbare Kette unterscheidet ein vorhandenes Backup von einer nachgewiesenen Wiederherstellung.
Ersatzgerät und Serienwechsel ausdrücklich testen
Im Notfall steht häufig nicht das ursprüngliche Gerät, sondern ein Ersatzmodell oder eine neuere Hardwaregeneration bereit. Prüfen Sie deshalb getrennt, ob sich die Sicherung auf derselben Geräteklasse und auf einem realistisch verfügbaren Ersatz einspielen lässt. Manche Einstellungen betreffen physische Portnummern, Hardwaremodule oder Lizenzmerkmale und können nicht unverändert übertragen werden. Die Dokumentation sollte eine Übersetzung dieser Werte enthalten, die von einer zweiten Person geprüft wird. Ein abstrakter Satz „Konfiguration kompatibel“ hilft dem Team unter Zeitdruck nicht, wenn der erste freie Port eine andere Sicherheitszone bedient.
Nehmen Sie nach einem Serienwechsel die Zugangskette erneut in den Blick. Gerätegebundene Zertifikate oder Schlüssel können fehlen; eine zentrale Verwaltungsplattform kann das Ersatzgerät zunächst nicht kennen. Halten Sie fest, wer es registriert, wie die Identität geprüft wird und wann temporäre Berechtigungen entzogen werden. Führen Sie diesen Weg in der Testumgebung zumindest so weit aus, dass die kritischen Voraussetzungen sichtbar werden. Wenn ein externer Dienstleister die Inbetriebnahme übernimmt, prüfen Sie seinen erreichbaren Kontakt und die benötigte Bevollmächtigung; die bloße Angabe einer Vertragsnummer ist keine getestete Wiederherstellungsressource.
Schließen Sie die Probe mit einem Soll-Ist-Vergleich der aktuellen freigegebenen Netzarchitektur. Eine historische Sicherung kann technisch funktionieren und trotzdem einen inzwischen verbotenen Kommunikationsweg wieder eröffnen. Notieren Sie, welche Änderungen nach dem Einspielen zwingend nachgezogen werden müssen und wie ihre Ausführung validiert wird. Das Team benötigt damit nicht nur eine Datei, sondern eine Reihenfolge aus Restore, Sicherheitsanpassung und Freigabe der fachlichen Nutzung.