Detaillierter Bericht

Der Trugschluss der Perimetersicherheit (Der Status Quo)

Historisch gesehen stützte sich die IT-Infrastruktur von Unternehmen auf ein “Burg und Burggraben”-Sicherheitsmodell (Castle-and-Moat). In diesem Paradigma fungieren Perimeter-Firewalls als Burgmauern, während Virtual Private Networks (VPNs) als Zugbrücke dienen. Sobald sich ein Benutzer oder ein Gerät erfolgreich über das VPN authentifiziert und den Perimeter überschreitet, wird ihm weitgehend vertraut und umfassender Zugriff auf das interne Netzwerk gewährt.

Dieser Status Quo birgt jedoch schwerwiegende architektonische Schwachstellen. Gelingt es einem Bedrohungsakteur, den Perimeter zu durchbrechen, sei es durch kompromittierte Zugangsdaten, Phishing oder ungepatchte VPN-Schwachstellen, so erhält er uneingeschränkte Möglichkeiten zur lateralen Bewegung innerhalb des internen Netzwerks. Darüber hinaus erfordert die Aufrechterhaltung dieses veralteten Perimeters explizit die Öffnung öffentlich zugänglicher, eingehender Ports ins Internet. Dies schafft eine ständige, leicht auffindbare Angriffsfläche für automatisierte Scanner und böswillige Akteure.

Regulatorischer Treiber: Erreichung der NIS2-Compliance

Die zunehmende Häufigkeit von Lateral-Movement-Angriffen und Kompromittierungen der Lieferkette hat zu einem strukturellen Wandel in der europäischen Cybersicherheitsgesetzgebung geführt. Die EU-NIS2-Richtlinie (Artikel 21) macht Cybersicherheit von einem rein technischen IT-Thema zu einer strengen Corporate-Governance- und Compliance-Vorgabe für wesentliche Einrichtungen.

Unter NIS2 sind Unternehmen gesetzlich verpflichtet, robuste Risikomanagementmaßnahmen zu implementieren, einschließlich strenger Zugriffskontrollen, Vorfallbearbeitung und absoluter Geschäftskontinuität. Das Verlassen auf veraltete Firewalls mit offenen Ports wird diesen strengen regulatorischen Erwartungen oft nicht gerecht.

Indem wir das Vertrauen auf Netzwerkebene durch einen kryptografisch verifizierten, identitätsbasierten Zugriff ersetzen, dient unsere Zero Trust Architektur (ZTA) als aktives Compliance-Framework. Sie neutralisiert proaktiv die Risiken interner lateraler Bewegungen und stellt sicher, dass die Infrastruktur die Kernsäulen der Richtlinie für Sicherheit und Resilienz vollumfänglich erfüllt.

Das Zero Trust Paradigma & OpenZiti

Um das fehlerhafte Perimetermodell zu überwinden und die NIS2-Vorgaben zu erfüllen, haben wir das Netzwerk nach dem Grundprinzip von Zero Trust konzipiert: “Niemals vertrauen, immer verifizieren” (Never trust, always verify). Vertrauen wird niemals aufgrund des Netzwerkstandorts gewährt (z. B. weil man mit dem Büro-LAN oder dem VPN verbunden ist). Stattdessen muss jede einzelne Zugriffsanfrage explizit authentifiziert und autorisiert werden, bevor überhaupt eine Verbindung hergestellt wird.

Um dies zu erreichen, nutzten wir OpenZiti, ein quelloffenes, identitätszentriertes Netzwerk-Overlay. OpenZiti verändert die Art und Weise, wie Datenverkehr durch die Infrastruktur geleitet wird, grundlegend:

• Identität statt IP: Das Routing wird durch kryptografisch verifizierte Identitäten (mittels X.509-Zertifikaten) bestimmt, nicht durch IP-Adressen. Fehlt einem Gerät eine gültige Identität, ignoriert der Netzwerk-Controller die Anfrage mathematisch.
• Dark Infrastructure (Dunkle Infrastruktur): OpenZiti macht eingehende, offene Ports überflüssig. Interne Dienste stellen ausschließlich ausgehende (outbound-only) Verbindungen zum Ziti-Overlay her. Für das öffentliche Internet und bösartige Port-Scanner ist die interne Infrastruktur völlig unsichtbar.
• End-to-End mTLS: Sämtlicher Datenverkehr, der das OpenZiti-Overlay durchquert, wird mittels Mutual TLS (mTLS) stark verschlüsselt, wodurch absolute Datenintegrität und Vertraulichkeit bei der Übertragung gewährleistet sind.

Ein Wort der Anerkennung: An dieser Stelle ein großes und herzliches Dankeschön an das OpenZiti-Team für die Entwicklung eines so großartigen Tools. Das Projekt ist hier zu finden und die Community kann hier erreicht werden.

Hochverfügbarkeits-Infrastruktur & Business Continuity

Eine entscheidende Säule der NIS2-Richtlinie ist Disaster Recovery und operative Resilienz. Die Sicherung einer Infrastruktur ist irrelevant, wenn die zugrunde liegenden Systeme Hardwareausfälle oder lokale Ausfälle nicht überstehen können.

Um einen kontinuierlichen Betrieb zu gewährleisten, ist das physische Fundament dieser Architektur über drei On-Premise-Server an unterschiedlichen physischen Standorten verteilt.

• Proxmox Virtual Environment (VE): An jedem physischen Standort laufen mehrere virtualisierte Knoten, die über Proxmox VE orchestriert werden, um hohe Nebenläufigkeit und automatisierte Fallback-Szenarien zu bewältigen.
• Kubernetes (K8s) Orchestrierung: Containerisierte Workloads werden über Kubernetes verwaltet. Dies stellt sicher, dass Dienste je nach Echtzeitbedarf dynamisch über die verteilten Knoten skalieren können.
• Redundante Datenreplikation: An jedem Standort läuft eine unabhängige Instanz des Proxmox Backup Servers. Das System automatisiert lokale Snapshots und synchronisiert täglich Remote-Backups über alle physischen Standorte hinweg.
• Verteilter Datenspeicher: Die Architektur nutzt einen verteilten Datastore und eine Caching-Ebene. Dies garantiert, dass an jedem Standort mehrere, hochaktuelle Kopien aller kritischen Daten existieren, was ein nahtloses Failover-Routing ohne Datenverlust ermöglicht, falls ein primärer Knoten ausfällt.

Netzwerktopologie & Die Dual-Firewall-Verteidigungsstrategie

Um einen Single Point of Failure (SPOF) zu vermeiden und vor menschlichen Konfigurationsfehlern zu schützen, haben wir eine strikte Defense-in-Depth-Netzwerktopologie (tiefgestaffelte Verteidigung) implementiert. Innerhalb jedes Proxmox VE-Servers sind die Dienste in voneinander getrennten virtuellen Netzwerken (vNets) vollständig isoliert.

Das Gateway für den gesamten ein- und ausgehenden Datenverkehr wird von einer virtualisierten pfSense-Firewall verwaltet. Sich auf eine einzige zustandsbehaftete (stateful) Firewall zu verlassen, birgt jedoch eine Schwachstelle, falls ein Administrator versehentlich eine zu freizügige Regel erstellt oder einen unbeabsichtigten Port öffnet. Um dieses Risiko zu mindern, nutzen wir die native Proxmox VE-Firewall-Ebene:

• Gespiegelte Konfiguration: Die Proxmox-Host-Firewall spiegelt aktiv die strengen strukturellen Regeln der primären pfSense-Firewall.
• Failover-Zugriffskontrolle: Da die Proxmox-Firewall unabhängig auf der Hypervisor-Ebene arbeitet, wird eine versehentliche Fehlkonfiguration auf der pfSense-Firewall weiterhin von der Proxmox-Ebene abgefangen und blockiert, was ein unabhängiges, aktives Eingreifen zur Änderung erfordert.
• Proaktive Bedrohungsabwehr: Das pfSense-Gateway ist zusätzlich mit lokalem Geoblocking gehärtet, um Datenverkehr aus nicht auf der Whitelist stehenden Regionen komplett zu verwerfen. Ergänzt wird dies durch eine CrowdSec-Integration, die Protokolle dynamisch analysiert und IP-Adressen blockiert, die böswilliges Verhalten zeigen.

OpenZiti Routing-Mechaniken & Komponentenarchitektur

Innerhalb jedes Servers sind die OpenZiti-Komponenten aufgeteilt, um hochriskante, öffentliche Zugangspunkte von der sicheren internen Infrastruktur zu isolieren. Jeder Knoten führt drei OpenZiti-Kernelemente aus: einen öffentlich zugänglichen Ziti Controller, einen öffentlich zugänglichen Ziti Edge Router und einen Private Ziti Router.

Die Netzwerktopologie erzwingt eine strikte gerichtete Abhängigkeit:

• Die Demilitarisierte Zone (DMZ): Der öffentlich zugängliche Ziti Controller und der Public Edge Router befinden sich in einem streng regulierten, isolierten DMZ-vNet. Dieses vNet hat keine direkten Kommunikationswege zu internen Anwendungsdiensten.
• Die Private Router-Grenze: Der Private Router sitzt tief im internen Anwendungsnetzwerk. Er ist die einzige Komponente, die autorisiert ist, Routen zu öffnen und direkt mit den lokalen OpenZiti-Service-Tunnelern zu kommunizieren. Der Public Edge Router ist strukturell davon ausgeschlossen, direkt mit den Anwendungs-Hosts zu sprechen; er muss seinen Datenverkehr stets über die sichere Grenze via Private Router leiten (Proxy).

Schritt-für-Schritt Traffic-Flows

Um die Sicherheit dieses Modells zu veranschaulichen, analysieren wir den Lebenszyklus sowohl externer als auch interner Zugriffsanfragen:

1. Externer Nutzer-Zugriffsfluss: Wenn ein externer Client (z. B. ein Laptop oder Mobiltelefon) versucht, auf ein internes Tool zuzugreifen, aktiviert der Nutzer seinen lokalen Ziti Edge Tunneler und navigiert zur Ressourcen-URL.

   • Authentifizierung: Die Anfrage erreicht den öffentlich zugänglichen Ziti Controller. Wenn der Client ein gültiges, kryptografisch signiertes Identitätszertifikat vorlegt, genehmigt der Controller die Sitzung und stellt den optimalen Routing-Pfad bereit. Ist die Identität ungültig oder fehlt sie, verwirft der Controller das Datenpaket stillschweigend, sodass das System für den Anfragenden nicht zu existieren scheint.
   • Routing: Nach der Autorisierung fließt der Datenverkehr des Benutzers via mTLS zum Public Edge Router in der DMZ, der die Verbindung an den internen Private Router übergibt. Der Private Router stellt schließlich die Verbindung zum lokalen Tunneler des Host-Dienstes her.

2. Interner Nutzer-Zugriffsfluss: Befindet sich ein Benutzer bereits physisch oder logisch innerhalb des lokalen Netzwerks, wird der Workflow auf Leistung optimiert, wobei strenge Sicherheitsgrenzen gewahrt bleiben. Anstatt ins öffentliche Internet hinaus- und wieder hineinzuspringen, umgeht die Verbindung den Public Edge Router vollständig und baut eine direkte, hochsichere interne Route auf, die ausschließlich vom Private Router verwaltet wird.

Fazit: Architektonische Ausrichtung an den NIS2-Mandaten

Über Hochverfügbarkeit und sicheres Routing hinaus fungiert diese Architektur als automatisierte Compliance-Engine. Die folgende Tabelle ordnet unsere technische Implementierung direkt den zentralen regulatorischen Säulen der EU-NIS2-Richtlinie (Artikel 21) zu:

NIS2-Säule (Artikel 21)	Technische Implementierung
Sicherheit der Netz- und Informationssysteme	OpenZiti Zero Trust Overlay, das null eingehende offene Ports und eine komplett “dunkle” Infrastruktur gewährleistet.
Kryptografie & Verschlüsselung	Striktes End-to-End mTLS für alle Datenübertragungen; automatisierte, rotierende ACME-Zertifikate über Reverse-Proxys (Caddy/Traefik/Nginx) zur Datenisolierung.
Zugangskontrolle & Identitätsmanagement	Authentik (OIDC SSO) gekoppelt mit expliziten, kryptografisch signierten OpenZiti Identity-Tunnelern auf den Endgeräten der Benutzer.
Business Continuity & Krisenmanagement	3x On-Premise Proxmox VE Server, automatisierte lokale Snapshots, tägliche standortübergreifende Remote-Replikation und aktive Kubernetes-Cluster für ein schnelles Failover.
Bewältigung von Sicherheitsvorfällen & Meldepflichten	Full-Stack-Observability über OpenTelemetry und Grafana für automatisierte Anomalieerkennung, Alarmierung und Audit-Bereitschaft.
Schwachstellen- & Risikominderung	Redundante Dual-Firewall-Schichten (pfSense + native Proxmox-Regeln) zur Neutralisierung menschlicher Fehlkonfigurationen, erweitert durch CrowdSec Threat-Intelligence und Geoblocking.

Durch die Beseitigung des traditionellen Netzwerkperimeters stellt dieser Blueprint sicher, dass sowohl Sicherheit als auch regulatorische Compliance nativ (by Design) in den Infrastruktur-Stack integriert sind.