Architektur- und Netzwerkreview: Entscheidungen belastbar vorbereiten
Eine praktische Entscheidungshilfe für Architektur- und Netzwerkreviews: Funktionen, Abhängigkeiten, Betriebsfähigkeit und Übergabe systematisch prüfen.
Ein Architektur- oder Netzwerkreview sollte nicht mit einer Produktliste beginnen. Zuerst muss klar sein, welche Funktion erhalten oder ermöglicht werden soll: Wer benötigt welche Information, über welchen Weg, mit welcher zeitlichen Erwartung? Erst danach lassen sich technische Optionen, Abhängigkeiten und Grenzen sinnvoll vergleichen.
Ein Review ist dabei keine Abnahme und keine Garantie für Sicherheit oder Verfügbarkeit. Es ist eine begründete Momentaufnahme, die Annahmen sichtbar macht und nächste Entscheidungen vorbereitet.
Eine Entscheidung in sechs Schritten vorbereiten
1. Funktion und Randbedingungen beschreiben
Notieren Sie für jede wichtige Funktion:
- beteiligte Menschen, Anwendungen und Prozesse,
- benötigte Datenflüsse und Kommunikationspartner,
- tolerierbare Unterbrechungen und notwendige Wiederanlaufreihenfolge,
- bekannte räumliche, organisatorische und rechtliche Grenzen.
Formulieren Sie Anforderungen als beobachtbare Eigenschaften. „Das Netz muss robust sein“ ist dafür zu unbestimmt. „Die Abhängigkeit vom einzigen Kommunikationsweg soll sichtbar bewertet werden“ ist eine prüfbare Arbeitsfrage.
2. Abhängigkeiten als Kette darstellen
Eine Anwendung hängt oft nicht nur von einem Server ab. Endgeräte, Identitäten, Namensauflösung, Zeitquellen, Speicher, Sicherungen, Leitungen, Routing und externe Dienste können ebenso erforderlich sein. Für jede Abhängigkeit sollte die Übersicht mindestens beantworten:
| Frage | Entscheidungshilfe |
|---|---|
| Wofür wird sie benötigt? | Funktion und betroffene Nutzer benennen |
| Wer ist verantwortlich? | Zuständigkeit und Eskalationsweg festhalten |
| Woran wird ihr Zustand erkannt? | Messpunkt, Prüfschritt oder fachliche Rückmeldung nennen |
| Was geschieht bei Ausfall? | Rückfallweg, eingeschränkten Betrieb oder bewusste Unterbrechung beschreiben |
| Wie wird sie wiederhergestellt? | Reihenfolge, benötigte Zugänge und vorhandene Sicherungen prüfen |
Unbekannte Abhängigkeiten sind zunächst ein Ergebnis des Reviews, kein Grund, sie durch Annahmen zu ersetzen.
3. Grenzen und Datenflüsse prüfen
Zeichnen Sie logische Grenzen, nicht nur Geräte. Dazu gehören etwa Netze mit unterschiedlichen Schutzanforderungen, administrative Zuständigkeiten und Übergänge zu externen Diensten. Für jeden Übergang sollten Zweck, erlaubte Kommunikation, verantwortliche Rolle und Prüfpunkt dokumentiert sein.
Die NIST-Leitlinie zu Firewalls und Firewall-Policies beschreibt Regeln für ein- und ausgehenden Verkehr, die aus den Sicherheitsanforderungen der Organisation abgeleitet werden. Für ein Review folgt daraus eine einfache Frage: Welche Kommunikation wird tatsächlich benötigt, und wie wird die Entscheidung später überprüft? Die Quelle ist eine technische Leitlinie, keine pauschale Empfehlung für ein bestimmtes Produkt.
4. Optionen anhand derselben Kriterien vergleichen
Bewerten Sie jede Option mit derselben kleinen Matrix:
| Kriterium | Leitfrage |
|---|---|
| Funktion | Erfüllt die Option den beschriebenen Zweck ohne unnötige Zusatzannahmen? |
| Abhängigkeiten | Welche Bindungen an Wege, Dienste, Hersteller, Verträge oder Einzelwissen entstehen? |
| Betrieb | Wer kann Änderungen, Fehleranalyse, Sicherung und Wiederherstellung durchführen? |
| Übergabe | Welche Unterlagen und welches Wissen müssen für den Betrieb verfügbar sein? |
| Rückfall | Was ist der begrenzte Weiterbetrieb, wenn ein Bestandteil ausfällt? |
| Veränderbarkeit | Wie lässt sich die Option später prüfen, erweitern oder ersetzen? |
Offene Standards oder Open-Source-Komponenten können Prüfbarkeit und Übergabe erleichtern. Sie lösen aber keine fehlenden Zuständigkeiten und sind nicht automatisch die passende Wahl. Entscheidend ist, ob die konkrete Option die Funktion mit einem beherrschbaren Betriebsmodell verbindet.
Governance und Herstellerbindung vor der Entscheidung klären
Neben Funktion und Kosten gehört zur Architekturentscheidung, wer die Lösung beherrschen und unter welchen Vorgaben betreiben kann. Ein Standort des Rechenzentrums beantwortet für sich genommen weder die Frage nach anwendbarem Recht noch nach möglichen Zugriffen aus anderen Ländern. Die jeweils einschlägigen gesetzlichen, vertraglichen und kundenspezifischen Anforderungen müssen für das konkrete Vorhaben geklärt werden; dieser Beitrag legt keine Jurisdiktion pauschal fest.
| Prüffeld | Frage vor einer Bindung |
|---|---|
| Rechts- und Vertragsraum | Wer sind Vertragspartner und Unterauftragnehmer? Wo erfolgen Betrieb, Administration, Support und Datenverarbeitung? Welche Rechtswahl, Zugriffs- und Herausgaberegeln sowie Kunden- oder Branchenanforderungen sind zu prüfen? |
| Verantwortung | Wer entscheidet über Datenklassen, Freigaben, Änderungen, Vorfälle und die Annahme verbleibender Risiken? Welche Nachweise und Prüfungsrechte werden benötigt? |
| Vertrauen in den Anbieter | Sind Sicherheitsupdates, Umgang mit Schwachstellen und Vorfällen, Support, Lebenszyklus und Vertragsänderungen nachvollziehbar? Welche Zusagen sind überprüfbar statt bloßes Marketing? |
| Technische Bindung | Welche proprietären Formate, Schnittstellen, Identitätsdienste, Lizenzen, Verwaltungswerkzeuge oder Einzelkenntnisse machen einen Herstellerwechsel aufwendig? |
| Wirtschaftliche Bindung | Welche Kosten entstehen nicht nur beim Einstieg, sondern auch bei Wachstum, Datenexport, Vertragsende und Parallelbetrieb während einer Migration? |
| Ausstieg | Lassen sich Daten, Konfigurationen und Betriebswissen vollständig exportieren? Ist ein Ersatzbetrieb mit definierten Fristen, Zuständigkeiten und einem getesteten Rückweg möglich? |
Eine tiefe Herstellerintegration kann bewusst sinnvoll sein. Sie sollte aber als Entscheidung mit Nutzen, Abhängigkeiten und Ausstiegsweg dokumentiert werden, statt sich aus vielen kleinen Einzelentscheidungen unbeabsichtigt zu ergeben. Das BSI beschreibt rechtliche und vertragliche Anforderungen sowie die Exit-Strategie bei Cloud-Diensten ausdrücklich als eigene Prüfgegenstände; die konkrete rechtliche Einordnung gehört bei Bedarf in die dafür zuständige Fachprüfung.
5. Wiederherstellung als Teil der Architektur behandeln
Eine Sicherung ist nicht dasselbe wie eine getestete Wiederherstellung. Prüfen Sie daher getrennt:
- Welche Daten und Konfigurationen werden gesichert?
- Wer kann auf die Sicherung und die erforderlichen Zugangsdaten zugreifen?
- In welcher Reihenfolge werden abhängige Komponenten wieder in Betrieb genommen?
- Wie wird festgestellt, dass die Funktion wiederhergestellt ist?
- Wann wird dieser Ablauf mit vertretbarem Aufwand geübt?
Das BSI nennt für Notfallvorsorge und -bewältigung ausdrücklich Dokumentation, Verantwortlichkeiten sowie Tests und Übungen als Prüfgegenstände. Daraus folgt keine Verfügbarkeitsgarantie; es zeigt nur, dass Betriebsfähigkeit nicht mit dem Aufbau der Technik endet.
6. Entscheidung und Übergabe dokumentieren
Ein brauchbares Review-Ergebnis muss auch später verständlich sein. Halten Sie deshalb fest:
- die geprüfte Ausgangslage und offene Annahmen,
- die verworfenen und gewählten Optionen mit Begründung,
- bekannte Risiken und bewusst akzeptierte Grenzen,
- Verantwortlichkeiten und nächste Prüfschritte,
- die Unterlagen, die an den Betrieb übergeben werden.
Die Arbeitsweise beschreibt die Verbindung von Lagebild, Funktionsklärung, Bestandsprüfung, Abhängigkeitsordnung und Betriebsübergabe. Ein Review kann diese Kette vorbereiten, ersetzt aber nicht die gemeinsame Prüfung des konkreten Systems.
Wann ist ein Review-Ergebnis ausreichend?
Vor einer Entscheidung sollte eine außenstehende technische Person nachvollziehen können:
- welche Funktion geschützt oder ermöglicht werden soll,
- welche Abhängigkeiten die Funktion hat,
- welche Optionen nach welchen Kriterien verglichen wurden,
- wie Betrieb, Rückfall und Wiederherstellung gedacht sind,
- wer die Entscheidung trägt und wann sie erneut geprüft wird.
Fehlt eine dieser Antworten, ist die sinnvolle nächste Maßnahme meist eine gezielte Klärung – nicht die sofortige Auswahl eines Produkts.
Grenzen dieses Beitrags
Der Beitrag enthält keine konkrete Netzplanung, keine Sicherheitsberatung für einen Einzelfall, keine rechtliche oder regulatorische Bewertung und keine Zusage eines bestimmten Ergebnisses. Praxisbeispiele bleiben anonymisiert und werden nur verwendet, wenn ihr Inhalt dafür freigegeben ist.
Für ein konkretes Vorhaben können Beratung und Projektplanung sowie Netzwerke, Routing und Funk die passenden nächsten Einstiegspunkte sein. Eine Anfrage sollte die konkrete Fragestellung, vorhandene Unterlagen und bekannte Grenzen benennen; die Kontaktmöglichkeit bleibt davon unberührt.
Ein abgegrenzter Praxisbezug steht im anonymisierten Profil zur Sicherheitsprüfung im Kanzleiumfeld. Es beschreibt keine allgemeine Erfolgszusage, sondern ordnet Prüfung, Schutzarchitektur und Übergabe einem konkreten Leistungsrahmen zu.
Quellen
Die technischen Aussagen wurden gegen folgende Primärquellen geprüft (Abruf: 24.–26.09.2026):
- NIST, SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy, DOI
10.6028/NIST.SP.800-41r1, csrc.nist.gov - Bundesamt für Sicherheit in der Informationstechnik, IT-Grundschutz – Notfälle üben
- Bundesamt für Sicherheit in der Informationstechnik, IT-Grundschutz-Kompendium, ORP.5 Compliance Management (Anforderungsmanagement), Edition 2023, PDF
- Bundesamt für Sicherheit in der Informationstechnik / UP KRITIS, Empfehlungen zur Vorbereitung einer Exit-Strategie bei Nutzung von Cloud-Dienstleistungen
Die Quellen belegen allgemeine technische Leitlinien. Sie belegen weder konkrete Unternehmensleistungen noch ein bestimmtes Ergebnis.