OpenFGA v1.21.0 ist ein Pattern für die Frage, die der Login nie beantwortet: Darf dieser Techniker das Objekt dieses Kunden anfassen?

OpenFGA v1.21.0 ist ein Muster für die Frage, die der Login nie beantwortet: Darf dieser Techniker das Objekt dieses Kunden anfassen?

Die Realität eines MSP sind viele Kunden-Tenants, Techniker mit je nach Kunde unterschiedlichen Delegationen und Maschinenintegrationen, die eigenständig handeln. Nach der Authentifizierung lautet die eigentliche Frage: „Darf dieses Subjekt diese Aktion an diesem Objekt in diesem Tenant ausführen?“ Ein Token, ein Gruppen-Claim oder ein Logout-Ereignis beantwortet sie nicht; ein Entscheidungspunkt schon. Das hier besprochene Projekt ist ein Referenzmuster, keine Empfehlung: OpenFGA, Repository openfga/openfga, Apache-2.0, seit dem 28. Oktober 2025 ein CNCF-Incubating-Projekt (aufgenommen am 14. September 2022), von seinen Maintainern als hochperformante Autorisierungs- und Berechtigungs-Engine beschrieben, inspiriert von Google Zanzibar.

Am 5. Oktober 2026 zeigte das GitHub-Repository 5920 Sterne und einen letzten Push am 2. Oktober 2026. Release v1.21.0, veröffentlicht am 20. September 2026, nennt eine einzige Neuerung, Dynamic Conditions, die das Projekt als experimentell kennzeichnet. Am 6. Oktober 2026 folgte mit v1.22.0 ein neueres Release. Dieser Artikel behauptet nicht, dass ein Altovar-Produkt OpenFGA verwendet.

Der Rest des Beitrags behandelt, wie sich beziehungsbasierte Autorisierung auf die Mandantenstruktur eines MSP abbilden lässt, welche Pin- und Lieferketten-Nachweise die Releases bieten, was OpenFGA nicht ist (Admission Policy, Netzwerk-Overlay, Scanner) und sechs Kontrollen für den Betrieb eines beliebigen zentralen Entscheidungspunkts. Login, Logout und Token-Gültigkeit sind Eingaben; die Berechtigung ist eine Entscheidung, die bei jeder Anfrage getroffen wird.

Laut Beschreibung und Topics des Repositorys ist OpenFGA eine von Google Zanzibar inspirierte Autorisierungs- und Berechtigungs-Engine. Die Topics nennen beziehungsbasierte Zugriffskontrolle neben RBAC, ABAC und richtlinienbasiertem Zugriff sowie „entitlements“. Dieser Artikel bleibt bei diesen Quellen: Er bietet keine Funktionsmatrix, keine Durchsatz- oder Latenzzahlen und keine Liste von Anwendern.

ReBAC im Stil von Zanzibar bedeutet in der Sprache des Einkäufers: Berechtigungen ergeben sich aus Beziehungen zwischen Subjekten und Objekten (wer Mitglied welches Tenants ist, welcher Standort zu welchem Tenant gehört, welcher Techniker für welchen Standort delegiert ist) statt aus einer langen Rollenliste, die in jedes Token kopiert wird. Die Entscheidung durchläuft den Beziehungsgraphen. Sie kopiert keinen Rollenkatalog in jedes JWT.

Governance laut der CNCF-Projektseite, gelesen am 5. Oktober 2026: am 14. September 2022 in die CNCF aufgenommen, seit dem 28. Oktober 2025 Incubating. Incubating ist eine Reifestufe in einem Stiftungsprozess. Es ist weder eine Sicherheitszertifizierung noch ein Supportvertrag. Ein MSP, der „CNCF Incubating“ als „für unsere Kunden geprüft“ versteht, liest ein Stiftungsetikett als Kundenzusicherung, die es nicht bietet.

Am 5. Oktober 2026 hatte das Repository 5920 GitHub-Sterne und 511 Forks. Sterne sind ein Popularitätssignal, keine Bewertung. Die CNCF-Seite zeigt separate LFX-Kennzahlen mit einer anderen Sternezahl; dieser Artikel verwendet die GitHub-Zahl und vermischt die beiden nicht. Die im Repository angegebene Lizenz ist Apache-2.0.

Die jüngsten Releases: v1.22.0 am 6. Oktober 2026, v1.21.0 am 20. September 2026, v1.20.0 am 8. September 2026 und v1.19.0 am 25. August 2026. Keines ist als Pre-Release markiert. Die Pin-Regel zum Wiederholen: v1.21.0 oder neuer betreiben und nichts Älteres, wobei v1.22.0 das bessere Ziel für neue Rollouts ist, weil es ein Sicherheitsupdate einer Abhängigkeit enthält. Folgen Sie in einer Kundenumgebung keinem beweglichen latest-Image ohne ein Change-Ticket, das den Tag nennt.

Die Untergrenze ist nicht einfach „das Neueste“. v1.20.0 enthielt einen Security-Abschnitt: eine CVE-Korrektur in der Toolchain, eine neu gebaute Health-Probe-Abhängigkeit und die Behebung eines OpenFGA-Advisorys im ListUsers-Pfad. Alles, was älter als v1.20.0 ist, hat diese Korrekturen nicht; v1.21.0 baut darauf auf. v1.22.0 fügt einen weiteren Security-Eintrag hinzu, eine aktualisierte gRPC-Bibliothek, die GO-2026-6443 behebt. Der Satz, den ein MSP in ein Ticket schreiben kann, lautet: „v1.20.0 brachte Sicherheitskorrekturen, darunter ein OpenFGA-Advisory im ListUsers-Pfad; ≥ v1.21.0 betreiben, vorzugsweise v1.22.0.“

Dynamic Conditions verlangt genaue Formulierung. Die Release Notes von v1.21.0 führen es als „neue experimentelle Funktion“ (unsere Übersetzung): experimentell, nicht allgemein verfügbar. Die Berechtigungslogik für Kunden sollte nicht von einer experimentellen Funktion abhängen, es sei denn, der Kunde akzeptiert dieses Risiko ausdrücklich schriftlich.

Release-Nachweise, die ein MSP an ein Change-Ticket anhängen kann, wie sie bei den Releases v1.21.0 und v1.22.0 aufgeführt sind: Beide sind als unveränderlich (immutable) markiert, und jedes liefert signierte Prüfsummendateien, eine in-toto-Attestierung und eine SBOM pro Binärarchiv. Diese Nachweise belegen, dass das bereitgestellte Artefakt dem entspricht, was das Projekt veröffentlicht hat, und dass Sie eine Komponentenliste haben. Sie sind kein Audit des Codes oder Ihres Autorisierungsmodells.

Die Frage, einmal aufgeschrieben und wiederverwendet: Subjekt · Aktion · Objekt · Tenant. Ein Techniker, ein Partnerkonto, ein Kundenbenutzer und eine Maschinenintegration sind vier Arten von Subjekten. „Lesen“, „Ändern“, „Exportieren“ und „Löschen“ sind verschiedene Aktionen. Ein Gerät, ein Postfach, ein Backup-Satz sind Objekte. Jedes Objekt gehört genau einem Kunden-Tenant. Diese vierteilige Frage beantwortet ein Login-Ereignis allein nie.

Beziehungen statt kopierter Rollen: Ein Tenant enthält Standorte oder Organisationen; Ressourcen gehören zu einem Standort; ein Techniker ist über eine Delegation, die befristet sein kann, mit einem Standort verbunden; ein Kundenadministrator ist nur mit seinem eigenen Tenant verbunden. Der Entscheidungspunkt leitet „Darf dieser Techniker dieses Postfach ändern?“ ab, indem er diese Beziehungen durchläuft.

Warum das dem MSP hilft: Die Berechtigung verlässt das Token und die Tausenden verstreuten if-Prüfungen im Anwendungscode und wird zu einer Stelle, die sich prüfen, testen und protokollieren lässt. Die Delegation eines Technikers für einen Kunden zu widerrufen heißt, eine Beziehung zu entfernen, nicht Tokens in jeder App neu auszustellen. Die Änderung hat einen Verantwortlichen und einen Audit-Trail in einem Speicher.

Der defensive Rahmen: standardmäßig verweigern, minimale Rechte und eine Prüfung bei jeder Anfrage (OWASP Authorization Cheat Sheet). Fehlerhafte Zugriffskontrolle (Broken Access Control), einschließlich des Zugriffs auf Objekte anderer Tenants, ist die Fehlerklasse, die dieses Muster verringern soll. Ein Logout oder ein Widerrufssignal kann eine erneute Prüfung auslösen; der Entscheidungspunkt ist der Ort, an dem sie stattfindet. Deshalb ist ein Logout allein auch kein Widerruf auf Tenant-Ebene.

Gatekeeper und Kyverno sind Kubernetes-Admission-Policies für Infrastrukturobjekte. Sie entscheiden, ob ein Manifest in einen Cluster darf, nicht, ob ein Techniker das Postfach eines Kunden lesen darf. Keines ersetzt das andere. Ein MSP, der Admission Policy und Anwendungsberechtigung verwechselt, setzt die falsche Kontrolle in die falsche Schicht.

OpenZiti ist ein Zero-Trust-Netzwerk-Overlay. Es entscheidet, welche Identitäten welche Dienste im Netzwerk erreichen können; über Anwendungsberechtigungen pro Objekt entscheidet es nicht. Netzwerkerreichbarkeit und Objektberechtigung sind verschiedene Tore.

Trivy, Syft und DefectDojo sind Scanner, SBOM-Generatoren und Werkzeuge zur Bündelung von Befunden. Sie beschreiben, was in Ihrer Software steckt und was daran falsch ist. Sie autorisieren keine Anfragen.

Dieser Artikel sagt nicht, dass Auris oder ein anderes Altovar-Produkt OpenFGA verwendet, einbettet oder integriert. OpenFGA wird als Open-Source-Referenzmuster für zentrale Autorisierung angeführt.

Sechs Kontrollen für Verteidiger, die einen beliebigen zentralen Entscheidungspunkt betreiben, jeweils mit dem, was als Nachweis gilt, und dem, was keiner ist.

Erstens, Inventar: Welche Stores und Autorisierungsmodelle gibt es, pro Kunde oder gemeinsam, und wer darf sie ändern? Nachweis ist eine exportierte Liste und ein Verantwortlicher pro Modell. „Wir nutzen ReBAC“ ist kein Nachweis. Zweitens, Pin: ≥ v1.21.0 im Change-Ticket festgehalten, mit angehängtem Ergebnis der Prüfsummen- und Attestierungsprüfung. Eine Sternezahl oder ein latest-Tag ist kein Nachweis.

Drittens, die Entscheidungs-API selbst schützen: nur authentifizierte Aufrufer, nur aus der Anwendungsschicht erreichbar, Admin-Operationen auf benannte Operatoren mit MFA beschränkt. Viertens, Modelländerungen sind Codeänderungen: geprüft, versioniert und vor dem Rollout mit expliziten tenantübergreifenden Deny-Fällen getestet. Nachweis ist ein Testlauf, der zeigt, dass Tenant B das Objekt von Tenant A nicht erreicht. „Das Modell kompiliert“ ist kein Nachweis.

Fünftens, die Beziehungsdaten sichern und wiederherstellen; eine Wiederherstellung üben. Ein Entscheidungspunkt mit verlorenen Beziehungen fällt entweder offen oder geschlossen aus, und beides ist ein Ausfall. Sechstens, Entscheidungen und Modelländerungen als Betriebssignale an das SIEM protokollieren, etwa unerwartete Modelländerungen oder gehäufte Ablehnungen nach einem Release. Schließlich: Experimentelle Funktionen bleiben aus den Berechtigungspfaden der Kunden heraus, bis das Projekt sie anders einstuft.

Kurz gesagt: Apache-2.0; CNCF Incubating seit dem 28. Oktober 2025; 5920 GitHub-Sterne am 5. Oktober 2026; Pin-Untergrenze v1.21.0 (20. September 2026), mit v1.22.0 (6. Oktober 2026) als besserem Ziel; die Sicherheitskorrekturen aus v1.20.0 liegen darunter; Dynamic Conditions ist experimentell. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft und DefectDojo ersetzen keinen zentralen Entscheidungspunkt in der Anwendung. Login, Logout und Token-Gültigkeit sind Eingaben; die Berechtigung ist eine Entscheidung, die bei jeder Anfrage getroffen wird.

Dieser Artikel behauptet nicht, dass Auris OpenFGA verwendet. Das Muster ist eine Open-Source-Referenzarchitektur für die MSP-Frage, die die Authentifizierung allein nie beantwortet.