Classificazione e ispezione con Sensitive Data Protection (Cloud DLP)

Sensitive Data Protection (l’ex Cloud DLP) è il servizio di riferimento per scoprire, classificare e de-identificare dati sensibili. Lavora su tre piani che l’esame tende a confondere. L’inspection identifica gli infoType (email, codici fiscali, carte di credito, PII generiche) in testo, immagini e storage strutturato, restituendo un livello di likelihood. La discovery effettua un profiling continuo e automatico degli asset (soprattutto BigQuery e Cloud Storage) a livello di organizzazione, popolando i risultati in Security Command Center: è la scelta giusta quando lo scenario chiede una data classification su larga scala e ricorrente, non una scansione ad hoc. La de-identification trasforma il dato, ed è qui che si concentrano le trappole.

Le tecniche di de-identification hanno trade-off precisi. La redaction rimuove il valore (nessuna reversibilità). Il masking lo offusca parzialmente (es. mostra solo le ultime cifre). La tokenization (crypto-based, tipicamente FPE — Format-Preserving Encryption — o deterministica) sostituisce il valore con un token: è la pseudonimizzazione richiesta quando serve preservare l’integrità referenziale (lo stesso input produce sempre lo stesso token, utile per join e analytics) oppure la reversibilità con la chiave. Scegli la tokenization deterministica quando il requisito è “analizzare senza esporre ma poter correlare i record”; scegli redaction/masking quando la reversibilità è indesiderata. La wrapping key della tokenization risiede in Cloud KMS, quindi il controllo dell’accesso al dato in chiaro passa dal controllo IAM sulla key.

Secret Manager: storage e rotazione dei segreti

Secret Manager è il repository gestito per API key, password e certificati, con versioning immutabile dei secret e accesso granulare via IAM (roles/secretmanager.secretAccessor). Punti da ricordare per l’esame: i segreti sono cifrati at-rest e supportano CMEK per il controllo della chiave; la rotation è supportata tramite schedule che pubblica un evento su Pub/Sub, ma la logica applicativa di generazione della nuova credenziale resta a carico tuo (Secret Manager notifica, non ruota le credenziali del sistema esterno da solo). La regola trasversale: niente segreti hardcoded in codice, container image o variabili d’ambiente in chiaro. Su GKE preferisci recuperare i segreti a runtime via Workload Identity, evitando service account key statiche.

Protezione di Cloud Storage e BigQuery

Su Cloud Storage il controllo fondativo è l’uniform bucket-level access: disabilita le ACL per-oggetto e affida l’autorizzazione unicamente a IAM. È preventivo contro le esposizioni accidentali (ACL allUsers su singoli oggetti) e va combinato con la Public Access Prevention imposta via organization policy come guardrail a livello di org.

Su BigQuery, la column-level security si realizza con i policy tag di Data Catalog: tagghi le colonne sensibili e concedi il ruolo Fine-Grained Reader solo a chi deve leggerle; chi non ha il ruolo non vede quella colonna. Distinguila dalla dynamic data masking (mascheramento del valore in query invece che negazione totale) e dalla row-level security (filtro sulle righe). Per l’ispezione, la discovery di Sensitive Data Protection può classificare automaticamente le tabelle e suggerire i policy tag.

Anti-esfiltrazione con VPC Service Controls

Il controllo chiave contro la data exfiltration è VPC Service Controls: crea un service perimeter attorno alle API dei servizi gestiti (Cloud Storage, BigQuery, ecc.) impedendo che dati vengano letti/copiati verso progetti o identità fuori dal perimetro, anche con credenziali IAM valide. È difesa in profondità: IAM dice chi può accedere, VPC-SC dice da dove i dati possono uscire. Ingress/egress rules e access levels (via Access Context Manager) regolano le eccezioni controllate.

Trappole tipiche d’esame

  • Serve pseudonimizzare mantenendo i join tra dataset → tokenization deterministica: redaction e masking distruggono la correlazione; solo la tokenization (crypto-based) preserva l’integrità referenziale.
  • Bloccare la copia di dati BigQuery verso un progetto esterno pur con IAM corretto → VPC Service Controls: non è un problema di ruoli né un firewall di rete; il perimetro impedisce l’esfiltrazione a livello di API.
  • Nascondere singole colonne sensibili a certi utenti → column-level security con policy tag: row-level security filtra le righe, non le colonne; la dynamic data masking altera il valore ma non nega l’accesso.
  • Impedire bucket pubblici a livello di organizzazione → organization policy (Public Access Prevention) + uniform bucket-level access: IAM da solo non impedisce che qualcuno riesponga un oggetto via ACL.
  • Classificazione automatica e continua degli asset dati → discovery/profiling di Sensitive Data Protection: l’inspection ad hoc scansiona su richiesta; la discovery alimenta i profili in Security Command Center.
  • Evitare API key statiche nel codice → Secret Manager (o Workload Identity): e ricorda che la rotation schedule notifica via Pub/Sub, non rigenera da sola la credenziale del sistema a valle.