Dashboards lügen nicht, aber sie schützen auch nicht

Viele Unternehmen investieren massiv in Sicherheits-Dashboards und Monitoring-Tools und bleiben dennoch verwundbar. Doch das Problem ist nicht das Werkzeug, sondern die Denkweise dahinter. Die ursprüngliche Logik der Netzwerksicherheit lässt sich treffend so beschreiben: eine harte Schale, ein weicher Kern. Der Perimeter war die Verteidigungslinie. Alles dahinter galt per Voreinstellung als vertrauenswürdig. Nicht weil diese Entscheidung je explizit getroffen wurde, sondern weil das Modell sie gar nicht erforderte. Solange die Außenhülle hart blieb, durfte der Kern weich bleiben.
Von   Peter Koencke   |  Country Manager DACH & Central Europe   |  Firemon
26. Mai 2026

Dashboards lügen nicht, aber sie schützen auch nicht

 

 

Der Ansatz bewährte sich – bis er an seine Grenzen stieß. Cloud-Umgebungen, Remote-Zugriff, Partnerintegrationen und die schiere Ausdehnung moderner Infrastrukturen haben die Perimeter als sinnvolle Grenze aufgelöst. Die Antwort darauf war Zero Trust: ein Modell, das kontinuierliche Verifikation fordert und Zugriff nicht mehr nach Netzwerkposition, sondern nach Identität und Kontext definiert. Dieses Prinzip ist solide. Das Problem ist jedoch, dass Prinzip und Umsetzung nicht dasselbe sind.

Transparenz als trügerische Sicherheit

Die meisten Zero-Trust-Implementierungen funktionieren in einer kontrollierten Umgebung genau so, wie vorgesehen. Im produktiven Betrieb, also in der realen Welt, treffen sie allerdings auf etwas, das sich unter Testbedingungen nie gezeigt hat: die aufgeschichtete Komplexität all dessen, was vor Zero Trust kam.

Wenn Implementierungen ins Stocken geraten, ist der erste Reflex, nach mehr Transparenz zu streben. Mehr Dashboards sollen eingeführt, die Überwachung intensiviert und ein klareres Bild von den Vorgängen in der gesamten Umgebung gewonnen werden. Dieses Vorgehen ist grundsätzlich richtig. Aber Transparenz allein verbessert die Sicherheit nicht. Sie schafft lediglich Bewusstsein für die Probleme. Doch ohne entsprechende Maßnahmen bleibt dieses Bewusstsein ohne Folgen.

Exponentielle Komplexität in Policy-Strukturen

Ein Blick auf das, was eine Enterprise-Netzwerksicherheitsumgebung in der Praxis ausmacht, ist ernüchternd. Am Anfang stand eine einzige Firewall. Man kannte sie und das gesamte Bild passte noch ins Gedächtnis. Die benötigten Zugriffsrechte waren überschaubar und Entscheidungen ließen sich fundiert und nachvollziehbar treffen. Doch dann kam eine weitere Schicht hinzu. Und dann noch eine. Und mit jeder neuen Schicht wuchs die Komplexität nicht linear. Sie wuchs exponentiell.

Heute umfassen Umgebungen Hunderte von Firewalls, von denen jede eine Policy aus Tausenden von Regeln hat, wobei jede Regel mehrere Quellen und Ziele umfasst. Schnell erreicht man einen Punkt, an dem Milliarden von Zugriffspfaden verwaltet werden müssen. Das ist weitaus mehr, als ein Mensch vollständig überblicken kann.

Um das handhabbar zu machen, muss man das übergeordnete Prinzip erkennen: die Richtlinie. Jede Technologie im Security-Stack – von den frühesten Access Control Lists bis hin zu Next-Generation-Firewalls und Zero-Trust-Architekturen – erfüllt einen einzigen Zweck. Sie setzt die definierte Richtlinie durch. Die Richtlinie ist somit die Steuerungsebene. Es spielt keine Rolle, wie ausgefeilt die Durchsetzungstechnologie ist: Wenn die Richtlinie schwach ist, ist auch die Sicherheit schwach. In Umgebungen dieser Komplexität, die Rechenzentren, Cloud-Workloads, Legacy-Infrastruktur und Partnerintegrationen umfassen, ist die Aufrechterhaltung einer einheitlichen Richtlinie über all dies hinweg die entscheidende Herausforderung.

Wenn alte Regeln zur Gefahr werden

Eine ehrliche Bewertung der Netzwerksicherheitslage in nahezu jeder Organisation führt bei allen zu einem ähnlichen Befund: Die Lage ist schlechter als erwartet. Das liegt nicht daran, dass die Entwickler unfähig wären. Das sind sie bei Weitem nicht, denn sie stehen unter großem Druck. Sie sind jedoch zum Scheitern verurteilt, da sie eine Komplexität geerbt haben, die von Anfang an nie vollständig verstanden wurde. Es gibt Regeln, die seit Jahren, ja sogar Jahrzehnten gelten, und niemand weiß mehr genau, warum. Niemand will sie ändern. Denn wer eine Änderung vornimmt und dadurch einen Ausfall verursacht, trägt die Verantwortung. Also bleiben sie bestehen. Das Regelwerk wächst. Die Lücken und Widersprüche häufen sich unsichtbar an.

Dies ist das Problem der Policy-Oberfläche. Genauso, wie sich die Angriffsfläche mit jedem neuen Gerät und jeder neuen Arbeitslast vergrößert, vergrößert sich auch die Policy-Oberfläche mit jeder neuen Regel, jeder Ausnahme und jeder temporären Zugriffsgenehmigung, die zur Dauerlösung wird. Unkontrolliert spiegelt sie irgendwann keine bewusste Absicht mehr wider, sondern nur noch gewachsene Geschichte. Entscheidend ist, dass sich diese Oberfläche über alle Umgebungen erstreckt, in denen das Unternehmen tätig ist – Firewalls, Cloud-Kontrollen, Mikrosegmentierungsgrenzen –, wobei jede ihre eigene Version des Zugriffs durchsetzt, ohne dass es eine einheitliche Gesamtübersicht über alle gibt. So kann es beispielsweise vorkommen, dass einem Nutzer auf der Netzwerkebene der Zugriff verweigert wird, er auf der Anwendungsebene jedoch durchgelassen wird. Ein Zugriff, der für einen Zweck genehmigt wurde, ermöglicht unter Umständen einen anderen. Die Kontrollen sind inkonsistent, weil die Governance nicht einheitlich ist. Und genau darin liegt das Risiko.

Dieses Problem lässt sich mit Zero Trust nicht lösen. Tatsächlich führt es oft zu neuen Verwaltungsherausforderungen, die zu den bestehenden hinzukommen – weil eben die Einführung nicht in einer sauberen Umgebung erfolgt.

Dadurch wird wird die Steuerung der Umgebung immer schwieriger. Mit jeder neuen Identität, die hinzukommt, sei es ein neuer Mitarbeiter, ein neuer Auftragnehmer oder ein Partner, dem Zugriff auf ein System gewährt wird, erweitert sich die Policy-Oberfläche. Jede dieser Identitäten erfordert eine Entscheidung darüber, welcher Zugriff angemessen ist, wie die minimal erforderlichen Berechtigungen aussehen und wie dieser Zugriff im Laufe der Zeit überprüft und validiert wird. Diese Disziplin ist auf menschlicher Ebene schon schwer genug aufrechtzuerhalten. Dann kamen Systeme hinzu, die autonom agieren.

Agentic-AI: eine neue Dimension des Risikos

Agentische KI-Systeme, die im Auftrag von Nutzern handeln, Entscheidungen treffen und mit anderen Systemen interagieren, ohne dass ein Mensch in den Prozess eingreift, führen eine neue Kategorie von Identitäten in eine ohnehin bereits komplexe Zugriffsumgebung ein.

Agenten haben Identitäten. Um ihre Funktion auszuführen, benötigen sie Zugriff. Sie interagieren mit anderen Agenten, rufen APIs auf und durchqueren die Infrastruktur – und das mit einer Geschwindigkeit und in einem Umfang, mit denen kein manueller Überwachungsprozess mithalten kann. Die Folge sind mehr Identitäten, mehr Zugriffspfade und ein größerer Bedarf an kontinuierlicher Validierung. Die meisten Governance-Prozesse können all dies gar nicht bewältigen.

Der Schadensradius einer schlecht abgesteckten Zugriffsentscheidung wird durch die damit verbundenen Richtlinien bestimmt. Ein Agent, der auf Systeme oder Daten zugreift, für die er keine Berechtigung hat – beispielsweise Kundendaten, Finanzdaten oder operative Technologie –, ändert nichts an diesem Grundsatz. Er verschärft ihn sogar. Sind die entsprechenden Richtlinien kohärent und werden sie kontinuierlich überprüft, bleibt der Radius begrenzt. Sind sie das Ergebnis von Abweichungen und ungeprüften Ausnahmen, ist der Radius unvorhersehbar. Agentische KI bringt neue Risiken mit sich. Die entscheidende Frage lautet: Ist die Policy-Umgebung gut genug gesteuert, um sie einzudämmen?

Von Transparenz zu Governance

Doch was bedeutet es konkret, auf der Grundlage von Transparenz zu handeln, statt Transparenz zum Selbstzweck zu betreiben? Zunächst ist eine ehrliche Bestandsaufnahme der derzeit bestehenden Zugriffsmöglichkeiten erforderlich: Welche Regeln gelten? Was erlauben sie? Welche sind redundant? Welche widersprechen sich und welche wurden noch nie überprüft? Dieser Klärungsprozess ist zwar wenig glamourös, aber unabdingbar. Man kann keine Policy-Umgebung steuern, die man nicht versteht. Zudem verfügen die wenigsten Unternehmen über eine einheitliche Sicht über Firewalls, Cloud und Mikrosegmentierungskontrollen hinweg.

Von dort wird die Herausforderung operativ: Täglich gehen neue Zugriffsanfragen ein, die von den ohnehin schon überlasteten Sicherheitsteams bearbeitet werden müssen. Der Druck, schnell zuzustimmen, um den Geschäftsbetrieb nicht aufzuhalten, ist real – und genau dadurch wird Policy-Drift, also die Abweichung von den Richtlinien, beschleunigt. Die Disziplin, die dem entgegenwirkt, ist nicht reaktiver Natur. Es geht darum, die Absicht zu überprüfen, bevor Änderungen umgesetzt werden. Das bedeutet, sicherzustellen, dass jede neue Zugriffsanfrage anhand definierter Richtlinien bewertet wird. Es muss gewährleistet sein, dass das, was bereitgestellt wird, eine bewusste Entscheidung widerspiegelt und nicht nur eine kurzfristige, spontaneLösung ist. Zudem muss die kumulative Wirkung einzelner Änderungen berücksichtigt werden, um die Kohärenz der gesamten Zugriffsumgebung nicht zu gefährden.

Network Security Policy Management (NSPM) bietet die erforderliche Governance-Schicht, um Policy-Absichten über Firewalls, Cloud- und Mikrosegmentierungskontrollen hinweg zu definieren, zu validieren und aufrechtzuerhalten. Dies ermöglicht es Unternehmen, den Schritt von der bloßen Transparenz hin zu nachweisbarer, operativer Sicherheit zu vollziehen. Gemeint ist die Fähigkeit, mit Zuversicht sagen zu können, dass jede geltende Richtlinie eine bewusste Entscheidung widerspiegelt und dass neu eingeführte Zugriffe durch Absicht definiert werden, anstatt standardmäßig übernommen zu werden.

Fazit: Sicherheit ist eine Frage der Policy-Disziplin

Richtlinien bleiben als Konstante. Die zugrunde liegenden Technologien hingegen werden sich weiterentwickeln. So haben sich Firewalls von Access Control Lists über Stateful Inspection zu applikationsbewussten Next-Generation-Architekturen entwickelt. Über allem steht das Zero-Trust-Framework – ein Satz von Prinzipien, deren Durchsetzung diese Technologien übernehmen sollen. Und genau das ist der springende Punkt: Egal, wie ausgefeilt die Durchsetzungstechnologie auch wird, sie erfüllt immer nur eine Aufgabe: Sie setzt die definierten Richtlinien durch. Richtlinien bilden die Steuerungsebene. Sind die Richtlinien schwach, ist auch die Sicherheit schwach. Das Framework ändert nichts an dieser Gleichung. Die Technologie auch nicht.
Was sich ändert, ist die Frage, ob Unternehmen Richtlinien als lebendige Disziplin behandeln. Also als etwas, das gepflegt, validiert und in ständiger Übereinstimmung mit der tatsächlichen Absicht gehalten wird und nichrt als Artefakt vergangener Entscheidungen, für deren Überprüfung weder Zeit noch Zuversicht vorhanden ist. Um das echte Versprechen von Zero Trust einzulösen, müssen diese Fragen ehrlich beantwortet werden. Sichtbarkeit ist der Anfang. Governance ist das, was zählt.

Peter Köhncke ist Country Manager DACH & Central Europe bei FireMon. Er verfügt über eine fast 30-jährige Erfahrung in der Network-Security-Industrie. Sein Fokus liegt darauf, Firemon gemeinsam mit führenden Partnern in der Region DACH und Zentraleuropa deutlich stärker zu etablieren.

Um einen Kommentar zu hinterlassen müssen sie Autor sein, oder mit Ihrem LinkedIn Account eingeloggt sein.

54856

share

Artikel teilen

Top Artikel

Ähnliche Artikel