Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Definizione dei ruoli del database da assegnare agli utenti federati in Amazon Redshift serverless
Quando si fa parte di un'organizzazione, si dispone una raccolta di ruoli associati. Ad esempio, disponi di ruoli per la tua funzione lavorativa, come programmatore e manager. I ruoli determinano a quali applicazioni e dati hai accesso. La maggior parte delle organizzazioni utilizza un provider di identità, come Microsoft Active Directory, per assegnare ruoli a utenti e gruppi. L'uso dei ruoli per controllare l'accesso alle risorse è aumentato, perché le organizzazioni non devono gestire i singoli utenti.
Recentemente, il controllo degli accessi basato su ruoli è stato introdotto in Amazon Redshift serverless. Utilizzando i ruoli del database, puoi proteggere l'accesso a dati e oggetti, come ad esempio, schemi o tabelle. Oppure puoi utilizzare i ruoli per definire una serie di autorizzazioni elevate, ad esempio per un monitoraggio del sistema o un amministratore di database. Tuttavia, dopo aver concesso le autorizzazioni per le risorse ai ruoli del database, c'è una fase aggiuntiva, che consiste nel connettere i ruoli di un utente dall'organizzazione ai ruoli del database. Puoi assegnare a ciascun utente i ruoli del database al momento dell'accesso iniziale eseguendo SQL delle istruzioni, ma richiede un notevole impegno. Un modo più semplice è definire i ruoli del database da concedere e passarli ad Amazon Redshift serverless. Questa operazione ha il vantaggio di semplificare il processo di accesso iniziale.
Puoi passare ruoli ad Amazon Redshift serverless utilizzando GetCredentials
. Quando un utente accede per la prima volta a un database Amazon Redshift serverless, viene creato un utente del database associato e mappato ai ruoli del database corrispondenti. Questo argomento descrive in dettaglio il meccanismo per passare i ruoli ad Amazon Redshift serverless.
Il passaggio dei ruoli del database ha un paio di casi d'uso principali:
-
Quando un utente accede tramite un provider di identità di terze parti, in genere con la federazione configurata, e passa i ruoli tramite un tag di sessione.
-
Quando un utente accede tramite credenziali di IAM accesso e i relativi ruoli vengono passati tramite una chiave e un valore di tag.
Per ulteriori informazioni sul controllo degli accessi basato sui ruoli, vedete Role-based access control (). RBAC
Definizione dei ruoli del database
Prima di poter passare i ruoli ad Amazon Redshift serverless, è necessario configurare i ruoli del database e concedere loro le autorizzazioni appropriate sulle risorse del database. Ad esempio, in uno scenario semplice, puoi creare un ruolo del database denominato vendite e concedergli l'accesso per eseguire query sulle tabelle con i dati di vendita. Per ulteriori informazioni su come creare ruoli nel database e concedere autorizzazioni, vedere CREATEROLEe GRANT.
Casi d'uso per definire i ruoli del database da concedere agli utenti federati
Queste sezioni descrivono un paio di casi d'uso in cui il passaggio dei ruoli del database ad Amazon Redshift serverless può semplificare l'accesso alle risorse del database.
Accesso tramite un provider di identità
Il primo caso d'uso presuppone che l'organizzazione disponga di identità utente in un servizio Identity and Access Management. Questo servizio può essere basato sul cloud, ad esempio JumpCloud Okta, o locale, come Microsoft Active Directory. L'obiettivo è mappare automaticamente i ruoli di un utente dal provider di identità ai ruoli del database quando accede a un client come Query editor V2, ad esempio, o con un client. JDBC Per configurare questo controllo, è necessario completare un paio di attività di configurazione. Questi sono i seguenti:
-
Configurazione dell'integrazione federata con il gestore dell'identità digitale utilizzando una relazione di trust. È un prerequisito. Quando lo configuri, il provider di identità è responsabile dell'autenticazione dell'utente tramite un'SAMLasserzione e della fornitura delle credenziali di accesso. Per ulteriori informazioni, consulta Integrazione di fornitori di soluzioni di terze parti con. SAML AWS Per ulteriori informazioni, consulta Federate access to Amazon Redshift query editor V2 with Active Directory Federation Services (AD FS)
(Accesso federato all'editor di query Amazon Redshift v2 con Active Directory Federation Services (ADFS) o Federate single sign-on access to Amazon Redshift query editor v2 with Okta (Accesso federato SSO all'editor di query Amazon Redshift v2 con Okta). -
L'utente deve disporre delle seguenti autorizzazioni delle policy:
-
GetCredentials
: fornisce le credenziali per l'autorizzazione temporanea all'accesso ad Amazon Redshift serverless. -
sts:AssumeRoleWithSAML
— Fornisce un meccanismo per collegare un archivio o una directory di identità aziendali all'accesso basato sui ruoli AWS . -
sts:TagSession
: autorizzazione all'operazione della sessione di tag, sul principale del provider di identità.
In questo caso,
AssumeRoleWithSAML
restituisce un set di credenziali di sicurezza per gli utenti che sono stati autenticati tramite una risposta autenticata. SAML Questa operazione fornisce un meccanismo per collegare un archivio di identità o una directory all'accesso basato sui ruoli senza AWS credenziali specifiche dell'utente. Per gli utenti con autorizzazioneAssumeRoleWithSAML
, il provider di identità è responsabile della gestione dell'SAMLasserzione utilizzata per passare le informazioni sul ruolo.Come procedura ottimale, consigliamo di allegare criteri di autorizzazione a un IAM ruolo e quindi di assegnarlo a utenti e gruppi in base alle esigenze. Per ulteriori informazioni, consulta Identity and access management in Amazon Redshift.
-
-
Il tag
RedshiftDbRoles
viene configurato con i valori dei ruoli separati da due punti, nel formato role1:role2. Ad esempiomanager:engineer
. Questi possono essere recuperati da un'implementazione di tag di sessione configurata nel provider di identità. La richiesta di SAML autenticazione trasferisce i ruoli a livello di codice. Per ulteriori informazioni sul passaggio dei tag di sessione, consulta Passare i tag di sessione in AWS STS.Nel caso in cui si passi un nome di ruolo che non esiste nel database, questo viene ignorato.
In questo caso d'uso, quando un utente accede utilizzando un'identità federata, i suoi ruoli vengono passati nella richiesta di autorizzazione tramite la chiave e il valore del tag di sessione. Successivamente, dopo l'autorizzazione, GetCredentials
passa i ruoli al database. Dopo una connessione riuscita, i ruoli del database vengono mappati e l'utente può eseguire attività di database corrispondenti al proprio ruolo. La parte essenziale dell'operazione è che al tag di sessione RedshiftDbRoles
vengano assegnati i ruoli nella richiesta di autorizzazione iniziale. Per ulteriori informazioni sul passaggio dei tag di sessione, consulta Passare i tag di sessione utilizzando. AssumeRoleWith SAML
Accesso tramite IAM credenziali
Nel secondo caso d'uso, è possibile passare ruoli a un utente che può accedere a un'applicazione client di database tramite IAM credenziali.
-
In questo caso, all'utente che accede devono essere assegnate le autorizzazioni delle policy per le seguenti operazioni:
-
tag:GetResources
: restituisce le risorse contrassegnate associate ai tag specificati. -
tag:GetTagKeys
: restituisce le chiavi dei tag attualmente in uso.Come procedura ottimale, consigliamo di allegare criteri di autorizzazione a un IAM ruolo e quindi di assegnarlo a utenti e gruppi in base alle esigenze. Per ulteriori informazioni, consulta Identity and access management in Amazon Redshift.
-
-
È inoltre necessario concedere le autorizzazioni per accedere al servizio di database, come Amazon Redshift serverless.
-
In questo caso d'uso, configura i valori dei tag per i propri ruoli in AWS Identity and Access Management. Puoi scegliere di modificare i tag e creare una chiave di tag chiamata RedshiftDbRolescon una stringa di valori del tag di accompagnamento che contiene i ruoli. Ad esempio, manager:engineer.
Quando un utente effettua l'accesso, il suo ruolo viene aggiunto alla richiesta di autorizzazione e passato al database. È mappato a un ruolo del database esistente.
Risorse aggiuntive
Come indicato nei casi d'uso, è possibile configurare la relazione di trust tra il proprio IdP e AWS. Per ulteriori informazioni, consulta Configurazione del tuo IdP SAML 2.0 con relying party trust e aggiunta di claim.