Distributed Infrastructure Security: A Zero Trust & NIS2 Compliance Blueprint

Detailed Report

The Perimeter Security Fallacy (The Status Quo)

Historically, enterprise IT infrastructure has relied on a “castle-and-moat” security model. In this paradigm, perimeter firewalls act as the castle walls, while Virtual Private Networks (VPNs) serve as the drawbridge. Once a user or device successfully authenticates through the VPN and crosses the perimeter, they are largely trusted and granted broad access to the internal network.

However, this status quo presents severe architectural vulnerabilities. If a threat actor breaches the perimeter, whether through compromised credentials, phishing, or unpatched VPN vulnerabilities, they gain unrestricted lateral movement across the internal network. Furthermore, maintaining this legacy perimeter explicitly requires opening public-facing inbound ports to the internet. This creates a constant, highly discoverable attack surface for automated scanners and malicious actors.

Regulatory Driver: Achieving NIS2 Compliance

The escalating frequency of lateral-movement attacks and supply chain compromises has prompted a structural shift in European cybersecurity legislation. The EU NIS2 Directive (Article 21) transitions cybersecurity from a purely technical IT concern into a strict corporate governance and compliance mandate for essential entities.

Under NIS2, organizations are legally required to implement robust risk management measures, including strict access controls, incident handling, and absolute business continuity. Relying on legacy open-port firewalls often fails to satisfy these rigorous regulatory expectations.

By replacing network-level trust with cryptographically verified, identity-based access, our Zero Trust Architecture (ZTA) serves as an active compliance framework. It proactively neutralizes the risks of internal lateral movement, ensuring that the infrastructure operates well within the directive’s core security and resilience pillars.

The Zero Trust Paradigm & OpenZiti

To move beyond the flawed perimeter model and satisfy NIS2 mandates, we engineered the network around the core tenet of Zero Trust: “Never trust and always verify.” Trust is never granted based on network location (e.g., being plugged into the office LAN or connected to the VPN). Instead, every individual access request must be explicitly authenticated and authorized before a connection is even established.

To achieve this, we utilized OpenZiti, an open-source, identity-centric network overlay. OpenZiti fundamentally changes how traffic routes through the infrastructure:

• Identity Over IP: Routing is determined by cryptographically verified identities (using X.509 certificates), not IP addresses. If a device lacks a valid identity, the network controller mathematically ignores the request.
• Dark Infrastructure: OpenZiti eliminates the need for inbound open ports. Internal services establish outbound-only connections to the Ziti overlay. To the public internet and malicious port scanners, the internal infrastructure is completely invisible.
• End-to-End mTLS: All traffic traversing the OpenZiti overlay is heavily encrypted using mutual TLS (mTLS), ensuring absolute data integrity and confidentiality in transit.

A Note of Appreciation: At this point, a big and heartwarming greeting to the OpenZiti team for making such a great tool. You can find the project here or engage with the community here.

High-Availability Infrastructure & Business Continuity

A critical pillar of the NIS2 Directive is disaster recovery and operational resilience. Securing an infrastructure is irrelevant if the underlying systems cannot survive hardware failures or localized outages.

To ensure continuous operation, the physical foundation of this architecture is distributed across three on-premise servers located at different physical sites.

• Proxmox Virtual Environment (VE): Each physical location runs multiple virtualized nodes orchestrated via Proxmox VE to handle high concurrency and automated fallback scenarios.
• Kubernetes (K8s) Orchestration: Containerized workloads are managed via Kubernetes, ensuring that services can dynamically scale across the distributed nodes based on real-time demand.
• Redundant Data Replication: Each site runs an independent instance of Proxmox Backup Server. The system automates local snapshots and synchronizes daily remote backups across all physical locations.
• Distributed Datastore: The architecture leverages a distributed datastore and caching layer. This guarantees that multiple, highly recent copies of all critical data exist at every location, enabling seamless failover routing without data loss if a primary node goes offline.

Network Topology & The Dual-Firewall Defensive Strategy

To prevent a single point of failure and safeguard against human configuration errors, we implemented a strict defense-in-depth network topology. Within each Proxmox VE server, services are completely isolated from one another inside distinct virtual networks (vNets).

The gateway for all inbound and outbound traffic is managed by a virtualized pfSense firewall. However, relying on a single stateful firewall leaves a vulnerability if an administrator accidentally creates an over-permissive rule or opens an unintended port. To mitigate this risk, we leverage the native Proxmox VE firewall layer:

• Mirrored Configuration: The Proxmox host firewall actively mirrors the strict structural rules of the primary pfSense firewall.
• Failover Access Control: Because the Proxmox firewall operates independently at the hypervisor layer, an accidental misconfiguration on the pfSense firewall will still be intercepted and blocked by the Proxmox layer, requiring independent, active intervention to change.
• Proactive Threat Mitigation: The pfSense gateway is further hardened with localized Geoblocking to drop traffic from non-whitelisted regions entirely, alongside a CrowdSec integration that dynamically analyzes logs and bans IP addresses exhibiting malicious behavior.

OpenZiti Routing Mechanics & Component Architecture

Within each server, OpenZiti’s components are compartmentalized to isolate high-risk public access points from the secure internal infrastructure. Each node runs three core OpenZiti elements: a public-facing Ziti Controller, a public-facing Ziti Edge Router, and a Private Ziti Router.

The network topology enforces a strict directional dependency:

• The Demilitarized Zone (DMZ): The public-facing Ziti Controller and Public Edge Router are placed in a tightly regulated, isolated DMZ vNet. This vNet has no direct communication paths to internal application services.
• The Private Router Boundary: The Private Router sits deep within the internal application network. It is the only component with authorization to open routes and communicate directly with the local OpenZiti service tunnelers. The Public Edge Router is structurally blocked from speaking directly to application hosts; it must always proxy its traffic across the secure boundary via the Private Router.

Step-by-Step Traffic Flows

To illustrate the security of this model, we analyze the lifecycle of both external and internal access requests:

1. External User Access Flow: When an external client (e.g., a laptop or mobile phone) attempts to access an internal tool, the user activates their local Ziti Edge Tunneler and navigates to the resource URL.

   • Authentication: The request hits the public-facing Ziti Controller. If the client presents a valid, cryptographically signed identity certificate, the controller approves the session and provides the optimal routing path. If the identity is invalid or missing, the controller silently drops the packet, making the system appear non-existent.
   • Routing: Once authorized, the user’s traffic flows via mTLS to the Public Edge Router in the DMZ, which hands the connection off to the internal Private Router. The Private Router finally establishes the link to the host service’s local tunneler.

2. Internal User Access Flow: If a user is already physically or logically inside the localized network, the workflow optimizes for performance while maintaining strict security boundaries. Instead of bouncing out to the public internet, the connection bypasses the Public Edge Router entirely, establishing a direct, highly secure internal route managed exclusively by the Private Router.

Conclusion: Architectural Alignment with NIS2 Mandates

Beyond high availability and secure routing, this architecture functions as an automated compliance engine. The table below maps our technical implementation directly to the core regulatory pillars of the EU NIS2 Directive (Article 21):

NIS2 Pillar (Article 21)	Technical Implementation
Network & Information System Security	OpenZiti Zero Trust overlay, ensuring zero inbound open ports and completely dark infrastructure.
Cryptography & Encryption	Strict end-to-end mTLS for all data in transit; automated rotating ACME certificates via reverse proxies (Caddy/Traefik/Nginx) for data isolation.
Access Control & Identity Management	Authentik (OIDC SSO) coupled with explicit, cryptographically signed OpenZiti identity tunnelers on end-user devices.
Business Continuity & Crisis Management	3x On-prem Proxmox VE servers, automated local snapshots, daily cross-site remote replication, and active Kubernetes clusters for rapid failover.
Incident Handling & Reporting	Full-stack observability via OpenTelemetry and Grafana for automated anomaly detection, alerting, and audit readiness.
Vulnerability & Risk Mitigation	Redundant dual-firewall layers (pfSense + native Proxmox rules) to neutralize human misconfiguration, enhanced by CrowdSec threat intelligence and Geoblocking.

By eliminating the legacy network perimeter, this blueprint ensures that both security and regulatory compliance are natively built into the infrastructure stack.