Networking: come esporre il database in modo privato

La prima decisione di design riguarda come le applicazioni raggiungono il database. Per Cloud SQL e AlloyDB la scelta di default sicura è il private IP: l’istanza riceve un indirizzo interno raggiungibile dalla VPC, senza esposizione su Internet. Il meccanismo classico è il private services access (PSA), basato su VPC peering: si alloca un range IP dedicato (allocated range) e Google crea il peering verso la rete gestita del servizio. Funziona bene, ma il peering è non-transitivo: reti raggiungibili solo via un’altra VPC peered o un hub Network Connectivity non “vedono” l’istanza.

Quando serve superare questo limite, o quando si vuole disaccoppiare il consumer dal range del producer, la risposta è Private Service Connect (PSC): espone il database dietro un endpoint (un IP nella VPC del consumer) e supporta scenari cross-VPC/cross-project più puliti, evitando conflitti di CIDR tipici del peering. In sintesi: PSA per il caso standard single-VPC, PSC quando la topologia è complessa o multi-tenant. Il public IP va evitato in produzione; se inevitabile, va accompagnato da authorized networks e SSL/TLS obbligatorio.

Encryption e key management: GMEK vs CMEK

Tutti i dati at-rest sui managed database sono cifrati per default con chiavi gestite da Google (GMEK, Google-managed encryption keys): nessuna configurazione, nessun controllo sul ciclo di vita. Quando la compliance richiede che il cliente possieda e controlli la chiave, si passa a CMEK (customer-managed encryption keys) tramite Cloud KMS: la chiave vive in un key ring, con rotazione, disabilitazione e revoca sotto il tuo controllo.

Il trade-off da ricordare per l’esame: con CMEK se disabiliti o distruggi la chiave, l’istanza diventa inaccessibile (di fatto un kill-switch, utile per data-residency ma pericoloso). La chiave KMS deve essere regionale e nella stessa region della risorsa da cifrare, e occorre concedere il ruolo di encrypt/decrypt alla service account del servizio. Per requisiti hardware-backed esiste Cloud HSM; per chiavi generate esternamente Cloud EKM. CMEK va deciso alla creazione dell’istanza: non è un flag che si abilita retroattivamente su un database esistente.

Accesso sicuro: Auth Proxy e IAM database authentication

Per le connessioni applicative il pattern raccomandato è il Cloud SQL Auth Proxy (e l’equivalente AlloyDB Auth Proxy): un componente che stabilisce un tunnel cifrato TLS verso l’istanza senza dover gestire certificati manualmente né aprire authorized networks. L’autorizzazione a connettersi passa da IAM (ruolo Cloud SQL Client), quindi il controllo di chi può aprire la connessione è centralizzato.

Da non confondere: una cosa è l’accesso alla connessione, un’altra è l’autenticazione dentro il database. Con la IAM database authentication l’utente/service account si autentica al DB usando la propria identità IAM e un token OAuth2 a vita breve invece di una password statica: meno segreti da ruotare, audit centralizzato. Resta comunque possibile la built-in authentication (utente/password nativi) per casi legacy. Auth Proxy e IAM database auth sono complementari, non alternativi.

Connection pooling: quando molte connessioni saturano il DB

PostgreSQL e MySQL soffrono quando migliaia di connessioni (tipico di serverless/microservizi) esauriscono memoria e slot: ogni connessione costa risorse. La soluzione non è scalare la macchina, ma mettere un pooler davanti. Opzioni: PgBouncer self-managed, oppure il managed connection pooling (AlloyDB e Cloud SQL for PostgreSQL offrono pooling gestito, che evita di operare PgBouncer manualmente). Il pooler multiplexa poche connessioni fisiche verso il DB su molte connessioni client. Attenzione ai pool mode: in transaction pooling non sono garantite feature session-level (prepared statement, advisory lock, SET di sessione).

Auditing: tracciare accessi e operazioni

Per la governance dei managed database ci si appoggia a Cloud Audit Logs: gli Admin Activity logs (sempre attivi, gratuiti) registrano le operazioni amministrative sull’istanza; i Data Access logs vanno abilitati esplicitamente e catturano letture/scritture a livello di piano dati. In più, i database audit plugin/flag (es. pgAudit per PostgreSQL) registrano le query dentro il motore. Per compliance è la combinazione Cloud Audit Logs + audit del motore a dare la copertura completa.

Trappole tipiche d’esame

  • Serve connettività cross-VPC/cross-project senza conflitti di CIDR → Private Service Connect: il private services access (VPC peering) è non-transitivo e vincola i range; PSC con endpoint nella VPC del consumer risolve il caso multi-VPC.
  • Il cliente deve poter revocare/distruggere la chiave per compliance → CMEK con Cloud KMS: GMEK non dà controllo sul ciclo di vita; ricorda che disabilitare la chiave rende l’istanza inaccessibile, ed è una scelta da fare alla creazione.
  • Troppi certificati/authorized networks da gestire per l’accesso app → Cloud SQL Auth Proxy + IAM: fornisce TLS e autorizzazione IAM senza gestione manuale dei certificati; non confonderlo con l’autenticazione interna al DB.
  • Eliminare le password statiche degli account applicativi → IAM database authentication: token OAuth2 a vita breve legati all’identità IAM; è distinta dall’Auth Proxy, che governa solo l’apertura della connessione.
  • Migliaia di connessioni serverless saturano PostgreSQL → connection pooling (managed pooling o PgBouncer): scalare la macchina non risolve; il pooler multiplexa le connessioni, ma il transaction pooling limita le feature session-level.
  • Requisito di tracciare le letture sui dati → abilitare i Data Access audit logs: gli Admin Activity logs sono sempre attivi ma coprono solo le operazioni amministrative; le letture/scritture di dati richiedono abilitazione esplicita, integrata da pgAudit nel motore.