Fünf Werkzeuge von der Anmeldung bis zur Rechteprüfung: Eine Zero-Trust-Architektur komplett mit Open Source

Zero Trust bedeutet den Verzicht auf implizites Vertrauen an jeder Stelle im Netz. Den normativen Rahmen dafür liefert NIST SP 800-207, die Referenzarchitektur der US-Standardbehörde für Zero Trust, mit der zentralen Trennung von Policy Decision Point (PDP) und Policy Enforcement Point (PEP).

Mehrere Behörden haben das Prinzip in eigene Leitlinien übersetzt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) geht von einem bereits erfolgten Einbruch aus und leitet daraus minimale Rechte für jede Entität ab.

Die Cybersecurity and Infrastructure Security Agency (CISA) ordnet die Kontrollen fünf Säulen zu; die National Security Agency (NSA) gliedert ihre Umsetzungsleitlinien von Anfang 2026 in aufeinander aufbauende Phasen. Für NIS-2-Betreiber wird die Umsetzung zudem zur Pflichtaufgabe. Der Lagebericht NIS360 2026 der European Union Agency for Cybersecurity (ENISA) weist allerdings einen ungleichen Stand quer durch die Sektoren aus.

Wer eine herstellerunabhängige Architektur aufbauen möchte, findet dafür quelloffene Komponenten für die gesamte Kette: Keycloak für die Anmeldung, OpenZiti oder NetBird für den Netzzugang, step-ca als private Public-Key-Infrastruktur (PKI) für kurzlebige Zertifikate, Secure Production Identity Framework for Everyone (SPIFFE) und SPIFFE Runtime Environment (SPIRE) für Maschinen-/Workload-Identitäten sowie OpenFGA für die Autorisierung.

Keycloak liefert die Anmeldeschicht

Am Anfang der Kette steht der Identity Provider (IdP). Keycloak ist ein quelloffener IdP unter der Schirmherrschaft der Cloud Native Computing Foundation (CNCF) und übernimmt dabei drei Aufgaben: Anmeldung und Token-Ausstellung, Echtzeit-Signalisierung bei Sicherheitsereignissen sowie die Anbindung an die Logging-Infrastruktur.

Dafür beherrscht es OpenID Connect, OAuth 2.0 und SAML und föderiert mit LDAP, Active Directory und externen Identity Providern. Version 26.7.0 hebt die System-for-Cross-domain-Identity Management-(SCIM)-API in den Preview-Status und bringt eine schlankere Multi-Cluster-Hochverfügbarkeit ohne externen Cache.

Über das OpenID Shared Signals Framework gibt Keycloak Sicherheitsereignisse in Echtzeit an angebundene Anwendungen weiter. Dafür schickt es signierte Security Event Tokens nach den Profilen Continuous Access Evaluation Profile (CAEP) 1.0 und Risk Incident Sharing and Coordination (RISC) 1.0 an registrierte Empfänger, per Push nach RFC 8935 oder per Poll nach RFC 8936.

Deaktiviert ein Administrator ein Konto, erfährt die Anwendung davon sofort und muss nicht bis zum nächsten Token-Refresh warten. Das ist genau die Verkürzung der Session-Lebensdauer, die das Zero-Trust-Prinzip der kontinuierlichen Verifikation verlangt.

Eine Phishing-resistente Anmeldung gehört zur Pflichtausstattung für Unternehmen, die Zero Trust umsetzen wollen. Dafür konfigurieren Administratoren in Keycloak über WebAuthn und Passkeys Attestierung, Resident Keys und User Verification in den Authentication Flows. Der private Schlüssel verlässt den Authenticator nicht.

Ohne übertragbares Passwort laufen Credential-Stuffing und Adversary-in-the-Middle-Angriffe ins Leere. Risikoadaptive Multi-Faktor-Authentifizierung (MFA) ergänzt das für Kontoklassen mit erhöhtem Schutzbedarf. Die ENISA-Auslegung der Angemessenheitsklausel verlangt für jede Kontoklasse eine dokumentierte Risikoabwägung.

Die Auswahl des Faktors wird damit zum prüfbaren Nachweis gegenüber der Aufsicht. Für die Erkennung von Identitätsangriffen reicht die Event-Listener-SPI per Webhook Log-in-Fehlversuche, Admin-Ereignisse und Token-Vorgänge an ein Security Information and Event Management (SIEM) oder eine Identity-Threat-Detection-and-Response-(ITDR)-Plattform weiter. Damit bedient Keycloak die ISO-27001-Maßnahmen A.8.15 (Protokollierung) und A.8.16 (Überwachungsaktivitäten) sowie die NIS-2-Pflicht zur Vorfallserkennung.

Openziti und Netbird schließen das Netz

Nach der Anmeldung folgt der Netzzugang. Das quelloffene Projekt OpenZiti baut ein Overlay aus Controllern, Routern und Identities, in dem jede Verbindung mit Mutual TLS (mTLS) abgesichert ist und Dienste ohne offene eingehende Ports erreichbar bleiben. Version 2.0 stuft redundante Controller als produktionsreif ein, macht OpenID Connect (OIDC) und JSON Web Tokens (JWT) zum Standardweg der Authentifizierung und nimmt die Verwaltung aus dem offenen Netz. Der Controller stellt für Management-API und Konsole keinen öffentlich erreichbaren Port mehr bereit; der Zugriff läuft ausschließlich über das Overlay selbst.

Mit JWT halten die Controller keine Sessions mehr vor und propagieren sie nicht an die Router, was einen Engpass aus der Steuerungsebene nimmt. Die Just-in-Time-Provisionierung von Identities über OIDC-Token verbindet den Netzzugang direkt mit Keycloak.

Version 2.0.1 liefert einen Fix gegen Privilege Escalation, erzwingt Revocation auf bestehenden Verbindungen und stellt signierte Binaries samt Software Bill of Materials (SBOM) bereit. Für Kubernetes zeigt das Projekt ein Muster mit ephemeren Identitäten, bei dem jeder Pod eine eigene X.509-Identity mit der Lebensdauer des Pods erhält. Langlebige Credentials in Secrets fallen damit weg, der Schaden eines kompromittierten Pods bleibt klein. Als vertrauenswürdige Autorität lässt sich SPIRE einbinden.

Als Alternative setzt NetBird auf ein WireGuard-Overlay mit Peer-to-Peer-Verbindungen, koordiniert über Management-Service, Signal-Server und Relay. Zu den Kernmechanismen zählen Set-up Keys für Maschinen ohne interaktiven Log-in, begrenzt in Gültigkeit und Zahl der Registrierungen, dazu Access Policies nach Default-Deny und Posture Checks auf Betriebssystem-, Client- und Geo-Kriterien.

Alle Kernkomponenten stehen unter BSD-3-Lizenz, neue Stable-Releases erscheinen im Zwei-Wochen-Takt. Hinter dem Projekt steht ein Berliner CISPA-Spinoff, das im Januar 2026 zehn Millionen US-Dollar Wagniskapital aufgenommen hat. Betreiber dürften darin eine höhere Gewähr für die dauerhafte Pflege der Codebasis sehen.

NetBird überzeugt mit schneller Inbetriebnahme, flacher Lernkurve und europäischem Ursprung; im Self-Hosting bleibt die Hochverfügbarkeit allerdings begrenzt. OpenZiti bietet die tiefere Zero-Trust-Semantik mit Diensten ohne offene eingehende Ports, SDK-Einbettung und produktionstauglicher Controller-Redundanz, verlangt dafür aber mehr Einarbeitung. Beide Wege bedienen die ISO-27001-Maßnahmen A.8.20 bis A.8.23 zu Netzsicherheit und Segmentierung.

step-CA stellt kurzlebige Zertifikate aus

Unterhalb der Netzwerkschicht liegt die private Public Key Infrastructure (PKI). Mit step-ca können Unternehmen eine quelloffene private Zertifizierungsstelle (CA) betreiben, deren ACMEv2-Server Zertifikate mit kurzer Gültigkeit ausstellt und automatisiert erneuert. Neun Provisioner-Typen decken die Ausstellungswege ab, darunter JWK, OIDC, ACME, X5C, SSHPOP, K8sSA und die Cloud-Attestierungen für AWS, GCP und Azure.

Der OIDC-Provisioner koppelt die Ausstellung an Keycloak, sodass die CA ein Zertifikat erst nach erfolgreicher Anmeldung ausgibt und die Identität des Anwenders im Subject steht. Hardware-gebundene Ausstellung deckt die ACME-Challenge „device-attest-01“ ab, die einen Nachweis über TPM oder Secure Enclave verlangt.

Kurze Gültigkeiten verändern die Risikolage. Ein Zertifikat mit 24 Stunden Laufzeit macht Sperrlisten und das Online Certificate Status Protocol (OCSP) für viele Anwendungsfälle verzichtbar, denn das Zeitfenster für einen gestohlenen Schlüssel bleibt eng. Voraussetzung dafür ist eine funktionierende Automatisierung, da manuelle Erneuerung bei diesen Intervallen nicht skaliert.

Für die ISO 27001 bedienen solche Verfahren die Maßnahmen A.8.24 (Kryptografie) und A.5.17 (Authentifizierungsinformationen). Eine native Federal-Information-Processing-Standards-(FIPS)-Zertifizierung bietet step-ca nicht; Betreiber sollten das bei Anforderungen aus regulierten US-Kontexten berücksichtigen. Im europäischen Information-Security-Management-System-(ISMS)-Umfeld genügt der Nachweis geeigneter Algorithmen und Schlüssellängen samt dokumentierter Prozesse.

Spiffe und Spire identifizieren Workloads

Neben Nutzern und Verbindungen brauchen auch Anwendungen und Dienste eine eigene Identität. Solche nicht-menschlichen Identitäten (Non-Human Identities) übersteigen die Zahl menschlicher Konten in modernen Umgebungen bereits um ein Vielfaches, und der Trend geht zu ephemeren Just-in-Time-Credentials. SPIFFE liefert das Benennungsschema, die zugehörige Implementierung SPIRE die Umsetzung. Ein SPIFFE-Verifiable-Identity-Document (SVID) kommt als X.509-Zertifikat oder JWT und benennt den Workload über eine URI der Form „spiffe://trust-domain/workload“.

Der SPIRE-Server ist die zentrale Instanz, der alle Beteiligten vertrauen und die als einzige SVIDs ausstellt. Die Agents auf den Knoten prüfen zuerst die Identität des Knotens und danach die der Workloads, anhand von Merkmalen wie Unix-UID, Kubernetes-Service-Account oder Container-Label. Beide Projekte haben bei der CNCF den Graduated Status, die höchste Reifestufe der Stiftung. Damit fallen langlebige Passwörter und API-Keys weg. Zwei Dienste weisen sich gegenseitig über TLS mit ihren SVIDs aus; ein fester Schlüssel in einer Konfigurationsdatei ist nicht mehr nötig.

Die aktuelle Version SPIRE 1.15.2 begrenzt die Zahl der Anfragen pro Aufrufer und bringt einen SPIFFE-Broker-Endpoint. Zum Plugin „azure_imds“ gibt es einen Sicherheitshinweis, den Betreiber vor dem Update lesen sollten. Was sich nicht als Zertifikat ausdrücken lässt, zum Beispiel Datenbank-Passwörter oder Zugangsdaten für Fremdsysteme, verwaltet der Secrets-Manager OpenBao, seit Version 2.6.0 mit der Möglichkeit, einzelne Namespaces getrennt zu versiegeln.

KI-Agenten verschärfen die Lage. Ein Agent handelt selbstständig, ruft Tools auf und benötigt deshalb eine eigene Identität, die sich kryptografisch überprüfen lässt; dazu kommt eine nachvollziehbare Kette bis zu dem Anwender, der ihn gestartet hat. Red Hat kombiniert dafür SPIFFE mit OAuth-Token-Exchange. Der Agent hat eine eigene Identität, die Rechte des Anwenders reicht er über getauschte Token weiter.

Beide Ebenen bleiben getrennt und trotzdem verknüpft. Die Cloud Security Alliance empfiehlt SPIFFE und SPIRE herstellerneutral als Basis für die Identität von KI-Agenten. NetFoundry liefert dazu eine quelloffene Zero-Trust-Enclave, die Model-Context-Protocol-(MCP)-Gateways ohne feste API Keys anbindet.

OpenFGA prüft feingranulare Rechte

Die Anmeldung klärt, wer jemand ist. Die Autorisierung klärt, was er mit einem einzelnen Dokument, Ticket oder Datensatz tun darf. Die Plattform OpenFGA setzt dafür das Zanzibar-Modell von Google quelloffen um (https://openfga.dev/docs/concepts). Die Rechte hängen an Beziehungen, nicht an starren Rollen.

Ein Authorization Model in einer eigenen Beschreibungssprache legt fest, welche Objekttypen es gibt und welche Beziehungen dazu möglich sind, etwa Betrachter, Bearbeiter oder Besitzer. Die einzelnen Beziehungen speichert OpenFGA als Relationship Tuples nach dem Muster Anwender, Beziehung, Objekt.

Über „Check“ beantwortet die API die Frage, ob ein bestimmter Zugriff erlaubt ist, über „ListObjects“ liefert sie alle Objekte, zu denen ein Anwender in einer bestimmten Beziehung steht. Rechte, die sich aus Gruppen, Ordnern oder der Zugehörigkeit zu einer Organisation ergeben, bildet OpenFGA über verknüpfte Beziehungen ab. Die Anwendung braucht dafür keine eigene Rechteprüfung.

Damit sitzt die Entscheidung an einer Stelle und die Durchsetzung an einer anderen, genau die Aufteilung, die NIST SP 800-207 beschreibt. OpenFGA entscheidet, die Anwendung oder ein vorgeschaltetes Gateway setzt die Antwort durch. Seit November 2025 hat das Projekt den Status CNCF-Incubating; zu den Anwendern gehören Grafana, Docker und Canonical.

In der Gesamtsicht liest sich der Ablauf mit den beschriebenen Tools von oben nach unten als eine Anfrage: Der Anwender meldet sich bei Keycloak an und bekommt ein Token. Mit diesem Token stellt OpenZiti oder NetBird die Verbindung ins Overlay her, ohne Token kommt keine Verbindung zustande. step-ca stellt die Zertifikate aus, die das Overlay und die Dienste für mTLS brauchen, gekoppelt an dieselbe Anmeldung. SPIFFE und SPIRE geben den Diensten selbst eine Identität, damit untereinander kein API Key mehr nötig ist. Am Ende prüft OpenFGA, ob dieser Anwender genau dieses Dokument öffnen darf.

Der Betrieb bleibt planbar

Quelloffene Bausteine sparen Lizenzkosten, kosten dafür aber Arbeitszeit. Keycloak etwa liefert alle zwei bis vier Wochen Sicherheitsupdates; Version 26.6.3 schloss allein sechzehn Common Vulnerabilities and Exposures (CVEs). Wer selbst hostet, braucht dafür eine feste Zuständigkeit im Team.

Migrationen über mehrere Hauptversionen hinweg gehören zuerst in eine Staging-Umgebung. Ein dokumentierter Sprung von Version 16.1.1 auf 26.6.2 scheiterte an einem Foreign-Key-Konflikt im Organizations-Feature; die Datenbank ließ sich nicht migrieren. IT-Teams mit belastbarer Praxis planen deshalb Datenbank-Snapshots, Rückfallpunkte und einen Probeimport der Realms fest ein. Der Aufwand verteilt sich ungleich über die Schichten.

Ohne den IdP läuft nichts, er braucht Hochverfügbarkeit, PostgreSQL im Cluster, TLS auf allen Strecken und eine vom Anwenderzugang getrennte Admin-Konsole – so steht es in der Produktionsreferenz von Keycloak. Danach folgt die PKI mit step-ca, mit automatischer Erneuerung und geschütztem Schlüsselmaterial der Root-CA, idealerweise offline oder im Hardware-Sicherheitsmodul (HSM). Workload-Identität mit SPIRE und Rechteprüfung mit OpenFGA lassen sich nachziehen, sobald die ersten beiden Schichten stabil laufen. Die Reihenfolge deckt sich mit dem Phasenmodell der NSA und lässt sich einem Auditor als Fahrplan vorlegen.

Die Architektur liefert die Nachweise

Die ISO 27001 schreibt keine bestimmte Technik vor, verlangt aber wirksame und belegte Kontrollen. Die hier beschriebene Architektur deckt dabei mehrere Kontrollbereiche ab: Die Identität als Ansatzpunkt bedient A.5.16 (Identitätsmanagement), A.5.17 (Authentifizierungsinformationen) und A.8.5 (sichere Authentifizierung).

Minimale Rechte erfüllen A.5.15 (Zugangssteuerung), A.5.18 (Zugangsrechte), A.8.2 (privilegierte Zugangsrechte) und A.8.3 (Beschränkung des Informationszugriffs). Laufende Prüfung und Protokollierung bedienen A.8.15 (Protokollierung) und A.8.16 (Überwachungsaktivitäten), die Mikrosegmentierung A.8.20 (Netzwerksicherheit), A.8.22 (Trennung von Netzwerken) und A.8.23 (Webfilterung), die Annahme eines bereits erfolgten Einbruchs A.5.24 bis A.5.26 (Vorfallmanagement).

Für die NIS-2-Umsetzung nach § 30 des Gesetzes über das Bundesamt für Sicherheit in der Informationstechnik (BSIG) liefert dieselbe Architektur die technischen Maßnahmen zu Zugriffskontrolle, Kryptografie, Netzsicherheit und Erkennung von Vorfällen. Beim Nachweis haben quelloffene Komponenten einen Vorteil, den kommerzielle Produkte selten bieten: Realm-Exporte, Ziti-Policies, stepca-Konfiguration, SPIRE-Registration-Entries und OpenFGA-Modelle liegen als Textdateien in der Versionskontrolle. Ein Auditor sieht damit nicht nur den aktuellen Stand, sondern zusätzlich jede Änderung mit Datum, Autor und Freigabe.

Signierte Binaries und eine SBOM aus der aktuellen OpenZiti-Version belegen die Herkunft der Software und passen zu den NIS-2-Anforderungen an Lieferantenbeziehungen. Der europäische Ursprung von NetBird stützt zudem die Argumentation zur digitalen Souveränität, ohne dass eine technische Abhängigkeit von einem US-Anbieter bleibt.

Fazit

Die Kette aus Keycloak, OpenZiti oder NetBird, step-ca, SPIFFE mit SPIRE und OpenFGA deckt Zero Trust von der Anmeldung bis zur Rechteprüfung am einzelnen Objekt quelloffen ab. Jede Schicht hat eine belastbare Codebasis, eine aktive Community und einen dokumentierten Bezug zu den Annex-A-Controls der ISO 27001. Was an Lizenzkosten wegfällt, fließt in Patch-Management, Automatisierung und Kompetenzaufbau.

Die Rechnung hängt damit am Betriebsmodell. CISOs gewinnen Auditfähigkeit und senken das Risiko, Architekten gewinnen wiederholbare Muster, Compliance-Verantwortliche prüfbare Nachweise aus der Versionskontrolle. Mit selbstständig handelnden KI-Agenten wächst das Gewicht der Maschinen-Identität, und quelloffene Projekte liefern hier bereits fertige Bausteine.