Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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 istruzioni SQL, ma è molto impegnativo. 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 le credenziali di accesso IAM e i suoi ruoli vengono passati tramite una chiave e un valore di tag.
Per ulteriori informazioni sul controllo degli accessi basato sui ruoli, consulta [Controllo accessi basato sui ruoli (RBAC)](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html).
## 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 del database e concedere autorizzazioni, consulta [CREATE ROLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_ROLE.html) e [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html).
## 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, ad esempio, accede a un client l'editor di query V2 o con un client JDBC. Per configurare questo controllo, è necessario completare un paio di attività di configurazione. Questi sono i seguenti:
1. Configurazione dell'integrazione federata con il gestore dell'identità digitale utilizzando una relazione di trust. È un prerequisito. Quando si configura questa impostazione, il provider di identità è responsabile dell'autenticazione dell'utente tramite un'asserzione SAML e della fornitura delle credenziali di accesso. Per ulteriori informazioni, consulta [Integrazione di fornitori di soluzioni SAML di terze parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html) con. AWS Per ulteriori informazioni, consulta [Federate access to Amazon Redshift query editor V2 with Active Directory Federation Services (AD FS)](https://aws.amazon.com/blogs//big-data/federate-access-to-amazon-redshift-query-editor-v2-with-active-directory-federation-services-ad-fs-part-3/) (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](https://aws.amazon.com/blogs//big-data/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).
1. 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 utenti che sono stati autenticati tramite una risposta di autenticazione 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 autorizzati per `AssumeRoleWithSAML`, il provider di identità è responsabile della gestione dell'asserzione SAML utilizzata per trasmettere le informazioni sul ruolo.
Come best practice, consigliamo di collegare le policy di autorizzazioni a un ruolo IAM, che quindi viene assegnato a utenti e gruppi secondo le necessità. Per ulteriori informazioni, consulta [Identity and access management in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-authentication-access-control.html).
1. Il tag `RedshiftDbRoles` viene configurato con i valori dei ruoli separati da due punti, nel formato *role1:role2*. Ad esempio, `manager:engineer`. Questi possono essere recuperati da un'implementazione di tag di sessione configurata nel provider di identità. La richiesta di autenticazione SAML passa i ruoli a livello di programmazione. Per ulteriori informazioni sul passaggio dei tag di sessione, consulta [Passare i tag di sessione in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html).
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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_adding-assume-role-saml) i tag di sessione utilizzando SAML. AssumeRoleWith
### Accesso tramite credenziali IAM
Nel secondo caso d'uso, i ruoli possono essere passati per un utente e quest'ultimo può accedere a un'applicazione client del database tramite le credenziali IAM.
1. 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 best practice, consigliamo di collegare le policy di autorizzazioni a un ruolo IAM, che quindi viene assegnato a utenti e gruppi secondo le necessità. Per ulteriori informazioni, consulta [Identity and access management in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-authentication-access-control.html).
1. È inoltre necessario concedere le autorizzazioni per accedere al servizio di database, come Amazon Redshift serverless.
1. 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 *RedshiftDbRoles*con 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 provider di identità SAML 2.0 con una relazione di attendibilità e aggiungendo attestazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_relying-party.html).