Integrationen
NetBox-Kontext für die Prüfung von Firewall-Regeln

Die meisten Prüfungen von Firewall-Änderungen finden in einem Vakuum statt. Ein Prüfer sieht die Quelle 10.42.7.0/24, das Ziel 203.0.113.5, Port 443 – und muss entscheiden, ob er die Regel genehmigt, ohne zu wissen, ob diese Adressen zur Produktion, zur DMZ, zu einem stillgelegten Segment oder zu jemandes privatem Heimlabor gehören. Dieser Kontext existiert in NetBox bereits. Er ist nur nicht dort, wo der Prüfer hinschaut.
Die Lücke bei der Prüfung
NetBox ist die führende quelloffene Single Source of Truth für Netzwerke. Tausende Unternehmen setzen es ein. Es kennt jeden Prefix, jeden VRF, jeden Standort und jedes Gerät, das eine IP besitzt. Und doch taucht nichts davon auf, wenn ein Prüfer eine vorgeschlagene Firewall-Regel betrachtet.
Die Folgen sind vorhersehbar. Regeln werden für IPs genehmigt, die es längst nicht mehr gibt. Regeln werden abgelehnt, weil ein Prüfer nicht erkennen kann, ob ein Subnetz zur Produktion oder zum Test gehört. Prüfer wechseln ständig zwischen dem Change-Ticket und NetBox hin und her, fügen IPs einzeln in die NetBox-Suchleiste ein und verlieren dabei den Faden. Manche winken Dinge einfach durch, weil der Aufwand für die Kontextrecherche zu hoch ist.
Inline-Kontext löst das. Wenn Prefix, VRF, Mandant und nächstgelegenes Gerät direkt neben jeder Quell- und Ziel-IP der Regel erscheinen, werden Genehmigungsentscheidungen schneller und genauer.
Fünf Situationen, in denen NetBox-Kontext die Entscheidung verändert
Dies sind Fälle, die wir in echten Änderungsprüfungen erlebt haben, in denen inline verfügbare NetBox-Daten das Ergebnis umgekehrt haben:
- Geister-Subnetze. Eine Regel verweist auf 172.16.10.0/24, ein Subnetz, das vor acht Monaten stillgelegt wurde. NetBox weiß, dass der Prefix den Status: Deprecated hat. Ohne dieses Signal wird die Regel genehmigt und bleibt für immer in der Firewall stehen.
- Mandantenübergreifender Zugriff. Die Quelle ist in NetBox unter dem Mandanten TenantA verschlagwortet, das Ziel unter TenantB. Ein Prüfer erkennt die Mandanten-Diskrepanz sofort und fragt nach, warum mandantenübergreifender Verkehr überhaupt nötig ist.
- Falscher VRF. Quelle und Ziel liegen in unterschiedlichen VRFs ohne Transit. Die Regel würde in der Produktion nie funktionieren und sollte abgelehnt werden, bevor jemand die Firewall anfasst.
- Prüfung der Spezifizität. Eine Regel zielt auf 10.0.0.0/8, obwohl NetBox zeigt, dass der relevante Produktions-Prefix 10.42.7.0/24 lautet. Den Geltungsbereich zur Prüfzeit einzuschränken dauert 30 Sekunden; es sechs Monate später während eines Regelwerk-Audits zu tun, dauert Tage.
- Geräte-Drift. Die geänderte FwChange-Firewall ist mit einem NetBox-Gerät verknüpft, das als Status: Planned oder Inventory markiert ist. Der Prüfer bemerkt, dass das Gerät noch nicht in Produktion ist, und kennzeichnet den Zeitpunkt.
Keiner dieser Fälle ist ein Sonderfall. Sie treten in etwa einer von zwanzig Prüfungen auf – bei jeder Organisation mit mehr als fünfzig Firewalls.
NetBox in 5 Schritten mit FwChange verbinden
Die Integration ist schreibgeschützt und bereits heute in FwChange enthalten. Die Einrichtung dauert unter 5 Minuten.
- Einen schreibgeschützten NetBox-API-Token erstellen. In NetBox: Admin → API Tokens → Add. Deaktivieren Sie Write Enabled. Legen Sie ein Ablaufdatum fest, falls Ihre Richtlinie das verlangt. Kopieren Sie den Token.
- Den Connector in FwChange hinzufügen. Dashboard → Integrations → IPAM → Add Connector. Geben Sie Ihre NetBox-Basis-URL und den Token ein. Lassen Sie Verify SSL aktiviert, außer Sie betreiben NetBox mit einem selbstsignierten Zertifikat.
- Die Verbindung testen. Klicken Sie auf Test. FwChange ruft den Endpunkt /api/status/ von NetBox auf, bestätigt die Version und setzt den Connector auf ACTIVE.
- Firewalls mit NetBox-Geräten verknüpfen (optional). Setzen Sie bei einer beliebigen FwChange-Firewall die ipamDeviceIdauf die zugehörige NetBox-Geräte-ID. Die Prüf-Seitenleiste zeigt dann Standort, Rack, Seriennummer und primäre IP des Geräts an.
- Eine ausstehende Änderung öffnen. Die Karte mit dem NetBox-Kontext erscheint in der rechten Seitenleiste. Jede Quell- und Ziel-IP der vorgeschlagenen Regel wird auf ihren kleinsten umschließenden NetBox-Prefix, den Mandanten und das nächstgelegene Gerät aufgelöst.
Was die Integration nicht tut
Es lohnt sich, die Grenzen klar zu benennen.
- Keine Schreibzugriffe auf NetBox. Der Token ist schreibgeschützt. FwChange erstellt, ändert oder löscht niemals NetBox-Datensätze. Ihre Single Source of Truth bleibt Ihre.
- Kein Drift-Abgleich. Wenn die Firewall-Realität von NetBox abweicht, zeigt FwChange die NetBox-Sicht an, versucht aber nicht, eine der beiden Seiten zu korrigieren. NetBox Assurance kümmert sich bereits um Drift; wir bleiben in der Bahn der Änderungsprüfung.
- Keine Massensynchronisierung. Es gibt keinen Hintergrundjob, der Ihr gesamtes NetBox-Inventar in FwChange zieht. Die Daten werden bei Bedarf pro Prüfung abgerufen, 5 Minuten lang zwischengespeichert und anschließend verworfen.
Sicherheitsmodell
Der API-Token wird mit AES-256-GCM ruhend verschlüsselt, unter Verwendung der FwChange-Umgebungsvariable ENCRYPTION_KEY. Nur die Organisation, die einen Connector erstellt hat, kann ihn nutzen; Tokens überschreiten niemals Mandantengrenzen.
Antworten werden pro Connector 5 Minuten lang in Redis zwischengespeichert, mit der Connector-ID als Schlüssel. Wird ein Connector deaktiviert oder gelöscht, wird der Cache sofort ungültig gemacht, sodass ein reaktivierter Connector frische Daten abruft.
Ist NetBox nicht erreichbar, degradiert die Seitenleiste kontrolliert – Sie sehen pro fehlgeschlagener Abfrage einen Inline-Fehler, und der Rest der Prüf-Ansicht funktioniert weiter. Eine IPAM-Ausfallzeit blockiert niemals die Regelgenehmigung.
Probieren Sie es aus
Wenn Sie NetBox bereits betreiben, beträgt der Einrichtungsaufwand fünf Minuten, und der Nutzen entsteht pro Prüfer, pro Prüfung – und das dauerhaft. Wenn Sie NetBox Cloud nutzen, richten Sie den Connector auf Ihre Mandanten-URL aus. Falls Sie ohne Risiko evaluieren möchten: NetBox stellt unter https://demo.netbox.dev eine öffentliche Demo bereit, mit der Sie sich über einen kostenlosen schreibgeschützten Zugang verbinden können.
Mehr zur FwChange-Methodik
Der NetBox-Connector ist Teil einer vierphasigen Methodik – Ingest, Analyze, Translate, Validate – die in mehr als 280 Firewall-Migrationen im Unternehmensumfeld angewendet wurde. Die Methodik-Seite dokumentiert die Architektur.