Architettura multi-tenant
Una soluzione multi-tenant supporta ambiti separati per clienti o gruppi. Un tenant non equivale automaticamente a una persona o a un database.
Un’architettura multi-tenant permette a un software di supportare più clienti o gruppi separati logicamente come tenant. Un tenant può essere un’azienda con più utenti. L’assegnazione di persone e dati deve essere definita chiaramente.
Esempio e limite architetturale
In un’applicazione ipotetica, aziende diverse usano lo stesso prodotto. I loro ordini restano nell’ambito consentito. Se una persona appartiene a più ambiti, appartenenza e passaggio richiedono regole chiare.
L’implementazione può usare risorse comuni o separate; un database unico non è un requisito. Il supporto multi-tenant non dimostra nemmeno un isolamento sicuro. Accessi tramite elenchi, file, interfacce e processi in background devono rispettare i limiti previsti. Dati condivisi intenzionalmente richiedono una regola esplicita dedicata.
Fonti
Termini correlati
- Controllo degli accessi basato sui ruoliRBAC collega permessi e ruoli e assegna le persone ai ruoli. Va definito anche l’ambito dei dati a cui è consentito accedere.
- Controllo degli accessi basato sugli attributiABAC valuta gli accessi mediante proprietà e regole definite. Origine e aggiornamento delle proprietà fanno parte della progettazione.
- Sistema legacyUn sistema esistente ancora utilizzato, con dipendenze tecniche e aziendali accumulate nel tempo.
- Cache del browserLa cache del browser conserva risposte HTTP adatte. Riuso e validazione seguono le regole applicabili.
- Invalidazione della cacheL’invalidazione termina il riuso di una copia secondo regole definite. Il record di origine resta distinto.
- CachingIl caching riutilizza dati o risultati conservati. Validità e ambito degli utenti autorizzati fanno parte della progettazione.
Articoli sul tema
Sviluppo software con ASES
Software su misura, app web e mobile