Nell’esempio di AWS, l’identità dell’utente passa da Amazon Cognito a un ruolo IAM; le credenziali temporanee di quel ruolo determinano quali dati Amazon Athena può interrogare, mentre AWS Lake Formation applica le autorizzazioni. È un modello per offrire analisi a clienti distinti, o tenant, usando dati condivisi. AWS descrive il flusso nel suo tutorial.
Per isolare i tenant, il controllo decisivo è il ruolo associato all’identità e applicato alla query sui dati.
Dal login a una query Athena circoscritta
Nel flusso descritto da AWS, Amazon Cognito autentica l’utente e inserisce nel token ID l’attributo custom:team. AgentCore Gateway convalida il token di accesso e inoltra il token ID alla funzione AWS Lambda tramite l’intestazione X-ID-Token. Le regole di Cognito Identity Pool associano il valore dell’attributo a un ruolo IAM del team; Lambda scambia quindi il token per credenziali temporanee. Athena esegue la query con quelle credenziali e Lake Formation applica i permessi e i filtri previsti per il ruolo.
In questo modo, la query usa le autorizzazioni associate all’identità del cliente. Il controllo sui dati avviene attraverso ruoli e autorizzazioni applicati alla query, non affidandosi soltanto alla formulazione della richiesta in linguaggio naturale.
Perché Lambda fa da broker delle credenziali
La funzione Lambda di destinazione gestisce lo scambio delle credenziali. Nel ruolo di esecuzione dell’esempio AWS elenca due azioni: cognito-identity:GetId e cognito-identity:GetCredentialsForIdentity. Quel ruolo non riceve permessi sui dati di Athena, Amazon S3 o AWS Glue; sono le credenziali temporanee del ruolo IAM associato al team a essere usate per la query.
La distinzione è utile quando si valuta il confine di accesso: Lambda fa da intermediario per ottenere le credenziali, mentre Athena interroga i dati con il ruolo assegnato all’utente.
Cosa fanno le regole per i team
L’esempio usa i valori LF-Tag TeamA, TeamB e shared per controllare l’accesso alle tabelle. AWS associa venue a Team A, category a Team B e users al tag condiviso. Per sales_extended, applica filtri di riga specifici per team. La configurazione mostrata imposta l’accesso a tutte le colonne e filtra le righe con un’espressione come team = 'Team A'.
L’attributo custom:team è dichiarato modificabile e determina la selezione del ruolo. Ne consegue che controllare chi può cambiarlo è parte del confine di autorizzazione: un’assegnazione errata del team può indirizzare l’utente a un ruolo diverso. È un’implicazione della mappatura usata nell’esempio.
Identità esterne e verifiche descritte
Per gli utenti esterni, AWS presenta Cognito User Pools e Identity Pools. Per le identità del personale indica invece IAM Identity Center con Trusted Identity Propagation.
Nel percorso di verifica descritto da AWS, si accede come Team A e Team B e si confrontano le tabelle visibili e le righe restituite da sales_extended. Il tutorial prevede anche di modificare un tag e il filtro di riga per controllare l’accesso risultante. AWS avverte che le modifiche ai permessi di Lake Formation possono impiegare alcuni minuti a propagarsi.
