Zero-Trust Network Access in modernen SaaS-Umgebungen: Reißen Sie Ihre VPNs ein

Wir müssen über Ihre Perimeter-Sicherheit sprechen. Wenn Sie sich im Jahr 2026 immer noch auf ein traditionelles Virtual Private Network (VPN) verlassen, um interne Dienste abzusichern, bauen Sie ein massives Sicherheitsrisiko auf. Das klassische Burggraben-Modell (Castle-and-Moat-Modell) ist tot. Sobald ein Angreifer den Graben überwindet, kann er sich ungehindert lateral in Ihrem gesamten internen Netzwerk bewegen. Für moderne SaaS-Umgebungen (Software as a Service) ist dies inakzeptabel.

Der einzig gangbare Weg nach vorn ist Zero-Trust Network Access (ZTNA). In einem Zero-Trust-Modell gilt das Netzwerk selbst als feindlich. Jede einzelne Anfrage - sei es von einem remote arbeitenden Mitarbeiter im Café oder von einem Microservice innerhalb Ihres eigenen Kubernetes-Clusters - muss explizit authentifiziert, autorisiert und kontinuierlich validiert werden.

Dieser Beitrag beleuchtet die Probleme traditioneller Netzwerkperimeter, den notwendigen architektonischen Wandel hin zu ZTNA und liefert eine konkrete Implementierungsstrategie mithilfe moderner Identity-Aware Proxys.

Das Problem: Perimeter-Sicherheit ist eine Illusion

Traditionelle Netzwerksicherheit basiert auf IP-Adressen und Netzwerkgrenzen. Sie platzieren eine Firewall am Rande Ihrer Infrastruktur und ein VPN-Gateway für den Remote-Zugriff. Sobald sich ein Benutzer am VPN anmeldet, erhält er eine interne IP-Adresse und damit weitreichenden Zugriff auf das gesamte interne LAN.

Diese Architektur weist drei fatale Schwachstellen auf:

1. Implizites Vertrauen: Das System vertraut blind jeder Instanz, die von einer internen IP-Adresse aus operiert. Wenn der Laptop eines Entwicklers kompromittiert wird, hat der Angreifer einen direkten Tunnel in Ihre Produktionsumgebung.
2. Fehlende Granularität: VPNs arbeiten auf OSI-Layer 3 oder 4. Sie gewähren Zugriff auf gesamte Netzwerksegmente (Subnetze) und nicht auf einzelne Anwendungen. Sie können ohne das Verwalten eines Labyrinths komplexer Netzwerk-ACLs nicht einfach festlegen: „Alice darf auf das interne Metrics-Dashboard zugreifen, nicht aber auf die Billing-API“.
3. Schlechte Benutzererfahrung: Die Umleitung des gesamten Datenverkehrs über ein zentrales VPN-Gateway führt zu massiven Latenzen und Bandbreiten-Engpässen.

Sie sichern das Falsche. Sie sichern das Netzwerk, obwohl Sie eigentlich die Anwendung sichern sollten.

Warum es schwierig ist: Die Komplexität des identitätsbasierten Zugriffs

Wenn Zero-Trust Network Access so viel besser ist, warum setzt es dann nicht jeder ein? Weil der Übergang von einer netzwerkzentrierten zu einer identitätszentrierten Sicherheit konzeptionell und operativ komplex ist.

Es erfordert, IP-Adressen als Vertrauenseinheit aufzugeben und sie durch kryptografische Identitäten und Kontext zu ersetzen.

Folgende Punkte machen diesen Übergang anspruchsvoll:

• Identity Federation (Identitätsföderation): Sie müssen das Identitätsmanagement zentralisieren. Jede Anwendung muss in Ihren Identity Provider (IdP) integriert werden - in der Regel Google Workspace, Okta oder Azure AD. Die Nachrüstung älterer interner Tools, die nur Basic Auth oder überhaupt keine Authentifizierung unterstützen, ist eine große Herausforderung.
• Richtlinienverwaltung (Policy Management): In einer VPN-Welt ist der Zugriff binär: Entweder man befindet sich im Netzwerk oder nicht. In einer ZTNA-Welt sind Zugriffsrichtlinien hochgradig granular und kontextbezogen. Sie müssen Regeln definieren, die auf der Rolle des Benutzers, dem Gerätestatus (handelt es sich um ein firmeneigenes Gerät? Ist die Festplattenverschlüsselung aktiv?), der Uhrzeit und der Vertraulichkeit der Anwendung basieren.
• Performance und Latenz: Jede Anfrage muss abgefangen, authentifiziert und autorisiert werden. Wenn Ihr Identity-Aware Proxy langsam arbeitet, fühlt sich Ihre gesamte Anwendungssuite träge an.

Trotz dieser Herausforderungen ist dieser Wandel zwingend erforderlich. Die Kompromittierung eines Perimeters ist keine Frage des „Ob“, sondern des „Wann“.

Architektur: Der Blueprint für Zero-Trust Network Access

Eine robuste ZTNA-Architektur in einer SaaS-Umgebung ersetzt das VPN-Gateway durch einen Identity-Aware Proxy (IAP). Der Proxy sits direkt vor Ihren internen Anwendungen und vermittelt jede einzelne HTTP-Anfrage.

Die Kernkomponenten dieser Architektur sind:

1. Identity Provider (IdP): Die Quelle der Wahrheit für Benutzeridentitäten und Gruppenmitgliedschaften (z. B. Okta).
2. Device Trust Provider: Ein System, das den Zustand und Sicherheitsstatus von Endgeräten bewertet (z. B. CrowdStrike, Kolide).
3. Policy Engine: Ein zentraler Dienst, der Zugriffsregeln speichert und auswertet.
4. Identity-Aware Proxy (IAP): Der Durchsetzungspunkt (Enforcement Point). Er fängt Anfragen ab, konsultiert die Policy Engine und leitet die Anfrage entweder an die Upstream-Anwendung weiter oder weist sie ab.

Der Ablauf einer Anfrage

Wenn ein Entwickler versucht, auf einen internen Dienst zuzugreifen (z. B. metrics.internal.yourcompany.com), läuft folgender Prozess ab:

1. Das DNS des Benutzers löst den Hostnamen in die öffentliche IP des Identity-Aware Proxys auf.
2. Der Browser des Benutzers initiiert eine TLS-Verbindung zum Proxy.
3. Der Proxy prüft, ob ein gültiges kryptografisches Session-Cookie existiert. Wenn nicht, leitet er den Benutzer via OpenID Connect (OIDC) zum IdP weiter.
4. Der Benutzer authentifiziert sich am IdP (erfordert phishing-resistente MFA, z. B. einen YubiKey).
5. Der IdP leitet den Benutzer mit einem Identity-Token zurück zum Proxy.
6. Der Proxy übergibt die Identität des Benutzers, den Gerätekontext und die angeforderte URL an die Policy Engine.
7. Die Policy Engine gleicht die Anfrage mit den definierten Regeln ab (z. B. „Nur Ingenieure auf firmeneigenen Geräten dürfen auf Metriken zugreifen“).
8. Bei erfolgreicher Autorisierung leitet der Proxy die Anfrage an die Upstream-Anwendung weiter. Wichtig: Der Proxy injiziert eine Assertion (meist ein signiertes JWT) in die Anfrage-Header.
9. Die Upstream-Anwendung validiert das JWT, um sicherzustellen, dass die Anfrage tatsächlich vom vertrauenswürdigen Proxy stammt und nicht von einem manipulierten Prozess innerhalb des Clusters.

Diese Architektur bietet eine kontinuierliche Verifizierung auf Layer 7.

Implementierung: ZTNA aufbauen mit Pomerium und Kubernetes

Betrachten wir eine konkrete Implementierung. Wir verwenden Pomerium als Identity-Aware Proxy und stellen es auf einem Kubernetes-Cluster (v1.29+) bereit. Pomerium ist eine hervorragende Wahl, da es Open Source, extrem schnell und nativ in gängige IdPs integrierbar ist.

Wir setzen voraus, dass Sie ein Kubernetes-Cluster betreiben und einen Dienst haben, den Sie sicher bereitstellen möchten, wie beispielsweise ein Grafana-Dashboard.

Schritt 1: Bereitstellung von Pomerium

Zuerst müssen wir Pomerium so konfigurieren, dass es eine Verbindung zu unserem IdP herstellt. Wir nutzen dafür ein Standard-Helm-Chart. Hier ist eine beispielhafte values.yaml-Konfiguration für Pomerium unter Verwendung von Google Workspace:

# pomerium-values.yaml
authenticate:
  idp:
    provider: google
    clientID: "YOUR_GOOGLE_CLIENT_ID"
    clientSecret: "YOUR_GOOGLE_CLIENT_SECRET"
    serviceAccount: "base64_encoded_service_account_json"

ingress:
  enabled: true
  className: "nginx"
  hosts:
    - authenticate.internal.yourcompany.com
  tls:
    - secretName: pomerium-tls
      hosts:
        - authenticate.internal.yourcompany.com

config:
  # Der Shared Secret für die Kommunikation zwischen den Pomerium-Komponenten
  sharedSecret: "generate_a_random_base64_string_here"
  cookieSecret: "generate_another_random_base64_string_here"

Wenden Sie das Helm-Chart an:

helm repo add pomerium https://helm.pomerium.io
helm install pomerium pomerium/pomerium -f pomerium-values.yaml --namespace pomerium --create-namespace

Schritt 2: Definition von Zugriffsrichtlinien

Nun müssen wir unsere Grafana-Instanz absichern. Dazu definieren wir eine Ingress-Ressource mit spezifischen Annotationen, die Pomerium interpretieren kann. Anstelle eines Standard-Kubernetes-Ingress nutzen wir Pomeriums Custom Resource Definition (CRD) namens PomeriumRoute.

Hier zeigt sich die Stärke von ZTNA: Wir definieren Richtlinien als Code (Policy as Code) direkt neben dem Deployment unserer Anwendung.

# grafana-route.yaml
apiVersion: ingress.pomerium.io/v1
kind: PomeriumRoute
metadata:
  name: grafana-secure-route
  namespace: monitoring
spec:
  from: https://metrics.internal.yourcompany.com
  to: http://grafana.monitoring.svc.cluster.local:80
  policy:
    - allow:
        and:
          - domain:
              is: yourcompany.com
          - claim/groups:
              has: "engineering-team@yourcompany.com"

Diese Konfiguration besagt: Erlaube den Zugriff auf https://metrics.internal.yourcompany.com NUR DANN, wenn sich der Benutzer mit einer E-Mail-Adresse von @yourcompany.com authentifiziert UND Mitglied der Gruppe engineering-team is.

Wenden Sie die Route an:

kubectl apply -f grafana-route.yaml

Schritt 3: Validierung auf der Upstream-Seite (Der entscheidende Schritt)

Wenn Sie nach Schritt 2 aufhören, haben Sie eine Sicherheitslücke. Was passiert, wenn ein Angreifer einen Pod innerhalb Ihres Kubernetes-Clusters kompromittiert? Er könnte Pomerium komplett umgehen und Anfragen direkt an http://grafana.monitoring.svc.cluster.local:80 senden.

Um echtes Zero-Trust Network Access zu realisieren, muss die Upstream-Anwendung (Grafana) verifizieren, dass jede Anfrage tatsächlich über Pomerium autorisiert wurde.

Pomerium fügt jeder weitergeleiteten Anfrage einen Header namens X-Pomerium-Jwt-Assertion hinzu. Dieses JWT ist mit dem privaten Schlüssel von Pomerium signiert.

Ihre Anwendung muss dieses JWT validieren. Wenn Sie eigene Go-Microservices entwickeln (z. B. mit Go 1.22), können Sie eine Middleware implementieren, um diese Prüfung durchzuführen:

package main

import (
	"context"
	"crypto/rsa"
	"fmt"
	"net/http"
	"strings"

	"github.com/golang-jwt/jwt/v5"
	"github.com/lestrrat-go/jwx/v2/jwk"
)

// JWKS URL für Pomerium
const pomeriumJWKSURL = "https://authenticate.internal.yourcompany.com/.well-known/pomerium/jwks.json"

func requirePomeriumAssertion(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		assertion := r.Header.Get("X-Pomerium-Jwt-Assertion")
		if assertion == "" {
			http.Error(w, "Missing Pomerium Assertion", http.StatusUnauthorized)
			return
		}

		// Abrufen und Cachen der öffentlichen Schlüssel von Pomerium
		ctx := context.Background()
		set, err := jwk.Fetch(ctx, pomeriumJWKSURL)
		if err != nil {
			http.Error(w, "Failed to fetch keys", http.StatusInternalServerError)
			return
		}

		// Parsen und Validieren des JWT
		token, err := jwt.Parse(assertion, func(token *jwt.Token) (interface{}, error) {
			if _, ok := token.Method.(*jwt.SigningMethodES256); !ok {
				return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
			}
			
			kid, ok := token.Header["kid"].(string)
			if !ok {
				return nil, fmt.Errorf("missing kid header")
			}

			key, ok := set.LookupKeyID(kid)
			if !ok {
				return nil, fmt.Errorf("key %v not found", kid)
			}

			var rawKey interface{}
			if err := key.Raw(&rawKey); err != nil {
				return nil, err
			}
			return rawKey, nil
		})

		if err != nil || !token.Valid {
			http.Error(w, "Invalid Assertion", http.StatusForbidden)
			return
		}

		// Weiterleitung zur Anwendung
		next.ServeHTTP(w, r)
	})
}

Durch die Durchsetzung der JWT-Validierung auf Anwendungsebene werden Netzwerkgrenzen irrelevant. Selbst wenn sich ein Angreifer im selben Subnetz befindet, kann er die Autorisierungsprüfungen nicht umgehen.

Fallstricke: Woran ZTNA-Implementierungen scheitern

Die Bereitstellung eines Identity-Aware Proxys ist relativ einfach. Die tatsächliche Umstellung einer Organisation auf ein Zero-Trust-Modell ist jedoch schwierig. Hier sind typische Fehlerquellen:

1. Vernachlässigung von Altsystemen (Legacy Applications)

Moderne SaaS-Apps basieren auf HTTP und unterstützen nativ OAuth oder OIDC. Ältere interne Tools tun das oft nicht. Sie verlassen sich eventuell auf fest codierte IP-Adressen oder einfache Basic-Authentication.

Versuchen Sie nicht, diese Anwendungen sofort komplett neu zu schreiben. Nutzen Sie stattdessen Ihren Proxy, um Header einzufügen oder eine Übersetzung für Basic-Auth durchzuführen. Wenn eine Anwendung ein Nicht-HTTP-Protokoll verwendet (wie SSH oder RDP), benötigen Sie einen Proxy, der Tunneling unterstützt (sowohl Pomerium als auch Teleport beherrschen dies gut).

2. Das „Break-Glass“-Antipattern

Teams implementieren oft strenge ZTNA-Richtlinien, lassen jedoch ein VPN als Hintertür laufen, „für den Fall“, dass der Identity Provider ausfällt. Das macht das gesamte Konzept zunichte. Angreifer werden dieses VPN finden.

Bauen Sie stattdessen Redundanz in Ihre ZTNA-Architektur ein. Verwenden Sie mehrere IdPs oder stellen Sie sicher, dass Ihr Proxy Richtlinienentscheidungen und kryptografische Schlüssel zwischenspeichern kann, um kurze Ausfälle des IdPs zu überbrücken.

3. Alarm-Müdigkeit (Alert Fatigue)

Eine Zero-Trust-Architektur erzeugt riesige Mengen an Logdaten. Jede einzelne Anfrage ist ein Autorisierungsereignis. Wenn Sie all diese Logs ungefiltert in ein SIEM leiten, wird Ihr Sicherheitsteam schnell von der Flut an Meldungen überwältigt.

Konzentrieren Sie sich beim Logging vor allem auf abgewiesene Anfragen, die von bekannten Firmengeräten stammen, oder auf auffällige Login-Muster (wie unmögliche geografische Ortswechsel) in Ihren Identitäts-Logs.

Fazit: Ein resilientes modernes SaaS

Der Wechsel zu Zero-Trust Network Access ist eine erhebliche Investition in Ihr Engineering. Er erfordert Schulungen der Teams, Aktualisierungen der Infrastruktur und ein grundlegend neues operatives Denken.

Doch das Ergebnis ist ein fundamental widerstandsfähigeres Unternehmen.

Wenn Sie das VPN abschaffen, verabschieden Sie sich auch vom Konzept der internen vs. externen Netzwerke. Sie gewähren Zugriff basierend auf Identität und Kontext, nicht auf IP-Adressen. Sie erhalten lückenlose Sichtbarkeit darüber, wer wann auf was zugreift.

Vor allem aber reduzieren Sie die Schadensreichweite (Blast Radius) eines kompromittierten Endpunkts drastisch. In einer perimeterbasierten Welt ist ein gestohlener Entwickler-Laptop eine Katastrophe. In einer Zero-Trust-Welt ist es ein eingrenzbarer Vorfall.

Reißen Sie Ihre Burggräben ein. Sichern Sie Ihre Anwendungen. Beginnen Sie noch heute mit dem Aufbau einer Zero-Trust-Architektur.