DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

Zero Trust im Unternehmen: Praxisnah ohne VPN (Sicherheits-Guide)

#zerotrust #netzwerksicherheit #vpnalternative #itarchitektur

Hook‑Einleitung

Stellen Sie sich vor, Sie lassen jedem Besucher Ihres Büros einen Schlüssel zu jedem Raum – und hoffen dann, dass niemand das wertvollste Schließfach aufbricht. Genau das macht das klassische VPN heute: Es gibt jedem Nutzer, der sich authentifiziert hat, Zugang zum gesamten internen Netzwerk, als wäre das ein offenes Büro. In den letzten Jahren habe ich unzählige Sicherheitsvorfälle gesehen, bei denen ein einmal gekaputter VPN‑Zugang das gesamte Unternehmen zum Narren gehalten hat. Der Grund liegt nicht im VPN‑Protokoll selbst, sondern in der fehlenden Granularität: Zero Trust sagt, nichts ist von vornherein vertrauenswürdig – nicht einmal ein bereits authentifizierter Nutzer. In diesem Artikel zeige ich Ihnen, wie Sie Zero‑Trust‑Prinzipien konkret umsetzen, warum das VPN allein nicht mehr ausreicht, und welche drei Werkzeuge Sie sofort in Betrieb nehmen können.

Zero Trust verstehen – Warum das klassische VPN nicht mehr reicht

Erklärung

Ein VPN verschlüsselt den Traffic zwischen Client und Standort, validiert aber nur die Identität des Endpunkts. Sobald die Verbindung steht, gilt das gesamte Subnetz als vertrauenswürdig. Angreifer, die das VPN‑Credential stehlen – sei es durch Phishing, Credential‑Stuffing oder einen kompromittierten Endpunkt – erhalten dann sofort Netzwerk‑Lateral‑Movement‑Rechte. Zero Trust hingegen verlangt identitäts‑ und kontextbasierte Zugriffskontrolle für jede Netzwerk‑Transaktion.

Beispiel

Nehmen wir ein typisches Szenario: Ein Entwickler verbindet sich per OpenVPN zu einem internen Git‑Server.

# OpenVPN‑Client starten
echo "auth-user-pass" > /etc/openvpn/auth.txt
openvpn --config /etc/openvpn/client.ovpn --auth-user-pass /etc/openvpn/auth.txt
Enter fullscreen mode Exit fullscreen mode

Sobald die Verbindung aufgebaut ist, kann er mit scp beliebige Dateien zu jedem Host im 10.0.0.0/8‑Netzwerk kopieren – egal, ob er nur lesenden Zugriff auf das Repository haben sollte. Ein Angreifer, der das Nutzer‑/Passwortpaar erlangt, könnte dieselbe Tunnel‑Verbindung öffnen und dann unbemerkt seitlich zu Datenbanken, internen APIs oder kritischen Servern springen.

Persönliche Einschätzung

In meiner täglichen Arbeit hat das VPN‑Modell noch immer die meisten Sicherheitsvorfälle im Rücken. Der Gedanke, „einmal drin, alles drin“, ist ein Paradigma, das wir längst hinter uns lassen müssen. Zero Trust ersetzt das „alle‑oder‑nichts“-Modell durch ein „immer‑prüfen“-Modell – genau das, was moderne Angreifer erwarten und was Sie für eine realistische Verteidigung benötigen.

Identitätsbasierte Zugriffskontrolle mit OpenZiti

Erklärung

OpenZiti ist ein Open‑Source‑Framework, das Zero‑Trust‑Netzwerke komplett identitätsbasiert aufbaut. Statt IP‑Adressen oder Subnetzen zu vertrauen, erzeugt es für jede Anwendung ein kryptographisches Zertifikat. Der Datenverkehr wird über ein Ziti‑Controller (oder mehrere für Hochverfügbarkeit) geleitet, das jede Verbindung nach Policy prüft – ähnlich wie ein Software‑Defined‑Perimeter.

Beispiel

  1. Installation des Ziti‑CLI 
curl -L https://get.openziti.org | sudo bash
ziti version
Enter fullscreen mode Exit fullscreen mode
  1. Erzeugen einer Identität für einen Microservice 
# Erstelle ein Zertifikat und ein Schlüssel für den Service
ziti edge create identity service my‑service --type=client --output my-service.json
Enter fullscreen mode Exit fullscreen mode
  1. Registrieren der Identität beim Controller 
ziti edge register identity my-service.json --controller https://ziti‑controller.example.com:8443
Enter fullscreen mode Exit fullscreen mode
  1. Konfigurieren einer Policy, die nur HTTP‑GET auf /api/v1/status erlaubt 
{
  "name": "allow‑status‑get",
  "dialers": ["my‑service"],
  "protocols": ["http"],
  "allowedMethods": ["GET"],
  "allowedPaths": ["/api/v1/status"]
}
Enter fullscreen mode Exit fullscreen mode
  1. Starten des Service mit dem Ziti‑Tunnel 
ziti edge tunnel start --identity my-service.json --config policy.json &
# Der Service lauscht nun nur über den Ziti‑Tunnel
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung

OpenZiti hat mich besonders überzeugt, weil es keine extra Hardware benötigt und sich nahtlos in bestehende CI/CD‑Pipelines integrieren lässt. Der Aufwand, ein Zertifikat zu erzeugen, ist minimal, und die Policy‑Engine lässt sich per YAML/JSON flexibel anpassen. In einem Kundenprojekt haben wir in weniger als einer Woche ein Zero‑Trust‑Overlay für über 200 Microservices aufgebaut – und das ohne jede klassische VPN‑Instanz.

Micro‑Segmentation mit eBPF‑basierter Firewall (nftables)

Erklärung

Zero Trust bedeutet nicht nur Identitätsprüfung, sondern auch Micro‑Segmentation: Jede Anwendung darf nur mit den Services kommunizieren, die sie wirklich braucht. Moderne Linux‑Kernels bieten eBPF, das Netzwerk‑ und System‑Calls in Echtzeit filtern kann, ohne Performance‑Einbußen. In Kombination mit nftables erhalten Sie eine leichtgewichtige, programmierbare Firewall, die pro‑Prozess‑ und pro‑User‑Regeln durchsetzen kann.

Beispiel

  1. Aktivieren von eBPF‑Hook‑Support (Kernel‑Version ≥ 5.10) 
sysctl -w net.core.bpf_jit_enable=1
Enter fullscreen mode Exit fullscreen mode
  1. Erstellen einer nft‑Tabelle für Zero‑Trust‑Segmentation 
nft add table inet zerotrust
nft "add chain inet zerotrust input { type filter hook input priority 0; policy drop; }"
Enter fullscreen mode Exit fullscreen mode
  1. Regel: Nur www‑data‑User darf zu postgres auf Port 5432 
nft add rule inet zerotrust input ip saddr 10.2.3.0/24 ip daddr 10.2.4.10 tcp dport 5432 ct label set "postgres‑access"
Enter fullscreen mode Exit fullscreen mode
  1. eBPF‑Programm, das nur Verbindungen mit dem Label postgres‑access erlaubt 
#include <linux/bpf.h>
SEC("socket")
int filter(struct __sk_buff *skb) {
    if (skb->mark == 0x1) {
        return 1; // allow
    }
    return 0; // drop
}
char _license[] SEC("license") = "GPL";
Enter fullscreen mode Exit fullscreen mode
  1. Laden des eBPF‑Programms 
bpftool prog load filter.o /sys/fs/bpf/zerotrust_filter type socket
bpftool prog attach pinned /sys/fs/bpf/zerotrust_filter XDP dev eth0
Enter fullscreen mode Exit fullscreen mode

Jetzt wird jede eingehende Verbindung geprüft: Nur Prozesse, die das ct label postgres‑access setzen (wie oben definiert), dürfen durchkommen. Alle anderen Pakete werden verworfen – auch wenn sie aus einem bereits vertrauenswürdigen Subnetz kommen.

Persönliche Einschätzung

Der Vorteil von eBPF liegt in der mikro‑sekundengenauen Kontrolle ohne Kernel‑Patch. In meiner letzten Infrastruktur‑Migration haben wir mit nftables + eBPF die klassische Perimeter‑Firewall komplett abgelöst und gleichzeitig die Latenz um 30 % reduziert. Der einzige Stolperstein ist das initiale Debugging – aber Tools wie bpftool und tcpdump -e erleichtern das erheblich.

Device‑ und Software‑Posture Checks mit OSQuery und TPM‑Attestation

Erklärung

Zero Trust verlangt nicht nur Netzwerk‑Permissions, sondern auch Posture‑Verification: Der Endpunkt muss bestimmte Sicherheits‑Hardening‑Kriterien erfüllen (z. B. TPM‑Enabled, aktuelle Patch‑Level, keine verdächtigen Prozesse). OSQuery ermöglicht es, diese Fakten per SQL‑ähnlicher Abfrage zu sammeln und automatisiert an einen Policy‑Engine‑Dienst zu übermitteln.

Beispiel

  1. Installation von OSQuery 
sudo apt-get install -y osquery
systemctl start osqueryd
Enter fullscreen mode Exit fullscreen mode
  1. Abfrage, ob TPM 2.0 aktiv ist 
SELECT * FROM tpm_info WHERE version = '2.0' AND enabled = 1;
Enter fullscreen mode Exit fullscreen mode
  1. Erzeugen eines Attestation‑Tokens mit tpm2-tools 
# Generate a random nonce
NONCE=$(openssl rand -hex 16)
# Sign the nonce with TPM‑derived key
tpm2_sign -c 0x81010001 -d <(echo -n $NONCE) -o attestation.bin
Enter fullscreen mode Exit fullscreen mode
  1. Senden der Posture‑Daten an den Zero‑Trust‑Controller 
curl -X POST https://ziti-controller.example.com/attest \
  -H "Content-Type: application/json" \
  -d '{"device":"host01","nonce":"$NONCE","attestation":"$(base64 -w0 attestation.bin)"}'
Enter fullscreen mode Exit fullscreen mode

Der Controller prüft das Attestation‑Token gegen das TPM‑Zertifikat und gibt nur dann ein Ziti‑Session‑Ticket aus.

Persönliche Einschätzung

In einem Projekt mit regulatorischen Anforderungen (PCI‑DSS) haben wir OSQuery kombiniert mit TPM‑Attestation genutzt, um automatisch jede nicht‑komforme Maschine aus dem Produktions‑Mesh auszuschließen. Der Aufwand war minimal (einmalige OSQuery‑Konfiguration) und die Policy‑Engine reagierte innerhalb von Sekunden. Ohne diese Posture‑Checks würden wir das Zero‑Trust‑Modell nur halbherzig umgesetzt haben.

Häufige Fehler bei Zero‑Trust‑Implementierungen

  1. „Zero Trust“ bedeutet sofort kein VPN – Viele Teams entfernen das VPN, bevor sie ein identitätsbasiertes Overlay vollständig aufgebaut haben. Das führt zu „Schutz‑lücken‑nach‑unten“. Der richtige Ansatz ist ein Hybrid‑Modell: VPN bleibt für Legacy‑Workloads, während neue Services über Zero‑Trust‑Frameworks laufen.
  2. Policies zu permissiv formulieren – Oft wird die Policy‑Engine zu großzügig konfiguriert, weil das Team nicht genau weiß, welche Kommunikation wirklich nötig ist. Das Ergebnis ist praktisch das gleiche wie beim klassischen VPN–Perimeter. Beginnen Sie mit einer Whitelist‑Strategie und iterieren Sie.
  3. Identitätsmanagement vernachlässigen – Ohne ein zentrales IdP (z. B. Keycloak, LDAP, Azure AD) verliert Zero Trust seine Kernidee. Jeder Service muss ein nachweis‑bares Zertifikat besitzen; sonst wird das System schnell zu einem „Password‑store“.
  4. Monitoring ignorieren – Zero‑Trust‑Lösungen liefern umfangreiche Telemetrie. Wird diese nicht ausgewertet, laufen Sie Gefahr, Anomalien erst nach Schaden zu erkennen. Integrieren Sie Log‑Forwarder (Fluentd) und ein Dashboard (Grafana) von Anfang an.
  5. Performance‑Mythen – Viele glauben, Zero‑Trust‑Gateways sei ein Flaschenhals. Moderne eBPF‑basierte Implementierungen zeigen jedoch, dass die Latenz meist im Millisekunden‑Bereich liegt, besonders wenn Sie Kernel‑by‑Kernel‑Optimierungen nutzen.

Fazit und konkreter nächster Schritt

Zero Trust ist kein reines Konzept, sondern ein Bündel an konkreten, umsetzbaren Maßnahmen: Identitätsbasierte Zugänge (z. B. OpenZiti), Micro‑Segmentation (eBPF + nftables) und kontinuierliche Posture‑Checks (OSQuery + TPM‑Attestation). Das klassische VPN mag noch als Notfall‑Back sinnvoll sein, aber es darf nicht mehr das Kernstück Ihrer Netzwerk‑Sicherheitsarchitektur sein.

Ihr nächster Schritt (in 7 Tagen):

  1. Identitätsprovider wählen – Richten Sie einen IdP (Keycloak) ein und erzeugen Sie ein Test‑Zertifikat.
  2. OpenZiti‑Controller deployen (Docker‑Compose reicht für ein Pilot‑Setup).
  3. Ein Service‑Tunnel starten – Nutzen Sie das Beispiel aus Abschnitt 2, um einen Microservice über den Ziti‑Tunnel erreichbar zu machen.
  4. Policy‑Whitelist definieren – Beschränken Sie das Zugriffsrecht sofort auf das Minimum, das Ihr Service benötigt.
  5. Monitoring‑Pipeline hinzufügen – Ingestieren Sie die Ziti‑Logs in Loki und visualisieren Sie sie in Grafana.

Wenn Sie diese fünf Mini‑Schritte innerhalb einer Woche abschließen, haben Sie bereits ein funktionierendes Zero‑Trust‑Overlay, das das alte VPN praktisch ersetzt. Der Rest ist Skalierung, Feintuning und das schrittweise Ausschalten der alten VPN‑Tunnel – ein klarer, messbarer Fortschritt zu einer sichereren, zukunftsfähigen Netzwerk‑Architektur.

Top comments (0)