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à.
# Gruppo di sicurezza database
Puoi gestire la sicurezza del database controllando gli utenti che possono accedere agli oggetti del database e gli oggetti nello specifico. Agli utenti possono essere assegnati ruoli o gruppi e le autorizzazioni concesse a utenti, ruoli o gruppi determinano a quali oggetti del database possono accedere.
**Topics**
+ [Panoramica della sicurezza di Amazon Redshift](c_security-overview.md)
+ [Autorizzazioni utente di default per il database](r_Privileges.md)
+ [superuser](r_superusers.md)
+ [Utenti](r_Users.md)
+ [Gruppi](r_Groups.md)
+ [Schemi](r_Schemas_and_tables.md)
+ [Controllo accessi basato sui ruoli (RBAC)](t_Roles.md)
+ [Sicurezza a livello di riga](t_rls.md)
+ [Sicurezza dei metadati](t_metadata_security.md)
+ [Mascheramento dinamico dei dati](t_ddm.md)
+ [Autorizzazioni con ambito](t_scoped-permissions.md)
L’accesso agli oggetti di database dipende dalle autorizzazioni concesse agli utenti o ai gruppi. Nelle linee guida seguenti viene riepilogato il funzionamento della sicurezza del database:
+ Di default, le autorizzazioni vengono concesse solo al proprietario dell'oggetto.
+ Gli utenti del database di Amazon Redshift sono utenti denominati che possono connettersi a un database. Le autorizzazioni vengono fornite a un utente in due modi: in modo esplicito, ovvero mediante assegnazione diretta all'account, oppure in modo implicito, in quanto membro di un gruppo a cui sono concesse le autorizzazioni.
+ I gruppi sono raccolte di utenti a cui possono essere assegnate le autorizzazioni collettivamente per una più agevole gestione della sicurezza.
+ Gli schemi sono raccolte di tabelle di database e altri oggetti di database. Gli schemi sono simili alle directory del file system, con la differenza che non possono essere nidificati. Agli utenti si può concedere l'accesso a uno o più schemi.
Inoltre, Amazon Redshift utilizza le seguenti funzionalità per fornire un controllo più preciso su quali utenti hanno accesso a quali oggetti del database:
+ Il controllo degli accessi basato sui ruoli (RBAC) consente di assegnare autorizzazioni ai ruoli che è possibile poi applicare agli utenti, consentendo di controllare le autorizzazioni per grandi gruppi di utenti. A differenza dei gruppi, i ruoli possono ereditare le autorizzazioni da altri ruoli.
La sicurezza a livello di riga (RLS) consente di definire policy che limitano l'accesso alle righe di propria scelta, quindi applicarle a utenti o gruppi.
Il mascheramento dinamico dei dati (DDM) protegge ulteriormente i dati trasformandoli durante il runtime della query in modo da consentire agli utenti di accedere ai dati senza esporre dettagli sensibili.
Per esempi di implementazione della sicurezza, vedi [Esempio di controllo dell'accesso di utenti e gruppi](t_user_group_examples.md).
Per ulteriori informazioni sulla protezione dei dati, consulta [Sicurezza in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html) nella *Guida alla gestione di Amazon Redshift*.
# Panoramica della sicurezza di Amazon Redshift
La sicurezza del database Amazon Redshift è diversa da altri tipi di sicurezza di Amazon Redshift. Oltre alla sicurezza del database descritta in questa sezione, Amazon Redshift offre le caratteristiche seguenti per gestire la sicurezza:
+ **Credenziali** di accesso: l'accesso alla console di gestione Amazon AWS Redshift è controllato dalle AWS autorizzazioni del tuo account. Per ulteriori informazioni, consultare [Credenziali di accesso](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html).
+ **Gestione degli accessi**: per controllare l'accesso a risorse Amazon Redshift specifiche, definisci account AWS Identity and Access Management (IAM). Per ulteriori informazioni, consultare [Controllo dell'accesso alle risorse di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html).
+ **Gruppi di sicurezza del cluster**: per concedere ad altri utenti l'accesso in entrata a un cluster Amazon Redshift, è necessario definire un gruppo di sicurezza del cluster e associarlo a un cluster. Per maggiori informazioni, consultare [Gruppi di sicurezza dei cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html).
+ **VPC**: per proteggere l'accesso al cluster utilizzando un ambiente di rete virtuale, è possibile avviare il cluster in un Amazon Virtual Private Cloud (VPC). Per ulteriori informazioni, consultare [Gestione dei cluster in Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html).
+ **Crittografia cluster**: per crittografare i dati in tutte le tabelle create dall'utente, è possibile abilitare la crittografia del cluster quando si avvia il cluster. Per ulteriori informazioni, consultare [Cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html).
+ **Connessioni SSL**: per crittografare la connessione tra il client SQL e il cluster, è possibile utilizzare la crittografia Secure Sockets Layer (SSL). Per ulteriori informazioni, consultare [Connessione al cluster mediante SSL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html).
+ **Crittografia dei dati di caricamento**: per crittografare i file di dati del caricamento della tabella quando vengono caricati su Amazon S3, è possibile usare la crittografia lato server o la crittografia lato client. Quando si esegue il caricamento dai dati crittografati lato server, Amazon S3 gestisce la decrittografia in modo trasparente. Quando si esegue il caricamento dai dati crittografati lato client, il comando COPY di Amazon Redshift decritta i dati quando carica la tabella. Per ulteriori informazioni, consulta [Caricamento di dati crittografati su Amazon S3](t_uploading-encrypted-data.md).
+ **Dati in transito**: per proteggere i dati in transito nel AWS cloud, Amazon Redshift utilizza SSL con accelerazione hardware per comunicare con Amazon S3 o Amazon DynamoDB per operazioni di COPY, UNLOAD, backup e ripristino.
+ **Controllo degli accessi a livello di colonna**: per avere il controllo degli accessi a livello di colonna per i dati in Amazon Redshift, utilizzare le istruzioni di concessione e revoca a livello di colonna senza dover implementare il controllo degli accessi basato sulle viste o utilizzare un altro sistema.
+ **Controllo di sicurezza a livello di riga**: per avere un controllo di sicurezza a livello di riga per i dati in Amazon Redshift, crea e collega a ruoli o utenti policy che limitano l'accesso alle righe definite.
# Autorizzazioni utente di default per il database
Quando crei un oggetto database, ne diventi proprietario. Di default, solo un utente con privilegi avanzati o il proprietario di un oggetto può modificarlo, eseguire query o concedere autorizzazioni per l'oggetto. Per consentire agli utenti di utilizzare un oggetto, è necessario concedere le autorizzazioni necessarie all'utente o al gruppo in cui è incluso. Gli utenti con privilegi avanzati del database dispongono delle stesse autorizzazioni dei proprietari del database.
Amazon Redshift supporta le seguenti autorizzazioni: SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, TEMPORARY e USAGE. Autorizzazioni diverse sono associate a tipi di oggetto diversi. Per informazioni sulle autorizzazioni degli oggetti di database supportate da Amazon Redshift, consulta il comando [GRANT](r_GRANT.md).
Solo il proprietario ha il permesso di modificare o distruggere un oggetto.
Di default, tutti gli utenti hanno le autorizzazioni CREATE e USAGE per lo schema PUBLIC di un database. Per impedire agli utenti di creare oggetti nello schema PUBLIC di un database, utilizza il comando REVOKE per rimuovere tale autorizzazione.
Per revocare un'autorizzazione concessa precedentemente, utilizza il comando [REVOKE](r_REVOKE.md). Le autorizzazioni del proprietario dell'oggetto, ad esempio le autorizzazioni DROP, GRANT e REVOKE, sono implicite e non possono essere concesse o revocate. I proprietari degli oggetti possono revocare le proprie autorizzazioni normali, ad esempio quello di creare una tabella in sola lettura personale e per altri utenti. Gli utenti con privilegi avanzati mantengono tutte le autorizzazioni, indipendentemente dai comandi GRANT e REVOKE.
# Utenti con privilegi avanzati
Gli utenti con privilegi avanzati del database dispongono delle stesse autorizzazioni dei proprietari dei database per tutti i database.
L'utente *admin*, ovvero l'utente creato quando è stato avviato il cluster, è un utente con privilegi avanzati.
Per poter creare un utente con privilegi avanzati, è necessario esserlo.
Le viste e le tabelle di sistema di Amazon Redshift sono visibili solo agli utenti con privilegi avanzati o a tutti gli utenti. Solo gli utenti con privilegi avanzati possono eseguire query sulle tabelle di sistema e le visualizzazioni di sistema designate come "visibili agli utenti con privilegi avanzati". Per informazioni, consulta [Viste di monitoraggio SYS](serverless_views-monitoring.md).
Gli utenti con privilegi avanzati possono visualizzare tutte le tabelle di catalogo. Per informazioni, consulta [Tabelle di catalogo di sistema](c_intro_catalog_views.md).
Un utente con privilegi avanzati di database ignora tutte le verifiche delle autorizzazioni. Gli utenti con privilegi avanzati mantengono tutte le autorizzazioni, indipendentemente dai comandi GRANT e REVOKE. Presta attenzione quando utilizzi il ruolo di un utente con privilegi avanzati. Consigliamo di svolgere la maggior parte dl lavoro con un ruolo diverso dall'utente con privilegi avanzati. Puoi creare un ruolo di amministratore con autorizzazioni più restrittive. Per ulteriori informazioni sulla creazione dei ruoli, consulta [Controllo accessi basato sui ruoli (RBAC)](t_Roles.md).
Per creare un nuovo utente con privilegi avanzati del database, accedi al database come utente con privilegi avanzati ed esegui un comando CREATE USER o ALTER USER con l'autorizzazione CREATEUSER.
```
CREATE USER adminuser CREATEUSER PASSWORD '1234Admin';
ALTER USER adminuser CREATEUSER;
```
Per creare, modificare o eliminare un utente con privilegi avanzati, utilizzare gli stessi comandi per gestire gli utenti. Per ulteriori informazioni, consultare [Creazione, modifica ed eliminazione di utenti](r_Users-creatingaltering-and-deleting-users.md).
# Utenti
Puoi creare e gestire gli utenti del database utilizzando i comandi SQL di Amazon Redshift CREATE USER e ALTER USER. In alternativa puoi configurare il client SQL con driver JDBC o ODBC personalizzati di Amazon Redshift. Questi gestiscono il processo di creazione degli utenti del database e delle password temporanee come parte del processo di accesso al database.
I driver autenticano gli utenti del database in base all'autenticazione (IAM). AWS Identity and Access Management Se gestisci già le identità degli utenti all'esterno AWS, puoi utilizzare un provider di identità (IdP) conforme a SAML 2.0 per gestire l'accesso alle risorse di Amazon Redshift. Utilizzi un ruolo IAM per configurare il tuo IdP e consentire AWS agli utenti federati di generare credenziali di database temporanee e accedere ai database Amazon Redshift. Per ulteriori informazioni, consultare [Utilizzo dell'autenticazione IAM per generare credenziali utente di database](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html).
Gli utenti di Amazon Redshift possono essere creati ed eliminati solo da un utente con privilegi avanzati del database. Gli utenti vengono autenticati quando accedono ad Amazon Redshift. Possono possedere database e oggetti di database (ad esempio tabelle). Possono inoltre concedere autorizzazioni per tali oggetti a utenti, gruppi e schemi per controllare chi vi ha accesso. Gli utenti che dispongono dei diritti CREATE DATABASE possono creare database e concedere le relative autorizzazioni. Gli utenti con privilegi avanzati dispongono delle autorizzazioni di proprietà per tutti i database.
# Creazione, modifica ed eliminazione di utenti
Gli utenti del database sono globali in un cluster di data warehouse (non per ogni singolo database).
+ Per creare un utente, utilizza il comando [CREA UTENTE](r_CREATE_USER.md).
+ Per creare un utente con privilegi avanzati, utilizza il comando [CREA UTENTE](r_CREATE_USER.md) con l'opzione CREATEUSER.
+ Pr rimuovere un utente esistente, utilizza il comando [DROP USER](r_DROP_USER.md).
+ Per modificare un utente, ad esempio per cambiare una password, utilizza il comando [ALTER USER](r_ALTER_USER.md).
+ Per visualizzare un elenco di utenti, esegui una query sulla tabella del catalogo PG\$1USER.
```
select * from pg_user;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
------------+----------+-------------+----------+-----------+----------+----------+-----------
rdsdb | 1 | t | t | t | ******** | |
masteruser | 100 | t | t | f | ******** | |
dwuser | 101 | f | f | f | ******** | |
simpleuser | 102 | f | f | f | ******** | |
poweruser | 103 | f | t | f | ******** | |
dbuser | 104 | t | f | f | ******** | |
(6 rows)
```
# Gruppi
I gruppi sono raccolte di utenti a cui è concesso qualsiasi autorizzazione associata al gruppo. Puoi utilizzare i gruppi per assegnare le autorizzazioni. Ad esempio puoi creare gruppi diversi per vendite, amministrazione e supporto fornendo agli utenti di ciascun gruppo l'accesso appropriato ai dati necessari per svolgere il proprio lavoro. Puoi concedere o revocare le autorizzazioni a livello di gruppo e queste modifiche vengono applicate a tutti i membri del gruppo, ad eccezione degli utenti con privilegi avanzati.
Per visualizzare tutti i gruppi di utenti, eseguire una query sulla tabella del catalogo di sistema PG\$1GROUP:
```
select * from pg_group;
```
Ad esempio, per elencare tutti gli utenti del database per gruppo, esegui il seguente comando SQL.
```
SELECT u.usesysid
,g.groname
,u.usename
FROM pg_user u
LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist)
```
# Creazione, modifica ed eliminazione di gruppi
Solo un utente con privilegi avanzati può creare, modificare o eliminare gruppi.
Puoi eseguire le seguenti operazioni:
+ Per creare un gruppo, utilizza il comando [CREATE GROUP](r_CREATE_GROUP.md).
+ Per aggiungere o rimuovere utenti in un gruppo esistente, utilizza il comando [ALTER GROUP](r_ALTER_GROUP.md).
+ Per eliminare un gruppo, utilizza il comando [DROP GROUP](r_DROP_GROUP.md). Questo comando elimina solo il gruppo, non gli utenti membri.
# Esempio di controllo dell'accesso di utenti e gruppi
In questo esempio vengono creati gruppi di utenti e utenti, quindi sono fornite loro diverse autorizzazioni per un database di Amazon Redshift che si connette a un client per applicazioni Web. Nell'esempio vengono utilizzati tre gruppi di utenti: utenti regolari di un'applicazione Web, utenti esperti di un'applicazione Web e sviluppatori Web.
Per informazioni su come rimuovere un utente da un gruppo, consulta [ALTER GROUP](r_ALTER_GROUP.md).
1. Crea il gruppo in cui verranno assegnati gli utenti. Il set di comandi seguente crea tre gruppi di utenti diversi:
```
create group webappusers;
create group webpowerusers;
create group webdevusers;
```
1. Crea diversi utenti di database con autorizzazioni differenti e aggiungili ai gruppi.
1. Creare due utenti e aggiungerli al gruppo WEBAPPUSERS:
```
create user webappuser1 password 'webAppuser1pass'
in group webappusers;
create user webappuser2 password 'webAppuser2pass'
in group webappusers;
```
1. Crea un utente sviluppatore Web e aggiungilo al gruppo WEBDEVUSERS:
```
create user webdevuser1 password 'webDevuser2pass'
in group webdevusers;
```
1. Crea un utente con privilegi avanzati. Questo utente disporrà dei diritti di amministratore per la creazione di altri utenti:
```
create user webappadmin password 'webAppadminpass1'
createuser;
```
1. Creare uno schema da associare alle tabelle di database utilizzate dall'applicazione Web e concedere ai vari gruppi di utenti l'accesso a questo schema:
1. Creare lo schema WEBAPP:
```
create schema webapp;
```
1. Concedere le autorizzazioni USAGE al gruppo WEBAPPUSERS:
```
grant usage on schema webapp to group webappusers;
```
1. Concedere le autorizzazioni USAGE al gruppo WEBPOWERUSERS:
```
grant usage on schema webapp to group webpowerusers;
```
1. Concedere le autorizzazioni ALL al gruppo WEBDEVUSERS:
```
grant all on schema webapp to group webdevusers;
```
Sono stati configurati utenti e gruppi di base. A questo punto puoi modificare utenti e gruppi.
1. Ad esempio, il comando seguente modifica il parametro search\$1path per. WEBAPPUSER1
```
alter user webappuser1 set search_path to webapp, public;
```
Il percorso di ricerca SEARCH\$1PATH specifica l'ordine con cui vengono eseguite le ricerche negli schemi per oggetti di database come tabelle e funzioni quando si fa riferimento all'oggetto utilizzando un nome semplice in cui non è specificato uno schema.
1. È inoltre possibile aggiungere utenti a un gruppo dopo averlo creato, ad esempio aggiungendoli WEBAPPUSER2 al gruppo WEBPOWERUSERS:
```
alter group webpowerusers add user webappuser2;
```
# Schemi
Un database contiene uno o più schemi con nome. Ogni schema di un database include tabelle e altri tipi di oggetti con nome. Per impostazione predefinita, un database include un solo schema, denominato PUBLIC. Puoi utilizzare gli schemi per creare gruppi di oggetti del database con lo stesso nome. Gli schemi sono simili alle directory del file system, con la differenza che non possono essere nidificati.
Puoi utilizzare nomi di oggetti del database identici in schemi diversi nello stesso database senza creare conflitti. Ad esempio, una tabella denominata MYTABLE può essere inclusa sia in MY\$1SCHEMA sia in YOUR\$1SCHEMA. Gli utenti che dispongono delle autorizzazioni necessarie possono accedere agli oggetti in più schemi in un database.
Per impostazione predefinita, un oggetto viene creato all'interno del primo schema nel percorso di ricerca del database. Per informazioni, vedi [Percorso di ricerca](#c_Search_path) più avanti in questa sezione.
Gli schemi possono aiutare a risolvere problemi di organizzazione e di simultaneità in un ambiente multi-utente nei modi seguenti:
+ Per consentire a più sviluppatori di lavorare nello stesso database senza interferire tra loro.
+ Per organizzare gli oggetti del database in gruppi logici per agevolarne la gestione.
+ Per consentire alle applicazioni di inserire gli oggetti in schemi separati in modo che i nomi non entrino in collisione con i nomi degli oggetti utilizzati da altre applicazioni.
## Percorso di ricerca
Il percorso di ricerca viene definito nel parametro search\$1path con un elenco di nomi di schemi separati da virgola. Il percorso di ricerca specifica l'ordine con cui vengono eseguite le ricerche negli schemi quando si fa riferimento a un oggetto, come una tabella o una funzione, utilizzando un nome semplice che non include un qualificatore di schema.
Se un oggetto viene creato senza specificare uno schema di destinazione, l'oggetto viene aggiunto al primo schema elencato nel percorso di ricerca. Se sono presenti oggetti con nomi identici in schemi diversi, un nome di oggetto che non specifica uno schema farà riferimento al primo schema del percorso di ricerca che include un oggetto con quel nome.
Per modificare lo schema predefinito per la sessione corrente, utilizza il comando [SET](r_SET.md).
Per ulteriori informazioni, vedi la descrizione [search\$1path](r_search_path.md) nella documentazione di riferimento relativa alla configurazione.
# Creazione, modifica ed eliminazione di schemi
Gli utenti possono creare schemi e modificare o eliminare gli schemi di cui sono proprietari.
Puoi eseguire le seguenti operazioni:
+ Per creare uno schema, utilizza il comando [CREATE SCHEMA](r_CREATE_SCHEMA.md).
+ Per modificare il proprietario di uno schema, utilizza il comando [ALTER SCHEMA](r_ALTER_SCHEMA.md).
+ Per eliminare uno schema con i relativi oggetti, utilizza il comando [DROP SCHEMA](r_DROP_SCHEMA.md).
+ Per creare una tabella all'intero di uno schema, crea la tabella con il formato *schema\$1name.table\$1name*.
Per visualizzare un elenco di tutti gli schemi, eseguire una query sulla tabella del catalogo di sistema PG\$1NAMESPACE.
```
select * from pg_namespace;
```
Per visualizzare un elenco delle tabelle che appartengono a uno schema, eseguire una query sulla tabella del catalogo di sistema PG\$1TABLE\$1DEF. Ad esempio, la query seguente restituisce un elenco di tabelle nello schema PG\$1CATALOG.
```
select distinct(tablename) from pg_table_def
where schemaname = 'pg_catalog';
```
# Autorizzazioni basate sullo schema
Le autorizzazioni basate sullo schema sono determinate dal proprietario dello schema:
+ Di default, tutti gli utenti hanno le autorizzazioni CREATE e USAGE per lo schema PUBLIC di un database. Per impedire agli utenti di creare oggetti nello schema PUBLIC di un database, utilizza il comando [REVOKE](r_REVOKE.md) per rimuovere tale autorizzazione.
+ A meno che il proprietario dell'oggetto non conceda loro l'autorizzazione USAGE, gli utenti non possono accedere a nessun oggetto presente negli schemi di cui non siano proprietari.
+ Se agli utenti è stato concesso l'autorizzazione CREATE per uno schema creato da un altro utente, possono creare oggetti in tale schema.
# Controllo accessi basato sui ruoli (RBAC)
Utilizzando il controllo degli accessi basato sui ruoli (RBAC) per gestire le autorizzazioni del database in Amazon Redshift, è possibile semplificare la gestione delle autorizzazioni di sicurezza in Amazon Redshift. Puoi proteggere l'accesso ai dati sensibili controllando ciò che gli utenti possono fare sia a livello generale che dettagliato. Puoi anche controllare l'accesso degli utenti alle attività normalmente limitate agli utenti con privilegi avanzati. Assegnando autorizzazioni diverse a ruoli diversi e assegnandole a diversi utenti, è possibile avere un controllo più granulare dell'accesso degli utenti.
Gli utenti con un ruolo assegnato possono eseguire solo le attività specificate dal ruolo per cui dispongono dell'autorizzazione. Ad esempio, un utente a cui è assegnato il ruolo con le autorizzazioni CREATE TABLE e DROP TABLE è autorizzato solo a eseguire tali attività. Puoi controllare l'accesso degli utenti concedendo livelli di autorizzazioni di sicurezza a utenti diversi per farli accedere solo ai dati necessari per il loro lavoro.
RBAC applica il principio delle autorizzazioni minime agli utenti in base ai requisiti del loro ruolo, indipendentemente dai tipi di oggetti coinvolti. La concessione e la revoca delle autorizzazioni vengono eseguite a livello di ruolo, senza la necessità di aggiornare le autorizzazioni per i singoli oggetti di database.
Con RBAC, puoi creare ruoli autorizzati a eseguire comandi con cui richiedere autorizzazioni di utente con privilegi avanzati. Gli utenti possono eseguire questi comandi purché sia loro assegnato un ruolo che includa tali autorizzazioni. Analogamente, puoi anche creare ruoli per limitare l'accesso a determinati comandi e assegnarli a utenti con privilegi avanzati o utenti che dispongano dell'autorizzazione per i ruoli in questione.
Per informazioni su come funziona Amazon Redshift RBAC, guardare il video seguente.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4)
# Gerarchia dei ruoli
I *ruoli* sono raccolte di autorizzazioni che puoi assegnare a un utente o a un altro ruolo. Puoi assegnare autorizzazioni di sistema o database a un ruolo. Un utente eredita le autorizzazioni dal ruolo assegnatogli.
In RBAC, gli utenti possono avere ruoli nidificati. Puoi concedere ruoli sia agli utenti che ad altri ruoli. Quando concedi un ruolo a un utente, fornisci anche tutte le autorizzazioni associate al ruolo in questione. Se concedi il ruolo r1 a un utente, gli fornisci le autorizzazioni associate al ruolo r1. L'utente ora dispone delle autorizzazioni concesse al ruolo r1 e di tutte le autorizzazioni esistenti di cui era già in possesso.
Quando concedi un ruolo (r1) a un altro ruolo (r2), autorizzi r2 con tutte le autorizzazioni da r1. Inoltre, quando concedi il ruolo r2 a un altro ruolo (r3), le autorizzazioni di r3 sono la combinazione delle autorizzazioni di r1 e r2. In base alla gerarchia dei ruoli, r2 eredita le autorizzazioni di r1. Amazon Redshift propaga le autorizzazioni con ogni autorizzazione di ruolo. La concessione di r1 a r2 e quindi r2 a r3 autorizza r3 con tutte le autorizzazioni dei tre ruoli. Pertanto, concedendo r3 a un utente, l'utente dispone di tutte le autorizzazioni dei tre ruoli.
Amazon Redshift non consente la creazione di un ciclo di autorizzazione dei ruoli. Un ciclo di autorizzazione dei ruoli si verifica quando un ruolo nidificato viene assegnato di nuovo a un ruolo precedente nella gerarchia dei ruoli, ad esempio r3 viene assegnato nuovamente a r1. Per ulteriori informazioni su come creare i ruoli e gestire le assegnazioni dei ruoli, consulta [Gestione dei ruoli in RBAC](r_roles-managing.md).
# Assegnazione del ruolo
Gli utenti con privilegi avanzati e gli utenti normali con le autorizzazioni CREATE ROLE possono utilizzare l'istruzione CREATE ROLE per creare ruoli. Gli utenti con privilegi avanzati e gli amministratori di ruolo possono utilizzare l'istruzione GRANT ROLE per concedere un ruolo ad altri. Possono utilizzare l'istruzione REVOKE ROLE per revocare un ruolo da altri e l'istruzione DROP ROLE per eliminare i ruoli. Gli amministratori dei ruoli includono i proprietari dei ruoli e gli utenti a cui è stato concesso il ruolo con l'autorizzazione ADMIN OPTION.
Solo gli utenti con privilegi avanzati o gli amministratori del ruolo possono concedere e revocare ruoli. Puoi concedere o revocare uno o più ruoli da o verso uno o più ruoli o utenti. Utilizza l'opzione WITH ADMIN OPTION nell'istruzione GRANT ROLE per fornire le opzioni di amministrazione per tutti i ruoli concessi a tutti gli assegnatari.
Amazon Redshift supporta diverse combinazioni di assegnazioni dei ruoli, come la concessione di più ruoli o la possibilità di avere più assegnatari. L'opzione WITH ADMIN OPTION si applica solo agli utenti e non ai ruoli. Analogamente, è possibile utilizzare l'opzione WITH ADMIN OPTION nell'istruzione REVOKE ROLE per revocare il ruolo e l'autorizzazione amministrativa concessi al beneficiario. Se nell'istruzione viene utilizzata l'opzione ADMIN OPTION, viene revocata dal ruolo solo l'autorizzazione amministrativa.
L'istruzione nell'esempio seguente revoca l'autorizzazione amministrativa del ruolo `sample_role2` da `user2`.
```
REVOKE ADMIN OPTION FOR sample_role2 FROM user2;
```
Per ulteriori informazioni su come creare i ruoli e gestire le assegnazioni dei ruoli, consulta [Gestione dei ruoli in RBAC](r_roles-managing.md).
# Ruoli definiti dal sistema di Amazon Redshift
Amazon Redshift offre alcuni ruoli definiti dal sistema che sono definiti con autorizzazioni specifiche. I ruoli specifici del sistema presentano il prefisso `sys:`. Solo gli utenti con accesso appropriato possono modificare i ruoli definiti dal sistema o creare ruoli definiti dal sistema personalizzati. Non è possibile utilizzare il prefisso `sys:` per un ruolo definito dal sistema personalizzato.
La tabella seguente riepiloga i ruoli e le autorizzazioni.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/r_roles-default.html)
## Ruoli e utenti definiti dal sistema per la condivisione dei dati
Amazon Redshift crea ruoli e utenti per uso interno che corrispondono a unità di condivisione dati e consumer di unità di condivisione dati. I nomi di ruoli e utenti interni hanno il prefisso del namespace riservato `ds:`. Hanno il seguente formato:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/r_roles-default.html)
Per ogni unità di condivisione dati viene creato un ruolo di condivisione dei dati. Contiene tutte le autorizzazioni attualmente concesse all’unità di condivisione dati. Per ogni consumer di unità di condivisione dati viene creato un utente per la condivisione dei dati. Viene concessa l’autorizzazione per un singolo ruolo di condivisione dei dati. Un consumer aggiunto a più unità di condivisione dati avrà un utente per la condivisione dei dati creato per ogni unità di condivisione dati.
Questi utenti e questi ruoli sono necessari per il corretto funzionamento della condivisione dei dati. Non possono essere modificati o rimossi e non è possibile accedervi o utilizzarli per alcuna attività eseguita dai clienti. Puoi ignorarli senza problemi. Per ulteriori informazioni sulla condivisione dei dati, consulta [Condivisione di dati tra cluster in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html).
**Nota**
Non puoi utilizzare il prefisso `ds:` per creare ruoli o utenti definiti dall’utente.
# Autorizzazioni di sistema per RBAC
Di seguito è riportato un elenco delle autorizzazioni di sistema che puoi concedere o revocare a un ruolo.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/r_roles-system-privileges.html)
# Autorizzazioni per un oggetto del database
Oltre alle autorizzazioni di sistema, Amazon Redshift include autorizzazioni per gli oggetti del database che definiscono le opzioni di accesso. I privilegi includono opzioni di accesso come la possibilità di leggere i dati in tabelle e visualizzazioni, scrivere dati e creare tabelle. Per ulteriori informazioni, consulta [GRANT](r_GRANT.md).
Utilizzando RBAC, è possibile assegnare le autorizzazioni per gli oggetti del database ai ruoli in modo analogo alle autorizzazioni di sistema. Puoi quindi assegnare ruoli agli utenti e concedere loro le autorizzazioni di sistema e database.
# ALTER DEFAULT PRIVILEGES per RBAC
Usa la dichiarazione ALTER DEFAULT PRIVILEGES per definire il set di default di autorizzazioni di accesso da applicare agli oggetti creati nel futuro dall'utente specificato. Per impostazione predefinita, gli utenti possono modificare solo le proprie autorizzazioni di accesso di default. Con RBAC, puoi definire le autorizzazioni di accesso di default per i ruoli. Per ulteriori informazioni, consulta il comando [ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md).
RBAC consente di assegnare le autorizzazioni per gli oggetti di database ai ruoli, in modo analogo alle autorizzazioni di sistema. Puoi quindi assegnare ruoli agli utenti e concedere loro le autorizzazioni di sistema e/o database.
# Considerazioni sull'utilizzo dei ruoli in RBAC
Quando utilizzi i ruoli RBAC, tieni in considerazione quanto riportato di seguito:
+ Amazon Redshift non consente cicli di autorizzazioni dei ruoli. Non puoi concedere r1 a r2 e successivamente concedere r2 a r1.
+ RBAC funziona sia per gli oggetti Amazon Redshift nativi che per le tabelle Amazon Redshift Spectrum.
+ In qualità di amministratore di Amazon Redshift, puoi attivare RBAC aggiornando il cluster alla patch di manutenzione più recente per iniziare.
+ Solo gli utenti con privilegi avanzati e gli utenti con l'autorizzazione di sistema CREATE ROLE possono creare ruoli.
+ Solo gli utenti con privilegi avanzati o gli amministratori del ruolo possono modificare o eliminare ruoli.
+ Il nome di un ruolo non può essere uguale a quello di un nome utente.
+ Il nome di un ruolo non può contenere caratteri non validi, come ":/\$1n".
+ Il nome di un ruolo non può essere una parola riservata, ad esempio PUBLIC.
+ Il nome del ruolo non può iniziare con il prefisso riservato per i ruoli di default, ovvero `sys:`.
+ Non è possibile eliminare un ruolo con il parametro RESTRICT quando viene concesso a un altro ruolo. L'impostazione predefinita è RESTRICT. Quando si tenta di eliminare un ruolo che ha ereditato un altro ruolo, Amazon Redshift genera un errore.
+ Gli utenti che non dispongono delle autorizzazioni di amministratore per un ruolo non possono concedere o revocare un ruolo.
+ RBAC non è completamente supportato per le tabelle e le viste di sistema. Le autorizzazioni RBAC per le tabelle e le viste di sistema non persistono durante gli aggiornamenti, i downgrade o i ridimensionamenti. Consigliamo di utilizzare [Ruoli definiti dal sistema di Amazon RedshiftRuoli e utenti definiti dal sistema per la condivisione dei dati](r_roles-default.md) per gestire le autorizzazioni per le tabelle e le viste di sistema. Per ulteriori informazioni sulle tabelle di sistema, consulta [Riferimento di tabelle e viste di sistema](cm_chap_system-tables.md).
# Gestione dei ruoli in RBAC
Di seguito viene fornito un elenco dei comandi necessari per eseguire determinate azioni:
+ Per creare un ruolo, utilizza il comando [CREATE ROLE](r_CREATE_ROLE.md).
+ Per rinominare un ruolo o modificare il rispettivo proprietario, utilizza il comando [ALTER ROLE](r_ALTER_ROLE.md).
+ Per eliminare un ruolo, utilizza il comando [DROP ROLE](r_DROP_ROLE.md).
+ Per concedere un ruolo a un utente, utilizza il comando [GRANT](r_GRANT.md).
+ Per revocare un ruolo da un utente, utilizza il comando [REVOKE](r_REVOKE.md).
+ Per concedere autorizzazioni di sistema a un ruolo, utilizza il comando [GRANT](r_GRANT.md).
+ Per revocare autorizzazioni di sistema da un ruolo, utilizza il comando [REVOKE](r_REVOKE.md).
Per visualizzare l'elenco dei ruoli del cluster o del gruppo di lavoro, consulta [SVV\$1ROLES](r_SVV_ROLES.md).
# Tutorial: creazione di ruoli ed esecuzione di query con RBAC
Con RBAC, puoi creare ruoli autorizzati a eseguire comandi con cui richiedere autorizzazioni di utente con privilegi avanzati. Gli utenti possono eseguire questi comandi purché sia loro assegnato un ruolo che includa tali autorizzazioni.
In questo tutorial utilizzi il controllo degli accessi basato sul ruolo (RBAC) per gestire le autorizzazioni in un database creato. Quindi ti connetti al database ed esegui query sul database da due ruoli diversi per testare la funzionalità di RBAC.
I due ruoli creati e utilizzati per eseguire query sul database sono `sales_ro` e `sales_rw`. Crei il ruolo `sales_ro` ed esegui query sui dati come utente con il ruolo `sales_ro`. L’utente `sales_ro` può utilizzare solo il comando SELECT ma non il comando UPDATE. Quindi crei il ruolo `sales_rw` ed esegui query sui dati come utente con il ruolo `sales_rw`. L’utente `sales_rw` può utilizzare il comando SELECT e il comando UPDATE.
Inoltre puoi creare ruoli per limitare l’accesso a determinati comandi e assegnarli a utenti con privilegi avanzati o utenti normali.
**Attività**
+ [Prerequisiti](#tutorial-rbac-prereqs)
+ [Fase 1: creare un utente amministratore](#tutorial-rbac-step1)
+ [Fase 2: configurare gli schemi](#tutorial-rbac-step2)
+ [Fase 3: creare un utente di sola lettura](#tutorial-rbac-step3)
+ [Fase 4: eseguire le query sui dati come utente di sola lettura](#tutorial-rbac-step4)
+ [Fase 5: creare un utente di lettura/scrittura](#tutorial-rbac-step5)
+ [Fase 6: eseguire query sui dati come utente con il ruolo di sola lettura ereditato](#tutorial-rbac-step6)
+ [Fase 7: concedere le autorizzazioni di aggiornamento e inserimento al ruolo di lettura/scrittura](#tutorial-rbac-step7)
+ [Fase 8: eseguire le query sui dati come utente di lettura/scrittura](#tutorial-rbac-step8)
+ [Fase 9: analizzare le tabelle in un database ed eseguirvi un’attività di vacuum come utente amministratore](#tutorial-rbac-step9)
+ [Fase 10: troncare le tabelle come utente di lettura/scrittura](#tutorial-rbac-step10)
+ [Funzioni di sistema per RBAC (facoltativo)](#tutorial-rbac-system-functions)
+ [Viste di sistema per RBAC (facoltativo)](#tutorial-rbac-system-views)
+ [Utilizza la sicurezza a livello di riga con RBAC (facoltativo)](#tutorial-rbac-rls)
## Prerequisiti
+ Crea un cluster o un gruppo di lavoro serverless Amazon Redshift caricato con il database di esempio TICKIT. Per creare un gruppo di lavoro serverless, consulta [Introduzione ai data warehouse serverless di Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html). Per creare un cluster, consulta [Creazione di un cluster di esempio Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html). Per ulteriori informazioni sul database di esempio TICKIT, consulta[Database di esempio](c_sampledb.md).
+ Accedi a un utente con autorizzazioni di utente con privilegi avanzati o amministratore del ruolo. Solo gli utenti con privilegi avanzati o gli amministratori del ruolo possono concedere e revocare ruoli. Per ulteriori informazioni sulle autorizzazioni richieste per RBAC, consulta [Autorizzazioni di sistema per RBAC](r_roles-system-privileges.md).
+ Rivedere le [Considerazioni sull'utilizzo dei ruoli in RBAC](r_role-usage-notes.md).
## Fase 1: creare un utente amministratore
Per configurare questo tutorial, crei un ruolo di Database Administrator e lo colleghi a un utente amministratore del database in questa fase. Devi creare il Database Administrator come utente con privilegi avanzati o amministratore del ruolo.
Esegui tutte le query in [Amazon Redshift Query Editor V2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html).
1. Per creare il ruolo di amministratore db\$1admin, utilizza l’esempio seguente.
```
CREATE ROLE db_admin;
```
1. Per creare un utente del database denominato dbadmin, utilizza l’esempio seguente.
```
CREATE USER dbadmin PASSWORD 'Test12345';
```
1. Per concedere il ruolo definito dal sistema denominato sys:dba al ruolo db\$1admin, utilizza l’esempio seguente. Quando gli viene concesso il ruolo sys:dba, l’utente dbadmin può creare schemi e tabelle. Per ulteriori informazioni, consulta [Ruoli definiti dal sistema di Amazon RedshiftRuoli e utenti definiti dal sistema per la condivisione dei dati](r_roles-default.md).
## Fase 2: configurare gli schemi
In questa fase ti connetti al database come Database Administrator. Quindi crei due schemi e a essi aggiungi i dati.
1. Connettiti al database di sviluppo come utente dbadmin utilizzando Query Editor V2. Per ulteriori informazioni sulla connessione a un database, consulta [Utilizzo di Query Editor V2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html).
1. Per creare gli schemi del database di vendita e marketing, utilizza l’esempio seguente.
```
CREATE SCHEMA sales;
CREATE SCHEMA marketing;
```
1. Per creare e inserire i valori nelle tabelle dello schema di vendita, utilizza l’esempio seguente.
```
CREATE TABLE sales.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO sales.cat(SELECT * FROM category);
CREATE TABLE sales.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO sales.dates(SELECT * FROM date);
CREATE TABLE sales.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO sales.events(SELECT * FROM event);
CREATE TABLE sales.sale(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO sales.sale(SELECT * FROM sales);
```
1. Per creare e inserire i valori nelle tabelle dello schema di marketing, utilizza l’esempio seguente.
```
CREATE TABLE marketing.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO marketing.cat(SELECT * FROM category);
CREATE TABLE marketing.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO marketing.dates(SELECT * FROM date);
CREATE TABLE marketing.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO marketing.events(SELECT * FROM event);
CREATE TABLE marketing.sale(
marketingid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO marketing.sale(SELECT * FROM marketing);
```
## Fase 3: creare un utente di sola lettura
In questa fase crei un ruolo di sola lettura e un utente salesanalyst per il ruolo di sola lettura. L’analista delle vendite necessita solo dell’accesso in sola lettura alle tabelle dello schema di vendita per svolgere il compito assegnato di trovare gli eventi che hanno portato alle commissioni più elevate.
1. Connettiti al database come utente dbadmin.
1. Per creare il ruolo sales\$1ro, utilizza l’esempio seguente.
```
CREATE ROLE sales_ro;
```
1. Per creare l’utente salesanalyst, utilizza l’esempio seguente.
```
CREATE USER salesanalyst PASSWORD 'Test12345';
```
1. Per concedere l’utilizzo del ruolo sales\$1ro e selezionare l’accesso agli oggetti dello schema di vendita, utilizza l’esempio seguente.
```
GRANT USAGE ON SCHEMA sales TO ROLE sales_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro;
```
1. Per concedere all’utente salesanalyst il ruolo sales\$1ro, utilizza l’esempio seguente.
```
GRANT ROLE sales_ro TO salesanalyst;
```
## Fase 4: eseguire le query sui dati come utente di sola lettura
In questa fase, l’utente salesanalyst esegue le query sui dati dallo schema di vendita. Quindi l’utente salesanalyst tenta di aggiornare una tabella e di leggere le tabelle nello schema di marketing.
1. Connettiti al database come utente salesanalyst.
1. Per trovare le 10 vendite con le commissioni più alte, utilizza l’esempio seguente.
```
SET SEARCH_PATH TO sales;
SELECT DISTINCT events.dateid, sale.commission, cat.catname
FROM sale, events, dates, cat
WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid
ORDER BY 2 DESC LIMIT 10;
+--------+------------+----------+
| dateid | commission | catname |
+--------+------------+----------+
| 1880 | 1893.6 | Pop |
| 1880 | 1893.6 | Opera |
| 1880 | 1893.6 | Plays |
| 1880 | 1893.6 | Musicals |
| 1861 | 1500 | Plays |
| 2003 | 1500 | Pop |
| 1861 | 1500 | Opera |
| 2003 | 1500 | Plays |
| 1861 | 1500 | Musicals |
| 1861 | 1500 | Pop |
+--------+------------+----------+
```
1. Per selezionare 10 eventi dalla tabella degli eventi nello schema di vendita, utilizza l’esempio seguente.
```
SELECT * FROM sales.events LIMIT 10;
+---------+---------+-------+--------+--------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+--------------------+---------------------+
| 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 |
| 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 |
| 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 |
| 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 |
| 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 |
| 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 |
| 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 |
| 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 |
| 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 |
| 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 |
+---------+---------+-------+--------+--------------------+---------------------+
```
1. Per tentare di aggiornare il nome dell’evento per eventid 1, utilizza l’esempio seguente. Questo esempio genererà un errore di autorizzazione negata perché l’utente salesanalyst dispone solo delle autorizzazioni SELECT per la tabella degli eventi dello schema di vendita. Per aggiornare la tabella degli eventi, devi concedere al ruolo sales\$1ro le autorizzazioni UPDATE. Per ulteriori informazioni su come concedere le autorizzazioni per aggiornare una tabella, consulta il parametro UPDATE per [GRANT](r_GRANT.md). Per ulteriori informazioni sul comando COPY, consulta [UPDATE](r_UPDATE.md).
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
1. Per tentare di selezionare tutto dalla tabella degli eventi nello schema di marketing, utilizza l’esempio seguente. Questo esempio genererà un errore di autorizzazione negata perché l’utente salesanalyst dispone solo delle autorizzazioni SELECT per la tabella degli eventi nello schema di vendita. Per selezionare i dati dalla tabella degli eventi nello schema di marketing, devi concedere al ruolo sales\$1ro le autorizzazioni SELECT per la tabella degli eventi nello schema di marketing.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
## Fase 5: creare un utente di lettura/scrittura
In questa fase, il tecnico commerciale responsabile della creazione della pipeline di estrazione, trasformazione e caricamento (ETL) per l’elaborazione dei dati nello schema di vendita riceverà l’accesso in sola lettura, ma in seguito avrà l’accesso in lettura e scrittura per svolgere le proprie attività.
1. Connettiti al database come utente dbadmin.
1. Per creare il ruolo sales\$1rw nello schema di vendita, utilizza l’esempio seguente.
```
CREATE ROLE sales_rw;
```
1. Per creare l’utente salesengineer, utilizza l’esempio seguente.
```
CREATE USER salesengineer PASSWORD 'Test12345';
```
1. Per concedere l’utilizzo del ruolo sales\$1rw e selezionare l’accesso agli oggetti dello schema di vendita assegnandogli il ruolo sales\$1ro, utilizza l’esempio seguente. Per ulteriori informazioni su come i ruoli ereditano le autorizzazioni in Amazon Redshift, consulta [Gerarchia dei ruoli](t_role_hierarchy.md).
```
GRANT ROLE sales_ro TO ROLE sales_rw;
```
1. Per assegnare il ruolo sales\$1rw all’utente salesengineer, utilizza l’esempio seguente.
```
GRANT ROLE sales_rw TO salesengineer;
```
## Fase 6: eseguire query sui dati come utente con il ruolo di sola lettura ereditato
In questa fase, l’utente salesengineer tenta di aggiornare la tabella degli eventi prima di ottenere le autorizzazioni di lettura.
1. Connettiti al database come utente salesengineer.
1. L’utente salesengineer può leggere correttamente i dati dalla tabella degli eventi dello schema di vendita. Per selezionare l’evento con eventid 1 dalla tabella degli eventi nello schema di vendita, utilizza l’esempio seguente.
```
SELECT * FROM sales.events where eventid=1;
+---------+---------+-------+--------+-----------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------+---------------------+
| 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+-----------------+---------------------+
```
1. Per tentare di selezionare tutto dalla tabella degli eventi nello schema di marketing, utilizza l’esempio seguente. L’utente salesengineer non dispone delle autorizzazioni per le tabelle dello schema di marketing. Pertanto questa query genererà un errore di autorizzazione negata. Per selezionare i dati dalla tabella degli eventi nello schema di marketing, devi concedere al ruolo sales\$1rw le autorizzazioni SELECT per la tabella degli eventi nello schema di marketing.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
1. Per tentare di aggiornare il nome dell’evento per eventid 1, utilizza l’esempio seguente. Questo esempio genererà un errore di autorizzazione negata perché l’utente salesengineer dispone solo delle autorizzazioni SELECT per la tabella degli eventi nello schema di vendita. Per aggiornare la tabella degli eventi, devi concedere al ruolo sales\$1rw le autorizzazioni UPDATE.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
## Fase 7: concedere le autorizzazioni di aggiornamento e inserimento al ruolo di lettura/scrittura
In questa fase concedi le autorizzazioni di aggiornamento e inserimento al ruolo sales\$1rw.
1. Connettiti al database come utente dbadmin.
1. Per concedere le autorizzazioni UPDATE, INSERT e DELETE al ruolo sales\$1rw, utilizza l’esempio seguente.
```
GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw;
```
## Fase 8: eseguire le query sui dati come utente di lettura/scrittura
In questa fase, l’utente salesengineer aggiorna correttamente la tabella dopo che al suo ruolo sono state concesse le autorizzazioni di inserimento e aggiornamento. Successivamente l’utente salesengineer tenta di analizzare la tabella degli eventi ed eseguirvi un’attività di vacuum, ma non riesce.
1. Connettiti al database come utente salesengineer.
1. Per aggiornare il nome dell’evento per eventid 1, utilizza l’esempio seguente.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
```
1. Per visualizzare la modifica apportata nella query precedente, utilizza l’esempio seguente per selezionare l’evento con eventid 1 dalla tabella degli eventi nello schema di vendita.
```
SELECT * FROM sales.events WHERE eventid=1;
+---------+---------+-------+--------+---------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+---------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+---------------+---------------------+
```
1. Per analizzare la tabella degli eventi aggiornata nello schema di vendita, utilizza l’esempio seguente. Questo esempio genererà un errore di autorizzazione negata perché l’utente salesengineer non dispone delle autorizzazioni necessarie e non è il proprietario della tabella degli eventi nello schema di vendita. Per analizzare la tabella degli eventi, devi concedere al ruolo sales\$1rw le autorizzazioni ANALYZE utilizzando il comando GRANT. Per ulteriori informazioni sul comando ANALYZE, consulta [ANALYZE](r_ANALYZE.md).
```
ANALYZE sales.events;
ERROR: skipping "events" --- only table or database owner can analyze
```
1. Per eseguire un’attività di vacuum nella tabella degli eventi aggiornata, utilizza l’esempio seguente. Questo esempio genererà un errore di autorizzazione negata perché l’utente salesengineer non dispone delle autorizzazioni necessarie e non è il proprietario della tabella degli eventi nello schema di vendita. Per cancellare la tabella degli eventi, devi concedere al ruolo sales\$1rw le autorizzazioni VACUUM utilizzando il comando GRANT. Per ulteriori informazioni sul comando VACUUM, consulta [VACUUM](r_VACUUM_command.md).
```
VACUUM sales.events;
ERROR: skipping "events" --- only table or database owner can vacuum it
```
## Fase 9: analizzare le tabelle in un database ed eseguirvi un’attività di vacuum come utente amministratore
In questa fase, l’utente dbadmin analizza tutte le tabelle e vi esegue un’attività di vacuum. L’utente dispone delle autorizzazioni di amministratore per questo database, quindi è in grado di eseguire questi comandi.
1. Connettiti al database come utente dbadmin.
1. Per analizzare la tabella degli eventi nello schema di vendita, utilizza l’esempio seguente.
```
ANALYZE sales.events;
```
1. Per eseguire un’attività di vacuum nella tabella degli eventi nello schema di vendita, utilizza l’esempio seguente.
```
VACUUM sales.events;
```
1. Per analizzare la tabella degli eventi nello schema di marketing, utilizza l’esempio seguente.
```
ANALYZE marketing.events;
```
1. Per riepilogare la tabella degli eventi nello schema di marketing, utilizza l’esempio seguente.
```
VACUUM marketing.events;
```
## Fase 10: troncare le tabelle come utente di lettura/scrittura
In questa fase, l’utente salesengineer tenta di troncare la tabella degli eventi nello schema di vendita, ma ci riesce solo se l’utente dbadmin concede le autorizzazioni di troncamento.
1. Connettiti al database come utente salesengineer.
1. Per provare a eliminare tutte le righe dalla tabella degli eventi nello schema di vendita, utilizza l’esempio seguente. Questo esempio genererà un errore perché l’utente salesengineer non dispone delle autorizzazioni necessarie e non è il proprietario della tabella degli eventi nello schema di vendita. Per troncare la tabella degli eventi, devi concedere al ruolo sales\$1rw le autorizzazioni TRUNCATE utilizzando il comando GRANT. Per ulteriori informazioni sul comando TRUNCATE, consulta [TRUNCATE](r_TRUNCATE.md).
```
TRUNCATE sales.events;
ERROR: must be owner of relation events
```
1. Connettiti al database come utente dbadmin.
1. Per concedere i privilegi di troncare la tabella al ruolo sales\$1rw, utilizza l’esempio seguente.
```
GRANT TRUNCATE TABLE TO role sales_rw;
```
1. Connettiti al database come utente salesengineer utilizzando Query Editor V2.
1. Per leggere i primi 10 eventi dalla tabella degli eventi nello schema di vendita, utilizza l’esempio seguente.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
| 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 |
| 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 |
| 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 |
| 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 |
| 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 |
| 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 |
| 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 |
| 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 |
| 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
1. Per troncare la tabella degli eventi nello schema di vendita, utilizza l’esempio seguente.
```
TRUNCATE sales.events;
```
1. Per leggere i dati dalla tabella degli eventi aggiornata nello schema di vendita, utilizza l’esempio seguente.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
### Creare ruoli di sola lettura e di lettura/scrittura per lo schema di marketing (facoltativo)
In questa fase crei ruoli di sola lettura e di lettura/scrittura per lo schema di marketing.
1. Connettiti al database come utente dbadmin.
1. Per creare ruoli di sola lettura e lettura/scrittura per lo schema di marketing, utilizza l’esempio seguente.
```
CREATE ROLE marketing_ro;
CREATE ROLE marketing_rw;
GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw;
GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro;
GRANT ROLE marketing_ro TO ROLE marketing_rw;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw;
CREATE USER marketinganalyst PASSWORD 'Test12345';
CREATE USER marketingengineer PASSWORD 'Test12345';
GRANT ROLE marketing_ro TO marketinganalyst;
GRANT ROLE marketing_rw TO marketingengineer;
```
## Funzioni di sistema per RBAC (facoltativo)
Amazon Redshift offre due funzioni per fornire informazioni di sistema sull’appartenenza degli utenti e sull’appartenenza ai ruoli in gruppi o ruoli aggiuntivi: role\$1is\$1member\$1of e user\$1is\$1member\$1of. Queste funzioni sono disponibili per gli utenti con privilegi avanzati e gli utenti normali. Gli utenti con privilegi avanzati possono controllare tutte le appartenenze ai ruoli. Gli utenti normali possono verificare l’appartenenza solo ai ruoli per cui hanno ottenuto l’accesso.
Come utilizzare la funzione role\$1is\$1member\$1of
1. Connettiti al database come utente salesengineer.
1. Per verificare se il ruolo sales\$1rw è un membro del ruolo sales\$1ro, utilizza l’esempio seguente.
```
SELECT role_is_member_of('sales_rw', 'sales_ro');
+-------------------+
| role_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Per verificare se il ruolo sales\$1ro è un membro del ruolo sales\$1rw, utilizza l’esempio seguente.
```
SELECT role_is_member_of('sales_ro', 'sales_rw');
+-------------------+
| role_is_member_of |
+-------------------+
| false |
+-------------------+
```
Come utilizzare la funzione user\$1is\$1member\$1of
1. Connettiti al database come utente salesengineer.
1. L’esempio seguente tenta di verificare l’appartenenza dell’utente salesanalyst. Questa query genera un errore perché l’utente salesengineer non ha accesso a salesanalyst. Per eseguire correttamente questo comando, connettiti al database come utente salesanalyst e utilizza l’esempio.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
ERROR
```
1. Connettiti al database come superutente.
1. Per verificare l’appartenenza dell’utente salesanalyst quando è connesso come utente con privilegi avanzati, utilizza l’esempio seguente.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Connettiti al database come utente dbadmin.
1. Per verificare l’appartenenza dell’utente salesengineer, utilizza l’esempio seguente.
```
SELECT user_is_member_of('salesengineer', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
SELECT user_is_member_of('salesengineer', 'marketing_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
SELECT user_is_member_of('marketinganalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
```
## Viste di sistema per RBAC (facoltativo)
Per visualizzare i ruoli, l’assegnazione dei ruoli agli utenti, la gerarchia dei ruoli e i privilegi per gli oggetti di database tramite i ruoli, utilizza le viste di sistema per Amazon Redshift. Queste viste sono disponibili per gli utenti con privilegi avanzati e gli utenti normali. Gli utenti con privilegi avanzati possono controllare tutti i dettagli del ruolo. Gli utenti normali possono controllare solo i dettagli dei ruoli per cui hanno ottenuto l’accesso.
1. Per visualizzare un elenco di utenti a cui sono concessi esplicitamente ruoli nel cluster, utilizza l’esempio seguente.
```
SELECT * FROM svv_user_grants;
```
1. Per visualizzare un elenco di ruoli a cui sono concessi esplicitamente ruoli nel cluster, utilizza l’esempio seguente.
```
SELECT * FROM svv_role_grants;
```
Per l’elenco completo delle viste di sistema, consulta [Viste SVV dei metadati](svv_views.md).
## Utilizza la sicurezza a livello di riga con RBAC (facoltativo)
Per avere il controllo degli accessi granulare sui dati sensibili, utilizza la sicurezza a livello di riga (RLS). Per ulteriori informazioni sulla RLS, consulta [Sicurezza a livello di riga](t_rls.md).
In questa sezione crei una policy RLS che concede all’utente `salesengineer` le autorizzazioni per visualizzare solo le righe della tabella `cat` che hanno il valore `catdesc` di Major League Baseball. Quindi esegui query sul database come utente `salesengineer`.
1. Connettiti al database come utente `salesengineer`.
1. Per visualizzare le prime cinque voci nella tabella `cat`, utilizza l’esempio seguente.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Connettiti al database come utente `dbadmin`.
1. Per creare una policy RLS per la colonna `catdesc` della tabella `cat`, utilizza l’esempio seguente.
```
CREATE RLS POLICY policy_mlb_engineer
WITH (catdesc VARCHAR(50))
USING (catdesc = 'Major League Baseball');
```
1. Per collegare la policy RLS al ruolo `sales_rw`, utilizza l’esempio seguente.
```
ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw;
```
1. Per modificare la tabella per attivare RLS, utilizza l’esempio seguente.
```
ALTER TABLE sales.cat ROW LEVEL SECURITY ON;
```
1. Connettiti al database come utente `salesengineer`.
1. Per tentare di visualizzare le prime cinque voci nella tabella `cat`, utilizza l’esempio seguente. Tieni presente che le voci vengono visualizzate solo quando la colonna `catdesc` è `Major League Baseball`.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
| 1 | Sports | MLB | Major League Baseball |
+-------+----------+---------+-----------------------+
```
1. Connettiti al database come utente `salesanalyst`.
1. Per tentare di visualizzare le prime cinque voci nella tabella `cat`, utilizza l’esempio seguente. Tieni presente che non viene visualizzata alcuna voce perché viene applicata la policy di rifiuto di tutto per impostazione predefinita.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Connettiti al database come utente `dbadmin`.
1. Per concedere l’autorizzazione IGNORE RLS al ruolo `sales_ro`, utilizza l’esempio seguente. All’utente `salesanalyst` vengono concesse le autorizzazioni per ignorare le policy RLS poiché è un membro del ruolo `sales_ro`.
```
GRANT IGNORE RLS TO ROLE sales_ro;
```
1. Connettiti al database come utente `salesanalyst`.
1. Per visualizzare le prime cinque voci nella tabella `cat`, utilizza l’esempio seguente.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Connettiti al database come utente `dbadmin`.
1. Per revocare l’autorizzazione IGNORE RLS dal ruolo `sales_ro`, utilizza l’esempio seguente.
```
REVOKE IGNORE RLS FROM ROLE sales_ro;
```
1. Connettiti al database come utente `salesanalyst`.
1. Per tentare di visualizzare le prime cinque voci nella tabella `cat`, utilizza l’esempio seguente. Tieni presente che non viene visualizzata alcuna voce perché viene applicata la policy di rifiuto di tutto per impostazione predefinita.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Connettiti al database come utente `dbadmin`.
1. Per scollegare la policy RLS dalla tabella `cat`, utilizza l’esempio seguente.
```
DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw;
```
1. Connettiti al database come utente `salesanalyst`.
1. Per tentare di visualizzare le prime cinque voci nella tabella `cat`, utilizza l’esempio seguente. Tieni presente che non viene visualizzata alcuna voce perché viene applicata la policy di rifiuto di tutto per impostazione predefinita.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Connettiti al database come utente `dbadmin`.
1. Per rimuovere la policy RLS, utilizza l’esempio seguente.
```
DROP RLS POLICY policy_mlb_engineer;
```
1. Per rimuovere RLS, utilizza l’esempio seguente.
```
ALTER TABLE cat ROW LEVEL SECURITY OFF;
```
## Argomenti correlati
Per ulteriori informazioni su RBAC, consulta la documentazione seguente:
+ [Gerarchia dei ruoli](t_role_hierarchy.md)
+ [Assegnazione del ruolo](t_role_assignment.md)
+ [Autorizzazioni per un oggetto del database](r_roles-database-privileges.md)
+ [ALTER DEFAULT PRIVILEGES per RBAC](r_roles-alter-default-privileges.md)
# Sicurezza a livello di riga
Utilizzando la sicurezza a livello di riga (RLS) in Amazon Redshift, puoi avere un controllo dettagliato degli accessi ai tuoi dati sensibili. Puoi decidere quali utenti o ruoli possono accedere a record di dati specifici all'interno di schemi o tabelle, in base alle policy di sicurezza definite a livello di oggetti di database. Oltre alla sicurezza a livello di colonna, in cui puoi concedere agli utenti le autorizzazioni per un sottoinsieme di colonne, le policy RLS possono essere utilizzate per limitare ulteriormente l'accesso a determinate righe delle colonne visibili. Per ulteriori informazioni sulla sicurezza a livello di colonna, consulta [Note di utilizzo per il controllo degli accessi a livello di colonna](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp).
Quando si applicano le policy RLS sulle tabelle, puoi limitare i set di risultati restituiti quando gli utenti eseguono le query.
Durante la creazione di policy RLS, puoi specificare espressioni che stabiliscono se Amazon Redshift restituisce righe esistenti in una tabella in una query. Creando policy RLS per limitare l'accesso, non dovrai aggiungere o esternalizzare altre condizioni nelle query.
Quando si creano le policy RLS, consigliamo di creare policy semplici ed evitare istruzioni complesse. Quando definisci le policy RLS, non utilizzare un numero eccessivo di unioni di tabelle basate sulle policy.
Quando una policy fa riferimento a una tabella di ricerca, Amazon Redshift esegue l'analisi della tabella aggiuntiva oltre che della tabella che contiene la policy. La stessa query restituirà prestazioni differenti per un utente con una policy RLS collegata e un utente senza alcuna policy.
# Utilizzo di policy RLS nelle istruzioni SQL
Quando si utilizzano policy RLS nelle istruzioni SQL, Amazon Redshift applica le seguenti regole:
+ Per impostazione predefinita, Amazon Redshift applica le policy RLS alle istruzioni SELECT, UPDATE e DELETE.
+ Per SELECT e UNLOAD, Amazon Redshift filtra le righe in base alla policy definita.
+ Per UPDATE, Amazon Redshift aggiorna solo le righe visibili per te. Se una policy limita un sottoinsieme di righe in una tabella, non sarà possibile aggiornarle.
+ Per DELETE, puoi eliminare solo le righe visibili per te. Se una policy limita un sottoinsieme di righe in una tabella, non sarà possibile aggiornarle. Per TRUNCATE, è comunque possibile troncare la tabella.
+ Per CREATE TABLE LIKE, le tabelle create con le opzioni LIKE non erediteranno le impostazioni delle autorizzazioni dalla tabella di origine. Allo stesso modo, la tabella di destinazione non erediterà le policy RLS dalla tabella di origine.
# Combinazione di più policy per utente
RLS in Amazon Redshift supporta il collegamento di più policy per utente e oggetto. Quando sono definite più policy per un utente, Amazon Redshift applica tutte le policy con la sintassi AND o OR a seconda dell'impostazione RLS CONJUNCTION TYPE per la tabella. Per ulteriori informazioni sui tipi di combinazione, consulta [ALTER TABLE](r_ALTER_TABLE.md).
Più policy su una tabella possono essere associate alla tua utenza. Le policy possono essere collegate direttamente a te o puoi appartenere a più ruoli e i ruoli hanno policy diverse associate.
Quando più policy devono limitare l'accesso alle righe in una determinata relazione, puoi impostare RLS CONJUNCTION TYPE della relazione su AND. Analizza l’esempio seguente. Alice può vedere solo gli eventi sportivi che hanno il "catname" NBA, come specificato nella policy.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Create an RLS policy that only lets the user see NBA.
CREATE RLS POLICY policy_nba
WITH (catname VARCHAR(10))
USING (catname = 'NBA');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
ATTACH RLS POLICY policy_nba ON category TO ROLE analyst;
-- Activate RLS on the category table with AND CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, catname
FROM category;
catgroup | catname
---------+---------
Sports | NBA
(1 row)
```
Quando più policy devono permettere agli utenti di vedere più righe in una determinata relazione, l'utente può impostare RLS CONJUNCTION TYPE della relazione su OR. Analizza l’esempio seguente. Alice può vedere solo "Concerts" e "Sports", come specificato nella policy.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see concerts.
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst;
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
-- Activate RLS on the category table with OR CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, count(*)
FROM category
GROUP BY catgroup ORDER BY catgroup;
catgroup | count
---------+-------
Concerts | 3
Sports | 5
(2 rows)
```
# Proprietà e gestione delle policy RLS
In qualità di utente con privilegi avanzati, amministratore della sicurezza o utente con il ruolo sys:secadmin, puoi creare, modificare, collegare e scollegare le policy RLS. Le politiche RLS possono essere allegate a tabelle, viste, viste con associazione tardiva (LBVs) e viste materializzate (MVs). A livello di oggetto, puoi attivare o disattivare la sicurezza a livello di riga senza modificare la definizione dello schema per le tabelle.
Per iniziare con la sicurezza a livello di riga, di seguito sono riportate le istruzioni SQL che è possibile utilizzare:
+ Utilizza l’istruzione ALTER TABLE per attivare o disattivare RLS in una tabella, una vista o una vista con associazione tardiva. Per ulteriori informazioni, consulta [ALTER TABLE](r_ALTER_TABLE.md).
+ Utilizza l’istruzione ALTER MATERIALIZED VIEW per attivare o disattivare RLS in una vista materializzata. Per ulteriori informazioni, consulta [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md).
+ Utilizza l'istruzione CREATE RLS POLICY per creare una policy di sicurezza per una o più tabelle e specificare uno o più utenti o ruoli nella policy.
Per ulteriori informazioni, consulta [CREATE RLS POLICY](r_CREATE_RLS_POLICY.md).
+ Utilizza l'istruzione ALTER RLS POLICY per modificare la policy, ad esempio cambiandone la definizione. Puoi utilizzare la stessa policy per più tabelle o viste.
Per ulteriori informazioni, consulta [ALTER RLS POLICY](r_ALTER_RLS_POLICY.md).
+ Utilizza l'istruzione ATTACH RLS POLICY per collegare una policy a una o più relazioni, a uno o più utenti o ai ruoli.
Per ulteriori informazioni, consulta [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ Utilizza l’istruzione DETACH RLS POLICY per scollegare una policy da una o più relazioni, da uno o più utenti o dai ruoli.
Per ulteriori informazioni, consulta [DETACH RLS POLICY](r_DETACH_RLS_POLICY.md).
+ Utilizza l'istruzione DROP RLS POLICY per eliminare una policy.
Per ulteriori informazioni, consulta [DROP RLS POLICY](r_DROP_RLS_POLICY.md).
+ Utilizza le istruzioni GRANT e REVOKE per concedere e revocare esplicitamente le autorizzazioni SELECT alle policy RLS che fanno riferimento alle tabelle di ricerca. Per ulteriori informazioni, consultare [GRANT](r_GRANT.md) e [REVOKE](r_REVOKE.md).
Per monitorare le policy create, sys:secadmin può visualizzare [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) e [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md).
Per elencare le relazioni protette da RLS, sys:secadmin può visualizzare [SVV\$1RLS\$1RELATION](r_SVV_RLS_RELATION.md).
Per tracciare l'applicazione delle policy RLS su query che fanno riferimento a relazioni protette da RLS, un superutente, sys:operator o qualsiasi utente con l'autorizzazione di sistema ACCESS SYSTEM TABLE può visualizzare [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md). Per impostazione predefinita, a sys:secadmin non sono concesse queste autorizzazioni.
Per consentire agli utenti l’accesso completo a una relazione protetta da RLS, puoi concedere l’autorizzazione IGNORE RLS. Agli utenti con privilegi avanzati o sys:secadmin l’autorizzazione IGNORE RLS viene concessa automaticamente. Per ulteriori informazioni, consulta [GRANT](r_GRANT.md).
Per spiegare i filtri delle policy RLS di una query nel piano EXPLAIN per la risoluzione dei problemi relativi alle query correlate a RLS, puoi concedere l'autorizzazione EXPLAIN RLS a qualsiasi utente. Per ulteriori informazioni, consultare [GRANT](r_GRANT.md) e [EXPLAIN](r_EXPLAIN.md).
# Oggetti e principi dipendenti dalle policy
Per garantire la sicurezza delle applicazioni ed evitare che gli oggetti delle policy diventino obsoleti o non validi, Amazon Redshift non consente di eliminare o modificare oggetti a cui fanno riferimento le policy RLS.
Di seguito sono elencate le dipendenze degli oggetti dello schema che Amazon Redshift monitora per le policy RLS.
+ Quando si tiene traccia della dipendenza degli oggetti dello schema per la tabella di destinazione, Amazon Redshift segue queste regole:
+ Quando si elimina una tabella di destinazione, Amazon Redshift scollega la policy da una relazione, un utente, un ruolo o un pubblico.
+ Quando si rinomina il nome di una tabella di destinazione, non vi è alcun impatto sulle policy collegate.
+ Puoi eliminare le colonne della tabella delle policy a cui viene fatto riferimento all'interno della definizione della policy solo se elimini o scolleghi prima la policy. Ciò vale anche quando viene specificata l'opzione CASCADE. Puoi eliminare altre colonne nella tabella di destinazione.
+ Non è possibile rinominare le colonne di riferimento della tabella di destinazione. Per rinominare le colonne di riferimento, scollega prima la policy. Ciò vale anche quando viene specificata l'opzione CASCADE.
+ Non è possibile modificare il tipo di colonna, anche se si specifica l'opzione CASCADE.
+ Quando si tiene traccia della dipendenza degli oggetti dello schema per la tabella di ricerca, Amazon Redshift segue queste regole:
+ Non è possibile eliminare una tabella di ricerca. Per eliminare una tabella di ricerca, è necessario eliminare prima la policy in cui si fa riferimento alla tabella di ricerca.
+ Non puoi rinominare una tabella di ricerca. Per rinominare una tabella di ricerca, è necessario eliminare prima la policy in cui si fa riferimento alla tabella di ricerca. Ciò vale anche quando viene specificata l'opzione CASCADE.
+ Non è possibile eliminare le colonne della tabella di ricerca utilizzate nella definizione della policy. Per eliminare le colonne di una tabella di ricerca utilizzata nella definizione di policy, è necessario eliminare prima la policy in cui si fa riferimento alla tabella di ricerca. Ciò si applica anche quando l'opzione CASCADE è specificata nell'istruzione ALTER TABLE DROP COLUMN. Puoi eliminare altre colonne nella tabella di ricerca.
+ Non è possibile rinominare le colonne di riferimento della tabella di ricerca. Per rinominare le colonne di riferimento, è necessario eliminare prima la policy in cui si fa riferimento alla tabella di ricerca. Ciò vale anche quando viene specificata l'opzione CASCADE.
+ Non puoi modificare il tipo della colonna a cui fai riferimento.
+ Quando un utente o un ruolo viene eliminato, Amazon Redshift scollega automaticamente tutte le policy collegate all'utente o il ruolo.
+ Se utilizzi l'opzione CASCADE nell'istruzione DROP SCHEMA, Amazon Redshift elimina anche le relazioni nello schema. Inoltre, elimina le relazioni in tutti gli altri schemi che dipendono dalle relazioni nello schema eliminato. Per una relazione che è una tabella di ricerca in una policy, Amazon Redshift non completa DROP SCHEMA DDL. Per qualsiasi relazione eliminata dall'istruzione DROP SCHEMA, Amazon Redshift scollega tutte le policy associate a tali relazioni.
+ Puoi eliminare una funzione di ricerca (una funzione a cui si fa riferimento all'interno di una definizione di policy) solo se elimini anche la policy stessa. Ciò vale anche quando viene specificata l'opzione CASCADE.
+ Quando una policy è collegata a una tabella, Amazon Redshift verifica in una policy diversa se questa tabella è una tabella di ricerca. In tal caso, Amazon Redshift non consentirà il collegamento di una policy a questa tabella.
+ Durante la creazione di una policy RLS, Amazon Redshift verifica se questa tabella è una tabella di destinazione per qualsiasi altra policy RLS. In tal caso, Amazon Redshift non consentirà la creazione di una policy su questa tabella.
## Esempio
Nell’esempio seguente viene illustrato come viene monitorata la dipendenza dello schema.
```
-- The CREATE and ATTACH policy statements for `policy_events` references some
-- target and lookup tables.
-- Target tables are tickit_event_redshift and target_schema.target_event_table.
-- Lookup table is tickit_sales_redshift.
-- Policy `policy_events` has following dependencies:
-- table tickit_sales_redshift column eventid, qtysold
-- table tickit_event_redshift column eventid
-- table target_event_table column eventid
-- schema public and target_schema
CREATE RLS POLICY policy_events
WITH (eventid INTEGER)
USING (
eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
```
# Considerazioni e limitazioni relative all’utilizzo delle policy RLS
## Considerazioni
Di seguito sono riportate le considerazioni sull'utilizzo delle policy RLS:
+ Amazon Redshift applica le policy RLS alle istruzioni SELECT, UPDATE e DELETE.
+ Amazon Redshift non applica le policy RLS alle istruzioni INSERT, COPY, ALTER TABLE APPEND.
+ Le politiche RLS possono essere allegate a tabelle, viste, viste con associazione tardiva (LBVs) e viste materializzate (). MVs
+ La sicurezza a livello di riga funziona con la sicurezza a livello di colonna per proteggere i tuoi dati.
+ Se RLS è attivato per la relazione di origine, Amazon Redshift supporta l'istruzione ALTER TABLE APPEND per gli utenti con privilegi avanzati e gli utenti a cui è stata concessa esplicitamente l'autorizzazione di sistema IGNORE RLS o il ruolo sys:secadmin. In questo caso, puoi eseguire l'istruzione ALTER TABLE APPEND per aggiungere righe a una tabella di destinazione spostando i dati da una tabella di origine esistente. Amazon Redshift sposta tutte le tuple dalla relazione di origine alla relazione di destinazione. Lo stato RLS della relazione di destinazione non influisce sull'istruzione ALTER TABLE APPEND.
+ Per facilitare la migrazione da altri sistemi di data warehouse, puoi impostare e recuperare variabili di contesto di sessione personalizzate per una connessione specificando il nome e il valore della variabile.
Nell'esempio seguente vengono impostate le variabili di contesto della sessione per una policy di sicurezza a livello di riga (RLS).
```
-- Set a customized context variable.
SELECT set_config(‘app.category’, ‘Concerts’, FALSE);
-- Create a RLS policy using current_setting() to get the value of a customized context variable.
CREATE RLS POLICY policy_categories
WITH (catgroup VARCHAR(10))
USING (catgroup = current_setting('app.category', FALSE));
-- Set correct roles and attach the policy on the target table to one or more roles.
ATTACH RLS POLICY policy_categories ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
```
Per informazioni dettagliate su come impostare e recuperare variabili di contesto della sessione personalizzate, consulta [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [MOSTRA](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) e [RESET](r_RESET.md). Per ulteriori informazioni sulla modifica della configurazione del server in generale, consulta [Modifica della configurazione del server](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Importante**
Quando utilizzi variabili di contesto della sessione all’interno delle policy RLS, la policy di sicurezza dipende dall’utente o dal ruolo che la invoca. Presta attenzione a evitare vulnerabilità di sicurezza quando utilizzi variabili di contesto della sessione nelle policy RLS.
+ La modifica dell'utente della sessione mediante SET SESSION AUTHORIZATION tra DECLARE e FETCH o tra le successive istruzioni FETCH non aggiornerà il piano già preparato in base alle policy utente definite con DECLARE. Evita di modificare l'utente della sessione quando i cursori vengono utilizzati con tabelle protette da RLS.
+ Quando gli oggetti di base all'interno di un oggetto di visualizzazione sono protetti da RLS, le policy collegate all'utente che esegue la query vengono applicate ai rispettivi oggetti di base. Ciò non avviene invece con i controlli delle autorizzazioni a livello di oggetto, in cui le autorizzazioni del proprietario della vista vengono verificate tenendo conto degli oggetti di base della vista. È possibile visualizzare le relazioni protette da RLS di una query nell'output del piano EXPLAIN.
+ Quando si fa riferimento a una funzione definita dall'utente (UDF) in una policy RLS (sicurezza a livello di riga) di una relazione collegata a un utente, questo deve disporre dell'autorizzazione EXECUTE sull'UDF per eseguire query sulla relazione.
+ La sicurezza a livello di riga potrebbe limitare l'ottimizzazione delle query. Ti consigliamo di valutare attentamente le prestazioni delle query prima di distribuire viste protette da RLS su set di dati di grandi dimensioni.
+ Le policy di sicurezza a livello di riga applicate alle viste con associazione tardiva potrebbero essere inviate in tabelle federate. Queste policy RLS potrebbero essere visibili nei log dei motori di elaborazione esterni.
## Limitazioni
Di seguito sono riportate le limitazioni che si hanno quando si lavora con le policy RLS:
+ Le policy RLS non possono essere collegate alle tabelle esterne e a molti altri tipi di relazione. Per ulteriori informazioni, consulta [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ Amazon Redshift supporta le istruzioni SELECT per determinate policy RLS con ricerche che hanno join complessi, ma non supporta le istruzioni UPDATE o DELETE. Nei casi con istruzioni UPDATE o DELETE, Amazon Redshift restituisce il seguente errore:
```
ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.
```
+ Ogni qual volta si fa riferimento a una funzione definita dall'utente (UDF) in una policy RLS (sicurezza a livello di riga) di una relazione collegata a un utente, questo deve disporre dell'autorizzazione EXECUTE sull'UDF per eseguire query sulla relazione.
+ Le query secondarie correlate non sono supportate. Amazon Redshift restituisce il seguente errore:
```
ERROR: RLS policy could not be rewritten.
```
+ Amazon Redshift non supporta le unità di condivisione dati con RLS. Se una relazione non ha RLS (sicurezza a livello di riga) disattivata per le unità di condivisione dati, la query restituisce il seguente errore sul cluster consumer:
```
RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.
```
Puoi disattivare RLS per le unità di condivisione dati utilizzando il comando ALTER TABLE con il parametro ROW LEVEL SECURITY OFF FOR DATASHARES. Per ulteriori informazioni sull’utilizzo di ALTER TABLE per abilitare o disabilitare RLS, consulta [ALTER TABLE](r_ALTER_TABLE.md).
+ Nelle query tra database, Amazon Redshift blocca le letture nelle relazioni protette da RLS (sicurezza a livello di riga). Gli utenti con l'autorizzazione IGNORE RLS possono accedere alla relazione protetta utilizzando query tra database. Quando un utente senza l'autorizzazione IGNORE RLS accede a una relazione protetta da RLS tramite una query tra database, viene mostrato il seguente errore:
```
RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.
```
+ ALTER RLS POLICY supporta solo la modifica di una policy RLS utilizzando la clausola USING (using\$1predicate\$1exp). Non puoi modificare una policy RLS con una clausola WITH quando si esegue ALTER RLS POLICY.
+ Non è possibile eseguire query sulle relazioni con la sicurezza a livello di riga attivata se i valori di una delle seguenti opzioni di configurazione non corrispondono al valore predefinito della sessione:
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
Prendi in considerazione la possibilità di reimpostare le opzioni di configurazione della sessione se tenti di eseguire query su una relazione con sicurezza a livello di riga e visualizzi il messaggio "RLS protected relation does not support session level config on case sensitivity being different from its default value".
+ Quando il cluster o lo spazio dei nomi serverless di cui è stato effettuato il provisioning ha policy di sicurezza a livello di riga, i seguenti comandi sono bloccati per gli utenti normali:
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Quando crei policy RLS, consigliamo di modificare le impostazioni delle opzioni di configurazione predefinite per gli utenti normali in modo che corrispondano alle impostazioni delle opzioni di configurazione della sessione al momento della creazione della policy. Gli utenti con privilegi avanzati e gli utenti con il privilegio ALTER USER possono eseguire questa operazione utilizzando le impostazioni del gruppo di parametri o il comando ALTER USER. Per informazioni sui gruppi di parametri, consulta [Gruppi di parametri di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) nella *Guida alla gestione di Amazon Redshift*. Per informazioni sul comando ALTER USER, consulta [ALTER USER](r_ALTER_USER.md).
+ Le viste e le viste con associazione tardiva con policy di sicurezza a livello di riga non possono essere sostituite dagli utenti normali con il comando [CREATE VIEW](r_CREATE_VIEW.md). Per sostituire le viste o LBVs con i criteri RLS, scollega innanzitutto i criteri RLS ad essi associati, sostituisci le viste oppure LBVs ricollega i criteri. I superutenti e gli utenti con `sys:secadmin permission` possono utilizzare CREATE VIEW sulle viste o LBVs con le politiche RLS senza scollegare le politiche.
+ Le viste con policy di sicurezza a livello di riga non possono fare riferimento a tabelle di sistema e viste di sistema.
+ Una vista con associazione tardiva a cui fa riferimento una visualizzazione normale non può essere protetta dalla RLS.
+ Non è possibile accedere alle relazioni protette dalla RLS e ai dati annidati dei data lake nella stessa query.
# Best practice per le prestazioni RLS
Di seguito sono riportate le best practice per garantire prestazioni migliori da Amazon Redshift su tabelle protette da RLS.
## Sicurezza degli operatori e delle funzioni
Quando si eseguono query su tabelle protette da RLS, l'utilizzo di determinati operatori o funzioni può portare a un peggioramento delle prestazioni. Amazon Redshift classifica operatori e funzioni come sicuri o non sicuri per l'esecuzione di query su tabelle protette da RLS. Una funzione o un operatore è classificato come sicuro per RLS quando non ha effetti collaterali osservabili a seconda degli input. In particolare, una funzione o un operatore sicuro per RLS non può essere uno dei seguenti:
+ Emette un valore di input, o qualsiasi valore dipendente dal valore di input, con o senza un messaggio di errore.
+ Non riesce o restituisce errori che dipendono dal valore di input.
Gli operatori RLS non sicuri includono:
+ Operatori aritmetici: \$1, -, /, \$1, %.
+ Operatori di testo: LIKE e SIMILAR TO.
+ Operatori cast.
+ UDFs.
Utilizza la seguente istruzione SELECT per verificare la sicurezza degli operatori e delle funzioni.
```
SELECT proname, proc_is_rls_safe(oid) FROM pg_proc;
```
Amazon Redshift impone delle limitazioni sull'ordine di valutazione dei predicati utente contenenti operatori e funzioni non sicuri per RLS durante la pianificazione di query su tabelle protette da RLS. Le query che fanno riferimento a operatori o funzioni non sicure per RLS, durante l'esecuzione di query su tabelle protette da RLS possono causare una riduzione delle prestazioni. Le prestazioni possono peggiorare in modo significativo quando Amazon Redshift non è in grado di inviare predicati non sicuri per RLS nelle scansioni della tabella di base per sfruttare le chiavi di ordinamento. Per ottenere prestazioni migliori, evita le query che utilizzano predicati RLS non sicuri che sfruttano una chiave di ordinamento. Per verificare che Amazon Redshift sia in grado di disattivare operatori e funzioni, è possibile utilizzare le istruzioni EXPLAIN in combinazione con l'autorizzazione di sistema EXPLAIN RLS.
## Caching dei risultati
Per ridurre il tempo di esecuzione delle query e migliorare le prestazioni del sistema, Amazon Redshift memorizza i risultati di certi tipi di query nella memoria sul nodo principale.
Amazon Redshift utilizza i risultati nella cache per una nuova query che esegue la scansione delle tabelle protette da RLS quando si verificano tutte queste condizioni per le tabelle non protette e quando si verificano tutte queste altre condizioni:
+ La tabella o le visualizzazioni nella policy non sono state modificate.
+ La policy non usa una funzione che deve essere valutata a ogni esecuzione, come GETDATE o CURRENT\$1USER.
Per prestazioni migliori, evita di utilizzare predicati di policy che non soddisfano le condizioni di cui sopra.
Per ulteriori informazioni sulla memorizzazione nella cache dei risultati in Amazon Redshift, consulta [Caching dei risultati](c_challenges_achieving_high_performance_queries.md#result-caching).
## Policy complesse
Per prestazioni migliori, evita di utilizzare policy complesse con query secondarie che uniscono più tabelle.
# Esempio di sicurezza a livello di riga end-to-end
Di seguito è riportato un end-to-end esempio per illustrare come un superutente crea alcuni utenti e ruoli. Quindi, un utente con il ruolo secadmin crea, collega, scollega ed elimina le policy RLS. Questo esempio utilizza il database di esempio di tickit. Per ulteriori informazioni, consulta [Caricamento dei dati da Amazon S3 ad Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html)nella *Guida alle operazioni di base di Amazon Redshift*.
```
-- Create users and roles referenced in the policy statements.
CREATE ROLE analyst;
CREATE ROLE consumer;
CREATE ROLE dbadmin;
CREATE ROLE auditor;
CREATE USER bob WITH PASSWORD 'Name_is_bob_1';
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
CREATE USER joe WITH PASSWORD 'Name_is_joe_1';
CREATE USER molly WITH PASSWORD 'Name_is_molly_1';
CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1';
GRANT ROLE sys:secadmin TO bob;
GRANT ROLE analyst TO alice;
GRANT ROLE consumer TO joe;
GRANT ROLE dbadmin TO molly;
GRANT ROLE auditor TO bruce;
GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC;
-- Create table and schema referenced in the policy statements.
CREATE SCHEMA target_schema;
GRANT ALL ON SCHEMA target_schema TO PUBLIC;
CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift);
GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check the tuples visible to analyst alice.
-- Should contain all 3 categories.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE();
ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON;
SELECT * FROM svv_rls_attached_policy;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that tuples with only `Concert` category will be visible to analyst alice.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to consumer joe.
SET SESSION AUTHORIZATION joe;
-- Although the policy is attached to a different role, no tuples will be
-- visible to consumer joe because the default deny all policy is applied.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that tuples with only `Concert` category will be visible to dbadmin molly.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of
-- sensitive information such as RLS filters.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
-- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin.
GRANT IGNORE RLS TO ROLE dbadmin;
-- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output.
GRANT EXPLAIN RLS TO ROLE auditor;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to auditor bruce.
SET SESSION AUTHORIZATION bruce;
-- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that no tuples are visible to analyst alice.
-- Although the policy is detached, no tuples will be visible to analyst alice
-- because of default deny all policy is applied if the table has RLS on.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_events
WITH (eventid INTEGER) AS ev
USING (
ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
RESET SESSION AUTHORIZATION;
-- Can not cannot alter type of dependent column.
ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float;
-- Can not cannot rename dependent column.
ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold;
-- Can not drop dependent column.
ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE;
-- Can not drop lookup table.
DROP TABLE tickit_sales_redshift CASCADE;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DROP RLS POLICY policy_concerts;
DROP RLS POLICY IF EXISTS policy_events;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF;
RESET SESSION AUTHORIZATION;
-- Drop users and roles.
DROP USER bob;
DROP USER alice;
DROP USER joe;
DROP USER molly;
DROP USER bruce;
DROP ROLE analyst;
DROP ROLE consumer;
DROP ROLE auditor FORCE;
DROP ROLE dbadmin FORCE;
```
# Sicurezza dei metadati
Come la sicurezza a livello di riga di Amazon Redshift, la sicurezza dei metadati offre un controllo più granulare sui metadati. Se la sicurezza dei metadati è abilitata per il cluster con provisioning o il gruppo di lavoro serverless, gli utenti possono visualizzare i metadati degli oggetti per i quali dispongono dell'accesso in visualizzazione. La sicurezza dei metadati ti consente di separare la visibilità in base alle proprie esigenze. Ad esempio, puoi utilizzare un singolo data warehouse per centralizzare tutta l'archiviazione di dati. Tuttavia, se archivi dati per più settori, la gestione della sicurezza può diventare problematica. Con la sicurezza dei metadati abilitata, puoi configurare la tua visibilità. Gli utenti di un settore possono avere maggiore visibilità sui propri oggetti, mentre limiti l'accesso in visualizzazione agli utenti di un altro settore. La sicurezza dei metadati supporta tutti i tipi di oggetti, come schemi, tabelle, viste, viste materializzate, stored procedure, funzioni definite dall'utente e modelli di machine learning.
Gli utenti possono visualizzare i metadati degli oggetti nelle seguenti circostanze:
+ Se l'accesso agli oggetti è assegnato all'utente.
+ Se l'accesso agli oggetti è assegnato a un gruppo o a un ruolo dell'utente.
+ L'oggetto è pubblico.
+ L'utente è il proprietario dell'oggetto del database.
Per abilitare la sicurezza dei metadati, utilizza il comando [ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html). Di seguito è riportata la sintassi di come utilizzare il comando ALTER SYSTEM per la sicurezza dei metadati.
```
ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off];
```
Quando abiliti la sicurezza dei metadati, tutti gli utenti che dispongono delle autorizzazioni necessarie possono vedere i metadati pertinenti degli oggetti a cui hanno accesso. Se desideri che solo determinati utenti possano visualizzare i metadati di sicurezza, concedi l'autorizzazione `ACCESS CATALOG` a un ruolo e quindi assegna il ruolo all'utente. Per ulteriori informazioni sull'utilizzo dei ruoli per controllare meglio la sicurezza, consulta [Controllo accessi basato sui ruoli](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html).
L'esempio seguente illustra come concedere l'autorizzazione `ACCESS CATALOG` a un ruolo e quindi assegnare il ruolo a un utente. Per ulteriori informazioni su come concedere le autorizzazioni, consulta il comando [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html).
```
CREATE ROLE sample_metadata_viewer;
GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer;
GRANT ROLE sample_metadata_viewer to salesadmin;
```
Se preferisci utilizzare ruoli già definiti, i [ruoli definiti dal sistema](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) `operator`, `secadmin`, `dba` e `superuser` dispongono tutti delle autorizzazioni necessarie per visualizzare i metadati degli oggetti. Per impostazione predefinita, gli utenti con privilegi avanzati possono visualizzare il catalogo completo.
```
GRANT ROLE operator to sample_user;
```
Se utilizzi i ruoli per controllare la sicurezza dei metadati, hai accesso a tutte le viste e le funzioni di sistema fornite dal controllo degli accessi basato sui ruoli. Ad esempio puoi eseguire query sulla vista [SVV\$1ROLES](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html) per visualizzare tutti i ruoli. Per vedere se un utente è membro di un ruolo o di un gruppo, utilizza la funzione [USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html). Per l'elenco completo delle viste SVV, consulta [Viste SVV dei metadati](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html). Per l'elenco delle funzioni di informazioni di sistema, consulta [Funzioni di informazioni di sistema](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html).
# Mascheramento dinamico dei dati
**Nota**
Amazon Redshift maschera automaticamente alcune colonne della tabella di sistema durante la registrazione di log delle informazioni sulle query effettuate nelle viste del Catalogo dati per prevenire l’esposizione di metadati sensibili. Per ulteriori informazioni, consulta [Registrazione di log sicura](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) nella *Guida alla gestione di Amazon Redshift*.
Il mascheramento dinamico dei dati (DDM) in Amazon Redshift consente di proteggere i dati sensibili di un data warehouse. Puoi manipolare il modo in cui Amazon Redshift mostra i dati sensibili all'utente al momento di eseguire query, senza modificarli nel database. Puoi controllare l'accesso ai dati tramite policy di mascheramento che applicano regole di offuscamento personalizzate a un determinato utente o ruolo. Ciò consente di rispondere alle mutevoli esigenze di privacy senza alterare i dati sottostanti o modificare le query SQL.
Le policy di mascheramento dinamico dei dati nascondono, offuscano o eseguono la pseudonimizzazione dei dati che corrispondono a un determinato formato. Quando è collegata a una tabella, l'espressione di mascheramento viene applicata a una o più colonne. È possibile modificare ulteriormente le policy di mascheramento per applicarle solo a determinati utenti o a ruoli definiti dall'utente che è possibile creare con [Controllo accessi basato sui ruoli (RBAC)](t_Roles.md). Inoltre, è possibile applicare il mascheramento dinamico dei dati a livello di cella utilizzando colonne condizionali durante la creazione della policy di mascheramento. Per ulteriori informazioni sul mascheramento condizionale, consulta [Applicazione condizionale del mascheramento dinamico dei dati](t_ddm-conditional.md).
È possibile applicare più policy di mascheramento con diversi livelli di offuscamento alla stessa colonna di una tabella e assegnarle a ruoli diversi. Per evitare conflitti quando si hanno ruoli diversi con policy distinte che si applicano a una colonna, è possibile impostare le priorità per ciascuna applicazione. In questo modo, è possibile controllare a quali dati può accedere un determinato utente o ruolo. Le policy di mascheramento dinamico dei dati possono oscurare parzialmente o completamente i dati o eseguirne l'hash utilizzando funzioni definite dall'utente scritte in SQL, Python o con AWS Lambda. Il mascheramento di dati mediante hash consente di applicare join a questi dati senza accedere a informazioni potenzialmente sensibili.
# Comandi SQL per la gestione delle politiche di mascheramento dinamico dei dati
Puoi eseguire le seguenti azioni per creare, collegare, scollegare ed eliminare le politiche di mascheramento dinamico dei dati:
+ Per creare una policy DMM utilizza il comando [CREATE MASKING POLICY](r_CREATE_MASKING_POLICY.md).
Di seguito è riportato un esempio di creazione di una policy di mascheramento utilizzando una funzione hash SHA-2.
```
CREATE MASKING POLICY hash_credit
WITH (credit_card varchar(256))
USING (sha2(credit_card + 'testSalt', 256));
```
+ Per modificare una policy DMM utilizza il comando [ALTER MASKING POLICY](r_ALTER_MASKING_POLICY.md).
Di seguito è riportato un esempio di modifica di una politica di mascheramento esistente.
```
ALTER MASKING POLICY hash_credit
USING (sha2(credit_card + 'otherTestSalt', 256));
```
+ Per collegare una policy DMM su una tabella a uno o più utenti o ruoli, utilizza il comando [ATTACH MASKING POLICY](r_ATTACH_MASKING_POLICY.md).
Di seguito è riportato un esempio di associazione di una politica di mascheramento a una coppia. column/role
```
ATTACH MASKING POLICY hash_credit
ON credit_cards (credit_card)
TO ROLE science_role
PRIORITY 30;
```
La clausola PRIORITY determina quale policy di mascheramento si applica a una sessione utente quando più policy sono associate alla stessa colonna. Ad esempio, se l'utente nell'esempio precedente ha un'altra policy di mascheramento collegata alla stessa colonna delle carte di credito con una priorità di 20, la policy di science\$1role è quella che si applica, poiché ha una priorità più alta (30).
+ Per scollegare una policy DMM su una tabella da uno o più utenti o ruoli, utilizza il comando [DETACH MASKING POLICY](r_DETACH_MASKING_POLICY.md).
Di seguito è riportato un esempio di separazione di una politica di mascheramento da una coppia. column/role
```
DETACH MASKING POLICY hash_credit
ON credit_cards(credit_card)
FROM ROLE science_role;
```
+ Per eliminare una policy DDM da tutti i database, utilizza il comando [DROP MASKING POLICY](r_DROP_MASKING_POLICY.md).
Di seguito è riportato un esempio di eliminazione di una policy di mascheramento da tutti i database.
```
DROP MASKING POLICY hash_credit;
```
# Gerarchia delle politiche di mascheramento dinamico dei dati
Quando colleghi più politiche di mascheramento, considera quanto segue:
+ È possibile collegare più policy di mascheramento a una singola colonna.
+ Quando a una query sono applicabili più policy di mascheramento, viene applicata quella con la priorità più alta collegata a ciascuna colonna corrispondente. Analizza l’esempio seguente.
```
ATTACH MASKING POLICY partial_hash
ON credit_cards(address, credit_card)
TO ROLE analytics_role
PRIORITY 20;
ATTACH MASKING POLICY full_hash
ON credit_cards(credit_card, ssn)
TO ROLE auditor_role
PRIORITY 30;
SELECT address, credit_card, ssn
FROM credit_cards;
```
Quando si esegue l'istruzione SELECT, un utente che ha sia il ruolo di analista che quello di revisore vede la colonna degli indirizzi con la policy di mascheramento `partial_hash` applicata. Vede le colonne delle carte di credito e dei numeri di previdenza sociale (SSN) con la politica di mascheramento `full_hash` applicata perché la politica `full_hash` ha la priorità più alta nella colonna delle carte di credito.
+ Se non si specifica una priorità quando si collega una policy di mascheramento, verrà applicata la priorità predefinita (0).
+ Non è possibile collegare due policy alla stessa colonna con la medesima priorità.
+ Non è possibile collegare due politiche alla stessa combinazione di utente e colonna oppure ruolo e colonna.
+ Quando più politiche di mascheramento sono applicabili allo stesso percorso SUPER e sono collegate allo stesso utente o ruolo, ha effetto solo l'associazione con la priorità più alta. Considera i seguenti esempi:
Il primo esempio mostra due politiche di mascheramento collegate sullo stesso percorso e che ha effetto la politica con priorità più alta.
```
ATTACH MASKING POLICY hide_name
ON employees(col_person.name)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 30;
--Only the hide_last_name policy takes effect.
SELECT employees.col_person.name FROM employees;
```
Il secondo esempio mostra due politiche di mascheramento collegate a percorsi diversi nello stesso oggetto SUPER, senza conflitti tra le politiche. Entrambi i collegamenti verranno applicati contemporaneamente.
```
ATTACH MASKING POLICY hide_first_name
ON employees(col_person.name.first)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 20;
--Both col_person.name.first and col_person.name.last are masked.
SELECT employees.col_person.name FROM employees;
```
Per confermare quale politica di mascheramento si applica a un determinato utente e a una determinata combinazione di colonna o ruolo e colonna, gli utenti con il [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)ruolo possono cercare la coppia column/role o colonna/utente nella vista di sistema. [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) Per ulteriori informazioni, consulta [Viste di sistema per il mascheramento dinamico dei dati](r_ddm-svv.md).
# Utilizzo del mascheramento dei dati dinamici con percorsi di tipo di dati SUPER
Amazon Redshift supporta l'associazione di politiche di mascheramento dei dati dinamici a percorsi di colonne di tipo SUPER. Per ulteriori informazioni sui tipi di dati SUPER, consultare [Dati semistrutturati in Amazon Redshift](super-overview.md).
Quando colleghi le politiche di mascheramento ai percorsi di colonne di tipo SUPER, tieni presenti le seguenti considerazioni.
+ Quando colleghi una politica di mascheramento al percorso di una colonna, tale colonna deve essere definita come tipo di dati SUPER. È possibile applicare le politiche di mascheramento solo a valori *scalari* del percorso SUPER. Non è possibile applicare le politiche di mascheramento a strutture o array complessi.
+ Puoi applicare diverse politiche di mascheramento a più valori scalari su una singola colonna SUPER, purché i percorsi SUPER non siano in conflitto. Ad esempio, i percorsi SUPER `a.b` e `a.b.c` sono in conflitto perché si trovano sullo stesso percorso, con `a.b` come padre di `a.b.c`. I percorsi SUPER `a.b.c` e `a.b.d` non sono in conflitto.
+ Amazon Redshift non può verificare che i percorsi associati a una politica di mascheramento esistano nei dati e siano del tipo previsto finché la politica non viene applicata al runtime della query dell'utente. Ad esempio, quando colleghi una politica di mascheramento che maschera i valori TEXT in un percorso SUPER contenente un valore INT, Amazon Redshift tenta di eseguire il casting del tipo di valore del percorso.
In tali situazioni, il comportamento di Amazon Redshift nel runtime dipende dalle impostazioni di configurazione per le query degli oggetti SUPER. Per impostazione predefinita, Amazon Redshift è in modalità permissiva e risolve i percorsi mancanti e i casting non validi come `NULL` per il percorso SUPER specificato. Per ulteriori informazioni sulle impostazioni di configurazione relative a SUPER, consulta [Configurazioni di SUPER](super-configurations.md).
+ SUPER è un tipo senza schema, il che significa che Amazon Redshift non può confermare l'esistenza del valore in un determinato percorso SUPER. Se colleghi una politica di mascheramento a un percorso SUPER che non esiste e Amazon Redshift è in modalità permissiva, Amazon Redshift risolve il percorso in un valore `NULL`. Ti consigliamo di considerare il formato previsto degli oggetti SUPER e la probabilità che abbiano attributi inaspettati quando colleghi le politiche di mascheramento ai percorsi delle colonne SUPER. Se ritieni che ci possa essere uno schema imprevisto nella colonna SUPER, prendi in considerazione la possibilità di collegare le politiche di mascheramento direttamente alla colonna SUPER. È possibile utilizzare le funzioni di informazioni di tipo SUPER per controllare attributi e tipi nonché usare `OBJECT_TRANSFORM` per mascherare i valori. Per ulteriori informazioni sulle funzioni di informazioni di tipo SUPER, consulta [Funzioni di informazioni sul tipo SUPER](c_Type_Info_Functions.md).
## Esempi
**Collegamento delle politiche di mascheramento ai percorsi SUPER**
L'esempio seguente collega più politiche di mascheramento a più percorsi di tipo SUPER in una colonna.
```
CREATE TABLE employees (
col_person SUPER
);
INSERT INTO employees
VALUES
(
json_parse('
{
"name": {
"first": "John",
"last": "Doe"
},
"age": 25,
"ssn": "111-22-3333",
"company": "Company Inc."
}
')
),
(
json_parse('
{
"name": {
"first": "Jane",
"last": "Appleseed"
},
"age": 34,
"ssn": "444-55-7777",
"company": "Organization Org."
}
')
)
;
GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC;
-- Create the masking policies.
-- This policy converts the given name to all uppercase letters.
CREATE MASKING POLICY mask_first_name
WITH(first_name TEXT)
USING ( UPPER(first_name) );
-- This policy replaces the given name with the fixed string 'XXXX'.
CREATE MASKING POLICY mask_last_name
WITH(last_name TEXT)
USING ( 'XXXX'::TEXT );
-- This policy rounds down the given age to the nearest 10.
CREATE MASKING POLICY mask_age
WITH(age INT)
USING ( (FLOOR(age::FLOAT / 10) * 10)::INT );
-- This policy converts the first five digits of the given SSN to 'XXX-XX'.
CREATE MASKING POLICY mask_ssn
WITH(ssn TEXT)
USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) );
-- Attach the masking policies to the employees table.
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.name.first)
TO PUBLIC;
ATTACH MASKING POLICY mask_last_name
ON employees(col_person.name.last)
TO PUBLIC;
ATTACH MASKING POLICY mask_age
ON employees(col_person.age)
TO PUBLIC;
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.ssn)
TO PUBLIC;
-- Verify that your masking policies are attached.
SELECT
policy_name,
TABLE_NAME,
priority,
input_columns,
output_columns
FROM
svv_attached_masking_policy;
policy_name | table_name | priority | input_columns | output_columns
-----------------+------------+----------+-----------------------------------+-----------------------------------
mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""]
mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""]
mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""]
mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""]
(4 rows)
-- Observe the masking policies taking effect.
SELECT col_person FROM employees ORDER BY col_person.age;
-- This result is formatted for ease of reading.
col_person
--------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc."
}
{
"name": {
"first": "JANE",
"last": "XXXX"
},
"age": 30,
"ssn": "XXX-XX-7777",
"company": "Organization Org."
}
```
Di seguito sono riportati alcuni esempi di collegamento di politiche di mascheramento non valide ai percorsi SUPER.
```
-- This attachment fails because there is already a policy
-- with equal priority attached to employees.name.last, which is
-- on the same SUPER path as employees.name.
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.name)
TO PUBLIC;
ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority
-- Create a masking policy that masks DATETIME objects.
CREATE MASKING POLICY mask_date
WITH(INPUT DATETIME)
USING ( INPUT );
-- This attachment fails because SUPER type columns can't contain DATETIME objects.
ATTACH MASKING POLICY mask_date
ON employees(col_person.company)
TO PUBLIC;
ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super
```
Di seguito è riportato un esempio di collegamento di una politica di mascheramento a un percorso SUPER che non esiste. Per impostazione predefinita, Amazon Redshift risolve il percorso come `NULL`.
```
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.not_exists)
TO PUBLIC;
SELECT col_person FROM employees LIMIT 1;
-- This result is formatted for ease of reading.
col_person
-----------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc.",
"not_exists": null
}
```
# Applicazione condizionale del mascheramento dinamico dei dati
È possibile eseguire il mascheramento dei dati a livello di cella creando policy di mascheramento con espressioni condizionali. Ad esempio, è possibile creare una policy di mascheramento che applichi maschere diverse a un valore, a seconda del valore di un'altra colonna in quella riga.
Di seguito è riportato un esempio di utilizzo di mascheramento condizionale dei dati per creare e collegare una policy di mascheramento che oscuri parzialmente i numeri delle carte di credito coinvolte in una frode e nasconda completamente i numeri di tutte le altre carte di credito. Per eseguire questo esempio è necessario essere un utente con privilegi avanzati o avere il ruolo [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html).
```
--Create an analyst role.
CREATE ROLE analyst;
--Create a credit card table. The table contains an is_fraud boolean column,
--which is TRUE if the credit card number in that row was involved in a fraudulent transaction.
CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16));
--Create a function that partially redacts credit card numbers.
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16))
RETURNS VARCHAR(16) IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--Create a masking policy that partially redacts credit card numbers if the is_fraud value for that row is TRUE,
--and otherwise blanks out the credit card number completely.
CREATE MASKING POLICY card_number_conditional_mask
WITH (fraudulent BOOLEAN, pan varchar(16))
USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan)
ELSE Null
END);
--Attach the masking policy to the credit_cards/analyst table/role pair.
ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number)
USING (is_fraud, credit_card_number)
TO ROLE analyst PRIORITY 100;
```
# Viste di sistema per il mascheramento dinamico dei dati
Gli utenti con privilegi avanzati, gli utenti con il ruolo `sys:operator` e gli utenti con l’autorizzazione ACCESS SYSTEM TABLE possono accedere alle seguenti viste di sistema relative a DDM.
+ [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md)
Utilizza SVV\$1MASKING\$1POLICY per visualizzare tutte le politiche di mascheramento create nel cluster o nel gruppo di lavoro.
+ [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md)
Utilizza SVV\$1ATTACHED\$1MASKING\$1POLICY per visualizzare tutte le relazioni e gli utenti o i ruoli che hanno policy collegate per il database attualmente connesso.
+ [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md)
Utilizza SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG per tracciare l’applicazione delle politiche di mascheramento a query che fanno riferimento a relazioni protette da DDM.
Di seguito sono riportati alcuni esempi di informazioni che è possibile trovare utilizzando le viste di sistema.
```
--Select all policies associated with specific users, as opposed to roles
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee_type = 'user';
--Select all policies attached to a specific user
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee = 'target_grantee_name'
--Select all policies attached to a given table
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE table_name = 'target_table_name'
AND schema_name = 'target_schema_name';
--Select the highest priority policy attachment for a given role
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_role_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_role_name')
ORDER BY samp.priority desc
LIMIT 1;
--See which policy a specific user will see on a specific column in a given relation
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_user_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_user_name')
ORDER BY samp.priority desc;
--Select all policies attached to a given relation.
SELECT policy_name,
schema_name,
relation_name,
database_name
FROM sys_applied_masking_policy_log
WHERE relation_name = 'relation_name'
AND schema_name = 'schema_name';
```
# Considerazioni relative all'utilizzo del mascheramento dinamico dei dati
Quando utilizzi il mascheramento dinamico dei dati prendi in considerazione quanto segue:
+ Quando eseguono query sugli oggetti creati da tabelle, come le viste, gli utenti vedranno i risultati in base alle proprie policy di mascheramento, non alle policy dell'utente che ha creato gli oggetti. Ad esempio, un utente con il ruolo di analista che esegue query su una vista creata da un secadmin vedrebbe i risultati con le policy di mascheramento collegate al ruolo di analista.
+ Per evitare che il comando EXPLAIN possa esporre filtri delle policy di mascheramento sensibili, solo gli utenti con l'autorizzazione SYS\$1EXPLAIN\$1DDM possono vedere le policy di mascheramento applicate negli output EXPLAIN. Gli utenti non dispongono per impostazione predefinita dell'autorizzazione SYS\$1EXPLAIN\$1DDM.
Di seguito è riportata la sintassi per concedere l’autorizzazione a un ruolo.
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
Per ulteriori informazioni sul comando EXPLAIN, consulta [EXPLAIN](r_EXPLAIN.md).
+ Gli utenti con ruoli diversi possono visualizzare risultati distinti in base alle condizioni di filtro o di join utilizzate. Ad esempio, l'esecuzione di un comando SELECT su una tabella utilizzando un valore di colonna specifico avrà esito negativo se all'utente che esegue il comando viene applicata una policy di mascheramento che offusca quella colonna.
+ Le policy di mascheramento dinamico dei dati devono essere applicate prima di qualsiasi operazione o proiezione prevedibile. Le politiche di mascheramento possono includere:
+ Operazioni costanti a basso costo, come la conversione di un valore in null
+ Operazioni a costo moderato, come l'hashing HMAC
+ Operazioni ad alto costo, come le chiamate a funzioni Lambda esterne definite dall'utente
È consigliabile pertanto utilizzare espressioni di mascheramento semplici, quando possibile.
+ È possibile utilizzare le policy di mascheramento dinamico dei dati (DMM) per i ruoli con policy di sicurezza a livello di riga, ma è importante notare che le policy RLS vengono applicate prima di quelle DDM. Un'espressione di mascheramento dei dati dinamici non sarà in grado di leggere una riga protetta dalla RLS. Per ulteriori informazioni sulla RLS, consulta [Sicurezza a livello di riga](t_rls.md).
+ Quando utilizzi il comando [COPY](r_COPY.md) per copiare da parquet a tabelle di destinazione protette, è necessario specificare esplicitamente le colonne nell'istruzione COPY. Per ulteriori informazioni sulla mappatura delle colonne con COPY, consulta [Opzioni di mappatura di colonne](copy-parameters-column-mapping.md).
+ Le policy DDM non possono essere collegate alle seguenti relazioni:
+ Tabelle e cataloghi di sistema
+ Tabelle esterna
+ Tabelle dell'unità di condivisione dati
+ Relazioni tra DB
+ Tabelle temporanee
+ Query correlate
+ Le policy DDM possono contenere tabelle di ricerca. Le tabelle di ricerca possono essere presenti nella clausola USING. I seguenti tipi di relazione non possono essere utilizzati come tabelle di ricerca:
+ Tabelle e cataloghi di sistema
+ Tabelle esterna
+ Tabelle dell'unità di condivisione dati
+ Viste, viste materializzate e viste con associazione tardiva
+ Relazioni tra DB
+ Tabelle temporanee
+ Query correlate
Di seguito è riportato un esempio di collegamento di una politica di mascheramento a una tabella di ricerca.
```
--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
CASE
WHEN
credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)
THEN '000000XXXX0000'
ELSE REDACT_CREDIT_CARD(credit_card)
END
);
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
```
+ Non è possibile collegare una policy di mascheramento che produrrebbe un output incompatibile con il tipo e la dimensione della colonna di destinazione. Ad esempio, non è possibile collegare a una colonna VARCHAR(10) una policy di mascheramento che restituisce una stringa lunga 12 caratteri. Amazon Redshift supporta le seguenti eccezioni:
+ Una politica di mascheramento con il tipo di input INTN può essere associata a una politica con dimensione INTM purché M < N. Ad esempio, una politica di input BIGINT (INT8) può essere associata a una colonna smallint (). INT4
+ Una politica di mascheramento con tipo di input NUMERIC o DECIMAL può sempre essere collegata a una colonna FLOAT.
+ Non puoi utilizzare le politiche DDM con la condivisione dei dati. Se il producer di dati dell'unità di condivisione dati collega una policy DDM a una tabella nell'unità di condivisione dati, la tabella diventa inaccessibile agli utenti del consumer di dati che stanno cercando di eseguire query sulla tabella. Il tentativo di aggiungere la relazione a un’unità di condivisione dati non riesce nel cluster o nel namespace lato producer con il seguente errore:
```
or a relation dependent on it is protected by a masking policy and cannot be added to a datashare
```
Se colleghi una politica di mascheramento a una relazione lato producer e la relazione è già inclusa in un’unità di condivisione dati, il tentativo di eseguire query sulla relazione lato consumer non riesce e genera l’errore seguente:
```
cross-cluster query of the masked relation is not supported.
```
Puoi disattivare DDM per le unità di condivisione dati utilizzando il comando ALTER TABLE con il parametro MASKING OFF FOR DATASHARES. Per ulteriori informazioni, consulta [ALTER TABLE](r_ALTER_TABLE.md).
+ Non è possibile eseguire query sulle relazioni che hanno policy DDM collegate se i valori di una delle seguenti opzioni di configurazione non corrispondono al valore predefinito della sessione:
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
Prendi in considerazione la possibilità di reimpostare le opzioni di configurazione della sessione se tenti di eseguire query su una relazione con una policy DDM collegata e se visualizzi il messaggio "DDM protected relation does not support session level config on case sensitivity being different from its default value".
+ Quando il cluster o lo spazio dei nomi serverless di cui è stato effettuato il provisioning ha una politica di mascheramento dei dati dinamici, i seguenti comandi sono bloccati per gli utenti normali:
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Quando crei policy DDM, ti consigliamo di modificare le impostazioni delle opzioni di configurazione predefinite per gli utenti normali in modo che corrispondano alle impostazioni delle opzioni di configurazione della sessione al momento della creazione della policy. Gli utenti con privilegi avanzati e gli utenti con il privilegio ALTER USER possono eseguire questa operazione utilizzando le impostazioni del gruppo di parametri o il comando ALTER USER. Per informazioni sui gruppi di parametri, consulta [Gruppi di parametri di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) nella *Guida alla gestione di Amazon Redshift*. Per informazioni sul comando ALTER USER, consulta [ALTER USER](r_ALTER_USER.md).
+ Le viste e le viste con associazione tardiva con policy DDM collegate non possono essere sostituite dagli utenti normali con il comando [CREATE VIEW](r_CREATE_VIEW.md). Per sostituire le viste o LBVs con le politiche DDM, scollegate prima le politiche DDM ad esse associate, sostituite le viste o e ricollegate le politiche. LBVs I superutenti e gli utenti con l'`sys:secadmin`autorizzazione possono utilizzare CREATE VIEW sulle viste o LBVs con le politiche DDM senza scollegare le politiche.
+ Le viste con policy DDM collegate non possono fare riferimento a tabelle e viste di sistema. Le viste con associazione tardiva possono fare riferimento alle tabelle e alle viste di sistema.
+ Le viste con associazione tardiva con policy DDM collegate non possono fare riferimento a dati annidati dei data lake, come i documenti JSON.
+ Le viste con associazione tardiva non possono avere policy DDM collegate se una vista fa riferimento alla vista con associazione tardiva.
+ Le policy DDM vengono collegate alle viste con associazione tardiva in base al nome di colonna. Al momento della query, Amazon Redshift verifica che tutte le politiche di mascheramento collegate alla vista con associazione tardiva siano state applicate correttamente e che il tipo di colonna di output della vista con associazione tardiva corrisponda ai tipi presenti nelle politiche di mascheramento collegate. Se la convalida non riesce, Amazon Redshift restituisce un errore per la query.
+ Puoi utilizzare le variabili di contesto della sessione personalizzate durante la creazione di politiche DDM. Nell’esempio seguente vengono impostate le variabili di contesto della sessione per una politica DDM.
```
-- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);
-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));
-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask
ON tickit_users_redshift(city)
TO ROLE analyst, ROLE dbadmin;
```
Per informazioni dettagliate su come impostare e recuperare variabili di contesto della sessione personalizzate, consulta [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [MOSTRA](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) e [RESET](r_RESET.md). Per ulteriori informazioni sulla modifica della configurazione del server in generale, consulta [Modifica della configurazione del server](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Importante**
Quando utilizzi le variabili di contesto della sessione all’interno delle politiche DDM, la policy di sicurezza dipende dall’utente o dal ruolo che la invoca. Presta attenzione a evitare le vulnerabilità di sicurezza quando utilizzi le variabili di contesto della sessione nelle politiche DDM.
# Esempio di mascheramento dinamico dei dati end-to-end
Di seguito è riportato un end-to-end esempio che mostra come creare e associare criteri di mascheramento a una colonna. Queste policy consentono agli utenti di accedere a una colonna e visualizzare valori diversi, a seconda del grado di offuscamento delle policy collegate ai loro ruoli. Per eseguire questo esempio è necessario essere un utente con privilegi avanzati o avere il ruolo [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html).
## Creazione di una policy di mascheramento
Per prima cosa, crea una tabella e inserisci i valori delle carte di credito.
```
--create the table
CREATE TABLE credit_cards (
customer_id INT,
credit_card TEXT
);
--populate the table with sample values
INSERT INTO credit_cards
VALUES
(100, '4532993817514842'),
(100, '4716002041425888'),
(102, '5243112427642649'),
(102, '6011720771834675'),
(102, '6011378662059710'),
(103, '373611968625635')
;
--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;
--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';
CREATE USER analytics_user WITH PASSWORD '1234Test!';
--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;
GRANT ROLE analytics_role TO analytics_user;
```
Quindi, crea una policy di mascheramento da applicare al ruolo di analista.
```
--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);
--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));
--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;
SELECT * FROM svv_attached_masking_policy;
```
## Collegamento di una policy di mascheramento
Collega le policy di mascheramento alla tabella delle carte di credito.
```
--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;
--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;
--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;
--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;
SELECT * FROM credit_cards;
--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;
SELECT * FROM credit_cards;
```
## Creazione di una politica di mascheramento
La sezione seguente mostra come modificare una politica di mascheramento dinamico dei dati.
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;
```
## Scollegamento ed eliminazione di una policy di mascheramento
La sezione seguente mostra come scollegare ed eliminare le policy di mascheramento dei dati mediante la rimozione di tutte le policy di mascheramento dinamico dei dati dalla tabella.
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
FROM PUBLIC;
DETACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
FROM ROLE analytics_role;
--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;
DROP MASKING POLICY mask_credit_card_partial;
```
# Autorizzazioni con ambito
Le autorizzazioni con ambito consentono di concedere autorizzazioni a un utente o a un ruolo per tutti gli oggetti di un tipo all’interno di un database o uno schema. Gli utenti e i ruoli con autorizzazioni con ambito dispongono delle autorizzazioni specificate per tutti gli oggetti correnti e futuri all’interno del database o dello schema.
Puoi visualizzare l’ambito delle autorizzazioni con ambito a livello di database in [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Puoi visualizzare l’ambito delle autorizzazioni con ambito a livello di schema in [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md).
Per ulteriori informazioni sull'applicazione delle autorizzazioni con ambito, consulta [GRANT](r_GRANT.md) e [REVOKE](r_REVOKE.md).
# Considerazioni sull'utilizzo delle autorizzazioni con ambito
Quando usi le autorizzazioni con ambito, tieni in considerazione quanto segue:
+ Puoi utilizzare le autorizzazioni con ambito per concedere o revocare le autorizzazioni di un ambito di database o schema a un utente o un ruolo specificato.
+ Non puoi concedere autorizzazioni con ambito ai gruppi di utenti.
+ L'assegnazione o la revoca delle autorizzazioni con ambito modifica le autorizzazioni per tutti gli oggetti attuali e futuri dell'ambito.
+ Le autorizzazioni con ambito e le autorizzazioni a livello di oggetto funzionano indipendentemente le une dalle altre. Ad esempio, un utente manterrà le autorizzazioni per una tabella in entrambi i casi seguenti.
+ All’utente vengono concesse l’autorizzazione SELECT per la tabella schema1.table1 e l’autorizzazione SELECT con ambito per schema1. All’utente viene quindi revocata l’autorizzazione SELECT per tutte le tabelle dello schema schema1. L’utente mantiene SELECT su schema1.table1.
+ All’utente vengono concesse l’autorizzazione SELECT per la tabella schema1.table1 e l’autorizzazione SELECT con ambito per schema1. All’utente viene quindi revocata l’autorizzazione SELECT per schema1.table1. L’utente mantiene SELECT su schema1.table1.
+ Per assegnare o revocare le autorizzazioni con ambito è necessario soddisfare uno dei seguenti criteri:
+ Utenti con privilegi avanzati.
+ Utenti con l'opzione di assegnazione per l'autorizzazione. Per ulteriori informazioni sulle opzioni di assegnazione, consulta il parametro WITH GRANT OPTION in [GRANT](r_GRANT.md).
+ Le autorizzazioni con ambito possono essere assegnate o revocate solo agli oggetti del database connesso o ai database importati da un'unità di condivisione dati.
+ Puoi utilizzare le autorizzazioni con ambito per impostare le autorizzazioni predefinite per un database condiviso creato da un’unità di condivisione dati. Un utente dell'unità di condivisione dati sul lato consumer a cui sono concesse le autorizzazioni con ambito su un database condiviso ottiene automaticamente le autorizzazioni per qualsiasi nuovo oggetto aggiunto all'unità di condivisione dati sul lato producer.
+ I produttori possono concedere autorizzazioni con ambito per gli oggetti all’interno di uno schema a un’unità di condivisione dati. (anteprima)