Snowflake Roles 101: la guida completa al controllo degli accessi

Snowflake adotta un approccio Role-Based Access Control (RBAC) per gestire ciò che utenti e altri sistemi possono fare e a cosa possono accedere. Nel modello RBAC, avere un determinato ruolo significa ricevere determinati privilegi.

Introduciamo qualche termine:

• User: un'entità che permette a una persona (o a un servizio) di connettersi a Snowflake.
• Object: un'entità a cui un User può accedere (ad esempio tabella, view, database), se dispone dei privilegi necessari.
• Privilege: un'operazione che un User può eseguire su un Object, se il suo Role l'ha ricevuta.
• Role: un'entità che fa da ponte tra User e Privilege. I Privilege vengono assegnati ai Role, e i Role vengono assegnati agli User.

In sintesi, come riassume la stessa Snowflake:

I privilegi vengono concessi ai ruoli, e i ruoli vengono concessi agli utenti, per specificare le operazioni che gli utenti possono eseguire sugli oggetti del sistema.

Partendo da questi 4 concetti chiave, le sezioni e i diagrammi che seguono si svilupperanno l'uno sull'altro, fino ad arrivare a una configurazione di controllo accessi minimale ma completa.

User

Uno User in Snowflake è un'identità che può connettersi a uno Snowflake Account ed eseguire un insieme di operazioni consentite. Ogni persona del Suo team dati dovrebbe avere uno Snowflake User per connettersi a Snowflake ed eseguire query. Uno Snowflake User può essere usato anche da un sistema di terze parti: ne sono esempi gli strumenti di BI (come Tableau o Looker) o gli strumenti ELT (come Stitch o Fivetran).

In definitiva, ciò che gli Snowflake User possono fare è il fulcro del controllo degli accessi.

Object

Gli Object sono le primitive di Snowflake su cui è possibile concedere l'accesso. Gli Object più immediati sono database, schema e tabelle, ma rientrano in questa categoria anche oggetti a livello di account come warehouse, storage integration e così via.

Ecco alcuni esempi comuni di Snowflake Object:

Securable Object	Livello	Descrizione
Database	Account-level	I database sono gli oggetti chiave che tengono isolati e raggruppati logicamente tutti gli altri securable object.
Schema	Database-level	Un raggruppamento logico di oggetti come tabelle, view, stage e così via.
Table	Schema-level	L'oggetto che contiene i dati e occupa storage fisico. Nella maggior parte dei casi, le tabelle sono il fulcro che rende Snowflake davvero utile. Esistono diversi tipi di tabella, ciascuno per casi d'uso specifici.
View	Schema-level	Una tabella "travestita". Fornisce accesso ai dati senza occupare storage. Una view è definita come una query costruita sopra altre tabelle. Esistono diversi tipi di view, ciascuno per casi d'uso specifici.
Virtual Warehouse	Account-level	Le principali risorse di compute necessarie per eseguire query o per caricare dati in Snowflake.
Storage Integration	Account-level	Un oggetto che collega un bucket S3 (e analogamente GCS e Azure Blob storage) a Snowflake, consentendo agli User di caricare o scaricare dati da Snowflake o di interrogare direttamente i contenuti del bucket.
Snowpipe	Schema-level	Un oggetto che automatizza il caricamento dei dati da S3 (o GCS e Azure Blob storage) nelle tabelle non appena nuovi file arrivano nel bucket.
Stage	Schema-level	Posizione dei file di dati (CSV, Parquet ecc.) nel cloud storage. Esistono due tipi di stage: interno (cloud storage gestito da Snowflake) ed esterno (cloud storage autogestito).

Privilege

I Privilege sono un concetto essenziale del controllo accessi. Permettono di eseguire una singola operazione, o talvolta un insieme di operazioni, su un oggetto.

Ad esempio, su una Snowflake Table un User potrebbe avere il privilege di eseguire SELECT sui dati, INSERT di righe, DELETE di dati e così via. Su uno Snowflake Database un User potrebbe poter eseguire CREATE SCHEMA oppure MONITOR.

La tabella seguente descrive in breve alcuni dei principali privilege che possono essere concessi sui principali oggetti.

Object	Object Privilege	Descrizione
Database	USAGE	Consente di usare e visualizzare il database, ma servono privilegi aggiuntivi per eseguire qualunque azione su di esso.
	MONITOR	Consente di eseguire il comando DESCRIBE.
	CREATE SCHEMA	Consente di creare (o clonare) uno schema nel database.
	IMPORTED PRIVILEGES	Si applica solo ai database condivisi e consente ad altri account role di accedere agli oggetti condivisi. Per approfondire gli imported privileges: https://docs.snowflake.com/en/user-guide/data-share-consumers#option-1-objects-in-a-share-not-associated-with-a-database-role.
Schema	USAGE	Consente di vedere e usare lo schema, ma servono comunque privilegi aggiuntivi sugli oggetti a livello di schema per visualizzarli o eseguire comandi su di essi.
	MONITOR	Consente di eseguire il comando DESCRIBE.
	CREATE TABLE / CREATE VIEW / CREATE STAGE / CREATE PIPE	/ CREATE STAGE / CREATE PIPE Consente di creare una table / view / stage / pipe nello schema.
Table	SELECT	Consente di interrogare la tabella per recuperare i dati.
	INSERT	Consente di inserire righe nella tabella.
	UPDATE	Consente di aggiornare i dati esistenti nella tabella.
	TRUNCATE	Consente di eliminare tutti i dati dalla tabella.
	DELETE	Consente di eliminare tutte le righe o un sottoinsieme specifico di righe dalla tabella.
View	SELECT	Consente di interrogare la view per recuperare i dati (indipendentemente dalle tabelle sottostanti e dai privilegi concessi su di esse).
Stage	USAGE	Consente di usare lo stage esterno in uno statement SQL.
	READ	Consente di eseguire qualsiasi comando che legge lo stage interno (GET, LIST, COPY INTO).
	WRITE	Consente di eseguire qualsiasi comando che scrive sullo stage interno (PUT, REMOVE, COPY INTO).

Trova l'elenco completo degli object privilege disponibili per il controllo accessi di Snowflake qui.

Con questo elenco in mente, quando dovrà fare audit degli accessi Le tornerà utile ricordare che i privilegi vengono concessi a livelli diversi a seconda di dove viene creato un oggetto (ovvero account-level, database-level, schema-level).

Il privilegio di Ownership

Snowflake adotta un approccio Role-Based Access Control (RBAC) […]

👆La prima frase di questa sezione era solo parzialmente vera. Snowflake combina l'RBAC con un concetto chiave di un altro modello di controllo accessi: il Discretionary Access Control (DAC). Nel DAC ogni oggetto deve avere un proprietario.

Nell'implementazione DAC di Snowflake, ogni oggetto è di proprietà del Role usato per crearlo. Un Role che possiede un oggetto ha il privilegio OWNERSHIP su di esso.

È importante chiarire che non sono gli User a possedere gli oggetti, ma i Role. Se tutti gli Analyst del Suo team dati hanno lo stesso Role, gli oggetti creati da un Analyst saranno posseduti da tutti gli Analyst.

Si tenga presente che il privilegio OWNERSHIP su un oggetto può essere trasferito a un altro Role. Potrebbe ad esempio voler trasferire la proprietà di una tabella a un ruolo "più potente" per limitare chi può concederne l'accesso ad altri ruoli.

Privilegi su oggetti futuri

A volte, durante la configurazione iniziale del controllo accessi, alcuni oggetti potrebbero non esistere ancora. Tuttavia, sa già in anticipo che vorrà dare a un certo ruolo l'accesso a quegli oggetti, una volta creati. Snowflake ci consente di muoverci in anticipo concedendo determinati privilegi su oggetti futuri.

Ad esempio, al ruolo ANALYST può essere concesso il privilegio SELECT sulle tabelle future del database GOLDEN_DB, o sulle tabelle future di uno schema specifico. Per maggiori dettagli sulla precedenza dei grant sugli oggetti futuri, consulti questa documentazione di Snowflake.

Role

Può immaginare i role di Snowflake come delle chiavi. 🔑 Ha una chiave di casa, un'altra per l'auto e magari una per l'ufficio. Se ha un vicino di casa fidato, potrebbe avere una copia della chiave di casa Sua (per le emergenze). Le chiavi di casa danno accesso sia a Lei sia al vicino.

Allo stesso modo, in Snowflake, un role concesso a un utente gli dà accesso a varie operazioni e oggetti. Ecco un esempio di come l'organigramma aziendale potrebbe tradursi in Snowflake Role.

In Snowflake esistono tre tipi principali di Role:

• account role
• database role
• instance role

Esistono inoltre gli application role, legati alle Snowflake Native Application: un argomento stimolante che merita un articolo a sé e che va oltre lo scopo di questo Snowflake Roles 101.

Account Role

I role originari di Snowflake, gli Account Role, sono i role standard che:

• possono ricevere privilegi su tutti i securable object dell'account,
• hanno nomi univoci a livello di Account,
• possono essere concessi a User o ad altri Account Role.

Database Role

Come suggerisce il nome, un Database Role è legato a un Database specifico e:

• può ricevere solo privilegi sugli oggetti di quel database (schema, tabelle, view ecc.),
• ha un nome univoco all'interno del Database in cui viene creato,
• può essere concesso ad altri Database Role (nello stesso Database) e ad Account Role,
• non può essere concesso direttamente agli User,
• per impostazione predefinita ha il privilegio USAGE sul proprio database.

Instance Role

Gli Instance Role sono il tipo di role meno utilizzato. Sono legati a una Snowflake Class Instance e vengono concessi agli Account Role, consentendo agli User di eseguire i metodi della Class Instance.

Al momento in cui scriviamo, solo Snowflake può creare Classes. Per maggiori informazioni sulle Snowflake Classes disponibili, consulti questa pagina.

Quale tipo di Role conviene usare?

Se sta muovendo i primi passi, gli Account Role La porteranno molto lontano.

Le cose si fanno interessanti quando inizia a ragionare sui database role e sul loro potenziale per semplificare e standardizzare la configurazione, permettendo al proprietario di un database di gestire autonomamente i privilegi senza bisogno di ACCOUNTADMIN.

Inoltre, se utilizza le Snowflake Shares per condividere i Suoi dati, i database role rendono più facile configurare il controllo accessi.

I Role possono essere concessi anche ad altri Role: in questo modo si crea una Role Hierarchy.

Il modo più semplice per definire una gerarchia di Role è con un esempio. Nella gerarchia qui sotto Splinter, con il suo ruolo SYSADMIN, ha il superset dei privilegi dei ruoli DATA_ENG_ROLE, ANALYST_ROLE e DB_MANAGER_ROLE, mentre Kim ha solo i privilegi di DATA_ENG_ROLE e DB_MANAGER_ROLE.

Quando crea uno Snowflake account e apre Admin / Users & Roles, vedrà un insieme di role che Snowflake crea per impostazione predefinita. Questi role system-defined non possono essere eliminati, né è possibile modificare l'insieme standard di privilegi assegnato a ciascuno di essi. Hanno tutti uno scopo preciso, e cioè:

• ACCOUNTADMIN: il ruolo "god-mode", in grado di fare qualsiasi cosa a livello di account. Sia molto selettivo nel concederlo. Si noti che il ruolo ACCOUNTADMIN eredita tutti i privilegi di SECURITYADMIN e SYSADMIN.
• SECURITYADMIN: a questo ruolo è concesso il privilegio account-level MANAGE GRANTS, che gli permette di concedere (o revocare) grant ad altri ruoli su tutti gli oggetti dell'account. Si noti che il ruolo SECURITYADMIN eredita tutti i privilegi che gli vengono passati dal ruolo USERADMIN.
• USERADMIN: come suggerisce il nome, serve a creare e gestire utenti (grazie ai privilegi account-level CREATE USER e CREATE ROLE).
• SYSADMIN: è abilitato a creare tutti gli oggetti dell'account (inclusi database, warehouse e altri oggetti a livello di schema).
• PUBLIC: tutti gli utenti dell'account ricevono per impostazione predefinita il ruolo PUBLIC, ma se non gli vengono esplicitamente concessi accessi a oggetti non può fare granché. Faccia comunque molta attenzione a non concedergli inavvertitamente privilegi su dati importanti, perché tutti gli utenti dell'account potrebbero accedervi. O, meglio ancora, non conceda alcun privilegio al ruolo PUBLIC. 😉

Infine, ORGADMIN merita un'attenzione particolare. Si usa per le operazioni a livello di organizzazione, come la creazione di ulteriori Snowflake account, e non si inserisce in modo naturale nella gerarchia predefinita dei role.

Quando si creano role personalizzati e si imposta una gerarchia di role, Snowflake raccomanda che tutti i role personalizzati siano, in ultima analisi, discendenti di SYSADMIN.

Per esperienza, lavorando su molti Snowflake account, capita spesso di vedere la maggior parte degli oggetti del database creati e posseduti da ACCOUNTADMIN. È una pratica in generale sbagliata: indica che si dedica poca attenzione al controllo accessi ed è il segnale che ACCOUNTADMIN viene usato come role predefinito, cosa che può portare a errori distruttivi come la cancellazione di dati o utenti. Tratteremo alcune best practice di controllo accessi nella Parte II di questa serie di articoli. 🙌

Role predefinito dell'utente

Quando si connette a Snowflake, un utente stabilisce una session che, nella maggior parte dei casi, richiede l'impostazione di un role. Se non viene specificato, Snowflake ripiega sul role predefinito dell'utente.

Secondary Role

I secondary role permettono a un utente di sfruttare contemporaneamente le capacità di accesso di più ruoli. La maggior parte dei clienti Snowflake utilizza solo i primary role (un singolo ruolo), ma i secondary role sono una funzionalità potente che può evitare di dover combinare più ruoli.

Così come esegue il comando use role per impostare il primary role in una sessione, può eseguire use secondary roles. La differenza principale è che questo comando accetta due opzioni:

1. use secondary roles all attiva tutti i ruoli a cui l'utente ha accesso;
2. use secondary roles none disattiva i secondary role.

D'accordo, d'accordo: "Mostratemi un po' di SQL!! 💢", La sento.

Componiamo il puzzle con un esempio end-to-end di bootstrap di un nuovo Snowflake account, che abilita Kim e Rufus a utilizzarlo in linea con le loro esigenze.

In sintesi:

• Creiamo User, Role e il Database.

use role SECURITYADMIN;
create role DATA_ENGINEER_ROLE;
create role DB_MANAGER_ROLE;
create role ANALYST_ROLE;

use role USERADMIN;
create user KIM;

use role SYSADMIN; -- objects are owned by the active role
create database SOURCE_DB;
create warehouse ANALYSIS_WH;

• I privilegi sui securable object vengono concessi ai Role.

use role SECURITYADMIN;

grant USAGE, MODIFY, CREATE SCHEMA
	on database SOURCE_DB to role DB_MANAGER_ROLE;
grant USAGE on database SOURCE_DB to role ANALYST_ROLE;

grant USAGE, OPERATE
	on warehouse ANALYSIS_WH to role ANALYST_ROLE;

• I Role vengono collegati in una gerarchia, dando luogo all'ereditarietà dei privilegi.

use role SECURITYADMIN;

grant role DB_MANAGER_ROLE to role DATA_ENGINEER_ROLE;
grant role ANALYST_ROLE to role DATA_ENGINEER_ROLE;
grant role DATA_ENGINEER_ROLE to role SYSADMIN;

• Gli User ottengono l'accesso ai securable object ricevendo i Role.

use role SECURITYADMIN;

grant role DATA_ENGINEER_ROLE to user KIM;
grant role ANALYST_ROLE to user RUFUS;

Otteniamo così una configurazione che:

1. consente a Kim di:
2. creare schemi in SOURCE_DB e utilizzarlo
3. usare e operare su ANALYSIS_WH
4. consente a Rufus di:
5. usare SOURCE_DB (se Si sta chiedendo se manchino privilegi aggiuntivi su schemi e database, ha 💯 ragione, ma li abbiamo omessi per semplicità.)
6. usare e operare su ANALYSIS_WH

Pur essendo una configurazione molto semplice, quanto sopra Le fornisce tutti i mattoni necessari per implementare il Suo modello RBAC in Snowflake. Nella Parte II, un articolo di seguito a questo, tratteremo le best practice RBAC di Snowflake e Le forniremo alcune raccomandazioni basate sulla nostra esperienza.