Mascheramento dinamico dei dati tramite crittografia

Questa esercitazione fornisce istruzioni su come configurare e utilizzare il mascheramento dinamico dei dati utilizzando la crittografia in Netezza Performance Server.

Il mascheramento dinamico dei dati aiuta a prevenire l'accesso non autorizzato ai dati sensibili negli oggetti del database, come i campi o le colonne delle tabelle, mascherandoli agli utenti non privilegiati. Le regole di mascheramento vengono applicate solo ai risultati della query e i dati del database non vengono toccati, per cui possono essere utilizzati da altre applicazioni che potrebbero aver bisogno di accedere a questi dati.

Informazioni su questa attività

In questa esercitazione viene utilizzato il seguente schema di esempio:

Le colonne 'customer_name e 'customer_address sono le colonne sensibili che devono essere mascherate e crittografate. Di tutti gli utenti che possono accedere a queste tabelle (cioè che hanno il privilegio 'SELECT ) solo quelli che hanno il ruolo 'ACCOUNTS sono autorizzati a visualizzare le due colonne sensibili. Per gli altri utenti questi valori sono mascherati tramite crittografia.

Il modo standard per farlo è limitare l'accesso alle tabelle sottostanti e sovrapporre alle tabelle delle viste che modificano i valori in base al ruolo dell'utente. A tale scopo, occorre innanzitutto rinominare la tabella sottostante e poi creare una vista, utilizzando il nome originale della tabella, che proietti valori criptati per le colonne sensibili in base ai ruoli che hanno accesso.

Procedura

Definire la chiave di crittografia:
Si tratta di un'operazione una tantum.
Impostare una chiave di crittografia da utilizzare per il mascheramento creando una tabella separata a cui solo gli amministratori hanno privilegi e accesso. Come amministratore del database:
```
create table encryption_keys (key varchar(30)); 
insert into encryption_keys values('<your key value goes here>');
```

Preparare la tabella di base rinominandola, quindi creare una vista di mascheramento su di essa.

Come amministratore del database:

alter table customers rename to customers_table;
create or replace view customers as
select
customer_id,
case when current_role = 'ACCOUNTS' then customer_name
else encrypt(customer_name, (select encryption_keys.key)) end as customer_name,
case when current_role = 'ACCOUNTS' then customer_address
else encrypt(customer_address, (select encryption_keys.key)) end as customer_address,
customer_state,
customer_zip
from customers_table;

Suggerimento: invece di mascherare i dati utilizzando la crittografia, è possibile utilizzare la stessa procedura per mascherare o nascondere completamente i dati:


CREATE VIEW customers AS 
SELECT customer_id, 
       CASE WHEN current_role = 'ACCOUNTS' THEN customer_name 
            ELSE '*****' -- this could be NULL if the column was not (VAR)CHAR
       END AS customer_name,
       CASE WHEN current_role = 'ACCOUNTS' THEN customer_address
            ELSE '*****'
       END AS customer_address,
       customer_state,
       customer_zip
FROM "$customers_base";

Tuttavia, il vantaggio di mascherare usando la crittografia è che, se necessario, è possibile, ad esempio, unire la colonna crittografata di questa tabella alla colonna crittografata di un'altra tabella e mantenere la relazione tra le righe. Questo non sarebbe possibile se la colonna fosse semplicemente mascherata o trattata come NULL.

Assegnare il ruolo 'ACCOUNTS agli utenti selezionati.
In questo passaggio, si concede a un sottoinsieme di utenti il privilegio di assumere il ruolo 'ACCOUNTS. Ad esempio, in un gruppo di utenti 'alice, 'bob e 'clark, solo 'alice e 'bob hanno bisogno del privilegio del ruolo 'ACCOUNTS.
```
create role accounts;
grant list on accounts to alice, bob;
```
Quindi, concedere il privilegio di eseguire query sui clienti (la vista mascherata) e sugli ordini (la tabella).
```
grant select on  customers, orders  to  public, accounts;
```
A questo punto la mascheratura dinamica è impostata e pronta all'uso.

Risultati

Supponiamo che l'utente 'alice abbia bisogno di un report del totale 'order_amount, suddiviso per codice di stato:

select
sum(order_amount) as total,
customer_state
from customers inner join orders using (customer_id)
group by customer_state;

TOTALE	STATO DEL CLIENTE
10750.01	NY
2000.00	TX
99.99	XX

Alice può accedere a CLIENTI (la vista mascherata). La colonna 'customer_id non è crittografata e viene utilizzata per eseguire un join con la tabella ORDINI. La colonna 'customer_state non è criptata e viene utilizzata per eseguire il roll-up (per stato). Ma 'customer_name e 'customer_address sono sensibili. Se decide di visualizzarle, sono criptate:

select * from customers order by customer_id;

ID CLIENTE	NOME CLIENTE	INDIRIZZO_CLIENTE	STATO DEL CLIENTE	ZIP DEL CLIENTE
10031	&J.&#+RXV	/U/%9$,1WZJ\*?<1L3-	TX	90210
21451	INR0-F50_0	1U*"\(7H"V;3S%NH0]!= ['T	NY	55555
43918	I_*$)VM0X0	0U+;!="XWV;#T&^Y#F#=8[	NY	98765
60844	M>6%(7Q0Y@	-T+#!9$@9T+#T6L(5L0	NY	55554
80008	H>F0*F]0Y@	1L>B4*7<#U:WN&Z,JISI7YS<	XX	0

Se Alice ha bisogno di accedere alle colonne non criptate, le è stato concesso il privilegio di assumere il ruolo " ACCOUNTS, che le consente di vedere i dati di origine non criptati:

set role accounts;
select * from customers order by customer_id;

ID CLIENTE	NOME CLIENTE	INDIRIZZO_CLIENTE	STATO DEL CLIENTE	ZIP DEL CLIENTE
10031	Marco F	234 Main Street	TX	90210
21451	Clark K	1 Metropolis Ave.	NY	55555
43918	Bruce W	1600 Gotham Lane	NY	98765
60844	Pietro P	500 Fifth Ave.	NY	55554
80008	Diana P	Isola di Themyscira	XX	0