Firewall rule e hierarchical firewall policy

Le VPC firewall rule sono stateful e si valutano per priority (0-65535, il numero più basso vince). Il target non è mai un IP di destinazione ma un insieme di VM, selezionato tramite network tag oppure — scelta più sicura perché non falsificabile da chi crea l’istanza — tramite service account. Ogni VPC ha due implied rule invisibili: allow egress verso qualsiasi destinazione e deny ingress da qualsiasi origine, entrambe a priority 65535. Da qui la logica least-privilege: si aprono solo i flussi necessari e si può usare una deny esplicita a priority più alta per bloccare pattern specifici.

Le hierarchical firewall policy si applicano a livello di organization o folder e vengono valutate prima delle rule della singola VPC. Servono come guardrail preventivo centralizzato (es. bloccare RDP/SSH da Internet su tutta l’organizzazione) con action allow, deny o goto_next per delegare la decisione ai livelli inferiori. Sono il modo giusto per imporre baseline che i team di progetto non possono aggirare.

VPC Service Controls: il perimetro contro la data exfiltration

Il punto più frainteso dell’esame: VPC Service Controls non è un firewall di rete. Non filtra pacchetti IP; crea un service perimeter logico attorno alle managed API di Google (Cloud Storage, BigQuery, Cloud KMS…) per mitigare la data exfiltration. Impedisce, per esempio, che credenziali rubate vengano usate per copiare un bucket verso un progetto esterno al perimetro, anche se l’identità ha i permessi IAM.

I flussi che attraversano il confine si governano con ingress e egress rule (chi/quale identità, da/verso quale progetto e servizio). Gli access level, definiti in Access Context Manager, aggiungono condizioni contestuali come range IP aziendali o attributi del device. È buona pratica attivare prima il dry-run mode per osservare cosa verrebbe bloccato senza interrompere la produzione. VPC Service Controls e IAM sono complementari: IAM decide chi può, il perimetro decide da dove e verso dove i dati possono muoversi.

Traffico privato verso le API: Private Google Access e Private Service Connect

Una VM senza IP pubblico non raggiunge le API di Google a meno di abilitare Private Google Access sulla subnet: il traffico verso le API resta su rete interna. Con VPC Service Controls si instrada verso il VIP restricted.googleapis.com, che espone solo i servizi supportati dal perimetro (a differenza di private.googleapis.com, che li espone tutti). Occorre allineare le route e le private zone di Cloud DNS a questo VIP.

Private Service Connect va oltre: crea un private endpoint con un IP interno di tua proprietà per raggiungere le API Google o servizi pubblicati da terzi/altri progetti, utile quando serve un consumo privato con controllo granulare dell’indirizzamento ed evitare peering complessi.

Cloud NAT, DNS security e Shared VPC

Cloud NAT è un servizio regionale gestito che permette l’egress verso Internet a istanze prive di IP pubblico (aggiornamenti, repository esterni), senza aprire alcun ingress non sollecitato: riduce la superficie d’attacco eliminando gli IP pubblici. Non serve per raggiungere le API Google (quello è Private Google Access).

Sul DNS, Cloud DNS gestisce private zone e supporta DNSSEC per firmare le zone pubbliche e prevenire cache poisoning/spoofing. Le DNS policy abilitano il logging delle query (utile per rilevare esfiltrazione via DNS o beaconing malware) e i server name alternativi.

Shared VPC centralizza la rete in un host project; i service project vi si agganciano e consumano le subnet. La segmentazione avviene assegnando compute.networkUser a livello di singola subnet, così ogni team usa solo il segmento previsto mentre l’amministrazione di firewall e routing resta al team di rete: separazione dei compiti e superficie coerente.

Trappole tipiche d’esame

  • Bloccare la copia di dati BigQuery verso un progetto esterno pur avendo identità con IAM valido → soluzione: VPC Service Controls, non una firewall rule; il perimetro ferma l’esfiltrazione a livello di servizio, non di pacchetto.
  • VM senza IP pubblico che deve leggere pacchetti da un repository su Internet → soluzione: Cloud NAT (egress), NON Private Google Access, che serve solo per le API Google.
  • VM senza IP pubblico che deve chiamare Cloud Storage restando compatibile col perimetro → soluzione: Private Google Access instradato su restricted.googleapis.com, non private.googleapis.com.
  • Impedire a tutti i progetti SSH da Internet senza fidarsi dei team → soluzione: hierarchical firewall policy a livello di organization/folder (guardrail valutato prima delle rule VPC), non una rule per progetto.
  • Targeting firewall robusto contro istanze create da utenti non fidati → soluzione: target per service account invece che per network tag, che chiunque può auto-assegnarsi.
  • Rete centralizzata con team separati che usano ognuno il proprio segmento → soluzione: Shared VPC con compute.networkUser a livello di subnet; VPC peering non offre questa separazione dei compiti.