Difesa in profondità della rete

La sicurezza di rete su Google Cloud si costruisce a strati e ogni strato risponde a una minaccia diversa: confondere i livelli è l’errore classico d’esame. Il primo livello è il firewall della VPC: regole stateful basate su priorità, service account o network tag, che controllano il traffico nord-sud e est-ovest tra istanze. Preferisci le regole basate su service account rispetto a quelle su tag, perché i tag sono modificabili da chi ha compute.instances.setTags e quindi meno robuste. Sopra il firewall, Cloud Armor agisce al bordo, integrato con l’External HTTP(S) Load Balancer: fornisce WAF (regole preconfigurate contro OWASP Top 10, come SQLi e XSS), rate limiting, geo-blocking e mitigazione DDoS L3/L7. Cloud Armor protegge applicazioni esposte a Internet; non è un controllo interno né sostituisce il firewall.

Per l’accesso alle API Google senza esporre le VM a Internet usi Private Google Access (istanze con solo IP privato che raggiungono storage.googleapis.com, BigQuery, ecc.) o Private Service Connect per endpoint privati verso servizi gestiti. Quando invece serve traffico in uscita verso Internet da istanze senza IP pubblico (es. per patch o webhook), usi Cloud NAT: managed, senza gestire NAT gateway, e non consente connessioni entranti non richieste.

VPC Service Controls: il perimetro anti-esfiltrazione

Questo è il concetto più frainteso. VPC Service Controls non è un firewall: definisce un service perimeter attorno alle API dei servizi gestiti (Cloud Storage, BigQuery, Cloud SQL) per impedire l’esfiltrazione dei dati. Anche se un attore ha credenziali IAM valide, non può copiare un bucket verso un progetto esterno al perimetro. Se lo scenario parla di “credenziali compromesse ma i dati non devono uscire”, “isolare BigQuery dall’accesso da Internet” o “prevenire l’esfiltrazione verso progetti non autorizzati”, la risposta è VPC Service Controls, non le firewall rules né IAM da solo. Gli access levels (Access Context Manager) affinano l’ingresso in base a IP, dispositivo o identità, e i ingress/egress rules gestiscono le eccezioni controllate tra perimetri.

Protezione dei dati: encryption, key management e DLP

Tutti i dati at-rest su Google Cloud sono cifrati di default con chiavi gestite da Google, senza configurazione. Il passo successivo, richiesto per compliance o separazione dei doveri, sono le CMEK (customer-managed encryption keys) create in Cloud KMS: mantieni il controllo su rotazione, disabilitazione e revoca della chiave (disabilitare la chiave rende i dati inaccessibili, utile come kill switch). Per il massimo controllo, Cloud EKM consente chiavi ospitate esternamente presso un key manager di terze parti, e Cloud HSM offre chiavi in moduli FIPS 140-2 Level 3. Non confondere CMEK (tu gestisci la chiave, Google la usa) con CSEK né con la cifratura a livello applicativo.

Per secret applicativi (password, API key, connection string) usa Secret Manager, non variabili d’ambiente in chiaro né file nel repository; supporta versioning, rotazione e IAM granulare. Per scoprire e mascherare dati sensibili (PII, carte di credito, codici fiscali) in storage o stream usi Sensitive Data Protection (Cloud DLP): classification, de-identification, tokenization e redaction. Sul fronte governance, Security Command Center è la piattaforma centrale di security posture, vulnerability e threat detection a livello di organizzazione, mentre la data residency si ottiene scegliendo region specifiche e vincolando le risorse con Organization Policy (es. constraints/gcp.resourceLocations).

Trappole tipiche d’esame

  • Credenziali IAM valide ma i dati non devono uscire dall’organizzazione → VPC Service Controls: IAM autentica e autorizza, ma non ferma l’esfiltrazione; solo il service perimeter isola le API dei servizi gestiti.
  • Bloccare SQL injection e attacchi DDoS su un’app web esposta → Cloud Armor: agisce al bordo sul Load Balancer con WAF e rate limiting; le firewall rules operano a un altro livello e non ispezionano L7.
  • VM senza IP pubblico che devono chiamare Cloud Storage e BigQuery → Private Google Access: per traffico in uscita verso Internet serve invece Cloud NAT; non confondere i due.
  • Requisito di controllo e revoca sulle chiavi di cifratura → CMEK con Cloud KMS: la default encryption non basta se la compliance impone key ownership; per key store esterno valuta Cloud EKM.
  • Data residency in una region UE → Organization Policy resource locations: non basta creare risorse “in Europa”; il vincolo va imposto a livello di policy, non lasciato alla scelta manuale.
  • Individuare e mascherare PII in dataset e stream → Sensitive Data Protection (DLP): Secret Manager serve per i secret applicativi, non per scansionare dati sensibili già archiviati.