Google PCD: Identità, autenticazione e sicurezza delle applicazioni — Guida allo studio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Panoramica

L’identità è il nuovo perimetro su Google Cloud. Le applicazioni devono autenticare i principali (utenti, servizi) e autorizzarli per un accesso ai dati e alle API basato sul principio del privilegio minimo (least-privilege), proteggendo al contempo segreti, chiavi e la catena di fornitura del software (software supply chain). Questa sezione delinea pratiche operative e di progettazione end-to-end che combinano Google Cloud IAM, protocolli di autenticazione moderni, difese a livello di rete e API, crittografia, logging e processi di risposta. L’enfasi è posta su credenziali a breve termine, policy centralizzate e controlli stratificati che garantiscano un fail-safe.

Identità, Autenticazione e Controllo degli Accessi

Ruoli IAM e account di servizio
- Utilizzare la gerarchia delle risorse (organizzazione > cartella > progetto) e i ruoli predefiniti rispetto ai ruoli primitivi. Preferire i ruoli personalizzati solo quando quelli predefiniti sono troppo ampi.
- Assegnare account di servizio (SA) ai workload. Non riutilizzare gli SA di default di Compute Engine o App Engine. Un SA per ogni confine di workload semplifica il principio del privilegio minimo e la rotazione della fiducia (rotation of trust).
- Applicare il principio del privilegio minimo concedendo il set minimo di autorizzazioni all’ambito di risorsa più ristretto.
- Impersonificazione: Preferire credenziali a breve termine tramite Service Account Token Creator per consentire a persone, sistemi CI/CD o altri servizi di ottenere un accesso effimero senza archiviare chiavi:
  - Concedere il ruolo roles/iam.serviceAccountTokenCreator sull’SA di destinazione all’identità chiamante.
  - Esempio:

undefined

Workload Identity
- GKE: Usare Workload Identity per associare gli account di servizio Kubernetes agli account di servizio Google; i token vengono proiettati e scambiati automaticamente, senza chiavi JSON.
- Workload esterni: Usare Workload Identity Federation per scambiare credenziali OIDC/SAML (ad esempio, da GitHub Actions o on-premise) con token di accesso Google senza archiviare chiavi a lunga durata.
Modalità di fallimento e compromessi
- Ruoli troppo ampi o concessioni con ambito esteso portano a movimenti laterali. La mancanza dei privilegi di Token Creator blocca i flussi di impersonificazione. I file di chiavi JSON aumentano il raggio d’impatto di una violazione (blast radius).
Autenticazione utente con OAuth 2.0, OpenID Connect e Google Identity
- Per l’autenticazione dell’utente finale, usare OIDC con Google come IdP o un IdP aziendale; validare gli ID token lato server. Per l’accesso alle API, usare token di accesso OAuth 2.0 con gli scope appropriati.
- Validare i token: verificare iss, aud, exp, iat e la firma utilizzando i JWK dell’IdP; mettere in cache i JWK e imporre la rotazione delle chiavi.
- Per i backend di applicazioni mobile/SPA, favorire il flusso Authorization Code con PKCE. Evitare i flussi impliciti.
- Per la comunicazione da servizio a servizio, usare il flusso JWT per Service Account di OAuth 2.0 o mTLS; evitare chiavi API statiche.
- Esempio (impersonificazione di token con gcloud):

undefined

Modalità di fallimento
- La mancata validazione di aud/iss consente la confusione di token (token confusion). Accettare token scaduti o non effettuare la rotazione dei JWK aumenta il rischio. L’uso di token di aggiornamento (refresh token) nelle app mobili espone credenziali a lunga durata.
Identity-Aware Proxy (IAP) per l’accesso via browser
- Usare IAP per esporre applicazioni HTTP su Cloud Run, GKE o Compute Engine senza integrare la logica di autenticazione. Imporre il ruolo “IAP-secured Web App User” per l’accesso.
- Le applicazioni ricevono un header firmato (x-goog-iap-jwt-assertion). Verificare il JWT per avere certezza dell’identità e dell’email dell’utente; non fare affidamento su X-Forwarded-* per l’autenticazione.
- Errori comuni: percorsi di bypass non instradati tramite IAP, firewall del backend configurato in modo errato, o fidarsi degli header IP del client senza l’integrità garantita da Cloud Load Balancing.

Segreti, Chiavi e Crittografia

Secret Manager
- Archiviare chiavi API, password di database e segreti dei webhook in Secret Manager. Fare affidamento sul controllo delle versioni (versioning), sui controlli IAM e sui log di audit.
- Pattern di accesso
  - Recuperare all’avvio e memorizzare nella cache in-memory; aggiornare su segnali di modifica del segreto (notifiche Pub/Sub).
  - Evitare di integrare i segreti nelle immagini o nelle variabili d’ambiente. Se si usano variabili d’ambiente, assicurarsi che non vengano mai registrate nei log o incluse nei report di crash.
- Rotazione
  - Automatizzare con Cloud Scheduler + Cloud Functions/Run per creare nuove versioni, aggiornare i componenti dipendenti e deprecare quelle obsolete.
  - Esempio:

undefined

Modalità di fallimento
- Chiamate eccessive a Secret Manager per richiesta aggiungono latenza e rischiano di esaurire la quota. La mancanza del ruolo roles/secretAccessor causa errori 403 a runtime.
Cloud KMS e crittografia a livello di applicazione
- Usare la crittografia a busta (envelope encryption): una chiave di crittografia dei dati (DEK) generata localmente crittografa i dati; una chiave gestita dal cliente (CMEK) in Cloud KMS crittografa la DEK (la CMEK funge da KEK).
- Effettuare regolarmente la rotazione delle chiavi; pianificare la ri-crittografia. Preferire l’approccio “decrittografa con la vecchia, crittografa con la nuova” in fase di scrittura; i job di ri-crittografia massiva per i dati at-rest sono più costosi.
- Abilitare le CMEK per i servizi (BigQuery, GCS, Pub/Sub, Cloud SQL, ecc.) quando richiesto dalla compliance. Mantenere le chiavi KMS nella stessa region dei dati.
- Esempio CLI:
  - Crittografia:

undefined

- Decrittografia:

undefined

Usare librerie crittografiche ben collaudate (ad esempio, Tink) per evitare errori di implementazione.
Modalità di fallimento
- Disallineamenti di region impediscono l’uso delle CMEK. La decrittografia KMS per richiesta aggiunge latenza; memorizzare le DEK nella cache in-memory, tenendo conto della loro rotazione. La mancanza del ruolo roles/cloudkms.cryptoKeyEncrypterDecrypter genera errori 403.

Autorizzazione, API e sicurezza perimetrale

Autorizzazione delle applicazioni
- Controlli basati sui ruoli (role-based): semplici, veloci, ma poco granulari. Il controllo degli accessi basato su attributi (ABAC) utilizza attributi dell’utente, attributi della risorsa e contesto (orario, stato del dispositivo) per decisioni a grana fine.
- Centralizzare la valutazione delle policy o usare un sidecar/OPA; propagare in modo coerente le attestazioni (claim) di identità e tenant attraverso i microservizi.
- Pattern di multi-tenancy
  - Incorporare il tenant_id nei token di autenticazione e applicarlo in ogni percorso di accesso ai dati; utilizzare il filtraggio a livello di riga o dataset separati per tenant per un isolamento rigoroso.
  - Considerare account di servizio o chiavi KMS per-tenant se è richiesto un isolamento normativo.
- Modalità di fallimento
  - Insecure direct object references (IDOR) dovuti a controlli mancanti sul tenant. Logica di autorizzazione divergente tra i servizi che causa un’applicazione incoerente.
Progettazione sicura delle API
- Convalidare e normalizzare tutti gli input; rifiutare payload di dimensioni eccessive. Applicare content type restrittivi. Eseguire il threat modeling per gli upload di file; usare URL firmate (signed URL) per oggetti di grandi dimensioni.
- Rate limiting e quote: usare il rate limiting di Cloud Armor o Apigee per mitigare abusi e errori 429. Implementare l’exponential backoff con jitter sui client.
- CORS
  - Restituire valori minimi per Access-Control-Allow-*; evitare origin wildcard nelle richieste con credenziali. La cache preflight riduce la latenza.
- Difese da CSRF
  - Preferire API stateless con bearer token negli header Authorization. Per sessioni basate su cookie, usare SameSite=strict o lax, cookie sicuri e un token CSRF (double-submit o synchronizer).
- Esempio (regola di Cloud Armor):
  - gcloud compute security-policies rules create 1000 –security-policy web-policy –expression “request.path.matches(’/api/’)” –action rate_based_ban –rate-limit-threshold-count 100 –rate-limit-threshold-interval-sec 60
- Modalità di fallimento
  - Un rate limiting ingenuo basato su IP può essere aggirato con IPv6 o proxy. Un CORS eccessivamente permissivo consente la fuga di token (token leakage). La mancanza di token CSRF con i cookie permette il session riding.
Controlli di rete e perimetro dei dati
- Utilizzare policy firewall gerarchiche e regole firewall VPC; consentire gli health check dei Google Front End quando si è dietro a un HTTP(S) Load Balancing.
- Esempio:
  - gcloud compute firewall-rules create allow-lb –network prod –allow tcp:80,tcp:443 –source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
- Cloud Armor fornisce WAF, difesa dai bot e restrizioni geografiche/IP; ottimizzare le regole e revisionare i falsi positivi.
- Private Service Access fornisce connettività IP privata ai servizi gestiti da Google (ad esempio, Cloud SQL, Memorystore); evitare l’egress pubblico e le allowlist di IP.
- VPC Service Controls riduce il rischio di esfiltrazione dei dati creando perimetri attorno ai servizi supportati; combinarlo con Access Context Manager per il contesto di dispositivo/posizione.
- Modalità di fallimento
  - Perimetri configurati in modo errato bloccano la CI/CD o interrompono le chiamate tra servizi. Allocazioni PSA mancanti impediscono la connessione di IP privati. Regole WAF eccessivamente restrittive possono causare incidenti di disponibilità.