FwChange

Enterprise-Firewall-Änderungsmanagement, nachweisbar gemacht

Erstellt von Rogue AI · Firewall-Änderungsmanagement mit nachvollziehbarem Audit-Trail · Selbst gehostet

Allein über eine längere Reihe von Iterationen entwickelt; läuft als selbst gehostete Laborumgebung und Portfolio-Demo.

FwChange — Enterprise-Firewall-Änderungsmanagement, nachweisbar gemacht

Das Problem

Firewall-Änderungen sind der Ort, an dem Ausfälle und Audit-Befunde entstehen. In den meisten Teams besteht der tatsächliche Ablauf aus einem Ticket, einem Slack-Thread und jemandem, der ein Gerät von Hand bearbeitet — wobei die Begründung, die Genehmigung und der Vorher-/Nachher-Zustand über drei Systeme verstreut oder ganz verloren sind. Wenn ein Prüfer oder eine Vorfallsanalyse später fragt, wer eine Regel gegen welche Richtlinie genehmigt hat und ob sie mit dem Bestehenden in Konflikt steht, muss die Antwort meist aus dem Gedächtnis rekonstruiert werden. FwChange existiert, um diesen Ablauf strukturiert und den Nachweispfad von vornherein rekonstruierbar zu machen.

Was ich gebaut habe

Eine Next.js-16-Anwendung mit PostgreSQL und Redis im Unterbau und NextAuth 5 für die Authentifizierung. Jede Änderung beginnt als strukturierter Antrag statt als Freitext, durchläuft eine mehrstufige Genehmigungskette und wird als unveränderlicher Audit-Eintrag festgehalten. Eine Regelanalyse-Engine prüft vorgeschlagene Änderungen vor der Genehmigung auf Konflikte, und Geräte-Treiber kapseln die herstellerspezifischen Unterschiede hinter einer Schnittstelle. Anmeldedaten der Geräte werden mit AES-256-GCM verschlüsselt gespeichert, die Datenbank läuft unter einem Benutzer mit minimalen Rechten, und der gesamte Stack wird als gehärtete, netzwerkisolierte Docker-Container bereitgestellt, die nur an localhost gebunden sind.

Architektur

Strukturierte Änderungsanträge

Eine Änderung ist ein typisierter Datensatz — Zielgerät, Regelabsicht, Begründung, gewünschtes Zeitfenster — kein Absatz in einem Ticket. Das macht alles Nachgelagerte (Analyse, Genehmigung, Audit) maschinenlesbar, statt Prosa, die später jemand auslegen muss.

Mehrstufige Genehmigungsketten

Anträge durchlaufen Genehmigungsstufen je nach Priorität, mit automatischer Eskalation, wenn ein Schritt sein SLA überschreitet. Die Kette wird mit dem Antrag festgehalten, sodass die Frage 'wer hat wann freigegeben' eine einzige Antwort hat statt einer Suche über Postfächer hinweg.

Geplante Änderungsfenster

Genehmigte Änderungen lassen sich an ein Wartungsfenster binden, statt in dem Moment ausgeführt zu werden, in dem sie die Prüfung passieren — so bleiben riskante Arbeiten innerhalb vereinbarter Ausfallzeiten und außerhalb der Geschäftszeiten, was in den abgebildeten Umgebungen meist zwingend ist.

Risiko- & Konfliktanalyse

Eine Analyse-Engine bewertet eine vorgeschlagene Regel gegen die bestehende Richtlinie auf Verdeckung (eine breitere Regel verschluckt sie bereits), Redundanz und zu freizügige Bereiche wie 'any' als Quelle oder Ziel. Sie erzeugt Markierungen und einen Risikohinweis für den Prüfer — eine Triage-Schicht, bewusst kein Auto-Genehmigungs-Gate.

Netzwerkkontext: IPAM / NetBox

Regeln lesen sich mit Kontext besser, daher reichert das System die Analyse mit IPAM-/NetBox-Quelldaten an — aus einem rohen Subnetz wird ein benanntes Segment mit bekanntem Eigentümer, was einen Prüfer beurteilen lässt, ob eine Änderung tatsächlich sinnvoll ist, statt nur, ob sie syntaktisch passt.

Multi-Vendor-Treiber-Registry

Eine Registry ordnet jeden Hersteller — Palo Alto, Fortinet, Check Point, Cisco, F5 und über 33 weitere — einem Treiber hinter einer gemeinsamen Schnittstelle zu, sodass Workflow- und Analyseebenen herstellerunabhängig bleiben. Ehrlicher Vorbehalt: einige wenige Treiber werden gegen echte Konfigurationen geprüft; der Rest sind schnittstellenvollständige Gerüste, und die Oberfläche sagt, was was ist.

Tech-Stack

Next.js 16Prisma 7PostgreSQLRedis 7NextAuth 5

Was zuerst gebrochen ist

▸
Ein Änderungsmanagement-Werkzeug gewinnt Vertrauen durch seinen Nachweispfad, nicht durch seine Automatisierung. Der Wert liegt darin, Monate später beantworten zu können, 'wer dies wann gegen welches Regelwerk und warum genehmigt hat' — deshalb mussten der strukturierte Antrag, die Genehmigungskette und das Audit-Protokoll wasserdicht sein, bevor irgendeine Push-auf-das-Gerät-Funktion überhaupt eine Rolle spielte.
▸
Multi-Vendor-Unterstützung bedeutet vor allem, einzugestehen, wie unterschiedlich die Geräte sind. Ein Registry-Muster mit einer Treiber-Schnittstelle pro Hersteller hält die Analyse- und Workflow-Ebenen herstellerunabhängig, doch die ehrliche Realität ist: eine Handvoll Treiber wird gegen echte Konfigurationen geprüft, der Rest ist Gerüst — daher macht die Oberfläche explizit, was was ist, statt eine einheitliche Abdeckung vorzutäuschen.
▸
Risiko- und Konfliktanalyse ist eine Triage-Hilfe, kein Urteil. Heuristiken, die verdeckte Regeln, Redundanz und zu freizügige 'any'-Bereiche markieren, fangen die offensichtlichen Fehler ab, die ein müder Prüfer übersieht, aber sie liefern Kandidaten zur menschlichen Beurteilung — sie ersetzen nicht, und sollen nicht ersetzen, dass ein Firewall-Ingenieur die Änderung freigibt.

Ergebnis

Das Ergebnis ist eine funktionierende Referenzimplementierung für nachweisbares Firewall-Änderungsmanagement: jede Änderung ist ein strukturierter, genehmigter, auditierter Datensatz, und Compliance-Nachweise lassen sich gegen die Rahmenwerke exportieren, denen diese Umgebungen tatsächlich gerecht werden müssen — NIS2, ISO 27001, PCI-DSS, DORA und KRITIS — statt zur Audit-Zeit von Hand zusammengetragen zu werden. Heute läuft es selbst gehostet als Labor- und Portfolio-Demo, und es ist ehrlich über seine Grenzen: ungleichmäßige Hersteller-Tiefe und eine Analyse, die einen menschlichen Prüfer informiert, statt ihn zu ersetzen. Als Demonstration, wie man Sicherheits-Änderungsmanagement von Grund auf auditierbar macht, erfüllt es seinen Zweck.

Ehrliche Grenzen

Dies ist ein selbst gehostetes Firewall-Änderungsmanagement-System, allein entwickelt, das als lokale Laborumgebung und Portfolio-Demo läuft — die frühere VPS-Bereitstellung wurde stillgelegt, es arbeitet heute also nicht gegen eine echte Produktionsflotte. Die Risiko- und Konfliktheuristiken markieren Kandidaten für die menschliche Prüfung; sie sind Entscheidungsunterstützung, kein automatischer Genehmiger, und sie ersetzen nicht das Urteil eines Firewall-Ingenieurs. Die Hersteller-Abdeckung ist ungleichmäßig: einige Treiber sind gegen echte Gerätekonfigurationen getestet, der Rest sind schnittstellenvollständige Gerüste. Verstehen Sie es als funktionierende Referenzimplementierung des Workflows, nicht als gehärtetes kommerzielles Produkt.