Amazon Redshift non supporterà più l'uso delle UDF di Python dopo il 30 giugno 2026. Inizieremo ad applicarlo gradualmente. Per ulteriori informazioni sulla fine del ciclo di vita di Python e sulle opzioni di migrazione, consulta il post sul blog
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à.
Note per l'utilizzo
Per concedere i privilegi su un oggetto, è necessario soddisfare uno dei seguenti criteri:
-
Essere il proprietario dell'oggetto.
-
Essere un utente con privilegi avanzati.
-
Avere un privilegio di concessione per l'oggetto e il privilegio.
Ad esempio, il seguente comando consente all'utente HR di eseguire i comandi SELECT sulla tabella dei dipendenti e di concedere e revocare lo stesso privilegio per altri utenti.
grant select on table employees to HR with grant option;
HR non può concedere privilegi per operazioni diverse da SELECT o su qualsiasi altra tabella rispetto a quella dei dipendenti.
Ad esempio, il seguente comando consente all'utente HR di eseguire i comandi ALTER sulla tabella dei dipendenti e di concedere e revocare lo stesso privilegio per altri utenti.
grant ALTER on table employees to HR with grant option;
HR non può concedere privilegi per operazioni diverse da ALTER o su qualsiasi altra tabella che non sia quella dei dipendenti.
Avere i privilegi su una vista non implica i privilegi sulle tabelle sottostanti. Allo stesso modo, avere i privilegi su uno schema non implica i privilegi sulle tabelle dello schema. Invece, è necessario concedere l'accesso alle tabelle sottostanti in modo esplicito.
Per concedere i privilegi a una AWS Lake Formation tabella, il ruolo IAM associato allo schema esterno della tabella deve disporre dell'autorizzazione a concedere i privilegi alla tabella esterna. L'esempio seguente crea uno schema esterno con un ruolo IAM associato myGrantor. Il ruolo IAM myGrantor ha l'autorizzazione per concedere le autorizzazioni ad altri. Il comando GRANT utilizza l'autorizzazione del ruolo IAM myGrantor associato allo schema esterno per concedere l'autorizzazione al ruolo IAM myGrantee.
create external schema mySchema from data catalog database 'spectrum_db' iam_role 'arn:aws:iam::123456789012:role/myGrantor' create external database if not exists;
grant select on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee';
Se vengono concessi i privilegi GRANT ALL a un ruolo IAM, i singoli privilegi vengono concessi nel relativo catalogo dati abilitato per Lake Formation. Ad esempio, il seguente GRANT ALL comporta la concessione di privilegi singoli (SELECT, ALTER, DROP, DELETE e INSERT) nella console Lake Formation.
grant all on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee';
Gli utenti con privilegi avanzati possono accedere a tutti gli oggetti indipendentemente dai comandi GRANT e REVOKE che impostano i privilegi dell'oggetto.
Note di utilizzo per il controllo degli accessi a livello di colonna
Le seguenti note di utilizzo si applicano ai privilegi a livello di colonna su tabelle e viste di Amazon Redshift. Queste note descrivono le tabelle; le stesse note si applicano alle viste a meno che non venga indicata esplicitamente un'eccezione.
-
Per una tabella Amazon Redshift, è possibile concedere i privilegi SELECT e UPDATE solo a livello di colonna. Per una vista Amazon Redshift, è possibile concedere solo il privilegio SELECT a livello di colonna.
-
La parola chiave ALL è un sinonimo di privilegi SELECT e UPDATE combinati quando utilizzata nel contesto di una GRANT a livello di colonna in una tabella.
-
Se non disponi del privilegio SELECT su tutte le colonne di una tabella, l'esecuzione di un'operazione SELECT * restituisce solo le colonne a cui hai accesso. Quando utilizzi una vista, un’operazione SELECT * tenta di accedere a tutte le colonne della vista. Se non disponi dell’autorizzazione ad accedere a tutte le colonne, queste query non riescono e viene visualizzato un errore di autorizzazione negata.
-
SELECT * non si espande solo alle colonne accessibili nei seguenti casi:
-
Non è possibile creare una vista normale con solo colonne accessibili utilizzando SELECT *.
-
Non è possibile creare una vista materializzata con solo colonne accessibili utilizzando SELECT *.
-
-
Se si dispone di privilegi SELECT o UPDATE su una tabella o vista e si aggiunge una colonna, si hanno ancora gli stessi privilegi sulla tabella o sulla vista e quindi tutte le relative colonne.
-
Solo il proprietario di una tabella o un utente con privilegi avanzati possono concedere privilegi a livello di colonna.
-
La clausola WITH GRANT OPTION non è supportata per i privilegi a livello di colonna.
-
Non è possibile mantenere lo stesso privilegio sia a livello di tabella sia a livello di colonna. Ad esempio, l'utente
data_scientistnon può avere sia il privilegio SELECT nella tabellaemployeesia il privilegio SELECT nella colonnaemployee.department. Considerare i seguenti risultati quando si concede lo stesso privilegio a una tabella e a una colonna all'interno della tabella:-
Se un utente dispone di un privilegio a livello di tabella su una tabella, la concessione dello stesso privilegio a livello di colonna non ha alcun effetto.
-
Se un utente dispone di un privilegio a livello di tabella in una tabella, la revoca dello stesso privilegio per una o più colonne della tabella restituisce un errore. Al contrario, revoca il privilegio a livello di tabella.
-
Se un utente dispone di un privilegio a livello di colonna, la concessione dello stesso privilegio a livello di tabella restituisce un errore.
-
Se un utente dispone di un privilegio a livello di colonna, la revoca dello stesso privilegio a livello di tabella revoca sia i privilegi di colonna sia di tabella per tutte le colonne della tabella.
-
-
Non è possibile concedere privilegi a livello di colonna nelle viste con associazione tardiva.
-
Per creare una vista materializzata, è necessario disporre del privilegio SELECT a livello di tabella nelle tabelle di base. Anche se si dispone di privilegi a livello di colonna su colonne specifiche, non è possibile creare una vista materializzata solo su tali colonne. Tuttavia, è possibile concedere il privilegio SELECT alle colonne di una vista materializzata, in modo simile alle viste normali.
-
Per cercare le concessioni dei privilegi a livello di colonna, utilizzare la vista PG_ATTRIBUTE_INFO .
Note di utilizzo per la concessione dell'autorizzazione ASSUMEROLE
Le seguenti note di utilizzo si applicano alla concessione dell'autorizzazione ASSUMEROLE in Amazon Redshift.
Utilizza l'autorizzazione ASSUMEROLE per controllare le autorizzazioni di accesso del ruolo IAM per gli utenti, i ruoli o i gruppi del database sui comandi quali COPY, UNLOAD, EXTERNAL FUNCTION o CREATE MODEL. Dopo aver concesso l'autorizzazione ASSUMEROLE a un utente, un ruolo o un gruppo per un ruolo IAM, l'utente, il ruolo o il gruppo può assumere tale ruolo all'esecuzione del comando. L'autorizzazione ASSUMEROLE consente di concedere l'accesso ai comandi appropriati in base alle esigenze.
Solo un utente del database con privilegi avanzati può concedere o revocare l'autorizzazione ASSUMEROLE per utenti, ruoli e gruppi. Un utente con privilegi avanzati mantiene sempre l'autorizzazione ASSUMEROLE.
Per abilitare l'utilizzo dell'autorizzazione ASSUMEROLE per utenti, ruoli e gruppi, un utente con privilegi avanzati esegue le due operazioni seguenti:
-
Esegue l'istruzione di seguito una volta nel cluster:
revoke assumerole on all from public for all; -
Concessione dell'autorizzazione ASSUMEROLE a utenti, ruoli e gruppi per i comandi appropriati.
Quando si concede l'autorizzazione ASSUMEROLE, è possibile specificare il concatenamento dei ruoli nella clausola ON. Per separare i ruoli in una catena di ruoli è possibile utilizzare le virgole, ad esempio Role1,Role2,Role3. Se il concatenamento dei ruoli è stato specificato durante la concessione dell'autorizzazione ASSUMEROLE, è necessario specificare la catena di ruoli durante l'esecuzione delle operazioni concesse dall'autorizzazione ASSUMEROLE. Non è possibile specificare singoli ruoli all'interno della catena di ruoli quando si eseguono operazioni concesse dall'autorizzazione ASSUMEROLE. Ad esempio, se a un utente, un ruolo o un gruppo viene concessa la catena di ruoli Role1,Role2,Role3, non è possibile specificare solo Role1 per eseguire le operazioni.
Se un utente prova a eseguire un'operazione COPY, UNLOAD, EXTERNAL FUNCTION o CREATE MODEL e non gli è stata concessa l'autorizzazione ASSUMEROLE, viene visualizzato un messaggio simile al seguente.
ERROR: User awsuser does not have ASSUMEROLE permission on IAM role "arn:aws:iam::123456789012:role/RoleA" for COPY
Per elencare gli utenti a cui è stato concesso l'accesso ai ruoli IAM e ai comandi tramite l'autorizzazione ASSUMEROLE, consultare HAS_ASSUMEROLE_PRIVILEGE. Per elencare i ruoli IAM e le autorizzazioni dei comandi concesse a un utente specifico, consultare PG_GET_IAM_ROLE_BY_USER. Per elencare gli utenti, i ruoli e i gruppi a cui è stato concesso l'accesso a un ruolo IAM specifico, consulta PG_GET_GRANTEE_BY_IAM_ROLE.
Note di utilizzo per la concessione delle autorizzazioni di machine learning
Non è possibile concedere o revocare direttamente le autorizzazioni relative a una funzione ML. Una funzione ML appartiene a un modello ML e le autorizzazioni sono controllate tramite il modello. È invece possibile concedere le autorizzazioni relative al modello ML. L'esempio seguente dimostra come concedere le autorizzazioni a tutti gli utenti per eseguire la funzione ML associata al modello customer_churn.
GRANT EXECUTE ON MODEL customer_churn TO PUBLIC;
Puoi anche concedere tutte le autorizzazioni a un utente per il modello ML customer_churn.
GRANT ALL on MODEL customer_churn TO ml_user;
La concessione dell'autorizzazione EXECUTE relativa a una funzione ML avrà esito negativo se nello schema è presente una funzione ML, anche se tale funzione ML dispone già dell'autorizzazione EXECUTEtramite GRANT EXECUTE ON MODEL. Si consiglia di utilizzare uno schema separato quando si utilizza il comando CREATE MODEL per mantenere le funzioni ML in uno schema separato. L'esempio seguente mostra come fare.
CREATE MODEL ml_schema.customer_churn FROM customer_data TARGET churn FUNCTION ml_schema.customer_churn_prediction IAM_ROLE default SETTINGS ( S3_BUCKET 'amzn-s3-demo-bucket' );
Note d'uso per la concessione dell'autorizzazione DEBUG
L'autorizzazione DEBUG si applica ai database nei magazzini Amazon Redshift con autorizzazioni federate che utilizzano il controllo degli accessi granulare (FGAC). Per impostazione predefinita, quando una query accede ai FGAC-protected dati in un database di questo tipo, Amazon Redshift oscura i valori sensibili nei record della tabella di registro del sistema generati per quella query. Ciò protegge i dati del produttore dal consumatore. La concessione di DEBUG consente a entità specificate di visualizzare quei record di registro senza redazione. Per l'elenco dei campi oscurati e ulteriori informazioni sulla registrazione sicura, consulta Secure logging nella Amazon Redshift Management Guide.
Solo un superutente o il proprietario del database possono concedere o revocare DEBUG. Puoi concedere DEBUG solo su un database in un magazzino Amazon Redshift con autorizzazioni federate, non su un database locale o un database creato da un catalogo o. AWS Lake Formation AWS Glue Data Catalog
DEBUG supporta i seguenti moduli:
-
Concessione a un'identità globale. Utilizza
TO, dove il prefisso identifica il provider di identità (ad esempio, per un utente IAM,<prefix>:<name>IAMper un ruolo IAM o il prefisso dello spazio dei nomi iDC (Centro identità AWS IAM)IAMRper un utente IDC). Solo l'identità specificata può vedere i record non redatti generati dalle proprie query. Nessun altro utente, incluso un superutente, può vederli. -
Concessione a un gruppo iDC. Usa
TO ROLE, dove il prefisso identifica l'istanza IdC ().Centro identità AWS IAM Ogni membro del gruppo può vedere i record non redatti generati dalle proprie query.<idc_prefix>:<group_name> -
Concessione agli amministratori degli account. Utilizza
TO ADMINS OF ACCOUNT '. Tutti i superutenti (al momento dell'accesso al registro) sull'account consumer specificato possono vedere i record non redatti. I record autorizzati in questo modo non vengono inoltre oscurati quando Amazon Redshift esporta i dati delle tabelle di sistema in Amazon S3 Tables. Puoi specificare solo lo stesso account che possiede il produttore.account_id'
Le seguenti note d'uso si applicano all'autorizzazione DEBUG:
-
DEBUG non è incluso in GRANT ALL ON DATABASE. È necessario concederlo in modo esplicito.
-
È possibile concedere DEBUG a un solo database per istruzione e non è possibile combinarlo con altre autorizzazioni nella stessa istruzione.
-
Non puoi concedere DEBUG a PUBLIC, a un utente locale o a un gruppo locale.
-
DEBUG è solo prospettico. La concessione di DEBUG ha effetto solo sui record di registro generati dopo la concessione. La revoca di DEBUG ha effetto solo sui record generati dopo la revoca; i record generati mentre DEBUG era attivo rimangono visibili per tutta la durata del registro.
-
Se si annulla la registrazione del cluster o dello spazio dei nomi, le concessioni DEBUG esistenti vengono mantenute ma non hanno alcun effetto AWS Glue Data Catalog, poiché il warehouse non utilizza più le autorizzazioni federate. Non è necessario revocarli. Se registri nuovamente il cluster o lo spazio dei nomi, le concessioni hanno nuovamente effetto. Le concessioni DEBUG vengono rimosse solo quando il database viene eliminato. Per ulteriori informazioni, consulta Annulla la registrazione da AWS Glue Data Catalog.
-
Quando una query unisce più database con autorizzazioni federate, è necessario concedere DEBUG a ogni database di questo tipo che fornisce dati alla query. FGAC-protected In caso contrario, i record rimangono oscurati.
-
Quando concedi DEBUG a un ruolo IAM, un superutente locale che assume quel ruolo (
SET SESSION AUTHORIZATION) utilizzando ALTER USER SET GLOBAL IDENTITY può vedere i record non redatti del ruolo. Gli utenti IAM e gli utenti IdC non possono essere impersonati in questo modo.