OpenFGA v1.21.0 este un model pentru întrebarea la care autentificarea nu răspunde niciodată: poate acest tehnician să atingă obiectul acestui client?

OpenFGA v1.21.0 este un model pentru întrebarea la care autentificarea nu răspunde niciodată: are voie acest tehnician să atingă obiectul acestui client?

Realitatea unui MSP înseamnă mulți tenanți ai clienților, tehnicieni cu delegări diferite la fiecare client și integrări automate care acționează singure. După autentificare, adevărata întrebare este: „are voie acest subiect să efectueze această acțiune asupra acestui obiect în acest tenant?” Un token, un claim de grup sau un eveniment de deconectare nu răspund la ea; un punct de decizie răspunde. Proiectul discutat aici este un model de referință, nu o recomandare: OpenFGA, depozitul openfga/openfga, Apache-2.0, proiect CNCF Incubating din 28 octombrie 2025 (acceptat pe 14 septembrie 2022), descris de mentenanți ca un motor de autorizare și permisiuni de înaltă performanță, inspirat de Google Zanzibar.

Pe 5 octombrie 2026, depozitul GitHub avea 5920 de stele și un ultim push pe 2 octombrie 2026. Versiunea v1.21.0, publicată pe 20 septembrie 2026, listează o singură noutate, Dynamic Conditions, pe care proiectul o marchează ca experimentală. O versiune mai nouă, v1.22.0, a urmat pe 6 octombrie 2026. Acest articol nu afirmă că vreun produs Altovar folosește OpenFGA.

Restul articolului arată cum se aplică autorizarea bazată pe relații structurii de tenanți a unui MSP, ce dovezi de fixare a versiunii și de lanț de aprovizionare oferă versiunile, ce nu este OpenFGA (politică de admitere, overlay de rețea, scanere) și șase controale pentru operarea oricărui punct central de decizie. Autentificarea, deconectarea și valabilitatea token-ului sunt date de intrare; dreptul de acces este o decizie luată la fiecare cerere.

Conform descrierii și subiectelor (topics) din depozit, OpenFGA este un motor de autorizare și permisiuni inspirat de Google Zanzibar. Subiectele menționează controlul accesului bazat pe relații alături de RBAC, ABAC și accesul bazat pe politici, plus „entitlements”. Acest articol se limitează la aceste surse: nu oferă o matrice de funcționalități, cifre de debit sau de latență ori o listă de utilizatori.

ReBAC în stilul Zanzibar înseamnă, pe limba cumpărătorului, că permisiunile derivă din relațiile dintre subiecți și obiecte (cine este membru al cărui tenant, ce locație aparține cărui tenant, ce tehnician are delegare pentru ce locație), nu dintr-o listă lungă de roluri copiată în fiecare token. Decizia parcurge graful relațiilor. Nu lipește un catalog de roluri în fiecare JWT.

Guvernanță, conform paginii proiectului la CNCF, citită pe 5 octombrie 2026: acceptat în CNCF pe 14 septembrie 2022, Incubating din 28 octombrie 2025. Incubating este un nivel de maturitate într-un proces al fundației. Nu este o certificare de securitate și nici un contract de suport. Un MSP care tratează „CNCF Incubating” drept „auditat pentru clienții noștri” citește o etichetă a fundației ca pe o garanție pentru client pe care aceasta nu o oferă.

Pe 5 octombrie 2026, depozitul avea 5920 de stele pe GitHub și 511 fork-uri. Stelele sunt un semnal de popularitate, nu o evaluare. Pagina CNCF afișează metrici LFX separate, cu un alt număr de stele; acest articol folosește cifra de pe GitHub și nu le amestecă. Licența declarată în depozit este Apache-2.0.

Versiunile recente: v1.22.0 pe 6 octombrie 2026, v1.21.0 pe 20 septembrie 2026, v1.20.0 pe 8 septembrie 2026 și v1.19.0 pe 25 august 2026. Niciuna nu este marcată ca pre-lansare. Regula de fixare de repetat: rulează v1.21.0 sau mai nouă și nimic mai vechi, iar v1.22.0 este ținta mai bună pentru implementări noi, pentru că adaugă o actualizare de securitate a unei dependențe. Nu urmări o imagine latest flotantă într-un mediu al clientului fără un tichet de schimbare care să numească tag-ul.

Pragul minim nu înseamnă doar „cea mai nouă”. v1.20.0 avea o secțiune Security: corectarea unui CVE din lanțul de instrumente, o dependență a sondei de sănătate recompilată și corectarea unui aviz de securitate OpenFGA în calea ListUsers. Tot ce este mai vechi decât v1.20.0 nu are aceste corecturi; v1.21.0 se bazează pe ele. v1.22.0 adaugă încă o intrare Security, o bibliotecă gRPC actualizată care rezolvă GO-2026-6443. Fraza pe care un MSP o poate pune într-un tichet este: „v1.20.0 a adus corecturi de securitate, inclusiv un aviz OpenFGA în calea ListUsers; rulați ≥ v1.21.0, de preferință v1.22.0.”

Dynamic Conditions cere o formulare atentă. Notele versiunii v1.21.0 o prezintă drept „o nouă funcționalitate experimentală” (traducerea noastră): experimentală, nu disponibilă general. Logica drepturilor clienților nu ar trebui să depindă de o funcționalitate experimentală decât dacă clientul acceptă explicit acest risc, în scris.

Dovezile de versiune pe care un MSP le poate atașa unui tichet de schimbare, așa cum sunt listate la versiunile v1.21.0 și v1.22.0: ambele sunt marcate ca imuabile, iar fiecare include fișiere de sume de control semnate, o atestare in-toto și un SBOM pentru fiecare arhivă binară. Aceste dovezi susțin că artefactul implementat corespunde celui publicat de proiect și că ai o listă de componente. Nu sunt un audit al codului sau al modelului tău de autorizare.

Întrebarea, scrisă o dată și refolosită: subiect · acțiune · obiect · tenant. Un tehnician, un cont de partener, un utilizator al clientului și o integrare automată sunt patru tipuri de subiecți. „Citire”, „modificare”, „export” și „ștergere” sunt acțiuni diferite. Un dispozitiv, o căsuță de e-mail, un set de backup sunt obiecte. Fiecare obiect aparține exact unui singur tenant al unui client. La această întrebare în patru părți un eveniment de autentificare nu răspunde niciodată singur.

Relații în loc de roluri copiate: un tenant conține locații sau organizații; resursele aparțin unei locații; un tehnician este legat de o locație printr-o delegare care poate fi limitată în timp; un administrator al clientului este legat doar de propriul tenant. Punctul de decizie deduce „are voie acest tehnician să modifice această căsuță de e-mail?” parcurgând aceste relații.

De ce ajută MSP-ul: dreptul de acces iese din token și din miile de verificări if împrăștiate în codul aplicațiilor și devine un singur loc care poate fi inspectat, testat și jurnalizat. Revocarea delegării unui tehnician la un client înseamnă eliminarea unei relații, nu reemiterea token-urilor în fiecare aplicație. Schimbarea are un responsabil și o pistă de audit într-un singur depozit de date.

Cadrul defensiv: refuz implicit, privilegiu minim și o verificare la fiecare cerere (OWASP Authorization Cheat Sheet). Controlul accesului defectuos (broken access control), inclusiv accesul la obiectele altui tenant, este clasa de eșec pe care acest model urmărește să o reducă. O deconectare sau un semnal de revocare poate declanșa o nouă verificare; punctul de decizie este locul unde are loc aceasta. Tot de aceea o deconectare, singură, nu este o revocare la nivel de tenant.

Gatekeeper și Kyverno sunt politici de admitere Kubernetes pentru obiecte de infrastructură. Ele decid dacă un manifest poate intra într-un cluster, nu dacă un tehnician poate citi căsuța de e-mail a unui client. Niciunul nu îl înlocuiește pe celălalt. Un MSP care confundă politica de admitere cu drepturile din aplicație va pune controlul greșit în stratul greșit.

OpenZiti este un overlay de rețea zero trust. Decide ce identități pot ajunge la ce servicii din rețea; nu decide drepturile din aplicație la nivel de obiect. Accesibilitatea în rețea și permisiunea asupra unui obiect sunt porți diferite.

Trivy, Syft și DefectDojo sunt scanere, generatoare de SBOM și instrumente de agregare a constatărilor. Ele descriu ce conține software-ul tău și ce este în neregulă cu el. Nu autorizează cereri.

Acest articol nu spune că Auris sau vreun alt produs Altovar folosește, încorporează sau integrează OpenFGA. OpenFGA este citat ca model de referință open source pentru autorizarea centralizată.

Șase controale defensive pentru operarea oricărui punct central de decizie, fiecare cu ce înseamnă o dovadă și ce nu este o dovadă.

Primul, inventarul: ce depozite și modele de autorizare există, separate pe clienți sau comune, și cine le poate modifica. Dovada este o listă exportată și un responsabil pentru fiecare model. „Folosim ReBAC” nu este o dovadă. Al doilea, fixarea versiunii: ≥ v1.21.0 consemnată în tichetul de schimbare, cu rezultatul verificării sumelor de control și a atestării atașat. Un număr de stele sau un tag latest nu sunt dovezi.

Al treilea, protejează chiar API-ul de decizie: doar apelanți autentificați, accesibil doar din stratul de aplicație, operații de administrare limitate la operatori numiți, cu MFA. Al patrulea, schimbările de model sunt schimbări de cod: revizuite, versionate și testate înainte de implementare cu cazuri explicite de refuz între tenanți. Dovada este o rulare de test care arată că tenantul B nu poate ajunge la obiectul tenantului A. „Modelul s-a compilat” nu este o dovadă.

Al cincilea, fă backup și restaurare pentru datele despre relații; exersează o restaurare. Un punct de decizie care și-a pierdut relațiile cedează fie deschis, fie închis, iar ambele situații sunt întreruperi. Al șaselea, trimite deciziile și schimbările de model în SIEM ca semnale operaționale, de exemplu modificări neașteptate ale modelului sau vârfuri de refuzuri după o versiune. În fine, ține funcționalitățile experimentale departe de căile drepturilor clienților până când proiectul le clasifică altfel.

Pe scurt: Apache-2.0; CNCF Incubating din 28 octombrie 2025; 5920 de stele pe GitHub pe 5 octombrie 2026; versiunea minimă v1.21.0 (20 septembrie 2026), cu v1.22.0 (6 octombrie 2026) drept țintă mai bună; dedesubt se află corecturile de securitate din v1.20.0; Dynamic Conditions este experimentală. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft și DefectDojo nu înlocuiesc un punct central de decizie în aplicație. Autentificarea, deconectarea și valabilitatea token-ului sunt date de intrare; dreptul de acces este o decizie luată la fiecare cerere.

Acest articol nu afirmă că Auris folosește OpenFGA. Modelul este o arhitectură de referință open source pentru întrebarea MSP la care autentificarea, singură, nu răspunde niciodată.