Richtlinienverwaltung im Firewall-Dschungel

Die heterogenen hybriden Netzwerke, mit denen Unternehmen heute zu kämpfen haben, sind das Ergebnis einer Mischung aus neuen und alten Technologien. Und mit der zunehmenden Auslagerung von Anwendungen, Workloads und jüngst auch Nutzern aus dem geschützten Perimeter nimmt die Heterogenität und Komplexität unserer IT-Umgebungen weiter zu. 

Dies stellt vor allem Netzwerkadministratoren und Sicherheitsteams vor große Herausforderungen und fordert von ihnen ein breites Spektrum an Tools, Erfahrung und Wissen, um diese nachhaltig zu bewältigen. So gibt es mittlerweile Dutzende, wenn nicht Hunderte von Firewalls oder Firewall-ähnlichen Lösungen, die Unternehmen in ihrer heterogenen Infrastruktur verwalten müssen. Und da der Multi-Tier-Ansatz zum Schutz von kritischen Daten und Anwendungen auch weiterhin erfolgsversprechend ist, ist ein Ende der Expansion längst nicht in Sicht.

Um die Netzwerkkomplexität, die Netzwerk- und Sicherheitsteams heute bezwingen müssen, zu veranschaulichen, werfen wir einen Blick auf eine typische Architektur. Eine typische Anwendung ist über mehrere Cloud-Plattformen verteilt, wobei einige Workloads in Public Clouds, andere in Private Clouds ausgeführt werden. Einige Elemente werden aller Voraussicht nach auf einer virtuellen Maschine betrieben, während andere in einer Kubernetes-verwalteten Umgebung laufen. Und viele, wenn nicht die meisten dieser Teile erfordern dabei den Zugriff auf eine on-premises-Datenquelle, während die Authentifizierung unterdessen über einen externen Service durchgeführt wird. Und dann verbinden sich die Benutzer natürlich über das Internet. Diese Komplexität macht die Notwendigkeit eines einheitlichen Network Policy-Managements deutlich. Denn eine große Herausforderung besteht darin, dass Sicherheitsrichtlinien über die gesamte Umgebung hinweg einheitlich verwaltet werden müssen.

Heutige Firewalls haben viele verschiedene Namen

Generell kann jedes Gerät oder jede Software, die Richtlinien durchsetzt und dabei steuert, wer mit wem bzw. was mit wem reden darf, als „Firewall“ bezeichnet werden. Ausgehend von dieser weit gefassten Definition, ist die Liste der „Firewalls“, die den Unternehmen heutzutage zur Verwaltung verschiedener Arten von Segmentierung zur Verfügung stehen, lang. Sie umfasst unter anderem:

• Perimeter- oder interne Firewalls, einschließlich Next-Gen Firewalls, die Konnektivität zu bzw. zwischen Virtual Private Clouds (VPCs) oder Virtual Networks (VNets) bereitstellen
• „Firewalls“, die den horizontalen Datenverkehr im Rechenzentrum verwalten: Etwa Security Groups in der Cloud und Netzwerkrichtlinien in Kubernetes 
• Firewalls als Service in der Cloud 
• Identity & Access Management (IAM) und Role-based Access Control (RBAC): Identity-„Firewalls“, die Richtlinien für Identity-Zugriffe managen
• Authentifizierungsdienste: eine Form von Identity-Firewalls, da sie bestimmen, welche Benutzer auf welche Aspekte der Anwendung zugreifen können
• Operating System Level „Firewalls”: Sorgen für die Isolierung zwischen Anwendungen und der Betriebssystemebene
• Application Level „Firewalls”: Proxys, Load Balancer und Application Gateways
• Web-Application-Firewalls (WAF)

Die Vorteile der Automatisierung

Diese sehr allgemeine Definition einer Firewall veranschaulicht die verschiedenen Technologien und den Umfang der Richtlinien, die daran beteiligt sind. Dabei besteht die Herausforderung für die Teams nicht nur darin, dass sowohl die Anzahl als auch Arten der verfügbaren „Firewalls“ weiterhin zunehmen, sondern auch darin, dass immer mehr Funktionen integriert werden. Dies erfordert bei der Verwaltung zusätzliche Fähigkeiten, eine bessere Netzwerkeinsicht sowie ein vertieftes Verständnis der Geschäftslogik der Anwendungen.

Um dies zu erreichen und die wachsende Komplexität nachhaltig zu bewältigen, bedarf es letztlich einer zentralisierten, skalierbaren und herstellerübergreifenden Richtlinienkontrolle in Kombination mit Automatisierung. Denn die manuelle Konfiguration jeder einzelnen „Firewall“-Kategorie ist sowohl zeitaufwändig als auch ineffizient und kann zu einem Mangel an Kohärenz führen, die „blinde Flecken“ hinterlässt und die Sicherheitslage eines Unternehmens insgesamt schwächt. Bei der Vielzahl an beweglichen Komponenten sind Fehlkonfigurationen vorprogrammiert. Eine zentralisierte Konsole für Sicherheitsrichtlinien, die einen Überblick über die gesamte Bandbreite an „Firewall“-Policies bietet und so deren Durchsetzung im gesamten Netzwerk vereinheitlicht, ist deshalb unabdingbar.  

Die Vorteile der Richtlinien-Abstraktion

Über die herstellerübergreifende Steuerung und Automatisierung hinaus liegt die Zukunft des Policy-Managements in der Abstraktion. So wie die objektorientierte Programmierung (OOP) Daten und Code trennt, erlaubt die Extraktion des „Richtlinien-Codes“ aus der Infrastruktur eine höhere Flexibilität und ein umfassenderes Management. Da Netzwerke nicht statisch sind, die Heterogenität zunimmt und sich die Implementierungen ändern werden, müssen Administratoren die Richtlinien aus den Implementierungen lösen. Denn sie benötigen ein einheitliches und zentrales Management, um zu steuern, wer mit wem und was mit wem kommunizieren kann. Selbstverständlich sollte dieses Management auch dann seine Gültigkeit behalten, wenn sich die zugrunde liegenden IPs, Sicherheitsgruppen oder Plattformen ändern. Dies gewährt ihnen die dringend benötigte Flexibilität sowie eine konsistente Durchsetzung von Richtlinien und eine detaillierte, einheitlichen Sicht auf das gesamte Netzwerk.

IT-Sicherheit ist immer nur so gut wie die definierten Policies. Aus diesem Grund müssen Firewalls stets so konfiguriert werden, dass das Least-Privilege-Prinzip, d.h. das Prinzip der minimalen Rechtevergabe, zu jeder Zeit eingehalten wird.