Policy-Risiken verstehen. Fragen zu Policies in natürlicher Sprache stellen. Demo anfragen →
Published:
Temporärer Zugriff darf nicht zur dauerhaften Firewall-Policy werden
Erfahren Sie, warum temporärer Firewall-Zugriff seinen Zweck überdauert und wie Owner, Begründung, Ablaufdaten und Reviews zeitlich befristete Regeln im Griff behalten.
by FireMon
Temporärer Zugriff hat die Angewohnheit, dauerhaft zu werden.
Eine Regel entsteht für ein Projekt, einen Dienstleister, eine Migration oder eine dringende Anforderung. Zu diesem Zeitpunkt ist allen klar, warum es sie gibt. Monate später lässt sich dieser Kontext kaum noch rekonstruieren.
Wer hat sie beantragt? Wer hat sie genehmigt? Welcher geschäftliche Bedarf stand dahinter? Wird der Zugriff überhaupt noch benötigt?
Ohne diese Informationen lässt sich selbst eine technisch einwandfreie Firewall-Regel nur schwer bewerten.
Deshalb reicht es für wirksames Policy Management nicht aus, zu wissen, was eine Regel erlaubt. Teams müssen außerdem wissen, warum die Regel existiert und wer dafür verantwortlich ist.
Kontext festhalten, solange die Entscheidung noch frisch ist
Im Video oben zeigt Rob Rodriguez, Senior Director of Global Field Engineering bei FireMon, wie Teams den geschäftlichen Kontext hinter einer Firewall-Regel direkt in Security Manager dokumentieren.
Dazu gehören zum Beispiel:
- Geschäftliche Begründung
- Geschäftsbereich
- Verantwortlicher für die Regel
- Antragsteller und Genehmiger
- Informationen zum Change Control
- Nächster Review-Termin
- Ablaufdatum
Das Beispiel, das Rob zeigt, trägt die Bezeichnung „Temp Access“ - und steht damit für ein typisches Problem im Policy Management.
Temporärer Zugriff kann durchaus notwendig sein. Riskant wird es, wenn es keinen klaren Mechanismus dafür gibt, wann dieser Zugriff wieder enden soll.
Ein Ablaufdatum oder ein geplanter Review schafft einen festen Prüfpunkt. Statt darauf zu hoffen, dass sich Monate später noch jemand an den ursprünglichen Antrag erinnert, trägt die Policy selbst die Informationen, die für eine erneute Bewertung nötig sind.
Regeln so dokumentieren, dass spätere Bewertungen leichter fallen
Die technische Konfiguration zeigt, was eine Firewall-Regel tut.
Die Dokumentation zeigt, warum es sie gibt.
Dieser Unterschied wiegt umso schwerer, je stärker Umgebungen wachsen und Teams sich verändern.
Ein Engineer, der eine Regel sechs Monate nach ihrer Erstellung prüft, war womöglich nie am ursprünglichen Antrag beteiligt. Der Application Owner hat die Rolle gewechselt. Das Projekt ist abgeschlossen. Die Geschäftsbeziehung zum Dienstleister besteht nicht mehr.
Ohne Verantwortlichkeit und geschäftliche Begründung muss das Team erst die Historie der Regel rekonstruieren, bevor es entscheiden kann, ob der Zugriff noch angemessen ist.
Wer diese Informationen von Anfang an dokumentiert, macht künftige Reviews deutlich einfacher.
Statt zu fragen „Weiß jemand, wofür diese Regel ist?“, starten die Verantwortlichen mit dokumentiertem Zweck, benanntem Owner und festem Review-Termin.
Temporärem Zugriff ein Enddatum geben
Temporäre Regeln verdienen besondere Aufmerksamkeit, weil ihr ursprünglicher Zweck meist an ein bestimmtes Ereignis oder einen Zeitraum gebunden ist.
Das kann ein Wartungsfenster sein, eine Migration, eine Testphase, die Zusammenarbeit mit einem Dritten oder eine kurzfristige geschäftliche Anforderung.
Entsteht die Regel ohne Ablaufdatum oder Review-Prozess, bleibt der Zugriff oft lange bestehen, nachdem der ursprüngliche Bedarf längst entfallen ist.
Ein besserer Prozess verknüpft die technische Regel mit ihrem geschäftlichen Lebenszyklus.
Wenn ein Zugriff einen Owner, eine Begründung und einen Review-Termin hat, haben Teams eine klare Grundlage für die Frage, ob er bestehen bleiben soll.
Das heißt nicht, jede temporäre Regel beim Erreichen des Datums automatisch zu löschen. Es heißt, einen bewussten Prüfpunkt zu setzen, statt Zugriffe standardmäßig unbegrenzt weiterlaufen zu lassen.
Firewall-Regeln zu gesteuerten Entscheidungen machen
Firewall Policies lassen sich leichter managen, wenn Regeln als geschäftliche Entscheidungen behandelt werden und nicht nur als Konfigurationsobjekte.
FireMon hilft Teams, technische Policies mit den Angaben zu Verantwortlichkeit, Begründung und Review zu verknüpfen, die für das Management dieser Zugriffe über die Zeit nötig sind.
Das Ergebnis: ein klarer Nachweis, warum ein Zugriff existiert, und ein praktikabler Weg, zu entscheiden, ob er noch gebraucht wird.
Denn die Frage ist nicht nur, ob eine Regel heute funktioniert. Sondern ob die Organisation diesen Zugriff morgen noch versteht, verantwortet und benötigt.
Bringen Sie geschäftlichen Kontext in Ihr Firewall Policy Management. Erfahren Sie, wie FireMon Security Manager Teams dabei unterstützt, Security Policies in komplexen Umgebungen zu verstehen, zu dokumentieren und zu steuern.
Häufig gestellte Fragen
Temporärer Firewall-Zugriff wird dauerhaft, wenn eine Regel ohne Owner, geschäftliche Begründung, Ablaufdatum oder Review-Termin angelegt wird. Beim Anlegen ist allen klar, warum es die Regel gibt. Monate später ist der Antragsteller vielleicht nicht mehr im Unternehmen und das Projekt abgeschlossen. Wenn niemand sagen kann, ob der Zugriff noch nötig ist, bleibt die Regel standardmäßig bestehen.
Bleibt temporärer Zugriff bestehen, kann eine Firewall-Regel technisch korrekt und trotzdem schwer bewertbar sein. Teams sehen, was sie erlaubt, aber nicht, warum es sie gibt oder wer dafür verantwortlich ist. So bleibt der Zugriff oft lange bestehen, nachdem der ursprüngliche Bedarf entfallen ist. Wer die Regel prüft, muss dann erst ihre Historie rekonstruieren, bevor er entscheiden kann, ob der Zugriff noch angemessen ist.
Temporärer Firewall-Zugriff unterstützt in der Regel ein bestimmtes Ereignis oder einen bestimmten Zeitraum. Typische Beispiele sind ein Projekt, ein Wartungsfenster, eine Migration, eine Testphase, die Zusammenarbeit mit einem Dritten oder Dienstleister, eine dringende Anforderung oder eine kurzfristige geschäftliche Anforderung. Weil der Bedarf an dieses Ereignis gebunden ist, sollte auch der Lebenszyklus der Regel daran gekoppelt sein - mit einem Review- oder Enddatum.
Dokumentieren Sie die geschäftliche Begründung, den Geschäftsbereich, den Verantwortlichen für die Regel, Antragsteller und Genehmiger, Informationen zum Change Control, den nächsten Review-Termin und das Ablaufdatum. Wer das festhält, solange die Entscheidung frisch ist, sorgt dafür, dass ein späterer Prüfer mit dokumentiertem Zweck und benanntem Owner startet, statt die Historie zu rekonstruieren. Mit FireMon Security Manager erfassen Teams diesen geschäftlichen Kontext direkt an der Firewall-Regel.
Ein Ablaufdatum oder ein geplanter Review schafft einen Prüfpunkt, der nicht davon abhängt, dass sich jemand an den ursprünglichen Antrag erinnert. Ist das Datum erreicht, geben Owner und Begründung dem Team eine klare Grundlage für die Entscheidung, ob der Zugriff bleibt, angepasst oder entfernt wird. Ohne diesen Prüfpunkt läuft temporärer Zugriff standardmäßig unbegrenzt weiter.
Nicht zwingend. FireMon empfiehlt, ein Ablaufdatum als bewussten Prüfpunkt zu verstehen und nicht als automatischen Löschauslöser. Mancher Zugriff wird weiterhin legitim benötigt, und ein Entfernen ohne Prüfung kann das Geschäft stören. Ziel ist, dass für jede temporäre Regel eine explizite Entscheidung getroffen wird - statt dass sie bestehen bleibt, weil niemand hingesehen hat.
Beginnen Sie mit vier Fragen: Wer hat diese Regel beantragt? Wer hat sie genehmigt? Welcher geschäftliche Bedarf stand dahinter? Besteht dieser Bedarf noch? Prüfen Sie anschließend, ob sich Owner, Anwendung, Projekt oder Dienstleisterbeziehung geändert haben. Sind Begründung, Owner und Review-Termin an der Regel dokumentiert, lässt sich das schnell beantworten - statt zu fragen, ob jemand weiß, wofür sie ist.
Achten Sie auf eine Lösung, die jeder Regel geschäftlichen Kontext zuordnet: Begründung, Geschäftsbereich, Owner, Antragsteller und Genehmiger, Informationen zum Change Control, Review-Termine und Ablaufdaten. Sie sollte Teams dabei unterstützen, Regeln als gesteuerte geschäftliche Entscheidungen mit einem Lebenszyklus zu behandeln und nicht nur als Konfigurationsobjekte. FireMon Security Manager ermöglicht es, diesen Kontext an Firewall-Regeln zu dokumentieren, sodass Teams temporäre Zugriffe auf einer klaren Datenbasis erneut bewerten können.