Wie FwMigrate Firewall-Konfigurationen ohne Regelverlust übersetzt
Ein technischer Walkthrough der Parsing-, Normalisierungs- und Validierungspipeline hinter herstellerübergreifender Firewall-Migration.
1. Das Migrationsproblem in Mid-Market-Umgebungen
Eine typische Mid-Market-Firewall-Migration umfasst zwischen 800 und 4.000 Regeln. Die meisten dieser Regeln wurden von Personen geschrieben, die nicht mehr im Unternehmen sind. Kommentare sind spärlich, die Benennung uneinheitlich, und Schattenregeln häufen sich über Jahre an.
Das traditionelle Migrations-Playbook: eine Tabelle, zwei Ingenieure, vier bis acht Wochen. Etwa eine von fünfzig Regeln wird falsch übertragen. Die Hälfte dieser Fehler wird im UAT entdeckt. Die andere Hälfte taucht in der Produktion auf — meistens dienstags um 02:00.
FwMigrate adressiert die Ursache: Hersteller-Syntaxdivergenz zwingt Menschen zu hunderten Kontextwechseln pro Migration. Jeder Wechsel ist eine Gelegenheit für einen Fehler.
2. Hersteller-Parser und die Zwischendarstellung
Jeder unterstützte Hersteller (Palo Alto, Cisco ASA, Cisco FTD, Check Point, Fortinet, Juniper SRX, F5, pfSense, OPNsense, MikroTik, AWS Security Groups) hat einen dedizierten Parser. Der Parser durchläuft die Konfiguration von oben nach unten und erzeugt strukturierte Tokens: Adress-Objekte, Service-Objekte, Security-Regeln, NAT-Regeln, Anwendungsfilter, Policy-Ketten.
Tokens werden in eine herstellerneutrale Zwischendarstellung (IR) abgebildet. Die IR nutzt dieselben Primitive für alle Hersteller: SourceZone, DestinationZone, SourceAddress, DestinationAddress, Service, Action, LogProfile, plus herstellerspezifische Erweiterungen als opake Metadaten.
Die IR ist der Vertrag. Solange ein Hersteller-Parser eine gültige IR erzeugt und ein Hersteller-Emitter eine konsumiert, kann jeder Quell-Hersteller jeden Ziel-Hersteller adressieren — ohne quadratische Explosion paarweiser Übersetzungslogik.
3. Übersetzung: Ausgabe der Ziel-Hersteller-Syntax
Übersetzung ist IR → Ziel. Der Emitter pro Hersteller kennt die Syntax, die Object-Naming-Constraints und die Policy-Evaluations-Reihenfolge der Zielplattform.
Es gibt zwei Klassen. Verlustfreie Übersetzungen erhalten jedes IR-Feld exakt. Die meisten Regelwerk-Migrationen sind verlustfrei, wenn Quelle und Ziel beide Zonen, Adress-Objekte und Service-Objekte unterstützen. Verlustbehaftete Übersetzungen lassen Felder fallen oder erzwingen sie, wenn die Zielplattform sie nicht abbildet. FwMigrate markiert jede verlustbehaftete Übersetzung explizit, statt Daten still zu verwerfen.
NAT-Regeln, anwendungsbezogene Filterung und identitätsbasierte Policies sind die häufigsten Quellen verlustbehafteter Übersetzungen. Der Emitter speichert die ursprüngliche IR neben der erzeugten Zielregel, sodass ein menschlicher Reviewer beides sieht.
4. Regelweise Validierung und der Risiko-Diff
Nach der Ausgabe validiert FwMigrate die Migration entlang dreier Achsen. Äquivalenz: Trifft die Zielregel denselben Traffic wie die Quelle? Abdeckung: Deckt die Vereinigung der Zielregeln jeden Flow ab, den die Quelle erlaubt hat? Drift: Tauchen neue Schatten oder Konflikte im Ziel-Regelwerk auf, die in der Quelle nicht existierten?
Äquivalenz wird per Traffic-Simulation geprüft: Ein repräsentatives Set synthetischer Pakete wird gegen Quell- und Ziel-Regelwerk evaluiert, die Verdikte werden verglichen. Abdeckung nutzt mengenbasierte Analyse auf Flow-Tupeln. Drift-Erkennung lässt die Regel-Analyse-Engine von FwChange gegen das Ziel-Regelwerk laufen.
Das Ergebnis ist der Risiko-Diff: ein Bericht pro Regel mit Äquivalenz-Verdikt, Abdeckungs-Delta und allen neuen Schatten oder Konflikten durch die Übersetzung. Reviewer sehen den vollständigen Diff, bevor eine Änderung eine Live-Firewall berührt.
5. Was zur menschlichen Prüfung markiert wird
FwMigrate verwirft keine Regeln still. Folgende Fälle landen immer auf dem Review-Tisch:
- Verlustbehaftete Übersetzungen, bei denen die Zielplattform ein Quellfeature nicht abbildet
- Regeln mit Identitäts- oder Anwendungs-Kriterien, wenn dem Ziel diese Primitive fehlen
- Schattenregeln, die nur in der Quelle existieren und in der Ziel-Auswertereihenfolge unerreichbar wären
- Object-Name-Kollisionen bei abweichenden Naming-Konventionen zwischen Quelle und Ziel
- Regeln mit unsicherem Äquivalenz-Verdikt (z. B. wenn die Quellaktion von noch nicht ingestiertem URL-Filtering abhängt)
Das ist Absicht. Zu tun, als ob jede Konfiguration sauber übersetzt, ist genau das, was 02:00-Dienstags-Ausfälle erzeugt.
6. Deployment, Scope und was FwMigrate nicht tut
FwMigrate wird als Docker-Image ausgeliefert. On-Premise-Deployment ist Default — Konfigurationen verlassen die Umgebung nie. Eine gehostete Version existiert für Evaluierung und kleine Projekte.
FwMigrate produziert export-fertige Konfigurationspakete. Es pusht keine Konfigurationen auf Live-Firewalls. Diese bewusste Trennung lässt Sie das Change-Window kontrollieren. Kombinieren Sie FwMigrate mit FwChange, wenn fortlaufendes Change-Management auf der neuen Plattform erforderlich ist.
Noch nicht unterstützte Hersteller (Sophos, SonicWall, Hillstone u. a.) stehen im Entwicklungs-Backlog. Die IR ist stabil genug, dass ein neuer Hersteller-Parser plus Emitter typischerweise zwei bis drei Wochen pro Plattform dauert.