Best Practices
Warum Excel-Tabellen bei der Firewall-Nachverfolgung jedes Audit nicht bestehen
Irgendwo in Ihrem Unternehmen liegt gerade in diesem Moment eine gemeinsam genutzte Excel-Datei mit einem Namen wie FW_Changes_2026_v3_FINAL_updated.xlsx. Sie liegt auf einem Netzlaufwerk, vielleicht in SharePoint, vielleicht auch auf einem einzelnen Laptop. Sie hat 47 Spalten, farblich markierte Zeilen, die nur eine einzige Person versteht, und eine „Notizen“-Spalte voller Einträge wie „Notfall – wird später dokumentiert“. Das „Später“ kam nie.
Wenn Ihnen das bekannt vorkommt, sind Sie damit nicht allein. Nach 17 Jahren des Aufbaus und Betriebs von Firewalls in Unternehmensumgebungen – Palo Alto, Cisco ASA, Fortinet, Check Point – zeigt sich dasselbe Muster in nahezu jeder Organisation, die nicht in dedizierte Werkzeuge für das Änderungsmanagement investiert hat. Die Firewall-Hardware kostet einen sechsstelligen Betrag. Die Regeln, die sie steuern, werden in einer Tabelle nachgehalten, bei deren Anblick jeder Auditor weinen würde.
Dieser Artikel zeigt genau auf, warum die tabellenbasierte Nachverfolgung von Firewall-Änderungen scheitert, was passiert, wenn es so weit ist, und wie ein ordentlicher Audit-Trail tatsächlich aussieht.
Die Realität aus Tabellen und E-Mails
So funktioniert die Nachverfolgung von Firewall-Änderungen in den meisten mittelständischen Unternehmen tatsächlich. Jemand – ein Netzwerkingenieur, ein Entwickler, ein Helpdesk-Mitarbeiter – braucht eine geänderte Firewall-Regel. Diese Person schreibt eine E-Mail. Mal geht sie an einen Verteiler, mal direkt an den Firewall-Administrator, mal an einen Vorgesetzten, der keine Ahnung hat, was ein Source-NAT ist, die Änderung aber „freigeben“ muss.
Der Firewall-Administrator liest die E-Mail, nimmt die Änderung an der Firewall vor und – sofern er daran denkt – öffnet die gemeinsame Excel-Datei und fügt eine Zeile hinzu. Diese Zeile enthält vielleicht das Datum, die Regelnummer und eine vage Beschreibung wie „Port 443 für Dienstleister geöffnet“. Welcher Dienstleister? Welche Quell-IP? Was war die geschäftliche Begründung? Wann läuft die Regel ab? Diese Spalten hat niemand ausgefüllt.
Wie die Nachverfolgung per Tabelle typischerweise aussieht
- Mehrere Versionen: Es existieren drei Kopien der „Master“-Tabelle. Niemand weiß, welche aktuell ist. Wenn zwei Personen gleichzeitig bearbeiten, überschreibt eine Version stillschweigend die andere.
- Freigaben per E-Mail: Die Freigabe steckt im Postfach von irgendjemandem. Sechs Monate später hat diese Person das Unternehmen verlassen. Die E-Mail ist weg. Die Freigabe ist weg.
- Keine Zeitstempel: In der Tabelle steht, die Änderung sei im „März“ erfolgt. Nicht am 3. März um 14:22 UTC. Einfach nur im März. Vielleicht.
- Verlorener Kontext: Die Regel lautet „allow any to 10.0.5.0/24 on TCP 3389“. Warum muss RDP von jeder beliebigen Quelle aus für ein ganzes Subnetz offen sein? Die Person, die das angefordert hat, ist vor zwei Jahren gegangen.
- Lücken im Notfall: Während eines Vorfalls um 2 Uhr nachts wurden drei Regeln hinzugefügt, um die Produktion wiederherzustellen. Niemand hat sie protokolliert. 18 Monate später sind sie immer noch da – weit offen.
Das ist kein Versagen einzelner Personen. Der Firewall-Administrator, der um 3 Uhr nachts während eines Produktionsausfalls vergessen hat, die Tabelle zu aktualisieren, hat das Richtige getan – er hat das Problem behoben. Das Versagen ist systembedingt. Sie können ein auditfähiges Änderungsmanagement nicht nachträglich auf E-Mail-Verläufe und Excel-Dateien aufpfropfen. Es skaliert nicht, es übersteht keine Personalwechsel, und es hält keiner genaueren Prüfung stand.
Was schiefgeht: reale Szenarien
Das Tabellenproblem ist nicht theoretisch. Dies sind Situationen, die sich in Organisationen jeder Größe wiederholen.
Szenario 1: „Wer hat Regel 847 geändert?“
Der Auditor klappt seinen Laptop auf und bittet um die Änderungshistorie einer bestimmten Firewall-Regel, die eingehenden Zugriff auf die Datenbankebene erlaubt. Sie sehen in der Tabelle nach. Für Regel 847 gibt es keinen Eintrag. Sie prüfen die Firewall-Protokolle. Die Regel wurde zuletzt vor 14 Monaten geändert, aber das Commit-Log zeigt lediglich das Admin-Konto – keine Zuordnung zu einer einzelnen Person, kein Ticketverweis, keine geschäftliche Begründung. Sie sehen in den E-Mails nach. Nichts. Der Auditor notiert eine Beanstandung.
Szenario 2: Der Notfall um 2 Uhr nachts
Sie bekommen um 2 Uhr nachts einen Anruf. Die Produktion ist ausgefallen. Der Load Balancer erreicht die Backend-Server nicht. Sie verbinden sich per SSH mit der Firewall und finden das Problem – eine Regel, die letzte Woche bei einer „Bereinigung“ verschärft wurde, blockiert nun den Health-Check-Verkehr. Sie fügen eine temporäre Permit-Regel hinzu, stellen den Dienst wieder her und legen sich wieder schlafen. Am nächsten Morgen nehmen Sie sich vor, das zu dokumentieren. Aber es warten 40 E-Mails, und morgen beginnt ein Change-Freeze. Aus der temporären Regel wird eine dauerhafte. Drei Monate später meldet ein Penetrationstester sie als überberechtigte Regel, die breiten Zugriff auf die Backend-Infrastruktur erlaubt. Niemand erinnert sich, warum sie existiert.
Szenario 3: Die Vendor-Migration ohne Baseline
Ihr Unternehmen migriert von Cisco ASA auf Palo Alto. Das Migrationsteam bittet um die aktuelle Regel-Baseline – nicht nur darum, was jetzt auf der Firewall liegt, sondern darum, was jede Regel eigentlich tun soll, wem sie gehört und ob sie noch benötigt wird. Sie öffnen die Tabelle. Sie hat 2.300 Zeilen. Die Hälfte ist gelb hinterlegt, ohne Legende. 200 Zeilen verweisen auf Ticketnummern aus einem Ticketsystem, das Sie 2024 stillgelegt haben. Das Migrationsteam verbringt sechs Wochen damit, jede Regel manuell zu überprüfen, weil es keine verlässliche Dokumentation gibt, mit der man arbeiten könnte.
Szenario 4: Die veraltete Zugriffsregel
Ein externer Mitarbeiter erhielt VPN-Zugang und eine Firewall-Regel, um die Entwicklungsumgebung zu erreichen. Das Projekt endete vor acht Monaten. Das VPN-Konto des externen Mitarbeiters wurde von der Personalabteilung deaktiviert. Aber niemand hat das Firewall-Team informiert, und in der Tabelle verfolgt niemand das Ablaufdatum von Regeln. Die Regel ist immer noch da und lässt den Quell-IP-Bereich des externen Mitarbeiters in das Entwicklungs-Subnetz. Wird dieser IP-Bereich neu zugewiesen oder kompromittiert, ist der Weg offen.
Warum Tabellen jedes Audit nicht bestehen
Compliance-Frameworks interessiert es nicht, wie Sie Firewall-Änderungen intern nachverfolgen. Sie interessieren sich für Nachweise. Und Tabellen liefern Nachweise, die unzuverlässig, unvollständig und trivial zu fälschen sind. Auditoren wissen das.
Was die Standards tatsächlich verlangen
- PCI-DSS 4.0 (Anforderung 1.2.2): Die Konfigurationen von Netzwerksicherheitskontrollen müssen mindestens alle sechs Monate überprüft werden. Jede Änderung muss mit geschäftlicher Begründung dokumentiert, von einer verantwortlichen Stelle autorisiert und getestet werden, um zu bestätigen, dass sie die Sicherheit nicht beeinträchtigt. Eine Tabelle mit „Port 443 für Dienstleister geöffnet“ erfüllt diese Messlatte nicht.
- ISO 27001 (A.8.32 – Änderungsmanagement): Änderungen an informationsverarbeitenden Einrichtungen und Systemen müssen einem Änderungsmanagementverfahren unterliegen. Der Standard verlangt formale Änderungsanträge, Auswirkungsbewertungen, Freigabenachweise und eine Verifizierung der Umsetzung. Ein E-Mail-Verlauf zwischen zwei Ingenieuren ist kein formaler Änderungsantrag.
- NIS2 (Artikel 21): Wesentliche und wichtige Einrichtungen müssen Richtlinien zum Änderungsmanagement umsetzen, einschließlich dokumentierter Verfahren für Konfigurationsänderungen an Netz- und Informationssystemen. Die Mitgliedstaaten können bei Nichteinhaltung Bußgelder von bis zu 10 Millionen EUR oder 2 % des weltweiten Umsatzes verhängen.
- TISAX (VDA ISA 5.2.6): Automobilzulieferer müssen ein kontrolliertes Änderungsmanagement für alle IT-Systeme nachweisen. Auditoren verlangen ausdrücklich Einsicht in die Freigabekette und die Rollback-Verfahren für Infrastrukturänderungen.
- DORA (Artikel 9): Finanzunternehmen müssen vollständige, korrekte Aufzeichnungen über alle IKT-Änderungen führen, einschließlich Änderungen an der Netzwerksicherheit. Jede Änderung muss auf einen autorisierten Antrag mit dokumentierter Risikobewertung zurückführbar sein.
Der rote Faden, der sich durch jedes Framework zieht, ist derselbe: Sie benötigen einen dokumentierten Prozess mit formalen Anträgen, autorisierten Freigaben, Umsetzungsnachweisen und Verifizierungsschritten. Tabellen scheitern, weil sie nichts davon zuverlässig belegen können. Es gibt keinen manipulationssicheren Zeitstempel. Es gibt keine garantierte Verbindung zwischen der Freigabe und der Umsetzung. Es gibt keinen automatischen Nachweis, dass die Änderung tatsächlich so vorgenommen wurde wie dokumentiert. Ein Auditor, der eine Tabellenzeile betrachtet, muss Ihnen aufs Wort glauben – und Auditoren werden dafür bezahlt, Ihnen nicht aufs Wort zu glauben.
Die häufigsten Audit-Beanstandungen im Zusammenhang mit tabellenbasierter Nachverfolgung sind:
- Änderungen an der Firewall, die im Änderungsprotokoll nicht auftauchen
- Einträge im Änderungsprotokoll ohne zugehörigen Freigabenachweis
- Fehlende geschäftliche Begründung für freizügige Regeln
- Kein Nachweis einer regelmäßigen Überprüfung oder Rezertifizierung
- Unfähigkeit, eine vollständige Änderungshistorie für eine bestimmte Regel vorzulegen
- Keine Rollback-Dokumentation für fehlgeschlagene Änderungen
Jeder einzelne dieser Punkte ist eine Beanstandung. Die meisten Organisationen, die mit Tabellen arbeiten, treffen drei oder mehr davon.
Wie eine ordentliche Firewall-Änderungsverfolgung aussieht
Die Kluft zwischen Tabellenchaos und einem auditfähigen Änderungsmanagement ist keine Frage des Kaufs teurer Software. Es geht darum, ein System zu haben, bei dem der Prozess selbst die Nachweise erzeugt. Wenn der Workflow selbst der Audit-Trail ist, hört die Dokumentation auf, eine lästige Pflicht zu sein, die übersprungen wird, und wird zu einem automatischen Nebenprodukt der eigentlichen Arbeit.
Die fünf Bausteine eines auditfähigen Änderungsmanagements
- 1. Strukturierte Änderungsanträge: Jede Änderung beginnt mit einem formalen Antrag, der erfasst, wer etwas anfordert, was benötigt wird, warum es benötigt wird und wann es ablaufen soll. Keine Freitext-E-Mails. Keine mündlichen Anfragen. Ein definiertes Formular mit Pflichtfeldern, das nicht unvollständig abgeschickt werden kann.
- 2. Freigabe-Workflows mit Zuordnung: Die richtigen Personen geben die Änderung je nach Risikostufe und Umfang frei. Jede Freigabe wird mit Zeitstempel versehen, einer namentlich genannten Person zugeordnet und unveränderlich gespeichert. Ist der Freigebende abwesend, eskaliert der Antrag automatisch – er bleibt nicht zwei Wochen lang im Postfach liegen.
- 3. Automatischer Audit-Trail: Wenn die Änderung auf der Firewall umgesetzt wird, erfasst das System genau, was sich geändert hat – den Zustand der Regel davor und danach, wer sie ausgerollt hat, wann das geschah und auf welchen freigegebenen Antrag sie zurückgeht. Das ist kein Mensch, der nachträglich etwas in eine Tabelle tippt. Es ist das System, das die Änderung erfasst, während sie geschieht. Werkzeuge wie FwChange erzeugen diesen Audit-Trail automatisch über mehrere Vendor-Umgebungen hinweg und verbinden jede Regeländerung mit ihrem ursprünglichen Antrag und ihrer Freigabekette.
- 4. Baseline-Vergleiche und Drift-Erkennung: Ein ordentliches System pflegt eine bekannte, einwandfreie Baseline Ihrer Firewall-Konfiguration. Jede Abweichung von dieser Baseline – sei es durch eine nicht autorisierte manuelle Änderung, ein fehlgeschlagenes Rollback oder eine Notfallregel, die nie bereinigt wurde – wird automatisch markiert. Sie sollten Konfigurationsdrift nicht erst während eines Audits entdecken. Sie sollten sie an dem Tag entdecken, an dem sie auftritt.
- 5. Regelmäßige Überprüfung und Rezertifizierung: Regeln gelten nicht ewig. Ein Zugriff, der vor sechs Monaten gerechtfertigt war, wird heute vielleicht nicht mehr benötigt. Ein ordentliches Änderungsverfolgungssystem plant regelmäßige Überprüfungen, weist sie den jeweiligen Regelverantwortlichen zu und verfolgt, ob jede Regel rezertifiziert, geändert oder entfernt wurde. Wenn der Auditor fragt „Wann wurde diese Regel zuletzt überprüft?“, haben Sie eine durch Nachweise belegte Antwort, keine Vermutung.
Der Unterschied zwischen diesem Ansatz und einer Tabelle liegt nicht in der Komplexität. Er liegt in der Zuverlässigkeit. Eine Tabelle hängt davon ab, dass Menschen jedes einzelne Mal daran denken, sie korrekt zu aktualisieren. Ein ordentliches Änderungsmanagementsystem macht es unmöglich, eine Änderung umzusetzen, ohne die zugehörige Dokumentation zu erzeugen. Der Prozess und der Nachweis sind ein und dasselbe.
Die Kosten des Nichtstuns
Organisationen, die weiterhin auf tabellenbasierte Nachverfolgung setzen, zahlen den Preis typischerweise auf eine von drei Weisen: durch Audit-Beanstandungen, die Zertifizierungen verzögern und Beratungshonorare für die Behebung verursachen, durch Sicherheitsvorfälle, die von undokumentierten Regeln ausgelöst werden, die längst hätten entfernt werden müssen, oder durch Migrationsprojekte, die doppelt so lange dauern, weil niemand weiß, wie der aktuelle Zustand tatsächlich aussieht.
Die Ironie ist, dass die Lösung nicht schwierig ist. Der schwierige Teil ist nicht die Technik – es ist das Aufbrechen der Gewohnheit, Firewall-Änderungen als informelle Anfragen unter Kollegen zu behandeln statt als kontrollierte Eingriffe in eine kritische Sicherheitsinfrastruktur. Sobald Sie akzeptieren, dass jede Firewall-Regeländerung dieselbe Sorgfalt verdient wie ein Code-Deployment – einen Antrag, eine Überprüfung, eine Freigabe, einen Nachweis –, ist das Werkzeug zur Unterstützung dieses Workflows unkompliziert.
Beginnen Sie mit Sichtbarkeit
Wenn Ihre Organisation noch auf Tabellen und E-Mail-Verläufen läuft, besteht der erste Schritt nicht im Kauf von Software. Der erste Schritt besteht darin, Ihren aktuellen Zustand zu verstehen. Wie viele Regeln haben Sie? Wie viele sind tatsächlich in Gebrauch? Wie viele haben keine geschäftliche Begründung, keinen Verantwortlichen und kein Ablaufdatum?
Die meisten Teams sind von der Antwort überrascht. Ein durchschnittliches Unternehmens-Regelwerk enthält 40 bis 50 % Regeln, die ungenutzt, redundant oder von anderen Regeln verdeckt sind. Das ist kein Tabellenproblem – das ist ein Sichtbarkeitsproblem. Und es ist der Grund, warum Auditoren immer wieder Fragen stellen, die Sie nicht beantworten können.
Sehen Sie, was Ihre Tabelle übersieht
Der kostenlose Firewall-Regel-Scanner von FwChange analysiert Ihr Regelwerk auf Schattenregeln, Redundanzen, überberechtigte Richtlinien und Compliance-Lücken – genau die Punkte, die eine tabellenbasierte Nachverfolgung nicht erfassen kann. Keine Installation erforderlich. Laden Sie einen bereinigten Konfigurationsexport hoch und erhalten Sie in wenigen Minuten Ergebnisse.
Kostenlosen NIS2-Readiness-Check durchführen →
