Herstellerübergreifende Abdeckung

Eine Plattform, jede Hersteller-Syntax

Eine reale Umgebung besteht nie aus nur einem Hersteller. Palo Alto im Rechenzentrum, Fortinet in der Filiale, ein Check-Point-Cluster, das niemand anfassen will, und drei Clouds, von denen jede eine Regel anders nennt. FwChange liest sie alle und normalisiert jede Regel auf ein einziges herstellerneutrales Modell, so funktionieren Prüfung, Konfliktanalyse und Audit immer gleich, egal welches System die Policy durchsetzt.

Herstellerneutral von Grund auf

Schluss mit dem Übersetzen im Kopf

Jeder Hersteller modelliert eine Regel anders: hier Adressobjekte, dort Service-Gruppen, anderswo Security-Zonen. Diese Übersetzung steckt meist im Kopf eines einzelnen Engineers, also genau dort, wo ein Audit sie nicht sehen kann.

  • Ein Regelmodell, Quelle, Ziel, Port, Aktion, Zweck, unabhängig von der Plattform darunter.
  • Native APIs statt Screen-Scraping, jeder Treiber spricht die herstellereigene Management-Schnittstelle.
  • Lesen zuerst, analysieren und nachweisen, bevor irgendetwas auf ein Gerät zurückgeschrieben wird.
Palo Alto, Security-Policy 443Normalisiert
Fortinet, Firewall-Policy 443Normalisiert
Check Point, Access-Rule 443Normalisiert
Cisco ASA, Access-List 443Normalisiert
Eine Regel · vier Syntaxen · eine AnsichtVereinheitlicht

Im Produktiveinsatz

Die vier Plattformen, auf denen die meisten europäischen Umgebungen laufen

Diese Treiber tragen den vollständigen Pfad aus Lesen, Analysieren und Schreiben, mit Regel-CRUD, Policy-Abfragen und Konfigurations-Backup, und werden gegen die unten genannten Herstellerversionen erprobt.

Palo Alto Networks

PAN-OS XML API · API-Key-Authentifizierung · Regel-CRUD, Policy-Abfragen, Health-Checks und Konfigurations-Backup. Getestet gegen PA-VM 10.x und 11.x, physisch, als VM und in der Cloud.

Fortinet FortiGate

FortiOS REST API · API-Token-Authentifizierung · Firewall-Policies, Adressobjekte, Services und VPN-Konfiguration. Getestet gegen FortiOS 6.x und 7.x auf Appliances, VM und in der Cloud.

Check Point

R80+ Web API · API-Key plus Session-Authentifizierung · Access-Rules, NAT, Objektverwaltung und Policy-Installation. Getestet gegen R80.40 und R81.x auf Appliances und CloudGuard.

Cisco ASA

REST API · Basic-Authentifizierung · Access-Lists, Object-Groups, NAT und VPN. Getestet gegen ASA 9.x über ASA 5500-X, Firepower und ASAv hinweg.

Unterstützt

Der Rest einer gemischten Umgebung

Die Plattformen, auf die eine Migration unterwegs tatsächlich trifft: die zweite Cisco-Linie, die On-Prem-Appliances und die Cloud- und SASE-Control-Planes, in denen Regeln zunehmend leben.

Cisco FTD / FMC

FMC REST API · Token-Authentifizierung · Access-Policies, Objektverwaltung und Deploy-Tasks. Getestet gegen FMC 7.x auf Firepower-Appliances und FTDv.

Cisco Meraki MX

Dashboard REST v1 · API-Key-Authentifizierung · cloud-verwaltete Layer-3- und Layer-7-Firewall-Regeln über die gesamte MX-Serie.

Juniper SRX

Junos REST und NETCONF · Token- oder Zertifikats-Authentifizierung · Security-Policies und Address-Books. Getestet gegen Junos 21.x und 22.x.

F5 BIG-IP AFM

iControl REST · Basic- oder Token-Authentifizierung · AFM-Firewall-Regeln und Address-Lists. Getestet gegen BIG-IP 15.x und 16.x.

OPNsense

REST API · API-Key plus Secret · Regeln und Aliases auf der Open-Source-Plattform. Getestet gegen 22.x, 23.x und 24.x; pfSense 2.6/2.7 läuft über denselben Treiber.

Cloud, AWS & Azure

AWS SDK für EC2-Security-Groups und VPC; Azure SDK für Network-Security-Groups und Azure Firewall. IAM- bzw. Service-Principal-Authentifizierung.

Darüber hinaus reicht dasselbe Normalisierungsmodell weiter über Cloud- und SASE-Control-Planes: zusätzliche Anbieter, Open-Source-Plattformen und FWaaS-Edges, insgesamt mehr als dreißig Hersteller. Die vier produktiv eingesetzten Treiber oben sind diejenigen, auf die sich eine regulierte Änderung heute stützen kann; der Rest liest und normalisiert, damit eine gemischte Umgebung auf einer einzigen Nachweiskette bleibt.

Auf einen Blick

API, Authentifizierung und getestete Versionen

Womit jeder Treiber spricht, wie er sich authentifiziert und gegen welche Hersteller-Releases er erprobt wurde.

HerstellerAPIAuthentifizierungGetestete VersionenStufe
Palo Alto NetworksPAN-OS XML APIAPI-KeyPA-VM 10.x, 11.xIm Produktiveinsatz
Fortinet FortiGateFortiOS REST APIAPI-TokenFortiOS 6.x, 7.xIm Produktiveinsatz
Check PointR80+ Web APIAPI-Key + SessionR80.40, R81.xIm Produktiveinsatz
Cisco ASAREST APIBasic-AuthASA 9.xIm Produktiveinsatz
Cisco FTD / FMCFMC REST APIToken-AuthFMC 7.xUnterstützt
Cisco Meraki MXDashboard REST v1API-KeyMX-SerieUnterstützt
Juniper SRXJunos REST + NETCONFToken / ZertifikatJunos 21.x, 22.xUnterstützt
F5 BIG-IP AFMiControl RESTBasic / TokenBIG-IP 15.x, 16.xUnterstützt
OPNsenseREST APIAPI-Key + Secret22.x, 23.x, 24.xUnterstützt
AWSAWS SDK (EC2)IAM-CredentialsEC2-, VPC-Security-GroupsUnterstützt
Microsoft AzureAzure SDKService-PrincipalNSG, Azure FirewallUnterstützt
SASE / FWaaSAnbieter-REST / GraphQLAPI-Key / TokenCloud-bereitgestellte EdgesUnterstützt

Die Abdeckung ist der einfache Teil. Die Methode ist der Punkt.

Jeden Hersteller zu lesen zählt nur, wenn die Änderung darauf geprüft, analysiert und nachweisbar ist. Diese Logik stammt aus über 280 Migrationen in regulierten europäischen Umgebungen, festgehalten auf der Methodik-Seite.