Multi-Vendor-Firewall-Umgebungen verwalten

Eine zentrale Steuerungsoberfläche, die mehrere Firewalls verschiedener Hersteller gleichzeitig verwaltet

Die meisten Unternehmensumgebungen setzen nicht auf einen einzigen Firewall-Hersteller. Durch Zukäufe, organisches Wachstum, Cloud-Einführung und herstellerspezifische Anforderungen verwalten Organisationen am Ende Firewalls von Palo Alto Networks, Fortinet, Check Point, Cisco und zunehmend auch cloud-native Security Groups von AWS und Azure. Jeder Hersteller bringt seine eigene Management-Oberfläche, CLI-Syntax, API-Struktur und sein eigenes Konfigurationsmodell mit.

Dieser Leitfaden erläutert, warum Multi-Vendor-Umgebungen entstehen, welche konkreten Herausforderungen sie mit sich bringen und mit welchen praxistauglichen Ansätzen man sie effektiv verwaltet – einschließlich Regel-Normalisierung, einheitlichem Change-Management und Single-Pane-of-Glass-Betrieb.

Warum Organisationen mehrere Firewall-Hersteller betreiben

Ein einziger Hersteller wäre einfacher, doch mehrere berechtigte geschäftliche und technische Gründe führen Organisationen zu gemischten Umgebungen:

Fusionen und Übernahmen: Wenn zwei Unternehmen fusionieren, verschmelzen auch ihre Firewall-Bestände. Das übernehmende Unternehmen betreibt Palo Alto, das übernommene Fortinet. Ein Austausch von Grund auf ist teuer und riskant, also koexistieren beide über Jahre hinweg.
Best-of-Breed-Strategie: Manche Organisationen setzen bewusst unterschiedliche Hersteller auf verschiedenen Netzwerkebenen ein. Palo Alto am Perimeter für fortgeschrittene Threat Prevention, Fortinet für die interne Segmentierung, wo der Durchsatz entscheidend ist, Check Point im Rechenzentrum.
Cloud-Einführung: On-Premise-Firewalls werden durch AWS Security Groups, Azure NSGs und cloud-native Netzwerksicherheit ergänzt. Diese unterscheiden sich grundlegend von klassischen Firewalls, erfüllen aber dieselbe Sicherheitsfunktion.
Kostenoptimierung: Firewalls der Enterprise-Klasse von Palo Alto oder Check Point am Perimeter, dazu kostengünstigere Alternativen (Fortinet, Open Source) für weniger kritische Segmente.
Risikominderung beim Hersteller: Das Prinzip der Defense-in-Depth legt nahe, dass eine Schwachstelle bei einem Hersteller nicht den gesamten Perimeter kompromittieren sollte. Der Einsatz mehrerer Hersteller schafft Diversität.
Regionale Anforderungen: Global aufgestellte Organisationen nutzen je nach lokaler Support-Verfügbarkeit, regulatorischen Vorgaben oder bestehenden Verträgen in verschiedenen Regionen unterschiedliche Hersteller.

Die Integrationsherausforderungen

Multi-Vendor-Umgebungen bringen konkrete betriebliche Herausforderungen mit sich, die Single-Vendor-Umgebungen erspart bleiben:

Unterschiedliche Regelmodelle

Jeder Hersteller modelliert Firewall-Regeln anders. Palo Alto arbeitet mit Sicherheitsrichtlinien auf Basis von Zonen, Applikationen und Benutzeridentifikation. Fortinet nutzt Policy-Pakete mit interface-basiertem Routing. Check Point setzt auf Layer und Inline-Layer. Cisco ASA verwendet Access Control Lists (ACLs) mit benannten oder nummerierten Einträgen. Das sind grundverschiedene Datenmodelle für ein und dasselbe Konzept: „Soll dieser Datenverkehr erlaubt oder verweigert werden?“

Unterschiedliche APIs und Management-Oberflächen

Palo Alto nutzt eine XML-API (PAN-OS). Fortinet verwendet eine REST API (FortiOS). Check Point bietet eine JSON-basierte Web-API (R80+). Cisco ASA verfügt über eine REST API, die sich anders verhält als die übrigen. Jede erfordert herstellerspezifischen Integrationscode, eigene Authentifizierungsmechanismen und eigene Fehlerbehandlung.

Uneinheitliche Änderungsprozesse

Ohne eine einheitliche Plattform entwickeln Teams oft herstellerspezifische Prozesse. Die Palo-Alto-Änderungen durchlaufen den einen Workflow, die Fortinet-Änderungen einen anderen. Diese Uneinheitlichkeit erzeugt Lücken in der Dokumentation, bei Freigabenachweisen und in den Audit-Trails – genau die Art von Lücken, die Compliance-Auditoren bei PCI-DSS-Prüfungen bemängeln.

Herstellerübergreifende Regelanalyse

Eine Schattenregel auf einer Palo-Alto-Firewall kann durch eine umfassendere Regel auf einem vorgelagerten Fortinet-Gerät verursacht werden. Wer Regeln nur innerhalb eines einzelnen Herstellers analysiert, übersieht diese herstellerübergreifenden Wechselwirkungen. Echte Optimierung des Regelwerks erfordert eine normalisierte Sicht über alle Hersteller hinweg.

Kompetenzen und Schulung

Jeder Hersteller verlangt spezialisiertes Wissen. Ingenieure zu finden, die zugleich Experten für Palo Alto UND Fortinet UND Check Point UND Cisco sind, ist selten und teuer. Die meisten Teams verfügen über Hersteller-Spezialisten, was Wissenssilos und Single Points of Failure schafft.

Der Normalisierungsansatz

Der Schlüssel zu einer effektiven Multi-Vendor-Verwaltung ist die Regel-Normalisierung – das Übersetzen herstellerspezifischer Regelformate in ein gemeinsames Datenmodell. Dadurch lassen sich Regeln aller Hersteller über eine einzige Oberfläche anzeigen, analysieren und verwalten.

Ein gut konzipiertes normalisiertes Modell erfasst die wesentlichen Elemente, die alle Firewall-Regeln gemeinsam haben, unabhängig vom Hersteller:

# Normalisiertes Regelmodell

{

"source": "10.1.0.0/16",

"destination": "192.168.1.100",

"service": "TCP/443",

"action": "allow",

"vendor": "palo_alto",

"firewallId": "pa-fw-01",

"nativeRuleId": "rule-2847",

"zone": { "from": "trust", "to": "dmz" }

}

Das normalisierte Modell bewahrt die herstellerspezifischen Metadaten (Zone, native Regel-ID) und stellt zugleich eine gemeinsame Struktur für die herstellerübergreifende Analyse bereit.

Single-Pane-of-Glass-Verwaltung

Das Ziel der Multi-Vendor-Verwaltung ist eine einzige Oberfläche, über die Sicherheitsteams folgende Aufgaben erledigen können:

✓ Alle Firewall-Regeln über sämtliche Hersteller hinweg an einem Ort einsehen
✓ Änderungsanträge einreichen, die automatisch an die richtige Firewall geleitet werden
✓ Regelanalysen über die gesamte Flotte ausführen, nicht nur auf einzelnen Geräten
✓ Einen einheitlichen Change-Management-Prozess unabhängig vom Hersteller anwenden
✓ Compliance-Berichte erstellen, die alle Firewalls konsistent abdecken
✓ Zustand und Leistung über die gesamte Flotte hinweg überwachen
✓ Genehmigte Änderungen über die jeweils passende Hersteller-API ausrollen

Herstellerspezifische Überlegungen

Jeder Hersteller hat eigene Merkmale, die eine Multi-Vendor-Management-Plattform berücksichtigen muss:

Palo Alto Networks

API: PAN-OS XML-API – ausgereift, gut dokumentiert, aber XML-basiert (kein JSON)
Regelmodell: Zonenbasiert mit Applikationserkennung. Nutzt App-ID für die Layer-7-Identifikation.
Commit-Modell: Änderungen werden vorbereitet und müssen explizit committet werden. Unterstützt Candidate-Konfigurationen und Rollback.
Überlegungen: Panorama für die zentrale Verwaltung, Device-Group-Hierarchien, Template-Stacks

Fortinet FortiGate

API: FortiOS REST API – JSON-basiert, unkomplizierte CRUD-Operationen
Regelmodell: Interface-/zonenbasierte Richtlinien. Nutzt VDOMs für Mandantenfähigkeit.
Commit-Modell: Änderungen werden sofort wirksam (kein Staging). Bei der Automatisierung ist Vorsicht geboten.
Überlegungen: FortiManager für die zentrale Verwaltung, ADOM-basierte Administration

Check Point

API: R80+ Web-API – JSON-basiert, sitzungsorientiert (Sitzungen müssen geöffnet/geschlossen werden)
Regelmodell: Policy-Layer und Inline-Layer. Mächtig, aber mit komplexer Hierarchie.
Commit-Modell: Änderungen werden in einer Sitzung vorbereitet. Erst „publish“, dann „install policy“, um sie auszurollen.
Überlegungen: SmartConsole für die Verwaltung, Policy-Installationsziele, Multi-Domain-Management

Cisco ASA

API: REST API (ASDM/CSM) – weniger ausgereift als die der Wettbewerber
Regelmodell: Access Control Lists (ACLs). Benannt oder nummeriert, auf Interfaces angewendet.
Commit-Modell: Änderungen werden sofort in der laufenden Konfiguration wirksam. Mit „write memory“ persistieren.
Überlegungen: kontextbasierte Mandantenfähigkeit, traditionell CLI-lastige Administration, FMC für Firepower

Cloud Security Groups: der fünfte Hersteller

Zunehmend muss die Multi-Vendor-Verwaltung auch cloud-native Sicherheitskontrollen einbeziehen. AWS Security Groups und Azure NSGs sind funktional Firewalls – sie steuern den Datenverkehr anhand von Quelle, Ziel, Protokoll und Port. Allerdings weisen sie andere Merkmale auf als klassische Firewalls:

Standardmäßig stateful: Sowohl AWS SGs als auch Azure NSGs sind stateful – der Rückverkehr wird automatisch erlaubt.
Kein explizites Deny: AWS Security Groups verfügen über ein implizites Deny; Deny-Regeln lassen sich nicht schreiben. Azure NSGs unterstützen sowohl Allow als auch Deny.
An Instanzen gebunden: Regeln werden auf einzelne Instanzen oder Subnetze angewendet, nicht auf Netzwerk-Interfaces im klassischen Sinne.
API-first: Cloud-Sicherheitskontrollen werden nativ über APIs verwaltet (AWS EC2 API, Azure ARM) und eignen sich dadurch gut für die Automatisierung.

Eine einheitliche Strategie aufbauen

Um eine Multi-Vendor-Firewall-Umgebung effektiv zu verwalten, benötigen Organisationen Folgendes:

Einen herstellerunabhängigen Change-Management-Prozess. Ein Prozess für alle Hersteller. Ein Freigabe-Workflow. Ein Audit-Trail. Die zugrunde liegende Herstellerkomplexität wird von Antragstellern und Genehmigern abgeschirmt.
Eine normalisierte Regeldarstellung. Ein gemeinsames Datenmodell, das herstellerspezifische Regeln in ein vergleichbares Format für die herstellerübergreifende Analyse übersetzt.
Native API-Integration. Jeder Hersteller muss über seine native API verwaltet werden – kein Screen Scraping, kein SSH-Scripting. Das sorgt für zuverlässige, idempotente Vorgänge.
Herstellerbewusstes Deployment. Beim Ausrollen von Änderungen muss die Plattform die normalisierten Regeln wieder in herstellerspezifische Syntax übersetzen. Eine Regel für Palo Alto erzeugt PAN-OS-XML; dieselbe logische Regel für Fortinet erzeugt FortiOS-JSON.
Flottenweite Analyse. Regeloptimierung und Compliance-Berichte müssen den gesamten Bestand umfassen, nicht nur einzelne Geräte. Eine Schattenregel-Analyse, die nur eine einzelne Firewall betrachtet, übersieht geräteübergreifende Wechselwirkungen.

FwChange unterstützt Palo Alto, Fortinet, Check Point, Cisco ASA, OPNsense und pfSense mit nativen API-Treibern, dazu AWS Security Groups und Azure NSGs für Cloud-Umgebungen. Alle Hersteller werden über einen einzigen Change-Management-Workflow verwaltet – mit einheitlichen Audit-Trails, normalisierter Regelanalyse und compliance-fertiger Dokumentation.

Wenn Sie Firewalls mehrerer Hersteller verwalten und sehen möchten, wie eine einheitliche Plattform funktioniert, starten Sie den kostenlosen Scanner auf einem Ihrer Geräte, um loszulegen. Planen Sie eine Konsolidierung auf einen einzigen Hersteller? Die Best Practices für die Palo-Alto-Migration behandeln die Prinzipien, um das sauber umzusetzen.