Firewall-Regelbereinigung: Ungenutzte Policies finden und auditieren

Ein Firewall-Policy-Audit ist der Prozess, mit Belegen nachzuweisen, dass jede Regel der Firewall noch eine geschäftliche Begründung hat, tatsächlich Verkehr sieht und nicht von einer anderen Regel verdeckt wird. Die Regelbereinigung ist das Ergebnis dieses Audits: Ungenutzte, redundante und zu weit gefasste Policies werden kontrolliert eingegrenzt oder entfernt. Das Resultat sind eine kleinere Angriffsfläche, ein lesbares Regelwerk und eine Nachweisakte für den Prüfer.

Was ist Firewall-Regelbereinigung und warum wird sie unvermeidlich?

Firewall-Regelbereinigung bedeutet, die Firewall-Policies zu inventarisieren, jene zu identifizieren, die keinen Verkehr sehen, im Geltungsbereich einer anderen Regel liegen oder ihre Begründung verloren haben, und sie anschließend zu entfernen oder einzugrenzen. Ein Regelwerk ist ein lebendes Dokument; weil niemand zu löschen wagt, wächst es nur, und mit ihm steigen Risiko und Betriebskosten.

Regelwerke wachsen nicht wegen schlechter Administration, sondern wegen der Natur des Geschäfts. Eine neue Anwendung geht in Betrieb, ein Server zieht um, ein Lieferant erhält zwei Wochen Zugang, bei der Fehlersuche wird eine „vorübergehende“ Freigabe eingetragen. Das Projekt endet, der Server wird abgeschaltet, der Lieferant geht; die Regel bleibt. Beim Austausch einer alten Appliance werden Regeln meist eins zu eins übernommen, weil niemand weiß, welche noch gebraucht werden. Nach einigen Jahren steht der Administrator vor einer Policy-Liste mit mehreren hundert Zeilen, und selbst der erfahrenste Ingenieur kann die Frage „was bricht, wenn ich das lösche?“ nicht sicher beantworten.

Diese Anhäufung hat drei Kosten. Erstens Sicherheit: Zu weit gefasste und vergessene Freigaberegeln sind Pfade für laterale Bewegung eines Angreifers, der bereits Fuß gefasst hat. Zweitens Betrieb: Jede Änderung erfordert das Lesen hunderter Regeln, die Fehlersuche dauert länger, und eine am Ende angehängte neue Regel wird mit steigender Wahrscheinlichkeit von einer breiten Regel darüber verdeckt. Drittens Compliance: Fragt der Prüfer „warum existiert diese Regel?“ und es gibt keine Antwort, wird ein Befund geschrieben, egal wie aktuell die Firmware ist.

Dieser Artikel wiederholt nicht die Grundlagen des Policy-Managements; zu Regelsyntax, Objektverwaltung und Sicherheitsprofilen lesen Sie unseren Leitfaden zum FortiGate-Firewall-Policy-Management. Der Fokus liegt hier auf dem Audit eines bestehenden Regelwerks und seiner sicheren Verkleinerung. Der effizienteste Moment für eine Bereinigung ist der Hardwaretausch: Wie in unserem Migrationsplan von einer Alt-Firewall zu FortiGate beschrieben, startet die neue Appliance vom ersten Tag sauber, wenn die Regeln vor der Übernahme auditiert werden.

Wo beginnt das Audit? Regelinventar und geschäftliche Begründung

Ein Firewall-Audit beginnt mit einem vollständigen Regelinventar: Die Policies jeder Appliance und jeder virtuellen Domäne (VDOM) werden exportiert, und jede Regel wird einem Verantwortlichen, einem Zweck und einem Änderungsdatensatz zugeordnet. Eine Regel ohne auffindbare Begründung wird als verdächtig markiert, auch wenn sie technisch funktioniert, und durchläuft eine Rezertifizierung.

Das Inventar beginnt mit einem Konfigurationsbackup. Das datierte Backup zu Beginn des Audits ist zugleich Rücksprungpunkt und erstes Dokument der Nachweisakte. Anschließend wird die Policy-Liste in eine Tabelle exportiert, die pro Zeile mindestens folgende Felder enthält: Policy-ID und Name, Quell- und Zielschnittstellen, Quell- und Zieladressobjekte, Dienste, Aktion, Zeitplan, NAT-Status, zugewiesene Sicherheitsprofile, Logging-Einstellung, Kommentarfeld, Hit Count und Zeitpunkt der letzten Nutzung. Diese Tabelle ist die Arbeitsfläche des Audits; Befunde, Entscheidungen und Termine werden an derselben Stelle festgehalten.

Schwieriger als die technischen Felder ist der geschäftliche Kontext. An jede Regel werden drei Fragen gestellt: Wer hat sie beantragt? Welcher Geschäftsprozess braucht sie? Wann wird sie überflüssig? Die Antworten sucht man im Kommentarfeld, in Änderungsdatensätzen oder im Ticketsystem. Auf einer FortiGate genügen Policy-Name und Kommentarfeld, um Ticketnummer und verantwortliche Abteilung zu tragen; nach dem Audit sollte ein Namensstandard verabschiedet werden, der diese Felder verpflichtend macht. Die NIST-Publikation SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, empfiehlt ein Regelwerk nach dem Prinzip „standardmäßig verweigern“, in dem jede Regel so eng wie möglich formuliert und dokumentiert ist; die Inventartabelle ist das unternehmensinterne Gegenstück zu dieser Dokumentation.

Für Regeln mit bekanntem Verantwortlichen wird eine Rezertifizierungsrunde eröffnet: Die Regelliste geht an den Fachbereich mit einer Frist, „weiterhin erforderlich“ oder „kann entfernt werden“ zu antworten. Regeln ohne Rückmeldung werden automatisch Kandidaten für die Deaktivierung. Dieser Schritt verhindert, dass das technische Team Löschentscheidungen allein trifft, und verlagert die Verantwortung dorthin, wo sie hingehört: zum Fachverantwortlichen. In unserer Projekterfahrung ist dies der längste Schritt eines ersten Audits; in späteren Zyklen verkürzt er sich deutlich, weil das Inventar aktuell gehalten wird.

Wie findet man ungenutzte Policies? Hit Count und Last-Used-Daten

Eine ungenutzte Firewall-Policy ist eine Regel, die während eines definierten Beobachtungsfensters keinen Verkehr getroffen hat. Auf einer FortiGate liefern die Spalten Hit Count und Last Used der Policy-Tabelle sowie in der CLI die Ausgabe von diagnose firewall iprope show 100004 <policy-id> den ersten und letzten Treffer; FortiAnalyzer-Logs bestätigen die Daten auf der Zeitachse.

Der Hit Count ist das stärkste Werkzeug des Audits, wird aber leicht falsch gelesen. Je nach Version und Konfiguration können Zähler nach einem Neustart, einer Regelbearbeitung oder einem manuellen Zurücksetzen (diagnose firewall iprope clear 100004) von vorn beginnen; auch der in der FortiOS-7.2-Dokumentation beschriebene gleitende Sieben-Tage-Zähler verändert den Zeitraum, den der angezeigte Wert abdeckt. Ein Wert von null bedeutet daher nicht automatisch „nie benutzt“. Notieren Sie vor Beginn, seit wann die Zähler laufen, und prüfen Sie das Zählerverhalten Ihrer Firmware in der Fortinet-Dokumentation. Das Beobachtungsfenster folgt dem Rhythmus des Geschäfts: Für routinemäßigen Büroverkehr gelten neunzig Tage als sinnvolles Minimum, während Regeln für seltene Prozesse wie Jahresabschluss, periodische Prüfungen oder Disaster-Recovery-Übungen ein Fenster von sechs bis zwölf Monaten brauchen.

Die zweite Nachweisquelle sind die Logs. Auf dem FortiAnalyzer lassen sich Verkehrslogs nach Policy-ID gruppieren und zu einem Bericht über die Policy-Nutzung pro Zeitraum verdichten; dieser Bericht ist unabhängig von den Gerätezählern und zeigt die Historie auch dann, wenn ein Zähler zurückgesetzt wurde. Unser Artikel zu FortiGate-Logging, Monitoring und FortiAnalyzer-Integration behandelt Log-Infrastruktur und Berichtsgestaltung. Wo der FortiAnalyzer bereits das zentrale Logging übernimmt, wird dieselbe Plattform zur Quelle der Audit-Nachweise.

Wird eine ungenutzte Regel gefunden, folgt ein Weg in vier Schritten. Erstens Klassifizierung: Freigaberegeln und explizite Verweigerungsregeln werden getrennt bewertet; ein explizites Deny ohne Treffer ist oft eine bewusste Policy-Aussage und kann bleiben. Zweitens Deaktivierung: Die Regel wird nicht gelöscht, ihr Status wird auf deaktiviert gesetzt, Datum und Audit-Referenz kommen ins Kommentarfeld. Drittens Quarantäne: Wird innerhalb einer Frist von etwa dreißig Tagen keine Störung gemeldet, ist die Regel löschbereit. Viertens Protokollierung: Die vollständige Definition der gelöschten Regel wird der Nachweisakte hinzugefügt. Während der gesamten Zeit sollte das Logging von Verstößen auf der Implicit-Deny-Policy aktiv sein; es macht echten Verkehr, den eine entfernte Regel blockiert, sofort sichtbar und erleichtert die Rollback-Entscheidung.

Wie erkennt man Shadow-, redundante und widersprüchliche Regeln?

Eine Shadow-Regel wird nie ausgeführt, weil eine weiter gefasste Regel darüber ihren gesamten Verkehr abfängt; eine redundante Regel wiederholt dieselbe Aktion für denselben Verkehr; eine widersprüchliche Regel wendet auf teilweise überlappenden Verkehr eine andere Aktion an. Alle drei zeigen einen Hit Count von null oder niedrig, doch die Ursache ist ein Reihenfolgefehler, und die Lösung ist Neuordnung statt Löschen.

Firewall-Policies werden von oben nach unten ausgewertet, der erste Treffer gewinnt. Diese einfache Regel erzeugt in langen Listen Überraschungen. Beispiel: Erlaubt Regel zwölf alle Dienste vom LAN zu einem Anwendungsserver in der DMZ, läuft die Regel „nur HTTPS“ an Position fünfundzwanzig niemals; der Administrator glaubt, eine enge Policy sei aktiv, das Gerät setzt die breite durch. Gefährlicher ist eine Verweigerungsregel, die Dateifreigaben vom Gastnetz zu einem Server blockieren soll, aber wegen einer breiten Freigabe darüber nie greift. In diesem Fall existiert die im Policy-Dokument beschriebene Sicherheitsmaßnahme in der Praxis nicht.

Zur Erkennung gibt es drei Wege. Unternehmen mit FortiManager können den Policy Consistency Check nutzen, der gegen ein Policy-Paket läuft und doppelte, verdeckte, überlappende sowie ungenutzte (verwaiste) Objekte meldet; prüfen Sie den Funktionsumfang in der Dokumentation Ihrer Version. Unabhängige Plattformen zur Regelanalyse untersuchen Appliances mehrerer Hersteller in einer Konsole und vergeben pro Regel eine Risikobewertung. Bei kleinen Regelwerken reicht es, die Inventartabelle nach Überlappung von Quell- und Zieladressen zu sortieren, damit ein erfahrenes Auge Shadow-Regeln manuell erkennt. Die folgende Tabelle fasst die im Audit anzutreffenden Anomalietypen und die jeweils richtige Maßnahme zusammen.

Wird eine Shadow-Regel gefunden, sollte die erste Frage „welche ist richtig?“ lauten und nicht „soll ich sie löschen?“. Meist drückt die enge Regel im Schatten die eigentliche Absicht aus, und zu entfernen ist die breite Regel darüber. Deshalb wird die Shadow-Analyse zusammen mit der Any-Any-Eingrenzung des nächsten Abschnitts durchgeführt.

Any-Any und zu weit gefasste Regeln: die riskantesten Policies eingrenzen

Eine Any-Any-Regel ist eine Policy, die in mindestens zwei der Felder Quelle, Ziel und Dienst „all“ verwendet und damit die Netzwerksegmentierung faktisch aufhebt. Der sichere Weg zur Entfernung ist nicht das sofortige Löschen, sondern zuerst Logging aktivieren, den echten Verkehr messen, darüber enge Regeln für diesen Verkehr anlegen und die breite Regel stufenweise deaktivieren.

Any-Any-Regeln stammen meist aus drei Quellen: breite Freigaben aus der Erstinstallation nach dem Motto „Hauptsache, es läuft“, bei der Fehlersuche geschriebene und vergessene Regeln sowie historische Policies, die von einer früheren Appliance migriert wurden. Gemeinsam ist ihnen ein hoher Hit Count; deshalb tauchen sie in der Analyse ungenutzter Regeln nie auf und brauchen eine eigene Untersuchung. Ein hoher Hit Count beweist nicht, dass eine Regel notwendig ist, sondern nur, dass sehr viel Verkehr über sie läuft.

Die Eingrenzung erfolgt in sechs Schritten. Erstens: Logging aller Sitzungen auf der breiten Regel aktivieren und Daten über das Beobachtungsfenster sammeln. Zweitens: Aus den Logs ermitteln, welche Kombinationen aus Quelle, Ziel und Dienst tatsächlich genutzt werden. Drittens: Diese Flüsse als enge Regeln über der breiten Regel anlegen und dabei Adress- und Dienstgruppen verwenden. Viertens: Internetgerichteten Regeln Profile für IPS, Antivirus, Webfilter und Anwendungskontrolle zuweisen; auf der breiten Regel fehlen diese Profile häufig. Fünftens: Beobachten, wie der Hit Count der breiten Regel gegen null fällt; tut er das nicht, wurde ein Fluss übersehen. Sechstens: Sobald der Hit Count null erreicht, die breite Regel deaktivieren, die Quarantänefrist abwarten und löschen.

Derselbe Ansatz gilt für den Verwaltungszugang: Der administrative Zugriff über die WAN-Schnittstelle wird geschlossen, Verwaltung ist nur von vertrauenswürdigen Quelladressen und, wo möglich, aus einem eigenen Managementnetz erlaubt. Diese Schritte sind hardwareunabhängig; jedes Modell der FortiGate-Familie teilt dieselbe Policy-Logik und dieselben Zähler, sodass die auf einer kleinen Filial-Appliance etablierte Audit-Disziplin unverändert auf das Zentralgerät übertragbar ist.

Change-Management und Audit-Nachweis: Wie bleibt die Bereinigung dauerhaft?

Die Bereinigung bleibt dauerhaft, wenn jede neue Regel mit genehmigtem Antrag, Verantwortlichem, Zweck und Ablaufdatum angelegt wird. Change-Management verlangt Konfigurationsbackups vor und nach der Änderung, einen Genehmigungsnachweis und einen Rollback-Plan; der Audit-Nachweis besteht aus datiertem Inventar, Hit-Count-Bericht, Liste entfernter Regeln und Rezertifizierungskorrespondenz.

Es kommt häufig vor, dass ein bereinigtes Regelwerk innerhalb von sechs Monaten in den alten Zustand zurückfällt; die Ursache ist ein fehlender Änderungsprozess. Der Mindestprozess lautet: Der Antrag geht mit schriftlicher geschäftlicher Begründung ins Ticketsystem; das technische Team prüft, dass die neue Regel bestehende Regeln weder verdeckt noch dupliziert; die Genehmigung wird eingeholt; die Änderung erfolgt im Wartungsfenster; Konfigurationsbackups vor und nach der Änderung werden aufbewahrt; das Ergebnis wird geprüft und das Ticket geschlossen. Für temporäre Zugänge werden FortiGate-Zeitplanobjekte verwendet; ein befristeter Zeitplan lässt eine Lieferantenregel von selbst auslaufen und trocknet die Klasse „vergessene temporäre Regel“ an der Quelle aus. Unternehmen mit FortiManager können über die Revisionshistorie der Konfiguration nachvollziehen, wer wann was geändert hat, und Unterschiede zwischen Revisionen vergleichen.

Die Nachweisakte beantwortet die Frage des Prüfers oder Kunden „überprüfen Sie Ihr Regelwerk?“ mit Dokumenten. Sie enthält: Beginn und Ende des Audits, datierte Konfigurationsbackups, die Regelinventartabelle, den Hit-Count- und Policy-Nutzungsbericht, die Anomalieliste mit der jeweils getroffenen Entscheidung, die vollständigen Definitionen entfernter und eingegrenzter Regeln, die Rezertifizierungsantworten der Fachverantwortlichen und die Change-Tickets. Dieselbe Akte ist der Ausgangspunkt des nächsten Audits.

Compliance-Rahmenwerke machen diesen Zyklus verpflichtend. Anforderung 1.2.7 von PCI DSS v4.0 verlangt, die Konfigurationen der Netzwerksicherheitskontrollen mindestens alle sechs Monate zu überprüfen. In der Türkei zählt der Leitfaden zur Sicherheit personenbezogener Daten (technische und organisatorische Maßnahmen) der Datenschutzbehörde KVKK Firewalls und die Verwaltung von Zugriffsrechten zu den technischen Maßnahmen; die Firewall-Seite dieser Maßnahmen behandeln wir in unserer Checkliste zu den technischen KVKK-Maßnahmen. Zu den Aufbewahrungspflichten für Verkehrs- und Ereignislogs lesen Sie unseren Artikel über das Gesetz Nr. 5651 und zentrales Log-Management; in beiden Bereichen empfehlen wir, die aktuelle Gesetzgebung und die offiziellen Leitfäden zu verifizieren. Kann das interne Team für diesen Zyklus keine Zeit aufbringen, gehören periodische Policy-Audits zum Standardumfang eines Managed-Firewall-Services.

Checkliste für das Firewall-Policy-Audit

Die Checkliste für das Firewall-Policy-Audit dient dazu, ein Audit von Anfang bis Ende durchzuführen und sein Ergebnis mit Nachweisen zu dokumentieren. Jede Zeile beantwortet eine einzige Frage mit Ja oder Nein und benennt den Nachweis, der in die Akte kommt; die Liste wird mindestens alle sechs Monate wiederholt, in Umgebungen mit vielen Änderungen vierteljährlich.

Statt die Liste in eine Punktzahl zu verwandeln, empfehlen wir, jedes „Nein“ in eine Maßnahme zu übersetzen. Viele „Nein“-Antworten im ersten Audit sind normal; Ziel ist, dass die Zahl im zweiten Zyklus sinkt und das Audit im dritten zur Routinewartung wird. In unseren Projekten kommen die schnellsten Gewinne aus einem Kommentarfeld-Standard und befristeten Zeitplänen: Diese beiden Gewohnheiten bremsen deutlich, wie schnell ein Regelwerk wieder verschmutzt.

Häufig gestellte Fragen

Wie oft sollte eine Firewall-Regelbereinigung durchgeführt werden?

Anforderung 1.2.7 von PCI DSS v4.0 verlangt, die Konfigurationen der Netzwerksicherheitskontrollen mindestens alle sechs Monate zu überprüfen. In Umgebungen mit vielen Änderungen ist ein Quartalsrhythmus sinnvoller; nach einer großen Migration oder einem Netzumbau sollte ein außerplanmäßiges Audit erfolgen.

Ist es sicher, eine Regel mit Hit Count null sofort zu löschen?

Nein. Zähler können durch einen Neustart oder eine Regelbearbeitung zurückgesetzt worden sein, und jährliche Prozesse liegen möglicherweise außerhalb des Beobachtungsfensters. Prüfen Sie zuerst, seit wann die Zähler laufen, deaktivieren Sie die Regel, warten Sie die Quarantänefrist ab und löschen Sie sie dann dokumentiert.

Was unterscheidet eine Shadow-Regel von einer redundanten Regel?

Eine Shadow-Regel greift nie, weil eine weiter gefasste Regel darüber ihren gesamten Verkehr abfängt; die beabsichtigte Policy wird stillschweigend nicht durchgesetzt. Eine redundante Regel wiederholt dieselbe Aktion für denselben Verkehr; sie schadet funktional nicht, bläht aber das Regelwerk auf und erschwert die Pflege.

Wie finde ich ungenutzte Policies auf einer FortiGate?

Blenden Sie in der Policy-Tabelle die Spalten Hit Count und Last Used ein und filtern Sie nach null oder veralteten Werten. In der CLI liefert diagnose firewall iprope show 100004 pro Policy den ersten und letzten Treffer; ein FortiAnalyzer-Bericht zur Policy-Nutzung bestätigt den Befund aus den Logs.

Fallen Geschäftsanwendungen aus, wenn wir die Any-Any-Regel entfernen?

Nicht bei richtiger Reihenfolge. Aktivieren Sie zuerst das Logging aller Sitzungen auf der breiten Regel, messen Sie den echten Verkehr über das Beobachtungsfenster, legen Sie darüber spezifische Regeln für diesen Verkehr an und warten Sie, bis der Hit Count der breiten Regel auf null fällt. Erst dann deaktivieren Sie sie.

Gilt ein Firewall-Policy-Audit als Nachweis für PCI DSS oder Datenschutz?

Der Nachweis ist das Ergebnis, nicht die Tätigkeit: datiertes Regelinventar, Hit-Count-Bericht, Liste entfernter und eingegrenzter Regeln, Rezertifizierungsantworten der Verantwortlichen und Change-Tickets. Diese Akte belegt die von PCI DSS geforderte regelmäßige Überprüfung und die dokumentierte Zugriffskontrolle, die Datenschutzleitfäden erwarten.

Ist es sinnvoll, die Regelbereinigung auszulagern?

Ja, wenn das interne Team vom Tagesbetrieb ausgelastet ist; periodische Policy-Audits gehören zum Umfang der meisten Managed-Firewall-Services. Entscheidend ist, dass Löschentscheidungen gemeinsam mit den Fachverantwortlichen getroffen und alle Schritte protokolliert werden: Das externe Team analysiert und setzt um, das Unternehmen genehmigt.

Fazit

Firewall-Regelbereinigung macht die Appliance nicht leistungsfähiger; sie sorgt dafür, dass die Appliance die Policy durchsetzt, die Sie tatsächlich geschrieben haben. Ein Audit-Zyklus, der mit Inventar und geschäftlicher Begründung beginnt, ungenutzte Regeln über Hit Counts und Logs aussortiert, Shadow- und Any-Any-Regeln neu ordnet und jeden Schritt mit Nachweisen dokumentiert, verkleinert die Angriffsfläche und erzeugt zugleich eine belastbare Akte für PCI-DSS- und Datenschutzprüfungen. Das Geheimnis der Dauerhaftigkeit ist prozessual, nicht technisch: Keine Regel wird ohne genehmigten Antrag, Verantwortlichen, Zweck und Ablaufdatum angelegt.

Um ein erstes Audit Ihres Regelwerks zu planen, Ihre aktuelle FortiGate-Konfiguration zu überprüfen oder periodische Audits in einen Managed Service zu überführen, können Sie ein kostenloses Erstgespräch mit Sora Yazılım vereinbaren; wir legen den passenden Umfang gemeinsam fest und erstellen ein Angebot.