Belegbar, nicht behauptet
Jeder Schritt hinterlässt ein Artefakt. Was sich geändert hat und warum, lässt sich nachträglich rekonstruieren, vom Reviewer wie vom Auditor.
Die Methodik
Eine Firewall-Migration scheitert selten an der Hardware. Sie scheitert an dem, was niemand dokumentiert hat: der Regel, die seit 2014 nichts mehr durchlässt, dem Any-Any, das jeder fürchtet anzufassen, der Genehmigung, die nie stattfand. Das ist die Reihenfolge, in der ich vorgehe, und der Grund, warum dieselbe Reihenfolge jedes Mal funktioniert.
Das Problem
Eine Migration läuft fast überall gleich ab: Regeln in eine Tabelle exportieren, von Hand übersetzen, deployen und hoffen. Bei tausenden Regeln übersieht dieser Ansatz zuverlässig Schattenregeln, überlappende Policies und redundante Konfigurationen, und Compliance wird zur Aufgabe nach dem Cutover statt davor.
Die Risiken liegen nicht im Offensichtlichen. Sie liegen in den Annahmen, die niemand mehr prüft, dass eine Regel noch gebraucht wird, dass eine Genehmigung existiert, dass „temporär" auch temporär war. Die Methodik unten macht jede dieser Annahmen explizit, bevor sie produktiv wird.
Die fünf Phasen
Keine Migration springt direkt zur Übersetzung. Reihenfolge ist die ganze Methode. Jede Phase produziert ein Artefakt, das die nächste prüfen kann, und am Ende einen vollständigen Audit-Trail, der zeigt, was sich geändert hat, wer es genehmigt hat und warum.
Das echte Regelwerk erfassen, nicht das dokumentierte. Jede Regel, jedes Objekt, jede verschachtelte Gruppe, normalisiert in ein herstellerunabhängiges Format.
Herstellersyntax auf eine gemeinsame Semantik abbilden: Quelle, Ziel, Service, Aktion, Logging. Erst dann ist ein Vergleich überhaupt möglich.
Die gesamte Hierarchie analysieren, nicht einzelne Regeln isoliert. Schattenregeln, Konflikte, Redundanzen und zu weite Zugriffe sichtbar machen.
In kontrollierten Fenstern deployen, mit Health-Checks und sofortiger Rollback-Fähigkeit. Kein „großer Knall", keine Überraschungen um 03:00 Uhr.
Jede Änderung, jede Übersetzungsentscheidung, jedes Validierungsergebnis mit Zeitstempel und Begründung, fertig für den Auditor.
Discovery
Die Dokumentation lügt fast immer. Sie beschreibt die Absicht von vor fünf Jahren, nicht den Zustand von heute. Discovery beginnt darum am Gerät, jede aktive Regel, jedes Adress- und Serviceobjekt, jede verschachtelte Gruppenreferenz wird aufgelöst und in ein herstellerunabhängiges Zwischenformat überführt.
Normalisierung
Palo-Alto-XML, Fortinet-CLI und Check-Point-Policy-Layer beschreiben dieselben Konzepte mit unterschiedlicher Syntax. Solange sie in dieser Syntax bleiben, lässt sich nicht sauber vergleichen, und damit nicht analysieren. Normalisierung bildet jede Regel auf eine gemeinsame Semantik ab: Quelle, Ziel, Service, Aktion, Logging. Bedeutung bleibt erhalten, Hersteller-Eigenheiten werden explizit.
Schatten- & Konfliktanalyse
Manuelle Reviews scheitern an genau einer Stelle: Sie betrachten Regeln einzeln, nicht in ihrer Verarbeitungsreihenfolge. Eine Regel, die durch eine frühere komplett verdeckt wird, sieht für sich genommen vernünftig aus. Erst die Analyse der gesamten Hierarchie zeigt, dass sie nie greift. Genau dort liegt das Risiko, das nach dem Cutover zum Ausfall wird.
Was die Daten zeigen
durchschnittlicher Schattenregel-Anteil in den analysierten RegelwerkenLab- und Projektbeobachtung
der Ingenieurzeit floss in repetitive Analyse, bevor sie automatisiert wurdeBranchendurchschnitt
Migrationen über 11 Tier-1-Großunternehmen in regulierten BranchenEigene Projektarbeit
Welche Fehlerklassen sich über 280 Migrationen tatsächlich wiederholen, und welche Muster sich aus den Regelwerk-Daten herauslesen lassen, habe ich in zwei Beiträgen ausgeschrieben: Datenanalyse von 280 Firewall-Migrationen und eine Taxonomie der Migrationsfehler.
Gestaffelter Cutover
Der riskanteste Moment einer Migration ist der Moment, in dem alles gleichzeitig umgestellt wird. Darum tue ich das nie. Der Cutover läuft gestaffelt, ein Segment nach dem anderen, jeweils in einem geplanten Wartungsfenster, mit definierten Health-Checks und einem Rollback, der in Sekunden greift, nicht in Stunden.
Nachweise
Jede Änderung trägt das Wer, Was, Wann und Warum. Validierung passiert vor dem Deployment, nicht danach: Die übersetzte Konfiguration wird gegen die regulatorischen Rahmenwerke geprüft, die europäische Teams tatsächlich beantworten müssen, und die Dokumentation entsteht automatisch, nicht in einer hektischen Woche vor dem Audit.
Warum das wiederholbar ist
Die Methodik ist nicht an einen Hersteller, eine Branche oder ein Projekt gebunden. Sie funktioniert, weil sie die richtigen Fragen in der richtigen Reihenfolge stellt, und jede Antwort als prüffähiges Artefakt festhält, bevor die nächste Frage drankommt.
Jeder Schritt hinterlässt ein Artefakt. Was sich geändert hat und warum, lässt sich nachträglich rekonstruieren, vom Reviewer wie vom Auditor.
Discovery vor Normalisierung, Analyse vor Cutover. Die Reihenfolge ist der Wert. Die Plattform automatisiert die Schritte, sie ersetzt nicht das Urteil.
Wenn die Nachweise an jeder Stelle mitlaufen, ist das Audit kein Projekt mehr. Der Trail existiert bereits, weil er Teil der Arbeit war.
Von der Methode zur Plattform
Siebzehn Jahre und über 280 Migrationen haben gezeigt, welche Schritte sich wiederholen und welche Fehler sich vermeiden lassen. FwChange kodiert genau das: strukturierte Änderungsanträge, mehrstufige Genehmigungsketten, Risiko- und Konfliktanalyse, herstellerübergreifende Übersetzung und Compliance-Exporte, damit jede Migration denselben prüffähigen Weg nimmt.
Praxis, nicht Theorie
Eine Migration ist kein Hardware-Tausch. Sie ist eine Übung im Beweisen, dass man verstanden hat, was die Firewall wirklich tut, bevor man sie ersetzt.
Palo AltoFortinetCheck PointCiscoJuniperF5
Das Whitepaper geht jeden Schritt im Detail durch, von der Discovery bis zum Nachweispaket. Wer wissen will, wer dahintersteht, findet das Profil und die Belege auf der Über-Seite.