Il modello di responsabilità condivisa

La sicurezza nel cloud non è delegata interamente al provider: è un accordo di responsabilità condivisa (shared responsibility) tra Google e il cliente. Google si occupa della sicurezza del cloud (data center fisici, hardware, rete globale, hypervisor), mentre il cliente resta responsabile della sicurezza nel cloud. Il confine però si sposta a seconda del modello di servizio: con una VM su Compute Engine il cliente gestisce sistema operativo, patch e configurazioni, mentre con un servizio serverless come Cloud Run o un data warehouse gestito come BigQuery Google assorbe molta più responsabilità operativa. Google descrive anche un modello di “shared fate”: non si limita a tracciare una linea di confine, ma fornisce blueprint sicuri, configurazioni consigliate e assicurazioni per aiutare attivamente il cliente a partire da una postura sicura. Il messaggio per l’esame: la responsabilità non sparisce mai, cambia solo chi ne detiene quale parte in base al servizio scelto.

Identità, encryption e visibilità

Identity and Access Management (IAM) è il cuore del controllo degli accessi: definisce chi (identità: utenti, gruppi, service account) può fare cosa (ruolo) su quale risorsa. Il principio guida è il least privilege, cioè concedere solo i permessi strettamente necessari, preferendo ruoli predefiniti granulari e gruppi rispetto a permessi individuali ampi. IAM permette di ereditare i criteri lungo la gerarchia delle risorse (organizzazione, cartelle, progetti), semplificando la governance su larga scala.

L’encryption è attiva di default e non richiede alcuna azione: tutti i dati sono cifrati at rest (a riposo, sui dischi) e in transit (in movimento sulla rete) senza configurazione. Il cliente che ha esigenze di compliance può però scegliere di gestire le proprie chiavi tramite Cloud Key Management Service (customer-managed encryption keys), ottenendo maggiore controllo pur restando all’interno della piattaforma.

Security Command Center è la piattaforma centralizzata per la visibilità su rischi e minacce: individua misconfigurazioni, vulnerabilità e comportamenti sospetti, offrendo una dashboard unica sulla postura di sicurezza. È lo strumento a cui pensare quando lo scenario chiede “vista d’insieme delle minacce” o “rilevamento di configurazioni errate”.

Zero-trust, protezione dei dati e compliance

L’approccio zero-trust rovescia il modello perimetrale tradizionale: non ci si fida di nulla per posizione di rete, ma si verifica ogni accesso in base a identità e contesto. In Google Cloud questo si concretizza in BeyondCorp, che consente accesso sicuro alle applicazioni senza dipendere da una VPN, valutando identità dell’utente e stato del dispositivo a ogni richiesta.

Per la protezione dei dati sensibili, servizi dedicati aiutano a scoprire, classificare e mascherare informazioni personali (come numeri di carta o codici fiscali) all’interno dei dataset, riducendo il rischio di esposizione. Sul fronte della residenza e sovranità dei dati, il cliente può scegliere le region in cui i dati risiedono, rispondendo a requisiti normativi di localizzazione; Google offre inoltre soluzioni di sovereign cloud per esigenze regolatorie più stringenti. Infine la compliance: Google mantiene certificazioni e attestazioni riconosciute (ISO, SOC, e allineamenti a normative come il GDPR) e le rende consultabili, ma la conformità resta un obiettivo condiviso, perché dipende anche da come il cliente configura e usa i servizi. Il concetto chiave da portare all’esame è che una sicurezza ben governata non è un costo ma un vantaggio competitivo del cloud.

Trappole tipiche d’esame

  • “Chi è responsabile della sicurezza dei dati che carico?” → responsabilità condivisa: la protezione dei dati e la configurazione degli accessi restano sempre al cliente; Google protegge l’infrastruttura sottostante, non i tuoi dati mal configurati.
  • “Devo attivare la cifratura dei dati a riposo” → encryption di default: l’encryption at rest e in transit è già attiva automaticamente; non va abilitata. Serve azione solo se vuoi gestire tu le chiavi (Cloud KMS).
  • “Voglio una vista centralizzata di minacce e misconfigurazioni” → Security Command Center: non è IAM (che controlla gli accessi) né Cloud KMS (che gestisce le chiavi); è lo strumento di visibilità e threat detection.
  • “Accesso alle app senza VPN, verificando identità e device” → zero-trust / BeyondCorp: la risposta perimetrale (VPN, firewall) è la trappola; il paradigma corretto è “mai fidarsi, sempre verificare”.
  • “I dati devono restare in una specifica area geografica” → residenza dei dati / scelta della region: è una decisione di localizzazione e sovranità, non una funzione di cifratura o di IAM.
  • “Serve il minimo permesso necessario” → least privilege con IAM: evita di assegnare ruoli ampi (come Owner/Editor) o permessi a singoli utenti; usa ruoli granulari e gruppi ereditati lungo la gerarchia.