Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Sicurezza multi-tenant trasparente ed efficace in BigQuery, dal suo strumento BI preferito…

By Diego MunozNov 2, 20213 min read

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

Se gestisce una dashboard multi-tenant su una piattaforma BI compatibile con OAuth e desidera limitare l'accesso alle righe di una tabella in base a un utente o a un gruppo specifico, la row-level security di BigQuery fa al caso suo.

Multi-tenant

Il metodo classico per limitare l'accesso a righe specifiche consisteva nell'aggiungere colonne supplementari alla tabella per identificare chi avesse l'accesso e nel fare una JOIN con una tabella ausiliaria contenente quegli utenti o gruppi. Per esempio:

SELECT
    t.*
FROM `project.dataset.table` AS t
JOIN `project.dataset.users` AS u ON t.access=u.name;

Tutto piuttosto semplice, no? Peccato che mantenere quella tabella utenti richieda un lavoro extra ogni volta che si aggiunge o si rimuove qualcuno. Il problema si risolve sfruttando la funzionalità row-level di BigQuery. Ora può concedere l'accesso direttamente sulla base dei gruppi Google e centralizzare la gestione. Per esempio:

CREATE OR REPLACE ROW ACCESS POLICY policy_<customer_id>
ON `project.dataset.table`
GRANT TO ('group:<customer_id>@<domain>')
FILTER USING (customer_id = '<customer_id>');

Inoltre, anziché usare credenziali condivise legate a un Single-Service Account, può affidarsi all'autorizzazione dell'utente tramite OAuth. In questo modo ottiene un controllo degli accessi più granulare (in termini di sicurezza e auditing), la gestione delle quote e dati sull'utilizzo che le permettono di guidare il prodotto sulla base di evidenze concrete.

Mi auguro che lei sia rigoroso e prenda decisioni basate sui fatti.

La sfida

Se durante la fase di crescita supera i 100 clienti, questa soluzione non regge: BigQuery prevede un limite rigido (mi creda, è inutile chiedere a Google di alzare la soglia). E poi, creare più di 100 regole per una sola tabella suona un po' eccessivo, non trova?

E se volesse avere un gruppo di amministratori con utenti che devono davvero accedere a tutti i dati? Anche questo scenario può complicarsi.

Come risolvere il problema

L'approccio che segue filtra gli accessi in base al dominio dell'utente. Il vantaggio è che le evita di creare nuovi gruppi e di gestirne le appartenenze. Allo stesso tempo, garantisce al suo team interno un accesso illimitato ai dati — il tutto con sole due policy a livello di riga.

Lo svantaggio evidente è che i suoi clienti devono utilizzare un dominio aziendale perché il meccanismo funzioni davvero. Questa soluzione non è adatta a domini generici come gmail.com, yahoo.com e hotmail.com, altrimenti finirebbe per concedere l'accesso a milioni di utenti.

-- Create a table
CREATE TABLE test.my_table (
id INT,
name STRING,
domain STRING);

-- Insert some values
INSERT INTO test.my_table (id, name, domain) VALUES
(1, 'test1', 'example.com'),
(2, 'test2', 'domain.com');

-- Restrict access to the users based on their domain name
CREATE OR REPLACE ROW ACCESS POLICY restrict_per_domain
ON `test.my_table`
GRANT TO ('allAuthenticatedUsers')
FILTER USING (domain = SUBSTR(SESSION_USER(),STRPOS(SESSION_USER(),'@')+1));

-- Grant access to an internal DoiT group
CREATE OR REPLACE ROW ACCESS POLICY grant_internal_group
ON `test.my_table`
GRANT TO ('group:<internal_group>@<domain>')
FILTER USING (1=1);

Il risultato:

1. [email protected], che appartiene al gruppo allAuthenticatedUsers, vede solo una riga, mentre

2. [email protected], che appartiene al gruppo [email protected], vede tutte le righe.

In sintesi, le policy a livello di riga più permissive prevalgono su quelle più restrittive (lo stesso meccanismo dell'ereditarietà dei permessi IAM) e, pur non essendo documentato esplicitamente da Google, è possibile utilizzare gruppi come allAuthenticatedUsers.

Per chiudere, abbiamo visto come sfruttare appieno la row-level security insieme allo strumento BI compatibile con OAuth che preferisce. Ottiene così il pieno controllo su cosa, quando e da chi vengono eseguite determinate azioni — e tutto questo con uno sforzo di manutenzione ridotto al minimo. La provi!

Per restare in contatto, ci segua sul DoiT Engineering Blog , sul DoiT Linkedin Channel e sul DoiT Twitter Channel . Per scoprire le opportunità di carriera, visiti https://careers.doit-intl.com .