Test dell’isolamento tra tenant: un cliente può accedere ai dati di un altro?

La decisione che questa guida vi aiuta a prendere

Utilizzi due tenant sintetici e modifichi una sola relazione di titolarità per volta. Verifichi ogni operazione separatamente ed esamini gli effetti a valle. Una risposta di accesso negato su un endpoint non dimostra l’isolamento di esportazioni, processi asincroni o altre azioni sullo stesso oggetto.

Mantenere costante una variabile

Iniziate con una richiesta valida per il tenant A. Ripetete l’operazione con un’identità del tenant B mantenendo invariato l’oggetto, quindi testate un oggetto diverso con l’identità originale. Questi confronti controllati aiutano a distinguere un errore di autorizzazione da una richiesta non valida o da un prerequisito mancante.

Verificare ogni operazione separatamente

Lettura, aggiornamento, approvazione, esportazione ed eliminazione possono essere soggetti a controlli in punti diversi. Il fatto che un endpoint di elenco filtri correttamente gli oggetti dice poco su un endpoint diretto agli oggetti o su un download di esportazione. Usate la matrice dei ruoli documentata per decidere cosa consentire e cosa negare.

Guardare oltre lo stato della risposta

Verificare la titolarità dell’oggetto, lo stato persistente e l’identità di audit. Alcuni servizi restituiscono una risposta generica di esito positivo prima che un processo in background esegua l’azione. Seguire l’attività approvata fino al risultato e confermare quali dati o autorizzazioni del tenant ha utilizzato.

Ritestare il confine della policy

Una correzione duratura associa sul server il principal autenticato al tenant, all’oggetto e all’operazione pertinenti. Verifichi sia la delega legittima sia il diniego. Gli identificatori casuali e i controlli nascosti possono ridurre le scoperte accidentali, ma non sostituiscono la decisione di autorizzazione aziendale.

Utilizzare un insieme di confronto scelto con criterio

Create due organizzazioni clienti con risorse sintetiche e identità di test separate. Verificate innanzitutto che ciascuna possa eseguire le operazioni legittime. Ripetete quindi un’operazione concordata sull’oggetto canary dell’altra organizzazione, mantenendo invariato il resto della richiesta. In questo modo il risultato è più facile da interpretare rispetto alla sostituzione casuale degli identificativi. Considerate separatamente i ruoli effettivi tra organizzazioni previsti dal prodotto: un operatore di supporto o della piattaforma può essere soggetto a una policy diversa da quella di un normale utente cliente.

Testi le diverse classi di operazioni, se presenti: recupero, modifica, esportazione, ricerca e azioni amministrative. Il buon esito di un confronto in sola lettura non dimostra che ogni percorso che gestisce lo stesso oggetto applichi la medesima decisione di policy.

Cerchi i cambiamenti di contesto all’interno del flusso di lavoro

Il contesto di titolarità può passare dal servizio web a una coda, un worker, una cache o un archivio di file. Individui questi passaggi nell’ambito e stabilisca dove la decisione attesa debba restare vincolata all’organizzazione richiedente. Il corretto rifiuto di una chiamata dal frontend è un riscontro utile, ma un’esportazione asincrona o un link ai risultati accessibile indipendentemente può richiedere una verifica separata. Utilizzi dati sintetici e un insieme ristretto di operazioni approvato dal responsabile.

La guida all’autorizzazione nei portali per i pazienti esamina cambiamenti analoghi nelle relazioni di accesso, compresi l’accesso delegato e la revoca. Le regole aziendali sono diverse, ma in entrambi i contesti è utile verificare il ciclo di vita di un’autorizzazione, anziché limitarsi alla sua creazione iniziale.

Ritestare la policy e il flusso di lavoro consentito

Formuli la condizione di accettazione specificando identità principale, operazione e titolarità. Registri la risposta di negazione e gli eventuali stati successivi pertinenti, indicando un riferimento di correlazione ove disponibile. Dopo la correzione, verifichi che il cliente legittimo possa ancora eseguire l’azione prevista e che l’interfaccia adiacente concordata applichi la stessa policy. Se l’implementazione centralizza l’autorizzazione, convalidi il risultato osservato invece di presumere che la modifica architetturale sia sufficiente.

Quando un’azione trasferisce valore o modifica lo stato di una transazione, utilizzare i confronti aggiuntivi della nostra guida al penetration test dell’autorizzazione dei pagamenti. La titolarità del tenant e la separazione tra chi dispone e chi verifica sono controlli complementari; un rilievo dovrebbe identificare quale decisione non ha funzionato, invece di usare «controllo degli accessi» come formula generica non spiegata.

Applicate le indicazioni

Utilizzate la lista di preparazione per documentare le ipotesi oppure consultate il rapporto fittizio di Fintech AG per esempi di evidenze e piani di trattamento. Contattate Atlant Security con una descrizione non sensibile dell’ambito.