Strategie per la privacy dei dati

MySQL   |  PostgreSQL   |  SQL Server

La privacy dei dati protegge dati quali le informazioni che consentono l'identificazione personale (PII) da coloro che non dovrebbero avervi accesso. Questa pagina descrive diversi approcci alla privacy dei dati che puoi utilizzare per proteggere le tue PII in Cloud SQL.

Puoi utilizzare Cloud SQL per archiviare le tue PII in modo sicuro. Vuoi assicurarti che queste informazioni vengano trattate con la massima protezione della privacy, in modo che non vengano rese accessibili inavvertitamente. Ad esempio, se archivi i dati delle carte di credito o i dati sanitari nei tuoi database, puoi utilizzare Cloud SQL per nascondere o mascherare PII agli utenti senza privilegi.

Utilizza le seguenti strategie per proteggere le tue PII in Cloud SQL:

• Sicurezza a livello di colonna
• Approccio basato sulle visualizzazioni
• Sicurezza a livello di riga
• Mascherare e anonimizzare i dati
• Criptare i dati

Sicurezza a livello di colonna

La sicurezza a livello di colonna consente di limitare gli utenti che possono visualizzare i contenuti in colonne specifiche delle tabelle di database. I privilegi a livello di colonna sono applicabili per le istruzioni INSERT, UPDATE, SELECT e REFERENCES.

Ad esempio, prendi in considerazione un sito web di vendita al dettaglio in cui vuoi gestire le PII per due utenti: Jack e Alice.

--User: "admin"

CREATE SCHEMA secure_schema;

CREATE TABLE secure_schema.user_details(id bigint, name text, age smallint, email_id text, password text);

--For this example, passwords are stored in plain text for demonstration
--purposes only. In production, never store passwords in plain text.

INSERT INTO secure_schema.user_details VALUES(1,'jack',34,'[e-mail]','testpass');
INSERT INTO secure_schema.user_details VALUES(2,'alice',37,'[e-mail]','testpass');

GRANT USAGE ON SCHEMA secure_schema TO analyst_ro;

--Grant read permissions on specific columns only.

GRANT SELECT (id, name, age) ON secure_schema.user_details TO analyst_ro;

--User: "analyst_ro"

SELECT * FROM secure_schema.user_details;
ERROR:  permission denied for table user_details

SELECT name, age, password FROM secure_schema.user_details;
ERROR:  permission denied for table user_details

SELECT id, name,age FROM secure_schema.user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

Se includi le colonne limitate nell'istruzione SELECT o inserisci SELECT *, viene visualizzato un messaggio di errore. Cloud SQL protegge le PII per Jack e Alice in queste colonne.

Puoi anche utilizzare una singola istruzione GRANT per combinare privilegi diversi.

GRANT SELECT (id,name,age), UPDATE (name) ON secure_schema.user_details TO analyst_ro;

Approccio basato sulle visualizzazioni

Puoi aumentare la sicurezza a livello di colonna anche creando una visualizzazione in una tabella, escludendo o mascherando le colonne che vuoi nascondere agli altri utenti e concedendo l'accesso alla vista anziché alla tabella.

L'esempio seguente mostra come utilizzare un approccio basato sulle visualizzazioni per il sito web di vendita al dettaglio per proteggere le PII di Jack e Alice:

--User: "admin"

CREATE SCHEMA analyst_ro;
CREATE VIEW analyst_ro.user_details AS SELECT id, name, age FROM secure_schema.user_details;
GRANT USAGE ON SCHEMA analyst_ro TO analyst_ro;
GRANT SELECT ON analyst_ro.user_details TO analyst_ro;

--User: "analyst_ro"

SELECT id,name,age FROM user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

SELECT * FROM user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

In questo esempio, viene creato uno schema separato per la vista, che manterrà lo stesso nome della tabella. Con l'approccio basato sulle visualizzazioni, puoi utilizzare SELECT *.

Puoi anche creare una visualizzazione e mascherare le colonne della tabella di database in modo che gli utenti senza privilegi non possano visualizzare le PII mascherate.

CREATE VIEW analyst_ro.user_details AS SELECT id, name, age, '[e-mail]' as email_id,'*****'::text as password FROM secure_schema.user_details;

SELECT * FROM user_details;
 id | name  | age |     email_id         | password
----+-------+-----+----------------------+---------
  1 | jack  |  34 | [e-mail] | *****
  2 | alice |  37 | [e-mail] | *****

Sicurezza a livello di riga

La sicurezza a livello di colonna e un approccio basato sulle visualizzazioni consentono di nascondere PII nelle colonne delle tabelle di database a utenti specifici. Tuttavia, a volte potresti voler filtrare questi dati e concedere l'accesso a righe specifiche di una tabella. Questa tabella contiene le PII a cui possono accedere solo determinati utenti, in base alle condizioni degli utenti idonei. Questa operazione è nota come sicurezza a livello di riga.

La sicurezza a livello di riga è utile per le applicazioni multi-tenant in cui gli utenti dispongono di privilegi di accesso in lettura e scrittura esclusivamente alle proprie PII. In Cloud SQL, le tabelle possono avere criteri di sicurezza a livello di riga che limitano, in base all'utente, le righe che gli utenti possono visualizzare creando query o le righe che gli utenti possono inserire, aggiornare o eliminare eseguendo comandi di modifica dei dati.

Per l'esempio del sito web di vendita al dettaglio, puoi implementare la sicurezza a livello di riga per Jack e Alice, in modo che possano visualizzare le proprie PII, ma non possano modificarle o eliminarle.

--User: "admin"
--Create and enable a policy for row-level security

CREATE POLICY user_details_rls_pol ON secure_schema.user_details FOR ALL TO PUBLIC USING (name=current_user);
ALTER TABLE secure_schema.user_details ENABLE ROW LEVEL SECURITY;

SELECT * FROM secure_schema.user_details;
 id | name  | age |     email_id      | password
----+-------+-----+-------------------+---------
  1 | jack  |  34 | [e-mail]  | testpass
  2 | alice |  37 | [e-mail] | testpass

--User: "jack"

SELECT * FROM secure_schema.user_details;
 id | name | age |    email_id      | password
----+------+-----+------------------+---------
  1 | jack |  34 | [e-mail] | testpass

--User: "alice"

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+-------------------+---------
  2 | alice |  37 | [e-mail] | testpass

Gli utenti assegnati a ruoli con attributo BYPASSRLS possono ignorare la sicurezza a livello di riga quando accedono a una tabella. I proprietari delle tabelle possono anche bypassare la sicurezza a livello di riga. Se vuoi sottoporre il proprietario di una tabella alla sicurezza a livello di riga, utilizza il comando ALTER TABLE ... FORCE ROW LEVEL SECURITY.

In alcuni casi, non è consigliabile applicare la protezione a livello di riga alle righe di una tabella di database. Ad esempio, se utilizzi pg_dump per eseguire il backup della tabella, è consigliabile che nessuna riga venga omessa dal backup. Per evitare che ciò accada, per l'utente che esegue il backup imposta il parametro di configurazione row_security su OFF. Se una o più righe vengono filtrate in base alla sicurezza a livello di riga, viene visualizzato un messaggio di errore.

Mascherare e anonimizzare i dati

Oltre a mascherare i dati con un approccio basato sulle visualizzazioni, puoi mascherarli utilizzando l'estensione postgresql_anonymizer. Questa estensione maschera o sostituisce le PII o i dati commercialmente sensibili di un database PostgreSQL.

L'utilizzo dell'estensione rispetto a un approccio basato sulle visualizzazioni offre i seguenti vantaggi:

• Esistono varie funzioni di mascheramento, come sostituzione, randomizzazione, falsifica, pseudonimi, scrambling parziale, shuffling, aggiunta di rumore e generalizzazione.

• Puoi generare dati mascherati significativi che puoi utilizzare per i test funzionali e l'elaborazione dei dati.

• Puoi utilizzare il Data Definition Language (DDL) PostgreSQL per dichiarare le regole di mascheramento e specificare la strategia di anonimizzazione all'interno della definizione della tabella.

Installa e configura l'estensione postgresql_anonymizer

Per utilizzare questa estensione su un'istanza Cloud SQL, completa i seguenti passaggi:

1. Modifica l'istanza, quindi imposta cloudsql.enable_anon flag su on. Per informazioni sull'impostazione dei flag e per esaminare i flag supportati per l'estensione, vedi Configurare i flag di database.

2. Crea l'estensione nel database eseguendo questo comando:

   --Connect to the PostgreSQL database
   
   CREATE EXTENSION IF NOT EXISTS anon CASCADE;
   SELECT anon.init();
   

Dopo aver installato e configurato l'estensione, utilizzala nell'istanza per implementare strategie di anonimizzazione per maschera dinamica, maschera statica e dump anonimo.

Maschera dinamica

Utilizza le maschere dinamiche per definire le regole di mascheramento per utenti specifici. Questi utenti non possono visualizzare PII. Invece, vede i dati mascherati. Tutti gli altri utenti vedono i dati non mascherati. Ciò è utile negli ambienti di produzione quando non vuoi modificare le PII, ma solo nasconderle a determinati utenti.

Per l'esempio del sito web di vendita al dettaglio, puoi implementare le maschere dinamiche in modo che l'amministratore possa visualizzare gli indirizzi email e le password non mascherati di Jack e Alice, mentre l'analista può visualizzare solo i dati mascherati.

--Activate the dynamic masking engine

SELECT anon.start_dynamic_masking();

--Declare the masking user and masking rules
--analyst_ro is the masked user with select privileges on the
--user_details table

SECURITY LABEL FOR anon ON ROLE analyst_ro IS 'MASKED';

SECURITY LABEL FOR anon ON COLUMN secure_schema.user_details.email_id IS 'MASKED WITH FUNCTION anon.fake_email()';
SECURITY LABEL FOR anon ON COLUMN secure_schema.user_details.password  IS 'MASKED WITH FUNCTION anon.hash(password)';

--User: "admin" (can see all unmasked data)

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+------------  -----+---------
  1 | jack  |  34 | [e-mail]  | testpass
  2 | alice |  37 | [e-mail] | testpass

--User:"analyst_ro" (note that the "email_id" and "password" columns are
--replaced with masked data,)
--Data in the password column is truncated for better formatting.

SELECT * FROM secure_schema.user_details;
 id | name  | age |       email_id         | password
----+-------+-----+-----------------  -----+----------------
  1 | jack  |  34 | [e-mail] | 13d249f2cb4127b
  2 | alice |  37 | [e-mail]   | 13d249f2cb4127b

Maschera statica

Utilizza le maschere statiche per rimuovere le PII in una tabella, in base ai criteri definiti nelle regole di mascheramento, e sostituisci queste informazioni con i dati mascherati. Gli utenti non possono recuperare i dati non mascherati. Questo è utile negli ambienti di test quando vuoi modificare le PII e non vuoi che nessun utente le visualizzi.

Nota:poiché le maschere statiche sostituiscono i dati non mascherati con i dati mascherati in una tabella, a seconda delle dimensioni della tabella, questo processo può richiedere molto tempo.

Per l'esempio del sito web di vendita al dettaglio, puoi implementare maschere statiche in modo che nessun utente possa visualizzare gli indirizzi email e le password non mascherati di Jack e Alice. ma visualizzano solo i dati mascherati.

--User: "admin"

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+--------------  ---+---------
  1 | jack  |  34 | [e-mail]  | testpass
  2 | alice |  37 | [e-mail] | testpass

--Apply earlier defined masking rules to the table permanently.
--Now all users see masked data only.

SELECT anon.anonymize_table('secure_schema.user_details');
 anonymize_table
-----------------
 t

--User: "analyst_ro"
--Data in the password column is truncated for better formatting.

select * from secure_schema.user_details;
 id | name  | age |           email_id              |  password
----+-------+-----+-------------------------  ------+---------------
  1 | jack  |  34 | [e-mail] | 13d249f2cb412c
  2 | alice |  37 | [e-mail]         | 13d249f2cb4127

Dump anonimo

Utilizza dump anonimi per esportare i dati mascherati in un file SQL. Per l'esempio del sito web di vendita al dettaglio, puoi creare un file di dump per i dati mascherati contenuti nella tabella user_details.

--Launch pg_dump_anon with the masked user to apply earlier defined --masking rules

pg_dump_anon -h HOSTIP -p 5432 -d DATABASE_NAME -U analyst_ro --table=secure_schema.user_details --file=user_details_anonysms.sql

Cripta i dati

Sebbene sia possibile mascherare le PII, le informazioni vengono archiviate nel database come testo normale. Queste informazioni possono essere visualizzate da un amministratore.

Utilizza l'estensione pgcrypto per criptare le PII prima di archiviarle. In questo modo, solo gli utenti che dispongono di una chiave di crittografia valida possono decriptare le informazioni e visualizzarle come testo normale.

L'estensione pgcrypto include diverse funzioni di hash e crittografia.

Hash

Un hash è una funzione crittografica unidirezionale in cui ti interessa solo criptare le PII. Ciò è utile per memorizzare le password in un formato con hash e far corrispondere le password inserite dagli utenti a quelle sottoposte ad hashing. Le password sottoposte ad hashing non vengono mai decriptate come testo normale.

Per l'esempio del sito web di vendita al dettaglio, puoi utilizzare l'estensione pgcrypto per eseguire l'hashing della password di Jack prima di memorizzarla nella tabella user_details.

--Hash passwords before storing them in the user_details table.

TRUNCATE TABLE secure_schema.user_details;
INSERT INTO secure_schema.user_details VALUES(1,'jack',34,'[e-mail]',crypt('testpassword', gen_salt('bf')));

--Match the hashed data with user entered password

SELECT id, name FROM secure_schema.user_details WHERE email_id = '[e-mail]' AND password = crypt('testpassword', password);
 id | name
----+-----
  1 | jack

Cripta

Utilizza una funzione crittografica di crittografia per criptare le PII con una chiave. Gli utenti hanno poi bisogno di questa chiave per decriptare le informazioni in testo normale. Ciò è utile per memorizzare i dati della carta di credito e i dati bancari dove le applicazioni desiderano recuperare le PII in un formato leggibile.

Per l'esempio del sito web di vendita al dettaglio, la password e l'indirizzo email di Giacomo sono criptati. Gli utenti che dispongono della chiave di crittografia possono decriptare queste informazioni e visualizzarle come testo normale. Per tutti gli altri utenti viene visualizzato un messaggio di errore.

--"user_acc_key" is the encryption key

TRUNCATE TABLE secure_schema.user_details;
INSERT INTO secure_schema.user_details VALUES(1,'jack',34,pgp_sym_encrypt('[e-mail]','user_acc_key'),pgp_sym_encrypt('testpassword','user_acc_key'));

--User: "admin" (queries without an encryption key)
--Data in the email_id and password columns are truncated for better
--formatting.

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id     | password
----+-------+-----+-----------------+-------------------
  1 | jack |  34 | \xc30d0407030209 | \xc30d040703028962

--User: "app_user" (queries with a valid encryption key)

SELECT name,pgp_sym_decrypt(email_id::bytea,'user_acc_key'),pgp_sym_decrypt(password::bytea,'user_acc_key') FROM secure_schema.user_details;
 name | pgp_sym_decrypt   | pgp_sym_decrypt
------+-------------------+----------------
 jack | [e-mail]  | testpassword

--If a user uses the wrong encryption key, then the following error message appears:

SELECT name,pgp_sym_decrypt(email_id::bytea,'user_bad_key'),
pgp_sym_decrypt(password::bytea,'user_bad_key') FROM secure_schema.user_details;
ERROR:  Wrong key or corrupt data

Nota: con l'estensione pgcrypto, l'intera elaborazione di crittografia e decriptazione avviene all'interno del database. Tuttavia, potrebbe essere opportuno controllare la logica di crittografia e decriptazione all'interno di un'applicazione. A questo scopo, utilizza la crittografia lato client per criptare le PII prima di scriverle in Cloud SQL. Puoi criptare queste informazioni in modo che solo le applicazioni possano decriptarle.

Passaggi successivi

Scopri i seguenti controlli aggiuntivi che puoi utilizzare per proteggere le PII da accessi indesiderati:

• Autenticazione IAM

• Reti autorizzate

• Certificati SSL/TLS

• Ruoli e autorizzazioni

• Manutenzione self-service