IAM, connettività e controllo degli accessi

Su Cloud SQL, AlloyDB e Spanner l’accesso si governa su due piani distinti che l’esame ama sovrapporre. Il primo è il control plane: chi può creare, configurare, avviare failover o gestire l’istanza. Questo è dominio di IAM, tramite ruoli come roles/cloudsql.admin, cloudsql.editor e cloudsql.viewer, assegnati secondo il principio del least privilege e preferibilmente a gruppi, non a singoli utenti. Il secondo piano è il data plane: chi si connette al database e con quali privilegi sulle tabelle.

Sulla connettività, la scelta di design tipica è tra private IP (via VPC private services access, nessuna esposizione a Internet) e public IP con autorizzazione degli indirizzi o, meglio, con Cloud SQL Auth Proxy, che gestisce TLS e autenticazione IAM senza aprire reti. Per scenari zero-trust il private IP + Auth Proxy è la risposta corretta; l’authorized networks su public IP è quasi sempre la trappola “veloce ma insicura”.

Autenticazione utenti: IAM vs built-in

Il servizio distingue due modelli. Gli utenti built-in (username/password gestiti dal motore MySQL/PostgreSQL/SQL Server) sono semplici ma richiedono rotazione manuale delle credenziali e non si integrano con l’identità aziendale. La IAM database authentication consente invece a user e service account Google di autenticarsi con credenziali IAM (token a vita breve), centralizzando l’identità, abilitando MFA a monte e riducendo le password statiche. La regola pratica: se lo scenario chiede audit centralizzato, service account per le applicazioni o eliminazione delle password long-lived, si sceglie IAM authentication. Attenzione però: IAM authentication autentica l’identità, ma i privilegi sugli oggetti (GRANT su tabelle/schemi) restano responsabilità dell’amministratore del database. Concedere il ruolo IAM non dà da solo accesso ai dati.

Monitoraggio e troubleshooting

La diagnostica parte dai vitals: CPU, memoria, storage e disk I/O esposti in Cloud Monitoring. Segnali tipici e loro lettura: CPU costantemente alta indica query non ottimizzate o istanza sottodimensionata (scale up); storage vicino al limite rischia il blocco delle scritture (attivare l’automatic storage increase); IOPS saturi segnalano contention sul disco. Per le query lente lo strumento d’elezione è Query Insights (Cloud SQL PostgreSQL/MySQL e AlloyDB), che individua le query costose, i wait event e i piani problematici; da lì si valutano indici mancanti o mal disegnati. Il database locking e la resource contention si diagnosticano dai wait event e dalle sessioni bloccanti, non aumentando la RAM.

Sul fronte scalabilità, va tenuta ferma la distinzione fondamentale: una read replica scala le letture e serve per offloadare reporting o traffico read-heavy, ma per default non promuove automaticamente lo scrittore in caso di guasto. L’high availability di Cloud SQL è invece una configurazione regionale con failover replica in un’altra zona, che subentra automaticamente al primary. Read replica ≠ HA: confonderle è la trappola classica.

Alert, quote e audit logging

Gli alerting policies in Cloud Monitoring vanno impostati sia sulle metriche di performance (CPU, memoria, storage %, replication lag) sia sugli errori e sulla disponibilità, con notification channel appropriati. Il replication lag merita un alert dedicato: una replica troppo indietro serve dati stale e, se promossa, causa perdita di dati. Le quote (connessioni, API) vanno monitorate perché il loro esaurimento produce errori applicativi diagnosticabili solo se osservati. L’audit logging (Cloud Audit Logs: Admin Activity sempre attivo, Data Access da abilitare) e i pgAudit/audit plugin del motore soddisfano i requisiti di compliance registrando chi ha fatto cosa.

Trappole tipiche d’esame

  • Connessione sicura senza esporre reti → private IP + Cloud SQL Auth Proxy: authorized networks su public IP sembra sufficiente ma resta esposto; è la scelta sbagliata negli scenari zero-trust.
  • Failover automatico dello scrittore → configurazione HA con failover replica, NON read replica: la read replica scala le letture e va promossa manualmente; non sostituisce l’HA.
  • Eliminare password statiche e centralizzare l’identità → IAM database authentication: ma ricorda che i GRANT sugli oggetti restano a carico dell’admin del DB.
  • Query lenta e CPU alta → Query Insights + indici, non subito scale up: aumentare la macchina maschera il problema; prima si analizza il piano e la mancanza di indici.
  • Ruolo IAM concesso ma “accesso negato” ai dati → mancano i privilegi a livello di database: IAM autentica, ma l’autorizzazione sugli oggetti è separata.
  • Replica promossa che perde dati → monitorare e allertare sul replication lag: una replica in ritardo promossa serve dati stale; l’alert sul lag è la salvaguardia.