OpenFGA v1.21.0 è un modello per la domanda a cui il login non risponde mai: questo tecnico può toccare l'oggetto di questo cliente?

OpenFGA v1.21.0 è un modello per la domanda a cui il login non risponde mai: questo tecnico può toccare l'oggetto di questo cliente?

La realtà di un MSP è fatta di molti tenant cliente, di tecnici con deleghe diverse per ogni cliente e di integrazioni macchina che agiscono da sole. Dopo l'autenticazione, la vera domanda è «questo soggetto può eseguire questa azione su questo oggetto in questo tenant?». Un token, un claim di gruppo o un evento di logout non rispondono; un punto di decisione sì. Il progetto di cui si parla qui è un modello di riferimento, non una raccomandazione: OpenFGA, repository openfga/openfga, Apache-2.0, progetto CNCF Incubating dal 28 ottobre 2025 (accettato il 14 settembre 2022), descritto dai maintainer come un motore di autorizzazione e permessi ad alte prestazioni ispirato a Google Zanzibar.

Il 5 ottobre 2026 il repository GitHub mostrava 5920 stelle e un ultimo push del 2 ottobre 2026. La release v1.21.0, pubblicata il 20 settembre 2026, elenca una sola novità, Dynamic Conditions, che il progetto indica come sperimentale. Una release più recente, la v1.22.0, è uscita il 6 ottobre 2026. Questo articolo non afferma che un prodotto Altovar usi OpenFGA.

Il resto del pezzo spiega come l'autorizzazione basata sulle relazioni si applica alla multi-tenancy di un MSP, quali prove di pin e di supply chain offrono le release, che cosa OpenFGA non è (policy di ammissione, overlay di rete, scanner) e sei controlli per gestire qualsiasi punto di decisione centrale. Login, logout e validità del token sono input; il diritto (entitlement) è una decisione presa a ogni richiesta.

Stando alla descrizione e ai topic del repository, OpenFGA è un motore di autorizzazione e permessi ispirato a Google Zanzibar. I topic elencano il controllo degli accessi basato sulle relazioni accanto a RBAC, ABAC e accesso basato su policy, più «entitlements». Questo articolo resta a quelle fonti: non offre una matrice di funzionalità, né cifre di throughput o latenza, né un elenco di utilizzatori.

La ReBAC in stile Zanzibar, detta in linguaggio da buyer, significa che i permessi derivano dalle relazioni tra soggetti e oggetti (chi è membro di quale tenant, quale sede appartiene a quale tenant, quale tecnico ha una delega su quale sede) anziché da un lungo elenco di ruoli copiato in ogni token. La decisione percorre il grafo delle relazioni. Non incolla un catalogo di ruoli in ogni JWT.

Governance, secondo la pagina del progetto CNCF letta il 5 ottobre 2026: accettato in CNCF il 14 settembre 2022, Incubating dal 28 ottobre 2025. Incubating è un livello di maturità in un processo di fondazione. Non è una certificazione di sicurezza né un contratto di supporto. Un MSP che tratta «CNCF Incubating» come «verificato per i nostri clienti» legge un'etichetta di fondazione come una garanzia per il cliente che non fornisce.

Il 5 ottobre 2026 il repository aveva 5920 stelle GitHub e 511 fork. Le stelle sono un segnale di popolarità, non una valutazione. La pagina CNCF mostra metriche LFX separate con un numero di stelle diverso; questo articolo usa il dato GitHub e non mescola i due. La licenza, come dichiarata nel repository, è Apache-2.0.

Le release recenti: v1.22.0 il 6 ottobre 2026, v1.21.0 il 20 settembre 2026, v1.20.0 l'8 settembre 2026 e v1.19.0 il 25 agosto 2026. Nessuna è segnata come pre-release. La regola di pin da ripetere: esegui la v1.21.0 o successiva e niente di precedente, con la v1.22.0 come obiettivo migliore per i nuovi rollout perché aggiunge un aggiornamento di sicurezza di una dipendenza. Non seguire un'immagine latest mobile in un ambiente cliente senza un ticket di change che nomini il tag.

Il minimo non è semplicemente «la più recente». La v1.20.0 conteneva una sezione Security: la correzione di una CVE della toolchain, una dipendenza dell'health probe ricompilata e la correzione di un advisory di OpenFGA nel percorso ListUsers. Tutto ciò che è più vecchio della v1.20.0 non ha queste correzioni; la v1.21.0 le include. La v1.22.0 aggiunge un'altra voce Security, una libreria gRPC aggiornata che risolve GO-2026-6443. La frase che un MSP può mettere in un ticket è: «la v1.20.0 ha introdotto correzioni di sicurezza, tra cui un advisory di OpenFGA nel percorso ListUsers; eseguire ≥ v1.21.0, preferibilmente v1.22.0».

Dynamic Conditions richiede parole precise. Le note della v1.21.0 la elencano come «una nuova funzionalità sperimentale» (traduzione nostra): sperimentale, non disponibile in via generale. La logica dei diritti dei clienti non dovrebbe dipendere da una funzionalità sperimentale, a meno che il cliente non accetti esplicitamente quel rischio per iscritto.

Le prove di release che un MSP può allegare a un ticket di change, come elencate nelle release v1.21.0 e v1.22.0: entrambe sono segnate come immutabili e ciascuna include file di checksum firmati, un'attestazione in-toto e uno SBOM per ogni archivio binario. Queste prove indicano che l'artefatto distribuito corrisponde a quanto pubblicato dal progetto e che hai un elenco dei componenti. Non sono un audit del codice né del tuo modello di autorizzazione.

La domanda, scritta una volta e riutilizzata: soggetto · azione · oggetto · tenant. Un tecnico, un account partner, un utente del cliente e un'integrazione macchina sono quattro tipi di soggetto. «Leggere», «modificare», «esportare» ed «eliminare» sono azioni diverse. Un dispositivo, una casella di posta, un set di backup sono oggetti. Ogni oggetto appartiene esattamente a un tenant cliente. Questa domanda in quattro parti è ciò a cui un evento di login, da solo, non risponde mai.

Relazioni invece di ruoli copiati: un tenant contiene sedi o organizzazioni; le risorse appartengono a una sede; un tecnico è legato a una sede da una delega che può avere una scadenza; un amministratore del cliente è legato solo al proprio tenant. Il punto di decisione ricava «questo tecnico può modificare questa casella di posta?» percorrendo queste relazioni.

Perché aiuta l'MSP: il diritto esce dal token e dalle migliaia di controlli if sparsi nel codice applicativo e diventa un unico punto che si può ispezionare, testare e registrare. Revocare la delega di un tecnico su un cliente significa rimuovere una relazione, non riemettere token in ogni applicazione. La modifica ha un responsabile e una traccia di audit in un unico archivio.

Il quadro difensivo: negare per impostazione predefinita, privilegio minimo e un controllo a ogni richiesta (OWASP Authorization Cheat Sheet). Il broken access control, incluso l'accesso a oggetti di un altro tenant, è la classe di errore che questo modello vuole ridurre. Un logout o un segnale di revoca può innescare un nuovo controllo; il punto di decisione è il luogo in cui il controllo avviene. È anche il motivo per cui un logout, da solo, non è una revoca del tenant.

Gatekeeper e Kyverno sono policy di ammissione Kubernetes per oggetti infrastrutturali. Decidono se un manifest può entrare in un cluster, non se un tecnico può leggere la casella di posta di un cliente. Nessuno dei due sostituisce l'altro. Un MSP che confonde policy di ammissione e diritti applicativi metterà il controllo sbagliato nel livello sbagliato.

OpenZiti è un overlay di rete zero-trust. Decide quali identità possono raggiungere quali servizi in rete; non decide i diritti applicativi sul singolo oggetto. Raggiungibilità di rete e permesso sull'oggetto sono cancelli diversi.

Trivy, Syft e DefectDojo sono scanner, generatori di SBOM e aggregatori di finding. Descrivono che cosa c'è nel tuo software e che cosa non va. Non autorizzano richieste.

Questo articolo non afferma che Auris, o un altro prodotto Altovar, usi, incorpori o integri OpenFGA. OpenFGA è citato come modello di riferimento open source per l'autorizzazione centralizzata.

Sei controlli difensivi per gestire qualsiasi punto di decisione centrale, ciascuno con ciò che vale come prova e ciò che non lo è.

Primo, inventario: quali store e modelli di autorizzazione esistono, per cliente o condivisi, e chi può modificarli. La prova è un elenco esportato e un responsabile per ogni modello. «Usiamo ReBAC» non è una prova. Secondo, pin: ≥ v1.21.0 registrata nel ticket di change, con allegato l'esito della verifica di checksum e attestazione. Un numero di stelle o un tag latest non è una prova.

Terzo, proteggi la stessa API di decisione: solo chiamanti autenticati, raggiungibile solo dal livello applicativo, operazioni di amministrazione limitate a operatori nominati con MFA. Quarto, le modifiche al modello sono modifiche al codice: revisionate, versionate e testate prima del rollout con casi espliciti di negazione tra tenant. La prova è un test che mostra che il tenant B non raggiunge l'oggetto del tenant A. «Il modello compila» non è una prova.

Quinto, esegui backup e ripristino dei dati di relazione; prova un ripristino. Un punto di decisione che perde le relazioni fallisce aperto o chiuso, ed entrambi i casi sono disservizi. Sesto, registra decisioni e modifiche al modello nel SIEM come segnali operativi, per esempio modifiche inattese al modello o picchi di negazioni dopo una release. Infine, tieni le funzionalità sperimentali fuori dai percorsi dei diritti dei clienti finché il progetto non le classifica diversamente.

In breve: Apache-2.0; CNCF Incubating dal 28 ottobre 2025; 5920 stelle GitHub il 5 ottobre 2026; versione minima v1.21.0 (20 settembre 2026), con la v1.22.0 (6 ottobre 2026) come obiettivo migliore; sotto ci sono le correzioni di sicurezza della v1.20.0; Dynamic Conditions è sperimentale. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft e DefectDojo non sostituiscono un punto di decisione applicativo centrale. Login, logout e validità del token sono input; il diritto è una decisione presa a ogni richiesta.

Questo articolo non afferma che Auris usi OpenFGA. Il modello è un'architettura di riferimento open source per la domanda dell'MSP a cui l'autenticazione, da sola, non risponde mai.