Firewall & IP Connectivity ist Security Architecture
Warum Firewall Changes, Routing und Segmentation keine reine Betriebsarbeit sind – und welche Verantwortung trotz Outsourcing beim Unternehmen bleibt.
Ein Firewall Change sieht im Ticket oft klein aus: Quelle, Ziel, Protokoll, Port, Zeitraum. In Wirklichkeit verändert er die erlaubte Kommunikation zwischen Systemen. Damit berührt er Trust Boundaries, mögliche Angriffswege und die Frage, wie weit sich ein Angreifer nach einer Kompromittierung bewegen kann.
Firewall & IP Connectivity ist deshalb nicht bloß Operations. Es ist Security Architecture in ausführbarer Form.
Connectivity verbindet die kritischen Räume
In einem Mobilfunkunternehmen verbindet die IP-Infrastruktur Data Center, Cloud-Plattformen, Management-Netze, Partnerzugänge, Customer Services und Telco Systems. Routing, DNS, DHCP, VPN und Firewall Policies bestimmen, welche Abhängigkeiten funktionieren – und welche bewusst verhindert werden.
Eine falsch verstandene Änderung kann mehrere Ebenen gleichzeitig treffen:
- Availability, wenn ein notwendiger Pfad fehlt,
- Confidentiality, wenn ein unzulässiger Pfad geöffnet wird,
- Integrity, wenn Management- oder Deployment-Wege zu weit erreichbar sind,
- Compliance, wenn Segmentierung oder Nachweise nicht mehr der Vorgabe entsprechen.
Ausführung kann extern sein, Verantwortung nicht
NIS2, IT-Sicherheitsrecht und Telekommunikationsanforderungen stärken die Verantwortung der Betreiber. Ein Provider kann technische Aufgaben übernehmen. Er kann aber nicht die unternehmerische Entscheidung ersetzen, welches Risiko akzeptiert wird und welche Architektur gelten soll.
Deshalb muss ein internes Team mindestens Zielarchitektur, Security Policies, Exception Handling und Risk Acceptance kontrollieren. Das gilt auch dann, wenn ein Provider die Plattform betreibt oder AI Agents große Teile des Workflows übernehmen.
AI als Assistent der Architecture Governance
AI kann genau dort helfen, wo große und historisch gewachsene Umgebungen Menschen überfordern:
- Rule Reviews und Recertification vorbereiten,
- geplante Changes gegen Policies und Zonenmodelle prüfen,
- Abhängigkeiten aus CMDB, IPAM, DNS, Routing und Logs zusammenführen,
- Anomalien, Schattenregeln und zu breite Freigaben erkennen,
- Risk Assessments und technische Dokumentation vorstrukturieren,
- Evidence für Audit und Compliance bereitstellen.
Aber AI darf Policies nicht nur in natürlicher Sprache „interpretieren“. Kritische Grenzen gehören in testbare, deterministic Policy Engines. Modelle können Kontext erschließen und Empfehlungen begründen; verbindliche Entscheidungen benötigen klare Regeln, nachvollziehbare Freigaben und vollständige Logs.
Was gutes Service Ownership ausmacht
Gutes Service Ownership verbindet drei Perspektiven:
- Architecture: Zonen, Trust Boundaries, Routing Patterns, Abhängigkeiten.
- Operations: Verfügbarkeit, Standard Changes, Incident Response, Lifecycle.
- Governance: Policies, Risk Acceptance, Compliance Evidence, Exceptions.
Wer nur Operations betrachtet, optimiert Ticketdurchsatz. Wer die drei Ebenen zusammenführt, steuert ein sicherheitskritisches System.
Management Summary
Firewall & IP Connectivity sollte nicht wie ein austauschbarer Commodity Service behandelt werden. Operative Tätigkeiten können standardisiert, automatisiert und an Provider vergeben werden. Architektur, Policies, Risk Decisions und die Grenzen der Autonomie müssen jedoch intern beherrscht werden.
AI-Shoring verstärkt diese Notwendigkeit: Je mehr ein Agent erledigt, desto genauer muss das Unternehmen definieren, was er darf, worauf seine Entscheidung beruht und wie ein falsches Ergebnis erkannt und rückgängig gemacht wird.
Quellen und Vertiefung
- Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz und KRITIS
- ENISA: Threat Landscape und NIS2 Guidance
- Europäische Union: NIS2-Richtlinie
- Bundesnetzagentur: Sicherheitskataloge für Telekommunikationsnetze