Firewall-Automatisierung mit Python: eine Library statt dreifach kopiertem KI-Code

Die Automatisierung wird als Produkt für das eigene Team behandelt, 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 in Azure Artifacts, dazu Azure Repos für den Code, Azure Pipelines für die Prüfungen und Azure Boards für die Arbeit. Der Trade-off gegen ein geteiltes Repo ohne Paketgrenze: Spezialisten sollen Funktionen benutzen, ohne die Implementierung zu kopieren. Kopieren ist genau das, was die KI vorher getan hat, und genau das wollte die Leitung nicht mehr pflegen. Der Trade-off gegen ein großes Rahmenwerk: Das Team hat keine Zeit für eine Plattform-Einführung. Es braucht Pakete, die eine konkrete Frage beantworten, etwa ob eine IP frei und erlaubt ist. Schulung bleibt deshalb klein und auf Python-Grundlagen begrenzt. Die Leitung und das Netzwerkteam sind mit dem Tagesgeschäft ausgelastet. Erklärt wird, was die Sprache an der Stelle kann. Der Rest steht so, dass man ihn ohne Architekturvorlesung aufruft.

Das erste abgeschlossene Werkzeug prüft eine angefragte Test-IP, bevor der Bestellvorgang in die Rückfrageschleife läuft. Zwei Fragen 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 Hin-und-her-Schleife wie eine belegte Adresse. Die Prüfung ist fertiggestellt und als Bibliothek bereitgestellt. Der weitere Bestellweg ist noch in Arbeit. Ziel ist, dass das Netzwerkteam den Vorgang nur noch gegenliest und freigibt, statt fehlende oder falsche Angaben selbst zu korrigieren. Bewusst nicht versprochen wird eine vollautomatische Provisionierung ohne menschliche Freigabe. In einer Bank mit Firewall-Verantwortung bleibt die letzte Aussage bei den Spezialisten. Die Automatisierung nimmt ihnen die Fälle ab, die nur deshalb Zeit kosten, weil die Eingabe nicht zum Regelwerk passt. Infrastructure as Code stand in der ursprünglichen Rollenbeschreibung, ist in diesem Einsatz aber nicht die Arbeit. Der Hebel liegt in Python zwischen Netzwerk und Firewall, nicht in einem zweiten Terraform-Stack.

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. Dafür werden die Systeme angebunden, die das Team vorher einzeln und teils von Hand abgefragt hat. Zugangsdaten kommen aus CyberArk oder aus dem Windows Credential Manager, Konten und Anmeldungen aus dem Active Directory. Die Ergebnisse werden bereinigt und als CSV in dem Format geschrieben, das der nachgelagerte Service erwartet. Polars übernimmt das Lesen und Bearbeiten der Tabellen, als modernerer Weg gegenüber Pandas für genau diese Dateien. Asynchrone Bibliotheken nutzen die Wartezeit auf die wenigen Systeme, die von den Testnetzen aus erreichbar sind. Der KI-Entwurf der Leitung hatte einen Teil der Strecke schon skizziert, ließ aber Anbindung, Tests und Struktur offen. Die Services sind angeschlossen und die Tests ergänzt. Der Code ist soweit fertig. Ein vollständiger Lauf gegen Produktion fehlt, weil dafür ein Wechsel auf die Produktivsysteme nötig ist.

Produktionsnähe und Testbarkeit widersprechen sich in diesem Netz. Viele Ziele sind vom Arbeitsplatz aus nicht erreichbar, Testserver haben kein Internet, und die Firewall-Leitung gibt den Sprung auf Produktion nur nach ihrem eigenen Prozess frei. Sie hat Security-Hintergrund und behandelt diesen Schritt bewusst langsam. Getestet wird deshalb 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 Testsystem für Checkpoint erreichbar ist, läuft zusätzlich ein Live-Abgleich. Der ist nötig, weil die Produktdokumentation Lücken hat und Antworten liefert, die ein strikt dokumentationsgetreuer Client nicht erwartet. Geprüft wird, dass gesendete und empfangene Nachrichten zum vereinbarten Vertrag passen, statt unerwartete Felder still zu schlucken. Shell-Skripte und Docker kommen nur dort dazu, 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.