Isolamento dei tenant per gli MSP: un tenant ID o un login non è autorizzazione

Un tenant ID fornito dal client, un header X-Tenant-ID, un login funzionante, una policy di Accesso Condizionale o una connessione SSO ti dicono qualcosa di utile — ma nessuno di questi, da solo, prova che chi chiama sia autorizzato a vedere i dati di un determinato cliente. Questa guida è per MSP e team IT che gestiscono o acquistano piattaforme multi-tenant: illustra, meccanismo per meccanismo, dove deve trovarsi davvero un controllo di autorizzazione lato server, dalla prima richiesta al giorno in cui un account viene disattivato.

Un tenant ID seleziona un cliente, non lo autorizza

Un tenant ID fornito dal client — nel corpo della richiesta, in un parametro di query, o ricavato da un sottodominio — è un selettore. Dice all'applicazione quale contesto cliente aprire. L'OWASP Multi-Tenant Security Cheat Sheet stabilisce la regola di fondo: lega ogni richiesta a un principal autenticato, ricava l'appartenenza al tenant di quel principal dallo stato lato server, applica controlli a livello di oggetto all'interno del tenant e mantieni i percorsi amministrativi o di break-glass separati dall'accesso tenant ordinario. Questo controllo deve funzionare ovunque un confine tenant sia rilevante, non solo alla porta d'ingresso dell'API: nelle letture e scritture, nelle azioni amministrative e nei processi in background che riprendono il lavoro dopo che la richiesta originale è terminata. Un processo attivato da una coda che eredita un tenant ID da un messaggio, senza riverificarlo, riapre esattamente la falla che il controllo originale doveva chiudere.

Un header X-Tenant-ID o un campo nel body nascondono la stessa trappola

Lo stesso errore si presenta con il nome di un header. Le API multi-tenant accettano comunemente un header X-Tenant-ID o un campo tenant nel corpo della richiesta per scegliere i dati di quale cliente una chiamata debba toccare, ed è facile trattare quel valore come sufficiente non appena viene interpretato correttamente. Le linee guida OWASP segnalano due insidie correlate: supporre che un identificativo tenant sia sicuro perché lungo o difficile da indovinare, invece di eseguire un vero controllo di autorizzazione; e lasciare che un percorso di codice normalmente vincolato al tenant ricada silenziosamente in una query senza vincoli quando il valore atteso manca o è malformato. Ciascuno dei due errori permette a chi è autenticato, ma non appartiene al tenant richiesto, di raggiungere dati che appartengono a qualcun altro.

Il login prova chi sei, non quale tenant puoi toccare

L'autenticazione risponde a una domanda diversa dall'isolamento. La NIST Special Publication 800-210, sul controllo degli accessi per i sistemi cloud, tratta l'isolamento dei tenant come una proprietà che la piattaforma stessa deve applicare su ogni API e percorso dati quando un'unica istanza software serve molti tenant, perché il cliente che usa il servizio non controlla l'infrastruttura sottostante. Il Well-Architected SaaS Lens di AWS descrive due modi in cui i fornitori costruiscono questo isolamento: in un modello «silo» ogni tenant ha risorse dedicate e un ruolo di esecuzione delimitato, più semplice da comprendere ma più difficile da gestire su larga scala; in un modello «pool» i tenant condividono l'infrastruttura e l'isolamento deve essere applicato dentro la logica applicativa a ogni richiesta. Nessuno dei due modelli è di per sé più sicuro. Ciò che conta è se un fornitore può mostrare, concretamente, come una richiesta venga vincolata al tenant di chi chiama prima che qualsiasi dato venga toccato — non che chi chiama abbia un login funzionante.

L'Accesso Condizionale protegge il login, non il percorso dei dati

Microsoft descrive l'Accesso Condizionale come un motore di policy Zero Trust basato su logica if-then: se un utente, o sempre più spesso un agente AI, prova a raggiungere una risorsa, allora una condizione come la conformità del dispositivo, il rischio di accesso o la posizione deve essere soddisfatta prima. È un cancello davvero utile — può impedire a una credenziale compromessa di avviare una sessione, o interrompere una sessione che inizia a comportarsi in modo sospetto. Ma non ha alcuna visibilità su come il backend di un'applicazione decida, una volta che una sessione esiste, quali record di quale cliente una determinata chiamata API sia autorizzata a leggere o scrivere. Se una piattaforma si fida di un valore tenant fornito dal client per prendere quella decisione, l'Accesso Condizionale ha già concluso il suo lavoro, con successo e in modo irrilevante, nel momento in cui la decisione viene presa. Un cancello di accesso ben configurato davanti a un'API mal isolata produce la stessa fuga di dati che produrrebbe senza quel cancello. La licenza Agent 365 di Microsoft sta estendendo l'Accesso Condizionale agli agenti AI, ma la stessa distinzione tra login e accesso ai dati continua a valere anche lì.

L'SSO fa entrare le persone; solo SCIM fa uscire chi lascia

La federazione risponde a «chi può accedere adesso?» Il System for Cross-domain Identity Management, standardizzato nella RFC 7644, risponde a una domanda diversa: quali account dovrebbero ancora esistere. La documentazione SCIM di Microsoft descrive il flusso tipico: un'eliminazione temporanea nel provider di identità imposta a false l'attributo active di una risorsa utente, e l'applicazione ricevente dovrebbe disabilitare o archiviare quell'utenza in risposta. Senza un'integrazione SCIM, l'accesso SSO di chi lascia smette di funzionare, ma la sua utenza — e qualsiasi accesso API residuo collegato — può restare intatta. Anche il lato provisioning ha bisogno di un proprio ambito: un token bearer SCIM dovrebbe essere emesso per ogni tenant cliente e accettato solo all'endpoint SCIM di quel tenant. Condividere un unico segreto SCIM multi-tenant tra più clienti trasforma un singolo token trapelato in un rischio di deprovisioning e di compromissione degli account tra clienti diversi.

Disabilitare l'account non termina la sessione né il token

Quando qualcuno lascia e un amministratore disabilita il suo account nel provider di identità, è facile pensare che il lavoro sia concluso. La stessa guida Microsoft sulla revoca dell'accesso dice il contrario: disabilitare un account blocca i nuovi login ma non invalida automaticamente i token di aggiornamento, le sessioni attive o i cookie del browser già rilasciati. Interrompere davvero l'accesso richiede di revocare separatamente sessioni e token e di cancellare le credenziali in cache — e, dove disponibile, la Valutazione Continua dell'Accesso applica l'interruzione più rapidamente rispetto all'attesa della scadenza naturale di un token. La bozza delle linee guida NIST sulla gestione delle sessioni fa un'osservazione correlata: possedere un token di accesso valido non è prova che una sessione sia ancora legittimamente aperta, e le sessioni del provider di identità e quelle dell'applicazione sono indipendenti tra loro, quindi terminarne una non termina l'altra. Per questo l'OWASP Session Management Cheat Sheet richiede l'invalidazione della sessione lato server con timeout sia di inattività sia assoluti, invece di affidarsi al client per scartare le credenziali.

Alcuni MSP preferiscono affidare questo lavoro di control plane a un fornitore dedicato invece di costruirlo e verificarlo da soli; Auris è una piattaforma europea di IAM-as-a-Service per MFA adattiva, SSO federato e log di audit immutabili.

Cosa fare

• Ricava l'appartenenza al tenant dai dati di identità lato server a ogni richiesta; non fidarti mai da solo di un ID, header o campo body fornito dal client.
• Applica questo controllo su ogni percorso in cui un confine tenant è coinvolto: letture, scritture, azioni amministrative e processi in background o attivati da coda.
• Rifiuta qualsiasi selettore di tenant che non sia stato confermato rispetto alle appartenenze reali del chiamante autenticato, invece di supporre che un identificativo lungo sia sicuro.
• Tratta Accesso Condizionale, SSO e associazione al tenant come controlli separati con modalità di guasto separate, e testali singolarmente.
• Attiva SCIM insieme all'SSO, delimita ogni token SCIM a un singolo tenant, e verifica che l'account di chi lascia sia disabilitato anche nel sistema di origine, non solo nel provider di identità.
• In fase di offboarding, revoca esplicitamente sessioni e token di aggiornamento su ogni applicazione toccata dalla persona, invece di fermarti a «account disabilitato».

Fonti: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — Panoramica sull'Accesso Condizionale, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.