Strategie per la privacy dei dati

MySQL   |  PostgreSQL   |  SQL Server

La privacy dei dati protegge dati come le informazioni che consentono l'identificazione personale (PII) di coloro che non dovrebbero avervi accesso. In questa pagina vengono descritti i diversi approcci alla privacy dei dati che puoi utilizzare per proteggere le tue PII in Cloud SQL.

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

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
• Cripta i dati

Sicurezza a livello di colonna

La sicurezza a livello di colonna consente di limitare gli utenti che possono vedere i contenuti in colonne specifiche delle tabelle di database. I privilegi a livello di colonna sono applicabili alle 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 di Jack e Alice in queste colonne.

Puoi anche utilizzare un'unica istruzione GRANT per combinare diversi privilegi.

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

Approccio basato sulle visualizzazioni

Puoi anche ottenere la sicurezza a livello di colonna creando una vista in una tabella, escludendo o mascherando le colonne che vuoi nascondere agli altri utenti e fornendo 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 al fine di proteggere le PII per 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 visualizzazione in modo che il nome rimanga invariato rispetto alla tabella. Con l'approccio basato sulle visualizzazioni, puoi usare SELECT *.

Puoi anche creare una vista e mascherare le colonne della tabella di database in modo che gli utenti non privilegiati non possano vedere 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 su viste ti consentono di nascondere le 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 che consentono l'accesso solo a determinati utenti, in base alle condizioni di utilizzo idonee. Questo procedimento è noto come sicurezza a livello di riga.

La sicurezza a livello di riga è utile per le applicazioni multi-tenant in cui gli utenti dispongono dei privilegi di accesso in lettura e scrittura solo per le proprie PII. In Cloud SQL, le tabelle possono avere criteri di sicurezza a livello di riga che limitano, su base 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 che consentono l'identificazione personale, ma non possono 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 l'attributo BYPASSRLS possono bypassare la sicurezza a livello di riga quando accedono a una tabella. I proprietari delle tabelle possono anche ignorare la sicurezza a livello di riga. Se vuoi applicare la sicurezza a livello di riga a un proprietario della tabella, utilizza il comando ALTER TABLE ... FORCE ROW LEVEL SECURITY.

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

Maschera e anonimizza i dati

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

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

• Sono disponibili varie funzioni di mascheramento, come sostituzione, randomizzazione, creazione di falsi, pseudonimizzazione, scrambling parziale, ordinamento casuale, aggiunta di rumore e generalizzazione.

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

• Puoi utilizzare il linguaggio DDL (Data Definition Language) di 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 in un'istanza Cloud SQL, completa i seguenti passaggi:

1. Modifica l'istanza e imposta cloudsql.enable_anon flag su on. Per informazioni sull'impostazione dei flag e per esaminare quelli 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 sull'istanza per implementare le strategie di anonimizzazione di maschera dinamica, maschera statica e dump anonimo.

Maschera dinamica

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

Nell'esempio del sito web di vendita al dettaglio, puoi implementare maschere dinamiche in modo che l'amministratore possa visualizzare gli indirizzi email e le password non mascherati di Jack e Alice, mentre l'analista possa 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

Utilizzare le maschere statiche per rimuovere le PII in una tabella, in base ai criteri definiti nelle regole di mascheramento, e sostituire queste informazioni con 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 visualizzi queste informazioni.

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

Nell'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. Al contrario, 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 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 tu possa mascherare le PII, le informazioni vengono archiviate nel database come testo normale. Un amministratore può visualizzare queste informazioni.

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 contiene una serie di funzioni di hash e crittografia.

Hash

Un hash è una funzione crittografica unidirezionale che ti interessa solo criptare le PII. Questo è utile per memorizzare le password in un formato sottoposto ad hashing e abbinarle a quelle inserite dall'utente. Le password sottoposte ad hashing non vengono mai decriptate in 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 di crittografia per criptare le PII con una chiave. Gli utenti avranno quindi bisogno di questa chiave per decriptare le informazioni in testo normale. È utile per memorizzare i dati della carta di credito e le coordinate bancarie nel caso in cui le applicazioni vogliano recuperare informazioni che consentono l'PII in un formato leggibile.

Per l'esempio del sito web di vendita al dettaglio, la password e l'indirizzo email di Jack sono crittografati. 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, tutta l'elaborazione di crittografia e decrittografia avviene all'interno del database. Tuttavia, potresti voler controllare la logica di crittografia e decrittografia all'interno di un'applicazione. A tale 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 ingiustificati:

• Autenticazione IAM

• Reti autorizzate

• Certificati SSL/TLS

• Ruoli e autorizzazioni

• Manutenzione self-service