Kundenreferenz: Firewall-Bibliothek, IP-Prüfung live

Constantin Budin, Cloud- und Platform-Engineer bei Pexon Consulting | 7 Min. Lesezeit | 24.09.2026

Das hier ist keine Anleitung. Es ist der Bericht aus einem laufenden Mandat bei einer deutschen Direktbank im BaFin- und DORA-Umfeld. Pexon stellt der stellvertretenden Leitung Firewall einen Entwickler zur Seite. Stand September 2026 ist die IP-Prüfung als Bibliothek veröffentlicht. Der größere Abgleich von Firewall-Regeln ist implementiert, der Produktionstest folgt dem Security-Prozess der Firewall-Leitung.

Regeln beim Netzwerkteam, Bibliothek bei uns

Die Direktbank betreibt das Netz für die Deutschland-Organisation. Das Firewall- und Netzwerkteam, etwa 10 bis 15 Personen, gibt frei, welche Prozesse mit welchen Servern sprechen dürfen. Python und Bash sind im Team bekannt. Kleine Skripte schreiben die Spezialisten selbst. Die stellvertretende Leitung kommt aus C und C++ und weiß, wie man ein Thema automatisiert.

In diesem Einsatz ist die Teilung klar. Die letzte Aussage über eine Regel bleibt bei den Spezialisten. Pexon sitzt als Entwickler in einem Team, das sonst keine Entwicklerrolle hat, und schneidet die Stücke, für die neben Firewall- und Netzwerkwissen eine Bibliothek mit Tests, Typen und einer Projektstruktur gebraucht wird. Infrastructure as Code stand in der ursprünglichen Rollenbeschreibung. In diesem Einsatz ist es nicht die Arbeit. Der Hebel liegt in Python zwischen Netzwerk und Firewall, nicht in einem zweiten Terraform-Stack.

Für größere Skripte hatte das Team KI-Tools genutzt. Die Entwürfe liefen. Dieselbe Funktion lag in einem Fall dreimal im Baum, weil jede Anfrage eine neue Kopie erzeugt hat. Die Leitung hat die Regel dazu selbst gesetzt: Es muss funktionieren, und es darf nur eine Stelle geben, an der diese Logik gepflegt wird. Kopien aus dem KI-Tool sind für den Betrieb kein Zustand, den das Team behält. Die Nacharbeit ist sichten, zusammenführen und testen. Ein Entwickler, dem man das Ziel einmal erklärt, zieht die fehlenden Anschlüsse selbst nach.

Sicherheit entsteht hier zuerst durch die Netztopologie. Viele Testserver haben keinen Internetzugang. Artefakte werden hinüberkopiert, Zugriffe gibt es nur auf festgelegte Systeme. Die Spezialisten wissen, in welchem Segment sie sich bewegen, und prüfen, ob nach dem Lauf nichts kaputt ist. Das zeigt, dass dieser eine Lauf auf diesem einen System nicht gescheitert ist. Es zeigt nicht, dass die nächste Änderung an Checkpoint, CyberArk oder Active Directory dasselbe Verhalten lässt. Die Produktdokumentation der Firewall hat Lücken. Wer sich strikt an sie hält, trifft auf Antworten, die ein dokumentationsgetreuer Client nicht erwartet. Der Produktionsschritt bleibt deshalb an Personen gebunden, die den Pfad schon einmal gegangen sind. Genau dafür haben wir die Tests so geschnitten, dass sie ohne das Produktivsystem auskommen.

Was wir in Azure Artifacts gelegt haben

Die Automatisierung behandeln wir als Produkt für das eigene Team, nicht als Ordner mit Skripten. KI-Entwürfe werden zerlegt, Dubletten auf eine Implementierung gezogen und als Bibliothek geschnitten. Die Pakete landen in einem privaten PyPI auf Azure Artifacts. Dazu Azure Repos für den Code, Azure Pipelines für die Prüfungen, Azure Boards für die Arbeit. Den Rahmen, in dem Repos, Pipelines und Artifacts zusammenhängen, beschreiben wir auf der Seite zur Azure DevOps Beratung. Dieser Bericht bleibt das Mandat.

Drei Entscheidungen haben den Schnitt bestimmt.

1. Paketgrenze statt geteiltem Repo. Die Spezialisten rufen eine Funktion auf. Sie kopieren die Implementierung nicht. Kopieren ist genau das, was der KI-Entwurf vorher getan hat.
2. Konkrete Frage statt Rahmenwerk. Ein Paket beantwortet eine Frage, etwa ob eine IP frei und für das anfragende Team erlaubt ist. Erklärt wird, was Python an der Stelle kann. Der Aufruf braucht keine Architekturvorlesung.
3. Shell und Docker nur dort, wo der Betrieb sie schon nutzt. Sie sind nicht das Architekturziel. Kleinere Altbestände sind über denselben Weg bereits bereinigt: Pipeline dran, Bibliothek veröffentlicht, Aufwand bewusst klein gehalten.

Das erste abgeschlossene Werkzeug prüft eine angefragte Test-IP, bevor der Bestellvorgang in die Rückfrage läuft. Zwei Bedingungen müssen gleichzeitig wahr sein. Die Adresse ist frei, und das anfragende Team darf sie benutzen. Nur eine von beiden reicht nicht. Eine freie Adresse im falschen Segment erzeugt dieselbe Schleife wie eine belegte Adresse.

def ip_ist_bestellbar(adresse: str, team: str) -> bool:
    """Beide Bedingungen, nicht nur die freie Adresse."""
    return adresse_ist_frei(adresse) and team_darf_segment(team, adresse)

Die Prüfung ist fertig und als Bibliothek bereitgestellt. Der weitere Bestellweg ist noch in Arbeit. Ziel ist, dass das Netzwerkteam den Vorgang gegenliest und freigibt. Eine vollautomatische Provisionierung ohne menschliche Freigabe haben wir nicht versprochen. In einer Bank mit Firewall-Verantwortung bleibt die letzte Aussage bei den Spezialisten. Die Bibliothek nimmt die Fälle ab, die nur deshalb Zeit kosten, weil die Eingabe nicht zum Regelwerk passt.

Das größere Werkzeug gleicht Firewall-Regeln über mehrere Checkpoint-Produkte ab. Die Frage an das Netzwerkteam lautet: Existiert eine Regel noch, die nicht mehr existieren soll, oder fehlt sie dort, wo sie stehen muss. Zugangsdaten kommen aus CyberArk oder aus dem Windows Credential Manager. Konten und Anmeldungen kommen aus dem Active Directory. Die Ergebnisse werden bereinigt und als CSV in dem Format geschrieben, das der nachgelagerte Service erwartet. Polars liest und bearbeitet diese Tabellen. Asynchrone Bibliotheken nutzen die Wartezeit auf die wenigen Systeme, die von den Testnetzen aus erreichbar sind. Der Entwurf der Leitung hatte einen Teil der Strecke schon skizziert. Anbindung, Tests und Struktur haben wir ergänzt. Die Services sind angeschlossen. Der Code ist soweit fertig.

Der Produktionstest bleibt beim Security-Prozess

Produktionsnähe und Testbarkeit widersprechen sich in diesem Netz. Viele Ziele sind vom Arbeitsplatz aus nicht erreichbar. Testserver haben kein Internet. Die Firewall-Leitung gibt den Sprung auf Produktion nur nach ihrem eigenen Prozess frei. Sie hat Security-Hintergrund und hält diesen Schritt, bis der Prozess die Freigabe gibt. Das ist der nächste Maßstab, den die Nähte schon tragen: Der Code steht, der Lauf gegen Produktion ist ein eigener Schritt.

Getestet wird in zwei Stufen. pytest deckt das Verhalten der Bibliothek ab. WireMock steht für die Gegenstelle, die hinter der Netzgrenze liegt und im Test nicht aufgerufen werden darf. Wo ein Checkpoint-Testsystem erreichbar ist, läuft zusätzlich ein Live-Abgleich. Der ist nötig, weil die Produktdokumentation nicht jede Antwort beschreibt. Geprüft wird, dass gesendete und empfangene Nachrichten zum vereinbarten Vertrag passen. Unerwartete Felder werden nicht still geschluckt.

Ein vollständiger Lauf des Firewall-Abgleichs gegen Produktion fehlt, weil dafür ein Wechsel auf die Produktivsysteme nötig ist. Die IP-Prüfung ist davon unabhängig. Sie ist veröffentlicht. Kleinere Bereinigungen laufen bereits mit Pipeline.

Was am Ende stand

Stand September 2026, aus unserer Sicht im laufenden Einsatz zu Firewall Python Bank:

• Die IP-Prüfung ist live. Sie beantwortet vor der Bestellung, ob die Adresse frei und für das Team erlaubt ist.
• Dieselbe Logik, die in einem KI-Entwurf dreifach lag, hat eine Stelle. Das Paket liegt im privaten PyPI auf Azure Artifacts.
• Der Checkpoint-Abgleich ist implementiert, inklusive CyberArk, Windows Credential Manager und Active Directory, und schreibt die CSV im Format des nachgelagerten Service. Der Produktionstest folgt dem Security-Prozess der Firewall-Leitung.

In einem vergleichbaren Mandat würde Pexon drei Dinge wieder so umsetzen. Eine Bibliothek, die das Team aufruft, statt die nächste Kopie zu pflegen. Beide Bedingungen an der IP, nicht nur die freie Adresse. pytest und WireMock, bevor irgendjemand auf Produktion wechselt.

Wer ein Firewall- oder Netzwerkteam in einer Bank hat und denselben Schnitt prüfen will, bringt vier Dinge mit. Die Checkpoint-Landschaft, die Stelle, an der Zugangsdaten liegen, die Aussage, ob die Testsysteme Internet haben, und die eine Prüfung, die zuerst eine Bibliothek werden soll. Dann können wir sagen, ob dieses Muster passt.

Nächster Schritt

Das Mandat läuft. Wenn bei Ihnen dieselbe Naht zwischen Firewall-Team und Bibliothek offen ist, gehen wir sie an Ihrem Bestand durch.

Paketverteilung ohne direkten Internetzugriff

In regulierten Umgebungen wie einer Bank scheitert die gewohnte Installation von Python-Paketen über das öffentliche PyPI an strikten Netzwerksegmenten. Die Build-Agents in Azure Pipelines sowie die Testsysteme im Netzwerkbereich besitzen keinen Zugriff auf das offene Internet. Jede externe Abhängigkeit muss daher kontrolliert und reproduzierbar in das interne Azure Artifacts Feed synchronisiert werden. Das betrifft Kernbibliotheken wie Polars ebenso wie Hilfswerkzeuge für pytest und WireMock. Ein unbedachtes Update einer Unterabhängigkeit führt ohne diesen Puffer unmittelbar zu blockierten Pipeline-Läufen.

Für den Betrieb bedeutet das eine klare Trennung bei der

Umgang mit Teilausfällen und Timeouts an den Schnittstellen

Die Automatisierung verbindet Systeme, die im Bankbetrieb unterschiedlichen Wartungsfenstern, Verfügbarkeiten und Netzwerklatenzen unterliegen. Der Abgleich von Firewall

Typisierung und Validierung der Regeldaten vor dem Export

Die Managementschnittstellen von Checkpoint sowie die Abfragen gegen das Active Directory liefern Datenbestände in heterogenen Strukturen. Neben teils unvollständig dokumentierten JSON