Google PCA: Sicurezza, compliance e architettura di protezione dei dati — Guida allo studio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fa parte della Google Professional Cloud Architect — 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 in Google Cloud si basano sui principi di responsabilità condivisa e difesa in profondità. Google protegge l’infrastruttura sottostante, mentre l’utente è responsabile della progettazione di identità, reti, applicazioni e gestione dei dati sicure. Adotta il modello Zero Trust come guida: non fidarti mai implicitamente della rete, verifica continuamente l’identità e il contesto e applica rigorosamente il principio del privilegio minimo (least privilege). Progetta assumendo una possibile compromissione (design for compromise): parti dal presupposto che le credenziali possano essere sottratte, gli endpoint sondati e i servizi interni utilizzati in modo improprio. Compensa con controlli multipli (preventivi, di rilevamento, di risposta), crittografia e gestione delle chiavi robuste, monitoraggio solido e una risposta agli incidenti ben collaudata.

I compromessi sono inevitabili. Controlli più stringenti possono aumentare la latenza, la complessità operativa e i costi. La tua architettura dovrebbe soppesare esplicitamente i rischi rispetto all’usabilità e alle prestazioni, preservando al contempo una conformità dimostrabile e la prontezza per le analisi forensi.

Architettura di Identità e Accesso

• Principi e modello

  • Privilegio minimo (least privilege) per impostazione predefinita: concedi il set minimo di autorizzazioni necessarie per completare un’attività e preferisci i ruoli predefiniti o personalizzati rispetto ai ruoli primitivi (Owner, Editor, Viewer).
  • Separazione dei compiti (separation of duties): suddividi i ruoli tra costruttori (CI/CD), addetti al deployment, operatori e addetti alla sicurezza. Utilizza account di emergenza (break-glass) con controlli e logging robusti per le situazioni critiche.
  • Applicazione del modello Zero Trust: utilizza l’accesso context-aware per verificare utente, dispositivo, posizione e rischio; richiedi una MFA forte; e valuta continuamente il contesto della sessione.
  • Organization Policy e IAM Deny: codifica i guardrail (ad esempio, vietando la creazione di chiavi per gli account di servizio, limitando la condivisione tra domini) e usa le deny policy per imporre confini non negoziabili.

• Implementazione di IAM e strategia per gli account di servizio

  • Stabilisci un modello di accesso basato sulla gerarchia: le cartelle (folder) riflettono le linee di business o gli ambienti (prod, non-prod); i progetti isolano il raggio d’impatto (blast radius) e la fatturazione; gli account di servizio (SA) rappresentano i carichi di lavoro (workload).
  • Un workload, un account di servizio: evita di condividere gli SA tra servizi non correlati. Associa le autorizzazioni all’ambito di deployment (progetto) e all’ambito della risorsa.
  • Preferisci credenziali a breve durata tramite Service Account Impersonation e Workload Identity Federation. Disabilita le chiavi degli account di servizio gestite dall’utente; se inevitabile, isolane l’uso, ruotale frequentemente e monitorale con i log di audit.
  • Usa gli Access Boundaries per limitare ciò a cui un SA impersonato può accedere al momento della richiesta (ad esempio, limitando i percorsi degli oggetti GCS), contenendo il raggio d’impatto anche in caso di uso improprio di un SA con privilegi elevati.
  • IAM condizionale: applica condizioni a livello di risorsa (ora, IP, attributi del principal) per limitare l’accesso. Esempio: nega l’accesso alla produzione tranne che dagli intervalli IP aziendali e durante le finestre di modifica (change window).

• Modalità di fallimento e compromessi

  • Ruoli con privilegi eccessivi (ad es., Editor a livello di progetto) aumentano il rischio; preferisci ruoli granulari e convalida tramite gli analizzatori di policy (policy analyzer).
  • La proliferazione di chiavi di account di servizio in CI/CD e script locali è un comune vettore di violazione; con l’impersonificazione, alcuni strumenti legacy potrebbero richiedere un adattamento.
  • Le policy di IAM Deny sono potenti ma possono essere difficili da diagnosticare; implementa e testa le modifiche in un ambiente non di produzione con esecuzioni di prova (dry run) esplicite.

Esempio (impersonificazione senza creare chiavi):

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

Protezione dei dati e crittografia

• Cloud KMS e modelli di gestione delle chiavi
  • La crittografia at-rest nativa è l’impostazione predefinita. Per un controllo aggiuntivo, utilizzare le Customer-Managed Encryption Keys (CMEK) con servizi come BigQuery, Cloud Storage, dischi di Compute Engine, Pub/Sub e volumi persistenti di GKE.
  • Progettare una gerarchia di chiavi per ambiente e dominio dei dati. Utilizzare keyring separati per ogni località e chiavi separate per ogni applicazione o set di dati per limitare il raggio d’impatto (blast radius).
  • Rotazione: abilitare la rotazione pianificata e deprecare gradualmente le versioni delle chiavi più vecchie con la crittografia envelope per le applicazioni. Convalidare la compatibilità dei consumer prima di aumentare la frequenza di rotazione.
  • External Key Manager (EKM) ed External Key Access (EKA) posizionano le chiavi al di fuori di Google Cloud per il controllo normativo. I compromessi includono una latenza aggiuntiva e la dipendenza dalla disponibilità di HSM esterni; pianificare le operazioni in modalità degradata.
  • Applicare il principio del privilegio minimo (least privilege) di IAM sulle CryptoKeys. Utilizzare i log di audit a livello di chiave come prova degli accessi.

Esempio (CMEK con rotazione):

undefined

undefined

• Crittografia a livello di applicazione

  • Utilizzare la crittografia envelope (ad esempio, Tink) per crittografare i campi sensibili a livello di applicazione, abilitando l’accesso selettivo e l’isolamento dei dati dei tenant. Derivare chiavi per-tenant per minimizzare l’impatto cross-tenant.
  • Convalidare l’integrità (AEAD) per prevenire la manomissione (tampering) e gli attacchi di tipo replay.

• Secret Manager e ciclo di vita dei segreti

  • Archiviare credenziali, token e chiavi API come segreti versionati; mai nelle immagini, in Git o nei metadati delle istanze. Concedere i permessi IAM a livello di segreto o di progetto al service account di runtime.
  • Rotazione: automatizzare utilizzando Cloud Functions/Cloud Run attivati da Pub/Sub per creare una nuova versione, aggiornare i dipendenti e revocare le versioni precedenti. Preferire la sostituzione delle password di database a lunga durata con l’autenticazione basata su IAM o con token a breve durata.
  • Sicurezza della configurazione: separare la configurazione non segreta (ConfigMap, variabili d’ambiente) dai segreti. Impedire l’esposizione dei segreti nei log e nei messaggi di errore.

Esempio (aggiungere una nuova versione del segreto):

undefined

• Hardening del calcolo e confidential computing
  • Shielded VMs: abilitare secure boot, vTPM e monitoraggio dell’integrità per proteggere da bootkit e rootkit. Applicare tramite policy dell’organizzazione e convalidare nelle pipeline di CI/CD.
  • Confidential VMs: la crittografia della memoria predefinita protegge i dati in uso con modifiche minime alla configurazione; valutare l’impatto sulle prestazioni per carichi di lavoro ad alto throughput e ad alta intensità di crittografia.
  • Immagini con hardening: partire da baseline ottimizzate da Google o con hardening CIS; gestire le patch con OS Config e disabilitare pacchetti e porte non necessari.

Sicurezza della rete e perimetrale (Edge)

• Segmentazione della rete e controllo dell’egress

  • Segmentare per livello (tier) e sensibilità utilizzando VPC, subnet e policy firewall gerarchiche separate. Combinare i tag firewall basati sull’identità con i vincoli service-to-service (ad esempio, GKE NetworkPolicy) per applicare controlli est-ovest.
  • Controllare l’egress con Cloud NAT, policy DNS e Private Google Access limitato per minimizzare l’esfiltrazione di dati. Utilizzare allowlist di egress esplicite e ispezione tramite proxy ove giustificato.

• VPC Service Controls (VPC SC)

  • Costruire perimetri di servizio attorno ai progetti che ospitano i dati in-scope per mitigare l’esfiltrazione dalle API gestite da Google (GCS, BigQuery, Secret Manager, Pub/Sub, ecc.).
  • Livelli di accesso: definire le condizioni di contesto (identità dell’utente, intervalli IP, stato del dispositivo) che devono essere soddisfatte per accedere ai servizi perimetrati.
  • Utilizzare i bridge di perimetro per flussi di lavoro multi-perimetro controllati e regole di egress per limitare le destinazioni. Testare con la modalità dry-run per evitare di interrompere le pipeline.
  • Limitazioni: non protegge direttamente il traffico verso gli IP di Compute Engine; integrare con controlli firewall e di egress. Alcuni strumenti e pattern ibridi possono richiedere service account consapevoli del perimetro e Private Service Connect verso VIP limitati.

• Protezione perimetrale (edge) e delle applicazioni

  • Cloud Armor: difendere le applicazioni HTTP(S) dietro il bilanciatore di carico esterno globale con mitigazione DDoS L3/L4/L7, liste di IP consentiti/negati (allow/deny list), controlli basati sulla geolocalizzazione e rate limiting.
  • Regole WAF: applicare regole gestite preconfigurate e firme personalizzate per OWASP Top 10; ottimizzare per ridurre i falsi positivi. Collegare per ogni backend service per personalizzare le policy in base alla versione dell’API o al componente dell’app.
  • Protezione delle API: esporre le API tramite API Gateway o Apigee per l’autenticazione, le quote, la convalida dello schema e il rilevamento delle minacce; integrare Cloud Armor per l’enforcement perimetrale; considerare reCAPTCHA Enterprise e i controlli anti-bot ove appropriato.
  • Compromessi: un’ispezione più approfondita può aggiungere latenza e rumore operativo. Mettere in staging le regole in modalità di anteprima (preview), monitorare i log e applicarle progressivamente.

Operazioni di Sicurezza, Monitoraggio e Conformità

• Security Command Center (SCC) e rilevamento delle minacce

  • SCC aggrega l’inventario degli asset e i risultati (finding) tra progetti e organizzazioni. Utilizzalo per definire una baseline della postura di sicurezza (bucket pubblici, regole firewall aperte), tracciare le deviazioni (drift) e guidare i flussi di lavoro di remediation.
  • Il rilevamento delle minacce Premium include Event Threat Detection, VM Threat Detection e Container Threat Detection per identificare malware, cryptomining e comportamenti anomali.
  • Integrare i risultati con le pipeline di ticketing e SOAR; definire policy di soppressione/eccezione con scadenza per evitare l’affaticamento da alert (alert fatigue).

• Sicurezza delle vulnerabilità e degli artefatti

  • Utilizzare Artifact Analysis per eseguire la scansione delle immagini dei container alla ricerca di CVE; applicare policy in fase di deployment con Binary Authorization e attestazioni firmate provenienti dalla CI.
  • Gestione delle patch tramite OS Config; monitorare le finestre di esposizione e automatizzare i rollout con canary.

• Log di audit, privacy e prove

  • I Cloud Audit Logs forniscono di default i log di Admin Activity e System Event; i log di Data Access possono essere abilitati per servizio e sono a pagamento. Instradare i log verso BigQuery per l’analisi e verso Cloud Storage per la conservazione immutabile e la conservazione a fini legali (legal hold).
  • Classificazione dei dati: utilizzare Cloud DLP per individuare e classificare le PII (Personally Identifiable Information), applicare etichette e tag e mappare a livelli di protezione (CMEK, VPC SC, Confidential VMs).
  • Privacy e residenza dei dati: limitare le location tramite policy dell’organizzazione; allineare le location di CMEK e dello storage con i requisiti normativi.
  • Conservazione a fini legali (legal hold) e retention: abilitare policy di retention e hold sui bucket; utilizzare l’Object Versioning dove necessario. Documentare la catena di custodia (chain of custody) per le immagini forensi e i log per produrre prove difendibili in giudizio.

• Risposta agli incidenti e preparazione forense

  • Preparare runbook, percorsi di accesso e automazione. Assicurarsi che i soccorritori (responder) abbiano accesso con il principio del privilegio minimo (least-privilege) e che l’audit sia abilitato a livello di organizzazione, cartelle e progetti.
  • Contenimento: isolare le istanze rimuovendole dai load balancer, applicando regole firewall di deny egress o spostando i progetti in policy dell’organizzazione più restrittive; disabilitare i service account compromessi e ruotare segreti e chiavi.
  • Analisi forense: creare snapshot dei dischi ed esportare le immagini per l’analisi offline; preservare i log tramite esportazioni. Utilizzare il packet mirroring dove applicabile. Evitare di modificare le prove; lavorare su copie.
  • Ripristino: ricostruire da immagini fidate, reidratare i segreti e convalidare con smoke test e test di sicurezza. Condurre revisioni post-incidente e integrare le lezioni apprese nei meccanismi di protezione (guardrail) e di rilevamento.

Scenario Pratico

NimbusPay, un’azienda SaaS fintech, deve elaborare dati classificati come PCI su microservizi multi-tenant in Google Cloud, applicare la residenza dei dati nell’UE, proteggersi da attacchi a livello di API e produrre prove verificabili dei controlli. L’azienda implementerà una nuova API v2 mantenendo attiva la v1 sotto lo stesso hostname.

Approccio:

1. Partizionare progetti e identità

• Creare progetti separati per ambiente e per livello di microservizio (ingestione, elaborazione, reporting). Assegnare un service account di workload univoco per ogni servizio. Razionale: isola il raggio d’impatto (blast radius) e mappa il principio del privilegio minimo a workload discreti.

2. Applicare Zero Trust e privilegio minimo

• Concedere ruoli predefiniti/personalizzati ai service account e ai gruppi DevOps; applicare IAM condizionale per limitare l’accesso alla produzione agli IP e agli orari aziendali. Razionale: riduce i movimenti laterali e le modifiche accidentali.

3. Rimuovere le chiavi statiche dei service account

• Disabilitare le chiavi SA gestite dall’utente tramite policy dell’organizzazione. Usare l’impersonificazione del Service Account (Service Account Impersonation) per CI/CD e operazioni; applicare Access Boundaries per limitare i percorsi GCS per tenant. Razionale: elimina un vettore frequente di fuga di credenziali e limita l’accesso ai dati anche in caso di furto dei token.

4. Proteggere i dati con CMEK e controlli regionali

• Creare keyring e chiavi di Cloud KMS nelle region europe-west; abilitare CMEK per i set di dati BigQuery, i bucket GCS e i Persistent Disk. Configurare la rotazione pianificata e il monitoraggio delle versioni. Razionale: controllo crittografico dimostrabile, allineato alla residenza UE e ai requisiti PCI.

5. Adottare la crittografia a livello di applicazione per i dati delle carte

• Utilizzare la crittografia envelope (Tink AEAD) con chiavi dati per-tenant sottoposte a wrapping da CMEK; archiviare solo il testo cifrato (ciphertext) nei database. Razionale: protezione a livello di campo e ambito ridotto durante il triage degli incidenti.

6. Centralizzare i segreti e ruotarli automaticamente

• Archiviare le credenziali del DB e i token API in Secret Manager con IAM per-servizio. Implementare job di rotazione attivati da Pub/Sub che creano nuove versioni e aggiornano i deployment. Dove possibile, passare all’autenticazione IAM DB per Cloud SQL. Razionale: ciclo di vita dei segreti verificabile con tempi di inattività minimi.

7. Segmentare le reti e controllare il traffico in uscita (egress)

• Utilizzare policy firewall gerarchiche per forzare i flussi web→API→DB; negare direttamente il flusso web→DB. Abilitare Cloud NAT con allowlist in uscita e Private Google Access (restricted) per le API di Google. Razionale: limita i movimenti est-ovest e blocca l’esfiltrazione non autorizzata.

8. Racchiudere i servizi dati con VPC Service Controls

• Inserire i progetti BigQuery, GCS e Secret Manager in un perimetro di servizio; definire livelli di accesso che richiedono IP aziendali e dispositivi gestiti. Testare con la modalità dry-run, quindi applicare. Razionale: mitiga l’esfiltrazione di dati tramite token rubati o client mal configurati.

9. Mettere in sicurezza l’edge e le API

• Proteggere il load balancer HTTPS globale con le regole gestite e il rate limiting di Cloud Armor. Usare il routing basato su percorso (path-based routing) per separare /v1 e /v2 verso servizi di backend distinti e applicare policy WAF personalizzate per versione. Integrare Apigee per l’autenticazione, le quote e la validazione dello schema. Razionale: protezione API a più livelli, transizione fluida da v1 a v2 e minimizzazione dei falsi positivi.

10. Rafforzare (harden) il compute e attestare gli artefatti

• Abilitare Shielded VM e Confidential VM per i nodi di elaborazione; adottare immagini di base con hardening CIS. Scansionare le immagini in Artifact Registry, richiedere attestazioni firmate con Binary Authorization per GKE. Razionale: protegge la catena di avvio (boot chain) e i dati in uso, e impone la fiducia nella supply-chain.

11. Monitorare la postura e le minacce con SCC

• Abilitare SCC Premium per rilevare configurazioni rischiose e minacce a runtime; integrare con il sistema di ticketing per gli SLA. Sopprimere i rischi accettati con date di scadenza. Razionale: garanzia continua e segnali utilizzabili (actionable).

12. Registrare, conservare e produrre prove

• Instradare i log di Admin Activity, Data Access e VPC Flow Log verso BigQuery e Cloud Storage con policy di retention e conservazione a fini legali (legal hold). Taggare i set di dati con etichette di residenza e sensibilità. Razionale: supporta le indagini e gli audit esterni con accesso limitato (scoped).

13. Preparare la risposta agli incidenti e l’analisi forense

• Creare runbook per isolare i servizi compromessi spostando i progetti in una cartella di quarantena con policy più restrittive, disabilitando i SA implicati e creando snapshot dei dischi per l’analisi offline. Razionale: contenimento rapido con conservazione delle prove.

Comandi brevi a supporto del rollout:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

Con questi passaggi, NimbusPay ottiene una protezione a più livelli (identità, crittografia, rete ed edge), una conformità verificabile, un’evoluzione controllata delle API sotto un unico hostname e la prontezza per rilevare, contenere e ripristinare gli incidenti.

← Networking · Tutti i domini · Affidabilità →

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

Sfoglia Google →