Google ACE: Sicurezza, conformità e protezione dei dati — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fa parte della Google Associate Cloud Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La sicurezza, la conformità e la protezione dei dati su Google Cloud si basano su un modello di responsabilità condivisa e su un approccio secure-by-default e di difesa in profondità (defense-in-depth). Google protegge l’infrastruttura fisica, i servizi fondamentali e la crittografia predefinita, mentre l’utente è responsabile della protezione di identità e accessi, classificazione e conservazione dei dati, configurazioni delle applicazioni e processi operativi. Progettare secondo il principio del privilegio minimo (least privilege) lungo tutta la gerarchia delle risorse, utilizzare i gruppi anziché i singoli utenti, preferire le identità gestite e le credenziali a breve termine, e stratificare i controlli in modo che il fallimento di un singolo controllo non porti a una compromissione. Costruire flussi di lavoro di osservabilità e risposta fin dall’inizio, in modo che la postura di sicurezza possa essere misurata e migliorata continuamente.

Fondamenti di Identità e Accesso

• Responsabilità condivisa e privilegio minimo
  • Organizzare i progetti sotto un’unica organizzazione con cartelle che rispecchiano i confini di fiducia (trust boundaries). Applicare i vincoli delle Organization Policy per imporre impostazioni predefinite sicure (ad esempio, non consentire IP pubblici, limitare le location, impedire la creazione di chiavi per i service account).
  • Assegnare i ruoli IAM ai Google Groups, non agli utenti, e preferire i ruoli predefiniti rispetto ai ruoli di base (basic roles). Rivedere regolarmente le associazioni di ruolo (role bindings) e rimuovere i permessi non utilizzati.

  • Abilitare l’auditabilità e l’attribuzione. Per l’accesso amministrativo al sistema operativo delle VM, utilizzare OS Login con chiavi SSH per utente; assegnare ai gruppi i ruoli roles/compute.osLogin o roles/compute.osAdminLogin. Esempio:

undefined

-

undefined

• Modalità di fallimento comuni: assegnare i ruoli di proprietario (owner) o editor agli utenti, utilizzare chiavi SSH a livello di progetto e creare chiavi per i service account a lunga durata.

• Protezione dell’accesso alle applicazioni con BeyondCorp e Identity-Aware Proxy (IAP)

  • IAP termina l’accesso basato sull’identità (identity-aware) sul perimetro di Google (edge) per le app HTTPS e per il forwarding TCP (SSH/RDP), eliminando la necessità di esporre applicazioni o bastion host a Internet. Abbinarlo a policy di accesso contestuali (Access Context Manager) per richiedere una determinata postura del dispositivo, intervalli IP o gruppi di utenti.
  • Vantaggi: autenticazione e autorizzazione (authN/Z) centralizzate, forte attribuzione, superficie di attacco ridotta e policy firewall semplificata (negare il traffico in entrata ad eccezione del load balancer/IAP).
  • Compromessi: una configurazione errata può bloccare l’accesso agli amministratori; mantenere un percorso di emergenza (break-glass) (un proprietario del progetto con permessi limitati, accesso alla console fuori banda). Alcuni protocolli legacy o servizi non-HTTP potrebbero richiedere il forwarding TCP di IAP o controlli alternativi.

• Service account e workload identity

  • Preferire l’associazione di service account a Compute Engine, GKE con Workload Identity, Cloud Run e Cloud Functions in modo che i workload ottengano automaticamente token a breve termine. Evitare di incorporare le chiavi; disabilitare la creazione di chiavi per i service account tramite una Organization Policy. Limitare strettamente lo scope IAM sui service account (principio del privilegio minimo).
  • Modalità di fallimento: assegnare il ruolo roles/iam.serviceAccountUser in modo esteso, il che consente l’impersonificazione; service account con privilegi eccessivi che diventano bersagli per movimenti laterali.

Protezione dei Dati e Gestione delle Chiavi

• Crittografia, Cloud KMS, CMEK e envelope encryption
  • Google crittografa tutti i dati a riposo (at rest) e in transito (in transit) per impostazione predefinita. Per un controllo aggiuntivo e la separazione dei compiti (segregation-of-duty), utilizzare le Customer-Managed Encryption Keys (CMEK) in Cloud KMS. Molti servizi (BigQuery, Cloud Storage, Pub/Sub, dischi di Compute Engine) supportano le CMEK; i servizi utilizzano la envelope encryption, in cui la tua CMEK avvolge le DEK (Data Encryption Key) per oggetto o per blocco (chunk).

  • Pianificare la gerarchia delle chiavi: key ring per regione, chiavi crittografiche (crypto key) per dominio di dati e rotazione ogni 90-365 giorni in base al rischio. Esempio di rotazione:

undefined

• Controllo degli accessi: assegnare ai service account il ruolo Cloud KMS CryptoKey Encrypter/Decrypter solo sulle chiavi necessarie. Monitorare con i log di utilizzo di Cloud KMS.

• Modalità di fallimento e compromessi: disabilitare o eliminare una CMEK rende illeggibili i dati dipendenti; pianificare i runbook per gli incidenti, ricontrollare l’IAM prima della rotazione e mantenere la disponibilità delle chiavi tra i vari deployment. Considerare External Key Manager se è necessario conservare le chiavi al di fuori di Google Cloud; tenere conto della latenza aggiuntiva e del rischio di dipendenza esterna.

• Secret Manager ed eliminazione delle credenziali hard-coded

  • Archiviare chiavi API, password di database e token in Secret Manager con versioning automatico e accesso basato su IAM. Integrare la rotazione tramite Cloud Scheduler → Pub/Sub → Cloud Functions/Run, che aggiorna il sistema a monte (upstream) e scrive una nuova versione del segreto. Le applicazioni recuperano i segreti all’avvio o su richiesta e li memorizzano nella cache il meno possibile.
  • Best practice: non inserire mai (commit) segreti nel codice o nelle immagini; evitare di stampare segreti nei log; assegnare il ruolo roles/secretmanager.secretAccessor alle workload identity; usare le etichette (label) per contrassegnare la sensibilità.
  • Modalità di fallimento: incorporare segreti in variabili d’ambiente che vengono registrate nei log in caso di crash; dimenticare di aggiornare le applicazioni a valle (downstream) dopo la rotazione; permessi IAM troppo ampi sui segreti.

• Classificazione, conservazione e privacy dei dati

  • Classificare i dati (pubblici, interni, confidenziali, regolamentati) e contrassegnare gli asset con etichette (label). Utilizzare la sicurezza a livello di colonna (column-level security) e le policy di accesso a livello di riga (row access policies) di BigQuery per un controllo granulare. Per la scoperta (discovery) e il mascheramento (masking) dei dati, utilizzare Sensitive Data Protection (DLP).
  • Implementare la conservazione (retention): ciclo di vita degli oggetti di Cloud Storage (transizioni di classe basate sull’età, eliminazione), policy di conservazione dei bucket con blocchi (hold) e TTL per tabelle o partizioni di BigQuery. Allineare la conservazione alle esigenze legali; una conservazione più lunga aumenta il rischio e i costi.
  • Privacy e residenza dei dati: limitare le location delle risorse con le Organization Policy; scegliere tra storage multi-regionale e regionale in base ai requisiti di sovranità e latenza. Produrre evidenze con i log di audit e le dashboard sulla postura di sicurezza di SCC (Security Command Center).

Sicurezza della Rete e del Perimetro (Edge)

• Difesa in profondità per le reti

  • Utilizzare le regole firewall del VPC con un approccio di negazione predefinita (default deny); consentire solo gli intervalli di origine e le porte necessarie. Preferire Private Google Access e Private Service Connect per mantenere il traffico API fuori dalla rete internet pubblica. Registrare i VPC Flow Logs e i log delle regole firewall (Firewall Rules Logging); esaminare regolarmente i pattern di traffico in uscita (egress).
  • Per il controllo del traffico in uscita, negare tutto il traffico in uscita (deny-all egress) e poi consentire esplicitamente le destinazioni necessarie tramite un proxy di egress FQDN o NAT più proxy. Monitorare i log di Cloud NAT e configurare la registrazione DNS (DNS logging).

• VPC Service Controls (VPC SC), perimetri di servizio e livelli di accesso

  • Racchiudere le API Google supportate (ad esempio, BigQuery, Storage, Pub/Sub) in perimetri di servizio per mitigare i rischi di esfiltrazione dei dati, anche in caso di compromissione delle credenziali. Utilizzare Access Context Manager per definire i livelli di accesso per gruppo di utenti, IP o stato del dispositivo (device posture), abilitando policy sensibili al contesto (context-aware).
  • Configurare regole di uscita (egress rules) per integrazioni legittime tra perimetri e bridge di perimetro (perimeter bridges) quando necessario. Testare con la modalità di prova (dry-run) di VPC SC per individuare potenziali interruzioni prima dell’applicazione forzata.
  • Modalità di fallimento: blocco involontario di processi CI/CD o tra progetti diversi, fallimento di integrazioni di terze parti o sviluppatori che aggirano i controlli con dispositivi non gestiti. Documentare le eccezioni ed esaminarle regolarmente.

• Cloud Armor, protezione DDoS e regole WAF

  • L’edge globale di Google fornisce una protezione DDoS L3/L4 sempre attiva. Cloud Armor aggiunge protezioni L7 per i load balancer HTTP(S) esterni, includendo rate limiting, accesso basato su geolocalizzazione/IP, espressioni personalizzate e set di regole WAF preconfigurate.
  • Esempio per creare e associare un WAF di base:
    • gcloud compute security-policies create web-waf
    • gcloud compute security-policies rules create 1000 –security-policy=web-waf –expression=“evaluatePreconfiguredWaf(‘sqli-v33-stable’)” –action=deny-403 –preview
    • Associare la policy al servizio di backend del proprio load balancer HTTPS.
  • Best practice: avviare le regole in modalità di anteprima (preview) per ridurre i falsi positivi, aggiungere regole di autorizzazione (allow rules) per il traffico noto e affidabile, e abilitare la protezione adattiva (adaptive protection) se idonei. Compromessi: Cloud Armor si applica ai load balancer basati su proxy e HTTP(S); i network load balancer e i load balancer interni richiedono altri tipi di controlli.

Operazioni di sicurezza e conformità

• Security Command Center (SCC) e gestione della postura di sicurezza

  • Utilizzare SCC come piano di controllo per la visibilità dei rischi. Il livello Standard aggrega i risultati relativi a errori di configurazione e i dati sulle vulnerabilità; il livello Premium aggiunge il rilevamento delle minacce (ad esempio, Event Threat Detection, VM and Container Threat Detection) e insight sui percorsi di attacco.
  • Effettuare il triage dei risultati in base alla gravità, assegnare i responsabili e monitorare fino alla risoluzione. Esportare i risultati su BigQuery o Pub/Sub per l’integrazione con SIEM e la raccolta di prove. Misurare continuamente la postura rispetto alle policy dell’organizzazione e impostare avvisi sulle regressioni.

• Shielded VM, avvio protetto, vTPM, monitoraggio dell’integrità e hardening del sistema operativo

  • Abilitare le funzionalità di Shielded VM per bloccare rootkit e manomissioni in fase di avvio: Secure Boot, vTPM e Integrity Monitoring per rilevare modifiche nei bootloader e nel kernel. Alcuni kernel personalizzati o moduli non firmati potrebbero non superare il Secure Boot; convalidare le immagini prima dell’abilitazione.
  • Eseguire l’hardening del sistema operativo con OS Config per la conformità delle patch, baseline allineate a CIS, pacchetti minimi, SSH senza password e registrazione degli eventi sudo e di autenticazione. Preferire il forwarding TCP di IAP per SSH e limitare il traffico in entrata a 0.0.0.0/0.

• Logging forense, triage degli incidenti, contenimento e remediation

  • Logging per abilitare l’analisi forense: audit log di Admin Activity e Data Access, VPC Flow Logs, Firewall Rules Logging, log di Cloud DNS, log dei load balancer e log di accesso a Cloud KMS e Secret Manager. Esportare in un progetto di log centralizzato e su BigQuery con controlli di accesso e conservazione appropriati.
  • Playbook di triage e contenimento:
    • Convalidare gli indicatori con i risultati di SCC e i log correlati.
    • Contenere revocando i token sospetti, disabilitando i service account compromessi, aggiungendo regole firewall di tipo “deny” o isolando temporaneamente le istanze con i tag.
    • Preservare le prove: creare snapshot dei dischi, esportare i log, acquisire la memoria se necessario utilizzando strumenti approvati e registrare la catena di custodia.
    • Eseguire la remediation: ruotare segreti e chiavi, applicare patch alle vulnerabilità, ricostruire da immagini note e affidabili, aggiungere rilevamenti per prevenire recidive ed eseguire una revisione post-incidente per rafforzare i controlli.

Scenario pratico

Nimbus Finance esegue carichi di lavoro web e API dietro a load balancer HTTP(S) esterni, elabora dati regolamentati in BigQuery e Cloud Storage e consente agli ingegneri l’accesso amministrativo da remoto. Un recente esercizio di red-teaming ha dimostrato rischi di esfiltrazione di dati tramite credenziali compromesse e movimento laterale. Il team operativo deve rafforzare gli accessi, proteggere i dati e migliorare il rilevamento senza interrompere l’erogazione dei servizi.

1. Applicare OS Login con attribuzione degli amministratori

• Passaggi: Abilitare OS Login a livello di progetto; aggiungere compute.osAdminLogin al gruppo degli ingegneri; rimuovere le chiavi SSH a livello di progetto.
• Motivazione: Le chiavi SSH per utente e l’assegnazione di ruoli basata su IAM forniscono un’attribuzione chiara e una revoca semplice. L’eliminazione delle chiavi condivise riduce il movimento laterale.

2. Controllare l’accesso remoto con IAP e l’accesso sensibile al contesto

• Passaggi: Posizionare l’interfaccia di amministrazione dietro un load balancer HTTPS protetto da IAP; richiedere l’appartenenza al gruppo operativo e la conformità dell’IP/dispositivo aziendale tramite Access Context Manager.
• Motivazione: L’accesso zero-trust elimina l’esposizione pubblica e applica centralmente le condizioni di identità e dispositivo, riducendo il rischio di phishing e credential stuffing.

3. Implementare Cloud Armor WAF con applicazione graduale

• Passaggi: Creare una policy di Cloud Armor; abilitare le regole WAF preconfigurate per SQLi/XSS in modalità anteprima; aggiungere una regola di rate-limiting per /login; monitorare i log; quindi applicare.
• Motivazione: La modalità anteprima riduce i falsi positivi; i limiti di frequenza mirati contrastano il credential stuffing e i bot senza danneggiare il traffico legittimo.

4. Racchiudere i servizi dati in VPC Service Controls

• Passaggi: Creare un perimetro di servizio per i progetti BigQuery e Cloud Storage; definire regole di egress per i job di CI/CD e di analisi approvati; richiedere livelli di accesso basati su gruppo e rete.
• Motivazione: I perimetri mitigano l’esfiltrazione di dati effettuata con credenziali valide, limitando dove e come è possibile accedere ai dati protetti.

5. Applicare CMEK con Cloud KMS e pianificare la rotazione

• Passaggi: Creare key ring e chiavi di crittografia regionali per BigQuery e Storage; concedere solo ai service account il ruolo roles/cloudkms.cryptoKeyEncrypterDecrypter; impostare una pianificazione di rotazione di 180 giorni; monitorare i log di utilizzo delle chiavi.
• Motivazione: CMEK applica la separazione dei compiti e confini crittografici controllati; la rotazione limita il raggio d’azione di un’eventuale compromissione di una chiave.

6. Centralizzare i segreti con Secret Manager e automatizzare la rotazione

• Passaggi: Spostare i token del database e di terze parti in Secret Manager; concedere l’accesso con privilegi minimi ai carichi di lavoro; implementare un job Cloud Scheduler → Pub/Sub → Cloud Run per ruotare i segreti e creare nuove versioni.
• Motivazione: Elimina le credenziali hard-coded; il controllo delle versioni e l’automazione garantiscono una rotazione prevedibile e verificabile con tempi di inattività minimi.

7. Rafforzare la sicurezza degli host con Shielded VM e l’hardening del sistema operativo

• Passaggi: Abilitare Secure Boot, vTPM e Integrity Monitoring su tutte le istanze di Compute Engine; imporre l’uso di SSH senza password; utilizzare OS Config per applicare patch settimanalmente e le baseline CIS.
• Motivazione: Previene la manomissione a livello di avvio, rileva le deviazioni (drift) e riduce la superficie di attacco sui nodi di calcolo.

8. Aumentare l’osservabilità e la gestione della postura con SCC

• Passaggi: Abilitare SCC Premium in tutta l’organizzazione; configurare notifiche in tempo reale su Pub/Sub; esportare risultati e log su BigQuery; creare dashboard per i KPI principali (risultati aperti ad alta gravità, tempo medio di remediation).
• Motivazione: La visibilità unificata riduce i tempi di rilevamento e risposta e fornisce prove di conformità.

9. Preparare e testare un playbook per gli incidenti

• Passaggi: Documentare i passaggi di triage, gli account “break-glass” con privilegi e le azioni di contenimento (disabilitazione IAM, isolamento tramite firewall, revoca dei token); esercitarsi trimestralmente; applicare la conservazione dei log e i blocchi degli oggetti nel progetto delle prove.
• Motivazione: I flussi di lavoro testati riducono gli errori sotto pressione e preservano l’integrità forense per l’analisi delle cause principali e la reportistica normativa.

10. Convalidare le modifiche e minimizzare le interruzioni

• Passaggi: Utilizzare la modalità “dry run” di VPC SC e l’anteprima di Cloud Armor per rilevare problemi; effettuare il rollout per ambiente con canary; mantenere un piano di rollback e finestre di modifica.
• Motivazione: Un rollout controllato mitiga i rischi per la disponibilità derivanti da una maggiore sicurezza, ottenendo al contempo la riduzione mirata del rischio di esfiltrazione e di accesso.

← Monitoraggio · Tutti i domini · Affidabilità →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →