Gestione degli accessi al tuo account Snowflake

Introduzione

Quando si inizia a lavorare con Snowflake è imprescindibile capire come configurare gli accessi basato sui ruoli, che limitano l’accesso agli Oggetti presenti in Snowflake.

Punti importanti da capire: 

  • Utilizzo del ruolo ACCOUNTADMIN
  • Controllare l’assegnazione del ruolo ACCOUNTADMIN agli utenti 
  • Evitare di usare il ruolo ACCOUNTADMIN per creare oggetti 
  • Evitare di utilizzare il ruolo ACCOUNTADMIN per gli script automatici
  • Accesso agli oggetti del database
  • Gestione dei ruoli personalizzati
  • Allineamento dell’accesso agli oggetti con le funzioni aziendali
  • Esempio
  • Centralizzazione della gestione delle sovvenzioni utilizzando gli schemi di accesso gestito 
  • Semplificare la gestione delle sovvenzioni utilizzando le sovvenzioni future 
  • Visualizzazione dei risultati della Query
  • Comprensione degli oggetti clonati e dei privilegi concessi

I diversi ruoli hanno accessi specifici (es. al Notification Centre) e vedono strumenti personalizzati.


Utilizzo del ruolo ACCOUNTADMIN

Il ruolo ACCOUNTADMIN è il ruolo più potente nel sistema. Ed è da solo il responsabile della configurazione dei parametri a livello di account.  

Gli utenti con questo ruolo possono visualizzare e operare su tutti gli oggetti nell’account, possono visualizzare e gestire i dati di fatturazione e credito di Snowflake e possono interrompere qualsiasi istruzione SQL in esecuzione. 

Nella gerarchia di controllo degli accessi predefinita, gli altri ruoli figli di questo ruolo: 

NB: Subito dopo la creazione dell’account, al primo utente viene assegnato il ruolo ACCOUNTADMIN. Questo utente deve quindi creare uno o più utenti aggiuntivi a cui viene assegnato il ruolo USERADMIN. Tutti gli utenti rimanenti devono essere creati dagli utenti con il ruolo USERADMIN.

Assegnazione del ruolo ACCOUNTADMIN agli utenti 

Il ruolo deve essere assegnato ad un numero selezionato/limitato di persone facente parte dei progetti.  

È meglio assegnare questo ruolo ad almeno due utenti in caso di password dimenticata o smarrita si riesce ad evitare di dover aspettare i tempi necessari per la reimpostazione perché gli utenti possono reimpostare le password degli altri. 

Dal punto di vista della sicurezza, è fortemente consigliato che tutti gli utenti con questo ruolo facciano uso dell’autenticazione a più fattori (MFA). Per i dettagli, vedere Configurazione del controllo di accesso).

È utile associare l’indirizzo e-mail di una persona reale agli utenti ACCOUNTADMIN, in modo che l’Assistenza Snowflake sappia chi contattare in una situazione urgente. 

Evita di usare il ruolo ACCOUNTADMIN per creare oggetti

Il ruolo ACCOUNTADMIN è destinato all’esecuzione di attività di configurazione iniziale nel sistema e alla gestione di oggetti e attività a livello di account su base quotidiana. In quanto tale, non dovrebbe essere utilizzato per creare oggetti nel tuo account, a meno che tu non abbia assolutamente bisogno di questi oggetti per avere il più alto livello di accesso sicuro.

Se si creano oggetti con il ruolo ACCOUNTADMIN e si desidera che gli utenti abbiano accesso a questi oggetti, è necessario concedere in modo esplicito i privilegi sugli oggetti ai ruoli per questi utenti.

Si consiglia invece di creare una gerarchia di ruoli allineata con le funzioni aziendali nella propria organizzazione e infine di assegnare questi ruoli al ruolo SYSADMIN. Per ulteriori informazioni, vedere Allineamento dell’accesso agli oggetti con le funzioni aziendali in questo argomento.

Suggerimento

Per evitare che gli amministratori dell’account utilizzino inavvertitamente il ruolo ACCOUNTADMIN per creare oggetti, assegnare a questi utenti ruoli aggiuntivi e designare uno di questi ruoli come predefinito (ovvero non impostare ACCOUNTADMIN come ruolo predefinito per nessun utente nel sistema).

Ciò non impedisce loro di utilizzare il ruolo ACCOUNTADMIN per creare oggetti, ma li costringe a cambiare esplicitamente il proprio ruolo in ACCOUNTADMIN ogni volta che effettuano l’accesso. Questo può aiutarli a renderli consapevoli dello scopo/funzione dei ruoli nel sistema e incoraggiare loro di passare al ruolo appropriato per l’esecuzione di una determinata attività, in particolare quando devono eseguire attività di amministratore dell’account.

Quando evitare di utilizzare il ruolo ACCOUNTADMIN

Si consiglia di utilizzare un ruolo diverso da ACCOUNTADMIN per gli script automatici. 

Se, come consigliato, si crea una gerarchia di ruoli nel ruolo SYSADMIN, tutte le operazioni di magazzino e oggetti di database possono essere eseguite utilizzando il ruolo SYSADMIN o ruoli inferiori nella gerarchia. Le uniche limitazioni che incontreresti sono la creazione o la modifica di utenti o ruoli. Queste operazioni devono essere eseguite da un utente con il ruolo SECURITYADMIN o un altro ruolo con privilegi di oggetto sufficienti.

Accesso agli oggetti del database

Tutti gli oggetti di database protetti (come TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE, ecc.) sono contenuti all’interno di un oggetto SCHEMA all’interno di un DATABASE. Di conseguenza, per accedere agli oggetti di database, oltre ai privilegi sugli oggetti di database specifici, è necessario concedere agli utenti il privilegio USAGE sul database del contenitore e sullo schema. 

 Ad esempio, supponiamo che mytable venga creato in mydb.myschema. Per interrogare mytable, un utente deve avere almeno i seguenti privilegi: 

Database 

USAGE on mydb  

Schema 

USAGE on myschema  

Table 

SELECT on mytable
Gestione dei ruoli personalizzati

Quando un ruolo personalizzato viene creato per la prima volta, esiste in isolamento. Il ruolo deve essere assegnato a tutti gli utenti che utilizzeranno i privilegi dell’oggetto associati al ruolo. Il ruolo personalizzato deve essere concesso anche a tutti i ruoli che gestiranno gli oggetti creati dal ruolo personalizzato. 

Per impostazione predefinita, nemmeno il ruolo ACCOUNTADMIN può modificare o eliminare oggetti creati da un ruolo personalizzato. Il ruolo personalizzato deve essere concesso direttamente al ruolo ACCOUNTADMIN o, preferibilmente, a un altro ruolo in una gerarchia con il ruolo SYSADMIN come padre. Il ruolo SYSADMIN è gestito dal ruolo ACCOUNTADMIN.

Allineamento dell’accesso agli oggetti con le funzioni aziendali

Prendi in considerazione l’opportunità di sfruttare le gerarchie dei ruoli per allineare l’accesso agli oggetti del database con le funzioni aziendali della tua organizzazione. In una gerarchia di ruoli, i ruoli vengono concessi ad altri ruoli per formare una relazione di ereditarietà. Le autorizzazioni concesse ai ruoli di livello inferiore vengono ereditate dai ruoli di livello superiore. 

Per una flessibilità ottimale nel controllo dell’accesso agli oggetti del database, creare una combinazione di ruoli di accesso agli oggetti con autorizzazioni diverse sugli oggetti e assegnarli in modo appropriato ai ruoli funzionali.

NB: Non esiste alcuna differenza tecnica tra un ruolo di accesso agli oggetti e un ruolo funzionale in Snowflake. La differenza sta nel modo in cui vengono utilizzati logicamente per assemblare e assegnare set di autorizzazioni a gruppi di utenti.

Esempio 

Come semplice esempio, supponiamo che due database in un account, fin e hr, contengano rispettivamente i dati sui salari e sui dipendenti. I contabili e gli analisti dell’organizzazione richiedono autorizzazioni diverse sugli oggetti in questi database per svolgere le proprie funzioni aziendali. Gli account dovrebbero avere accesso in lettura-scrittura a fin ma potrebbero richiedere solo l’accesso in sola lettura a hr perché il personale delle risorse umane mantiene i dati in questo database. Gli analisti potrebbero richiedere l’accesso in sola lettura a entrambi i database. 

Le autorizzazioni sugli oggetti di database esistenti vengono concesse tramite la seguente gerarchia di ruoli di accesso e ruoli funzionali: 

Nota 

Quando vengono aggiunti nuovi oggetti in ogni database, valutare la possibilità di concedere automaticamente i privilegi sugli oggetti ai ruoli in base al tipo di oggetto (ad es. schemi, tabelle o viste). 

Per configurare il controllo degli accessi per questo esempio: 

In qualità di amministratore utente (utente con ruolo USERADMIN) o un altro ruolo con privilegio CREATE ROLE sull’account, creare i ruoli di accesso e i ruoli funzionali in questo esempio: 

create role db_hr_r;
create role db_fin_r;
create role db_fin_rw;
create role accountant;
create role analyst;

In qualità di amministratore della sicurezza (utente con ruolo SECURITYADMIN) o un altro ruolo con privilegio MANAGE GRANTS sull’account, concedi le autorizzazioni minime richieste a ciascuno dei ruoli di accesso: 

-- Grant read-only permissions on database HR to db_hr_r role.
grant usage on database hr to role db_hr_r;
grant usage on all schemas in database hr to role db_hr_r;
grant select on all tables in database hr to role db_hr_r;
-- Grant read-only permissions on database FIN to db_fin_r role.
grant usage on database fin to role db_fin_r;
grant usage on all schemas in database fin to role db_fin_r;
grant select on all tables in database fin to role db_fin_r;
-- Grant read-write permissions on database FIN to db_fin_rw role.
grant usage on database fin to role db_fin_rw;
grant usage on all schemas in database fin to role db_fin_rw;
grant select,insert,update,delete on all tables in database fin to role db_fin_rw;

In qualità di amministratore della sicurezza (utente con ruolo SECURITYADMIN) o un altro ruolo con il privilegio MANAGE GRANTS sull’account, concedi il ruolo di accesso db_fin_rw al ruolo funzionale contabile e concedi i ruoli di accesso db_hr_r db_fin_r al ruolo funzionale analista:

grant role db_fin_rw to role accountant;
grant role db_hr_r to role analyst;
grant role db_fin_r to role analyst;

In qualità di amministratore della sicurezza (utente con il ruolo SECURITYADMIN) o un altro ruolo con il privilegio GESTIRE GRANTS sull’account, concedi entrambi i ruoli di analista e contabile al ruolo di amministratore di sistema (SYSADMIN):

grant role accountant,analyst to role sysadmin;
Centralizzazione della gestione delle sovvenzioni utilizzando gli schemi di accesso gestito

Con schemi regolari (cioè non gestiti) in un database, i proprietari degli oggetti (cioè i ruoli con il privilegio OWNERSHIP su uno o più oggetti) possono concedere l’accesso su quegli oggetti ad altri ruoli, con l’opzione di concedere ulteriormente a quei ruoli la capacità di gestire concessioni di oggetti.

Per bloccare ulteriormente la sicurezza degli oggetti, prendere in considerazione l’utilizzo di schemi di accesso gestito. In uno schema di accesso gestito, i proprietari degli oggetti perdono la capacità di prendere decisioni di concessione. Solo il proprietario dello schema (ovvero il ruolo con il privilegio OWNERSHIP sullo schema) o un ruolo con il privilegio MANAGE GRANTS può concedere privilegi sugli oggetti nello schema, comprese le concessioni future, centralizzando la gestione dei privilegi.

Semplificare la gestione delle sovvenzioni utilizzando le sovvenzioni future

Le concessioni future consentono di definire un insieme iniziale di privilegi su oggetti di un certo tipo (ad esempio tabelle o viste) in uno schema specificato. Quando vengono creati nuovi oggetti, i privilegi definiti vengono concessi automaticamente a un ruolo, semplificando la gestione delle concessioni.

Considera lo scenario seguente, in cui a un ruolo particolare viene concesso il privilegio SELECT su tutte le nuove tabelle create nello schema. In un secondo momento, si decide di revocare il privilegio da questo ruolo e di assegnarlo invece a un ruolo diverso. Utilizzando le parole chiave ON FUTURE per le nuove tabelle e la parola chiave ALL per le tabelle esistenti, sono necessarie poche istruzioni SQL per concedere e revocare i privilegi su tabelle nuove ed esistenti.

Esempio

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1
grant select on future tables in schema s1 to role r1;
-- / Create tables in the schema /
-- Grant the SELECT privilege on all new tables in a schema to role R2
grant select on future tables in schema s1 to role r2;
-- Grant the SELECT privilege on all existing tables in a schema to role R2
grant select on all tables in schema s1 to role r2;
-- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1
revoke select on future tables in schema s1 from role r1;
-- Revoke the SELECT privilege on all existing tables in a schema from role R1
revoke select on all tables in schema s1 from role r1;
Visualizzazione dei risultati della query

Un utente non può visualizzare il set di risultati di una query eseguita da un altro utente. Questo comportamento è intenzionale. Per motivi di sicurezza, solo l’utente che ha eseguito una query può accedere ai risultati della query.  

NB: Questo comportamento non è connesso al modello di controllo dell’accesso Snowflake per gli oggetti. Anche un utente con il ruolo ACCOUNTADMIN non può visualizzare i risultati di una query eseguita da un altro utente.

Comprensione degli oggetti clonati e dei privilegi concessi

La clonazione di un database, di uno schema o di una tabella crea una copia dell’oggetto di origine. L’oggetto clonato include un’istantanea dei dati presenti nell’oggetto di origine quando è stato creato il clone. 

Un oggetto clonato è considerato un nuovo oggetto in Snowflake. Eventuali privilegi concessi sull’oggetto di origine non vengono trasferiti all’oggetto clonato. Tuttavia, un oggetto contenitore clonato (un database o uno schema) conserva tutti i privilegi concessi sugli oggetti contenuti nell’oggetto di origine. Ad esempio, uno schema clonato conserva tutti i privilegi concessi su tabelle, viste, UDF e altri oggetti nello schema di origine. 

articoli correlati

Nuove funzionalità PowerBI (Dec 2023)

In questo articolo vedremo alcune nuove impostazioni di formattazione per i nostri grafici a colonne e a barre, nonché per le etichette dei dati. Credo

New Button Slicer in Power BI

La nuova funzionalità aggiunta in Power BI rende il pannello dei filtri molto più dinamico e personalizzabile. Con il nuovo oggetto grafico si ha infatti

Selezioni Data Academy 2024

La prossima Data Academy by The Information Lab Italia inizierà a Febbraio 2024! Le selezioni stanno per iniziare!